yeah glue isn't starting at all

as near as I can tell.. appshell will use BROWSER_CHROME_URL for any generic request for a browser window but that is NOT where the designated main window is spawned from that like the toolkit pref is also supposed to be in clh code somewhere

but yeah suite glue needs turned into a jsm component

but today has given me ideas to test in my example application cause well smaller test case

seamonkey works the same

Bug 1770237 made js xpcom component registration not possible

So I will need to minimum do a suite version of Thunderbird's Bug 1562313

basically part 1 plus editor/ui

which is why those should be ifdef'd off along with mailnews lol

well hopefully NOW I will get a shit load of js errors instead of nothing

and I do but it may be because it is a jsm not an esmodule now

cause everywhere else all commandline handlers are esmodules

well that was a fun exploration.. learned a lot i dunno rewriting all this javascript is the hardest bitch of such an endevor and I am not currently qualified to do it

I mean I know WHAT to do just not exactly HOW to do it if that makes sense.

anyway as for the python on fedora thing.. if I can find where on the filesystem it stores modules I can just slide six in

then it would work i suspect for git release

In the morning I will reapply the c-c patches and start again.. This time adding an alternative main window so I have something to work from that is running

and use the toolkit default command line handler

Then I can at least spawn some windows and maybe get devtools working

I doubt DOMi will

MattATobin: For "six" under Fedora-39 it seems you need python3-six-1.16.0-12.fc39.noarch .

Anyway, there is a "BuildRequires" statements in src.fedoraproject.org/rpms/seamonkey/blob/f39/f/seamonkey.spec . These packages, plus installed for build by default, plus all their dependencies are used at build time.

See root.log file for more info here:: koji.fedoraproject.org/koji/buildinfo?buildID=2346389

it IS installed

i am building str8 from git

i can build firefox and thunderbird and uxp for that matter

Well, then some other package from root.log ...

yeah i don't know what that means

an fc38 chroot also builds fine

but it has python 3.11 as the default py3

also save for ccache i have everything in the spec file

MattATobin: it seems python-3.12 still does not work. Firefox maintainer use 3.11, I just follow him there. See src.fedoraproject.org/rpms/firefox/blob/rawhide/f/firefox.spec#_863 for Fx, and src.fedoraproject.org/rpms/seamonkey/blob/f39/f/seamonkey.spec#_373 for SM

And I use clang, not gcc.

i am using clang

stop assuming I haven't built the code before

please

i am aware 3.12 doesn't work, I already figured out 3.11-devel was needed for firefox and thunderbird i already have all the deps from uxp through central.. and i have six installed and yet it says it can't find it on python 3.11

on fc39

MattATobin: I'm just trying to remember now what solved this problem. Because I had it too at one time...

voodoo

as i said lol

earlier

if i understood how to manually just shove six into py311 i'd do that but for the moment this fc38 chroot is producing builds fine.. if i hooked up a few more mounts i could even mach run it from the chroot

I spent yesterday as in thursday on it.. and friday I spent all day for no real serious reason trying to get a main window working on seamonkey on c-c

just to see if i could

not a working main window but ANY main window

i did it but not by proper means

btw buc sorry for being snippy if i had not fallen asleep with my headset on i wouldn't have woke up lol

Well, It is not enough to just install python3.11 packages, you also need to do "sed -i -e 's/python3/python3.11/' mach configure"

I tried that too

no six

wait

on more than mach?

And afair some other needed stuff was already installed by standard system python3 dependencies (all what was installed for build is in root.log etc.)

cause i edited mach for 3.11 specifically and said no six

MattATobin: yes, for SM *both" mach and configure

configure is regenerated every time tho

Hmmm.... But this works

ok

i shall try it after i get more sleep

how can I get ahold of you to report

if you discon

You can compare your logs with build.log from the link above etc.

well i do appreciate you taking the time to come and help

I review this irc.log regularly

