16:12:20 <CoordinatorTobin> frg_Away and all heads up: thereisonlyxul.org cross-reference will go down at some point today for a switch over to the larger server and all the Mozilla trees and 102 and 115 esrs will be added.
16:12:32 <CoordinatorTobin> and brought back
16:12:58 <CoordinatorTobin> are there any other comm trees besides comm-esr52 you guys want while I am doing it?
16:14:08 <CoordinatorTobin> would 60 or 68 be of help?
16:15:55 <frg_Away> thanks for the heads up.
16:16:46 <frg_Away> CoordinatorTobin dxr... is ok for me here. I personally don't need these.
16:17:30 <CoordinatorTobin> mozilla-central with comm will be back tho ;)
16:17:36 <CoordinatorTobin> that should he halpful
16:18:02 <frg_Away> Rarely need anthing less that 60 now. I usually check the files with tortoisehg then in central or older esr. But 2.53 is a lifesaver :)
16:18:22 <CoordinatorTobin> dxr / searchfox still isn't as NICE to use but it does have some extra capabilities mxr didn't
16:20:15 <CoordinatorTobin> come on.. green mozilla vs a light gray gradient searchbar
16:20:27 <CoordinatorTobin> you know which is the better experience frg_Away ;)
16:22:25 <CoordinatorTobin> That's beyond the nearly ∞ gigabytes worth of content that is indexed here.
16:22:45 <frg_Away> I need the annotate and revisions functions most of the time which are only available in dxr unfortunately.
16:23:21 <CoordinatorTobin> frg_Away: mxr can do HG revisions it still has hg specific features.. git not so much
16:24:12 <CoordinatorTobin> But this was also why I orginally wanted to gradually fork it to php and add those features
16:24:21 <frg_Away> It will be interesting what happen when they switch to shithub. I hope the old archives stay readyonly but do not have high hopes.
16:24:50 <CoordinatorTobin> Mozilla says they are aiming for a pure full history repo
16:24:57 <CoordinatorTobin> not just reusing gecko-dev as-is
16:25:19 <CoordinatorTobin> as for the hg repos
16:25:44 <CoordinatorTobin> well like cvs they will likely run it until they no longer have an internal need .. like svn too
16:29:16 <CoordinatorTobin> well I figured out the goals for my xhtml xre example
16:29:18 <CoordinatorTobin> Functional Feature Goals: Main Window with Menubar, Toolbar, Single Browser (not tabbed), and statusbar, a Preferences Window, Downloads Handling, and Places (History and Bookmarks).
16:31:15 <CoordinatorTobin> menubars are still xul tho not xbl, thunderbird has solutions for customizable toolbars and a statusbar .. prefwindow has no ce equiv it's just dialog most of the time if not in-content so that will likely be unimpressive, thunderbird again has a solution for downloads but places can also host it.
16:33:24 <CoordinatorTobin> waterfox has solutions for overlays and a bootstrap form of mozilla extensions
16:33:48 <CoordinatorTobin> and some of it came from thunderbird too
16:37:27 <CoordinatorTobin> the pieces or equiv or emulated are all there it just needs assembling in a way anyone can make use of
16:38:17 <CoordinatorTobin> I wish all the conversion scripts were
16:43:09 <therube> a decade old bug, https://bugzilla.mozilla.org/show_bug.cgi?id=966662, that someone bumped a year ago, that a bot happened to bump, today, that i, by pure coincidence happened to come across, & it took McCreight (whose post was not there when i looked at the bug) to say what should have been said, ages ago ;-)
17:28:38 <CaptainTobin> So more stuff means more memory eh?
17:28:47 <CaptainTobin> Let's remove composer
17:28:50 <CaptainTobin> that will save memory
17:29:01 <CaptainTobin> and honestly who the hell actually uses it practically speaking
17:29:39 <CaptainTobin> if frg_Away up and said kill composer I'd drop everything I was doing and do it lol
18:00:55 <frg_Away> CaptainTobin there are still people using it. Does not save much memory if you remove it I bet.
18:03:45 <CaptainTobin> What if you split it out?
18:04:06 <CaptainTobin> just pull a standalone composer job
18:15:18 <frg_Away> Maintaing the status quo is not imuch work. If something breaks it is usually in the shared editor component with mailnews.
18:15:27 <CaptainTobin> ah
18:22:39 <frg_Away> What I would really like is Ctrl+3 to link to to the calendar and decouple it a bit from mailnews. One of these days which will probably never come...
18:31:59 <CaptainTobin> make calendar able to open in its own winder, frg_Away?
18:33:29 <CaptainTobin> i mean simplest way to fake it would be make a new window with sm's version of tabbed mail to a document and load up the mailtab
18:34:32 <CaptainTobin> I mean except for linking mail contacts to events the calendar should not explicitly require mailnews ui functionality anymore than what overlays expect
18:34:37 <CaptainTobin> which can be changed
18:35:51 <CaptainTobin> and faking it first will be able to judge user response if they react poorly or don't care then dump it and its minimailtab window.. if they like it then do it for real
18:36:17 <CaptainTobin> least that is how I would handle it
18:36:22 <frg_Away> yes. Something like lightbird. I find the current ui confising. On the other hand invitations  need to be managed so it still needs to interact with mail accounts. Suspect needs a redesign and much thought to make it happen in a good way.
18:36:40 <CaptainTobin> not much of one
18:36:52 <CaptainTobin> and that could be imported
18:37:04 <CaptainTobin> remember sunbird was a standalone application
18:37:38 <CaptainTobin> the real issue is newer calendar IS an integrated part of thunderbird since no mozilla extensions and no overlays
18:37:45 <CaptainTobin> but the one you currently have
18:38:05 <frg_Away> yes but if you have more than one email account and want to link to calendar events...
18:38:43 <CaptainTobin> I see
18:39:04 <CaptainTobin> yeah a bit of redesign may be warrented
18:39:08 <frg_Away> nuking the extension would be not much of a problem.
18:39:21 <CaptainTobin> but I am sure the mail BITS can be selectively called without all of mailnews ui being involved
18:41:11 <CaptainTobin> maybe what SHOULD be done is ignore mail integration for the moment and work on cloning and adapting the calendar UI as a seamonkey component backend in comm/calendar and fe in comm/suite/components
18:41:21 <CaptainTobin> or wherever you place top level components in the tree
18:41:59 <CaptainTobin> the extension form just works as normal until mail integration is worked out and that is switched over
18:43:18 <CaptainTobin> also avoids patchqueue until the switchover with mail integration
18:43:48 <CaptainTobin> then we just either kill or ifdef calendar's extension ui off to MOZ_THUNDERBIRD
18:44:31 <frg_Away> well currently one calendar is linked to one email addy so it might not need much redesign initially. But as I stated one of these times. Too much on the platter and need to fix web compatibility first :(
18:46:31 <CaptainTobin> oh no doubt it is a longer term project
18:46:51 <CaptainTobin> but sure a revamped seamonkey calendar UI that sounds fun
18:48:30 <CaptainTobin> frg_Away: do you happen to know on linux would you imagine being able to build both UXP and Modern Mozilla likely means I have all the deps to build seamonkey lol
18:48:40 <CaptainTobin> or just what the redhat deps are
18:52:31 <frg_Away> Given that I am able to build in CentOS 7 and Rocky 8 it yes it should work. 9 was missing python 2 and I scrapped the vm but we are now py 3 so probably there too.
18:54:22 <CaptainTobin> well i have python 2
18:54:24 <CaptainTobin> so
18:54:27 <CaptainTobin> this is fedora 39
18:57:21 <CaptainTobin> frg_Away: I have this in my kickstart file https://dpaste.org/o3Mtk/raw ALL the dev i need
19:23:00 <CaptainTobin> so let's see that makes.. xref, weave, de-kinoization, and now calendar as a component I have basically promised lol least xref happened
19:23:12 <CaptainTobin> kinto*
19:23:57 <CaptainTobin> hello Hendikins
19:24:02 <CaptainTobin> how goes it?