need to test and see if cinnamon de is stable on el9 and also rebuild picom and a few other packages and get off redhat nightly

to beta

I really need to be on some el9 flavor for the rh cert stuff

but there are bits i do need to rebuild rpms for.. picom, lact (for gpu fan control), other stuff

also having a kernel vmware works on would be nice

need to get my lfs stuff moving again

too

I am just crash coursing the everything regardless if i like it or not i guess mister buc

MattATobin: Just remember that actually "elX" is "RH or CentOS or other clone" *plus* EPEL packages (ie. CentOS-9 + EPEL9, RHEL7 plus EPEL7 and so on)

Without epel stuff any RH is a piece of shit...

well maybe someone just needs to put it all in one massive repo

of course epel != all of fedora

there are the damnest gaps

In short: CentOS+EPEL == Fedora "ESR"

maybe I will use actual rhel

i can do that

anyone can

for developer purposes

then RHEL+EPEL

running mxr on el9 is gonna be a problem

cause for some reason perl 5 keeps getting altered

and also depending if kudo will get me his fixed glimpse package ..

There is also a useful system for alternative, unaccepted, rejected for some reasons packages copr.fedoraproject.org . Just to not build all the stuff yourselves.

yeah i after 7 years ALMOST grasp copr so maybe soonish lol

Ups, copr.fedorainfracloud.org

learning some spec file bits helps i'd guess

buc: I may end up remixing centos or possibily rhel its self as soon as I learn the media tools

if i do that then the first thing I want to do is a different installer that is wimlib based

For spec files: docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_files

yeah kudo has taught me a tiny tiny bit

as soon as I attain media creation capabilities I will be doing some remixes of fedora and centos

the centos is more than a remix tho i want to basically collapse the main repos and do monthly updates rather than appstream

basically CentOS Stream as if it was CentOS

and I'd ship cinnamon instead of gnome

Cinnamon should be in EPEL-9. As well as KDE and others.

yeah

Also MATE and XFCE for oldschools.

i run multimonitor and x

it is openbox or cinnamon

nothing else works properly for me

well gnome does but who wants to use that str8 up

buc: i could literally file dozens of bugs against fedora every release but they would be the same bugs filed for years now and the only general resolution i see is replacing stuff with new stuff that doesn't even fill the use case for which I used it for

its been very frustrating trying to adapt to this

I have been told in general fedora will only prioritize bugs because they personally want something fixed not merely because it is broken.. I think if it ain't redhat pushed it generally is on the chopping block as soon as it busts.. I want to believe differently but I can't see it any other way as an end user trying to get off windows

Very often people do not have enough manpower and time, and psychologically prefer to ignore problems that are “uninteresting” to them personally.

and i am extremely conserned that if i update to fc40 when it comes out my entire crafted environment I been working on for months will be busted

I get the man power and time thing, I mean come on.. but not igoring problems that clearly exist and persist for years

Liam-7142i

anyway buc think anyone would want an el uni-repo of baseos appstream and cbr that is unbranded plus a roll your own service webservice that generates the branding packages and repo and hosts it and a kickstart for people?

released on a gated monthly basis

did I also mention a far better kickstart geneator web thing than redhat's?

WG9s: so yeah we need to make xpcom js components into static component jsms and esms depending

at least glue and the browser content handler and command line handler

if we want cental to be somewhat workable

for more futile tinkering

MattATobin: People are either too simple and timid to use an alternative repository, or too smart not to already do something similar on their local network.

ah but you see.. i can literally make rebranded centos as service

where i have the unirepo, i have the webapp, and i host the kickstart and branding repo and you feed my iso with your kickstart and bam.. your own centos

just hosted kickstart creator and http hosting would be valuable i suspect

and i would make it better than redhat's

which is using the comps file only it seems

also buc you realize it is utterly ridiculous how firefox is gonna be the installer shell with a userChrome hack and nothing else.. you know I could make you a dedicated anaconda-webui xre application with a browser element and a few features and command line handler .. like pretty quickly if I were to focus 100% on it

hell my new modern mozilla example app is halfway there already.. as it has a main window that has a browser element in it

buc: if you care to occasionally check in on its progress github.com/binaryoutcast/mxp-example-app

consider it a port and completion of my uxp example app

lol

well at THIS point I guess I am gonna take a NAP rather than go back to sleep lol hi and bye frg_Away

There

sleep accomplished

Good morning frg_Away

so yeah, to go forward from here cause even causal tinkerwise I think the next step is to create an alternative main window that can launch various windows directly and allow the main window to spawn and do something

luckily I have one handy

and get devtools launching for chrome debugging

preferences because it is xbl based would need converted if possible but mailnew account manager just uses an iframe like xpfe preferences. Granted it is in-content now but it is the same design just needs style and metrics adjusted for dialog-ness rather than page-ness

also means navigator doesn't have a searchbar or urlbar either.. well they need recoded anyway for toolkit api regardless so..

I think I will tinker with central for a few hours then run sm 2.53 and see where it is at end-user wise.. been a minute since I seriously ran it

Maybe de-kinto

and work on porting weave.. May be best as to not bust sm platform browser/ to ifdef fxa off for MOZ_SUITE and put weave in sm comm

MattATobin greetings

same with kinto

keeps the patches simpler

rather than remove and replace just ifdef off and put tycho components in comm

frg_Away: wouldn't that approch be kinder to the patchqueue you run?

i mean unless the firefox code means nothing to you

Some of it is used for safebrowsing. I am not sure it is easy to do. So entangled. weave is nothing urgent. web compatibility and style is what currently bothers me. If SM can't render sites not much use for weave :(

yeah

is there anything you can mine UXP for even if the mods are only pending getting there properly?

which web feature is causing so many now-headaches?

Or do you want to rebase on something easier like 68 for a while

That certainly can be fixed up enough for things

for a while anyway

after 68 classic mozilla tech starts vanishing quite too much to not have to do a bunch of work

to compensate

when did xbl get killed

cause thunderbird kept rdf around for longer

xbl is the great divide really

in terms of getting the suite to run with only vNext Part 2 research

well firefox removed tabbrowser in 69

frg_Away: one could revert the esr68 CEs back to their xbl form for maximum compat

where needed

WG9s: so what do you think about what I been spouting

vrankly i ws out

frankly i was out

MattATobin dynamic imports and private class fields. I am on dynamic imports. uxp has them but our code is so much more future mozilla would need rebasing again.

an then not online at all becuase of moving hard drives around to get the drive i wanted in the mlaptop without the hardware issue

frg_Away: so Moonchild got someone to figure out how to import modules dynamically without crashing

neat

he was working on that long before I left

dyanmic imports should be around where you are in the patch queue 62ish

i know nothing about private class fields

who impl'd it? martok?

if so he may be willing to do it for sm .. others I doubt

I am not sure. Maybe.

Maybe once I figure out all the ifdef spots for mailnews and composer again I can test to see how feasable the suite would run on 68

reletively cheap (for me) experiment just to gather data

rss/feeds need to be redone as in TB and full themes would probably be gone or need to be reimplemented. I can do without xbl and data sources but overlays...

full themes aside from add-ons manager is a easy patch to revert .. i looked into it

all they did initally was just remove some refreshing the cache code and hardcoded skin to always be classic/1.0

no matter what chrome manifest or anyone says or asks for

problem would be taht NoScript and uBlock wouldn't be much good here. And no good alternative either. The webext versions are cripped and won't work for mail and suite would need to implement webext.

well now you remind me of my wife that was here filing system file folders all ending with stuff the one i had the biggest laugh about was shortly after we got married she made a folder about the end of her pervious marriage that she labeled "First Divorce Stuff"

frg_Away: waterfox had bootstrap extensions at the 68 level

restoring full extension support is only a matter of the add-ons manager

and chrome manifest

oops that was for a different channel

it's dooable

Too many dom and other stuff gone from the backend. They would need to be adapted.

because system add-ons are still xul at 68 i believe

yes last version they could be used I think.

Tell me which is simpler: Adapting code you know just a hop skip and jump from where its at or openweb compat lol

still it's all theory until I experiment some more and I am having so much damned fun and enjoyment out of it the past few days it has been pretty amazing for me consider the well years long pissed off lifestyle i been trapped in

considering*

I mean overall mozilla code is perfect for someone like my self, I can get a handle on it, it's ALWAYS acceptable to be bitching about it, and I enjoy it

Well esr60 already was a sh*tshow and it didn't get better afterwards or we would have 2.57 right now.

oh yeah

60 had a lot of issues

resulting in quantum compramises early on

they DID tend to eventually resolve them

or some of em

MattATobin: you said you would like to use lateset release for you work. It would be more helpfull if they could be base on what we consider to be the trunk which is the latest 2.53b1pre/

firefox can now load large ass documents like Pale Moon can again .. like actual static large ass html

WG9s: I use latest release as inital basis cause it tends to work, now that I have my baseline I will go dev code again cause patches on release don't apply to changing dev code and is pretty hostile to the patchqueue i'd suspect

exactly

but the l atest 2.53b1pre builds actually tend to work not amny pating and we tesnd to actually test our patches before landing

oh i know

i'd be bitching about it if you weren't I assure you

;)

but i also know broken for the day trunk can happen and when it is just a few people.. sometimes it's better to go to bed THEN wake up and revert and fix it

but the latest 2.53b1pre builds actually tend to work not many posting and we tend to actually test our patches before landing. those who do there work on windows often ask me to run a test build on Linux and macOS

aside from the enjoyment I am getting out of looking into this stuff.. I'd prefer any decision seamonkey makes about its future has the most and best options avilable to choose from.. cause why should you guys settle for less

and it's funny, cause I can find options by just poking things

68 may be one viable option with a little selective de-volution and the now I assume patented seamonkey patch queue

ride that for a year or two then re-evalute

I don't speak for the project, but you had asked about latest central and last I knew were no plans to ever go past mozilla 68 and no guarntee we woould go that far but trying to keep cental building to make it easier to backport a huge security issue if required

totally

Well this kind of broadjump shit is stuff I kinda pioneered doing .. I may not know how to fix every busted bit but I almost always know what needs to be done just not the specific how

but i do suspect WG9s fixing for 68 .. xbl aside would improve central building as well as backports

and I can certainly help keeping central building as well if it would help .. functioning with casual tinkering is a whole other ballpark and a hobby I am considering adoptiong but only as a hobby

I could also likely conform central suite's build files and configuration up to central state not just enough to satisfy the build system

If seamonkey IS seriously considering to rebasing to esr68 I'd certainly help and I am gonna do some research into that

I personally don't think 68 will do use much good. It is either central or continue with backporting I fear.

do you WANT to regain central status?

ux wise central isn't an issue it can be styled and shaped pretty much as it always was for nearly everything

I want to make 2.53 work but if this fails I would go for central. Interim versions would be outdated again and again and again. But I don't think central will happen with the current resources on hand. Even if you, ianN , WG9s and I work full time on it.

if you want to retain xbl 68 is likely the last stop beyond that into full webcomponents es modules customelements and all.. is a tricker and glorious prospect but not an easy one and is frought with unknowns even thunderbid hasn't had to figure out

So forked up either way...

I mean I partly blame my self, if I had been well a better me we'd all be peacefully coexisting on a xul platform everyone uses but I wasn't

I personally don't care about xbl. I just want a suite which does what it does now :) Can't say I like CE but I don't like a lot of things and xbl was not great either.

We only have what could be called deas or dreams but no real plans the isea is either go to 2.53 (esr60) or esr68 and then fork the backend port and support it ourselves. but we have zero pople who could actually support the back-end code. I used to do back-end stuff but that was about 20 years ago, in a galaxy far far away!

Well without more platform contributors yeah 68 seems like more work than the current patchqueue and some tobin patches central tho I am very interested in seeing seamonkey run on it and if organized into logical parts we can build or not build it makes the job of the partial reconstruction of the suite much more of an attainable goal for a tiny handful of crazies such as our selves

but I do not see hwo se could take on the fork the backend and support it ourselves at this point

for what? Mozilla?

current day mozilla?

not sure what options there re execpt mozilla becuase i really don;t think other options have a good backend for mial

That is the core goal of my research into what modern mozilla can offer that is eq or still existing

perhaps we cold get mail and composer and evn maybe irc to work but I don't think we have developers to be able to support the mail backend

you don't have to

thunderbird is already doing that

or do you mean 68

getting back on central eliminates nearly any platform or mailnews, calendar, chat core development

just suite development and the fix4mozchange situation

extensions are doable even if it involves overriding chrome registry chrome and the entire add-ons manager

like mozilla-style extensions

themes are another story

that would take some creative thought on how to make that happen

but if someone comes up with a new protocol for mail form an app wther tham IMAP and POP I do;nt thing TB or us would have a clue how to implement it

you may be right

so --disable-mailnews lol

WG9s: chances are it would be a web protocol so a js lib may simply do the trick

well i have a fairly good idea how to make esr68 possible so I am gonna ignore tangible testing of that theory for now and focus on git and central for you guys

it was painful to get imap to work right in TB for any server other than the one it was first written to work with

imap still doesn't work right in Interlink

just MOSTLY right

i can't maintain mailnews core

I couldn't maintain it when it was merged into uxp .. a200 can't either doing an email client was kinda dumb on my part

But yeah my strat for dealing with central is: Add a working main window that I can add buttons to launch suite windows from and get devtools going, then ifdef mailnews and composer from navigator.. then work on getting glue and browser content handler ported to jsm and an esmodule respectively.. from THERE it is .. fix navigator and shared communicator bits .. next would be composer followed by the big tamali mailnews ui

WG9s:

I wonder where my frien Dave Mose is these days. he is the one sho actually got IAMP working correctly under TB back in the day

literally mailnews UI is the biggest issue with getting central suite to be functional

not navigator

.. editor ui is a wildcard

mailnews ui was an issue for me at 52 level which is why I didn't make interlink the suite mailnews component

anyway that is what I have learned over the past 48 hours

WG9s frg_Away

and the past few weeks of experimenting in modern mozilla code

I would probably fork the ui. The current one is not much good for me personally. Want addresses in a window and not everything is a tab.

what and eliminate tabbed mail?

that would make things a fuck ton simpler if tabbed mail wasn't a thing

i mean tabbrowser is gonna be a bitch

No just not everything in a tab. Address book in a tab s*cks e.g.

same for rss

eyah i never understood why seamonkey took that on as a feature cause unlike thunderbird you HAVE a navigator

well thunderbird seems to be more about enforcing a spaces concept where spaces are the former windows

but right now it is just backed by tabbedmail

they have some interesting ideas but right now its half traditional half modern and the clash is a bit jarring

mailnews ui likely should just be rebuilt and tabbed mail only applies to messages everything else is a window like the old days

imo frg_Away

frg_Away: I have created a comm/suite/reconstruction to build a temporary main window based on my example so that we can actually do stuff within the running executable

and I am gonna get devtools hooked up to that

WG9s:

one nice thing is at this point removing the bindings and css declairations of em are just cleanup as they have no affect whatsoever

oh yeah

the sandbox renderes my browser element cause it ain't allowed

have to disable the sandbox

hi Hendikins and tomman