02:12:29 <tomman> https://jdan.github.io/98.css/ love those retro UI CSS libs that require absolutely ZERO JavaScript vomit
02:12:44 <tomman> although this one exhibits a rather odd rendering issue with checkboxes under SeaMonkey
02:13:29 <tomman> if you (de)select a checkbox, the checkbox renders... wrong (the actual checkbox gets misaligned with the label and the tick mark)
02:13:39 <tomman> everything else seems to Just Work™
03:44:48 <CaptainTobin> EITHER the caption buttons are too small except they look right or the caption bar is a about 1px too high top and bottom and the caption buttons need moved over by a pixel
03:44:51 <CaptainTobin> tomman:
03:46:42 <CaptainTobin> Developing
03:46:43 <CaptainTobin> First, run npm install.
06:14:21 <CaptainTobin> When will people ever figure out that insulting you and giving you good advice aren't mutually exclusive.
17:46:37 <CaptainTobin> hey frg_Away when you get a chance sometime in the next few weeks or so could you try and do a comm-esr52 or your esr52 .. just the comm part and convert it from hg to git.. all the imports and conversions I try to do fail badly
17:47:21 <CaptainTobin> not a priority just something that would improve my process
17:47:59 <CaptainTobin> i have a terrible time trying to navigate an hg repo on hgmo
19:09:47 <frg_Away> CaptainTobin IanN_Away did the conversion. For mozilla we didn't keep the history. Just for comm. Ping me next weekend.
19:13:10 <CaptainTobin> yeah I don't need the mozhistory i can get that from gecko-dev\
19:14:34 <CaptainTobin> mozilla i mean
19:14:38 <CaptainTobin> thanks dude
19:23:48 <CaptainTobin> I should have retained history back to 39.0a1 when i created the uxp git repo just so file history back to stock state of 38 would have been useful.. but manging that large of a repo is hard enough just filewise let alone commit history
19:35:13 <CaptainTobin> well that works for a go icon .. fx2 one was stylistically similar enough to fit in just fine.. have to change the search icon tho.. BUT I think I am actually gonna build a widget that will replace the button where instead of a search icon it has the engine icon and right click access the current search engine.. and just dump the search bar its self.. or shove it in an add-on
19:35:49 <CaptainTobin> http://personal.mattatobin.com/image/capture/85a4c545-9f39-47ee-84cd-fd3d3ecadd7d.jpg
19:38:00 <CaptainTobin> OH I looked into adding an inline toolbar onto the tabstrip from within the binding content.. it didn't go well.
19:38:31 <CaptainTobin> component toolbar turned inline customizable toolbar will have to suffice along with stuff in the navigational toolbox of course
19:39:26 <CaptainTobin> but i am going against some ancient construction inside that binding pulled from different incarnations of the orginal binding
19:39:28 <frg_Away> CaptainTobin For mozilla https://github.com/mozilla/gecko-dev/tree/esr52
19:39:46 <CaptainTobin> frg_Away: oh yeah that has been a key research url for years man
19:40:10 <CaptainTobin> there IS a comm-releases mirror but it suffers from mangled history as much as any of the not-central branches
19:40:30 <CaptainTobin> so history is fragmented duplicated erased restored and erased again
19:40:32 <CaptainTobin> heh
19:40:39 <CaptainTobin> and that is BEFORE the git conversion
19:41:58 <CaptainTobin> a big part of my engineering involves this.. now even more so http://xr.binaryoutcast.com/aura-central/source/mach#48
19:42:41 <CaptainTobin> so git history surfing is something I am VERY good at
19:42:48 <CaptainTobin> hg history .. not so much
19:43:01 <frg_Away> CaptainTobin our comm-release is probably not much good because missing the esr52 patches so need to check this one.  Problem might be the authors. git is fuzzy sometimes. IanN_Away did not retain the scripts it seems.
19:43:21 <CaptainTobin> oh well..
19:43:22 <frg_Away> I am using thg. Much better than git and tortoise git.
19:44:00 <CaptainTobin> i do this through a forge web interface github or code.binoc or rpmo
19:44:42 <CaptainTobin> yeah i dunno
19:50:05 <frg_Away> CaptainTobin Just checked we didn't take history for comm either. I can do an initial comm-esr52 this way maybe next weekend but with history might take a bit more time if ever.
19:52:11 <frg_Away> Had lots of fun checkin in irc and DOMi initally but this is something I could repeat easywith a 52 based one  :)
19:52:12 <frg_Away> https://ibb.co/KX9Mcgc
19:52:47 <CaptainTobin> don't worry about the traditional extensions
19:53:08 <CaptainTobin> just pure comm
19:53:19 <CaptainTobin> thanks for reminding me tho
19:53:34 <CaptainTobin> i need to reintegrate DOMi as a component
19:54:36 <CaptainTobin> I'll hack some build files to build it as an extension for less.. not-mine application targets
19:56:49 <CaptainTobin> I am not gonna bother with chatzilla .. but ressurected but the chatcore irc protocol should be far easier to update as part of the im fork
19:57:18 <CaptainTobin> ressurected IM fork
19:58:37 <CaptainTobin> because binary extensions are still a thing for me i can save a lot of time by seeking libpurple updated impls from those I can't do via js.. I plan by default the only protocols to be XMPP and IRC as those are the most stable.. everything else can be extension provided
19:59:43 <CaptainTobin> which basically makes the application its self fairly trivial .. it would all be about the extension provided protocols
20:00:04 <CaptainTobin> which can be either libpurple or js components or even binary xpcom components
20:00:43 <CaptainTobin> with no clear front runner in the non-encumbered-by-your-own-service-driving-everything world.. i could rise to the top
20:14:13 <CaptainTobin> frg_Away: how did you adapt composer to jsdownloads .. not that I need to know for any reason but one of the bits that was specific was the whole file transfer think based off nsDownloads or w/e
20:15:19 <CaptainTobin> i need to fork fireftp into a full application
20:15:47 <CaptainTobin> a mozilla based file transfer client.. what would I call it?
20:15:49 <CaptainTobin> LOL
20:16:15 <CaptainTobin> FTPZILLA OF COURSE
20:16:20 <CaptainTobin> nah that won't work
20:16:24 <CaptainTobin> hey therube
20:16:41 <CaptainTobin> what would YOU call a classical mozilla-based ftp client?
20:16:44 <therube> helo capt'n
20:17:33 <therube> call it SeaMonkey, as ftp: still works here ;-)
20:18:03 <CaptainTobin> well i was more half-joking about filezilla being called that but not using any moztech except maybe nss long ago
20:18:19 <frg_Away> CaptainTobin Neil did the inital patch. I just built on it. It was so long ago better don't ask about details. Bug 888915 for the dirty history. Lots of fun. Still not perfect.
20:18:35 <CaptainTobin> well.. i think a dedicated ftp client is not worth the trouble but an ftp client enabled file manager IS
20:18:46 <CaptainTobin> frg_Away: yeah
20:20:34 <CaptainTobin> if you are gonna stay on your 56-fork i say go ahead and just put nsDownloads back and revert the fe changes and stash the JSDownloads version for when you are FORCED to have it.. you right now aren't forced into it
20:20:42 <frg_Away> I pickes the intial patch and thought I would just use downloadcommon.jsm from Firefox. Then the fun started. I thought it was a self contained jsm encapsulating the api I could adapt but was all over the place. The result was not pretty and still isn't.
20:21:04 <CaptainTobin> frg_Away: do you see why I want no part of it
20:21:49 <CaptainTobin> as soon as I figure out how to revert the toolkit deps on it JSDownloads will be killed completely.. extensions be damned
20:22:59 <CaptainTobin> i still find true nsDownloads perform better and less "we couldn't save the file we have been saving to 99% for the past hour"
20:23:49 <CaptainTobin> i could help you do that just won't be until next year
20:23:55 <CaptainTobin> if you want
20:24:08 <frg_Away> It works now for the most part and rather enhance it. Same for the library. Biggest weakness of Firefox. Instead of providing a backend with an api you could call you hack frontend and backend together, scatter parts over browser, toolkit and who knows and then call it innovation.
20:24:39 <CaptainTobin> frg_Away: long for the days of nsBookmarks and nsHistory?
20:25:12 <CaptainTobin> fuck i would have just replaced serialization and reading from rdf to sqlite or whatever backend and kept the rest of it as it was.. it worked fine
20:25:45 <frg_Away> Before my time. I actually like the new library with history and bookmarks together.
20:26:06 <CaptainTobin> I don't.. they are different functions
20:27:12 <frg_Away> It did grow on me but I left downloads out. This is something not belonging in there.
20:27:43 <CaptainTobin> so while I will update the components I will retain the seperate manager FEs.. and anything that isn't STRICTLY fe will become common code HELL my seperate managers may become common code.. BUT i will make it so you don't HAVE to have a full on incarnation of the fe to use it.. Just use what level you like including as provided
20:28:12 <CaptainTobin> THAT is what the main goal aside from removing "whore features" was behind xpfe to aviary toolkit
20:28:21 <CaptainTobin> before Firefox became all consuming
20:29:23 <CaptainTobin> Just like the sidebar is going into as a common shared component as well..
20:29:48 <CaptainTobin> download manager.. my revamped phoenix incarnation permission managers and cookie manager
20:31:24 <CaptainTobin> there is simply NO reason in the world for multiple projects using the same codebase to have to maintain multiple components that are all eventually sync'd at one point or another without a very specific ux justification.. Mozilla understood this.. but the trap i have to avoid is because components orginally designed or used my one applicatoon should not have unconditional priority to dictate the progression of said common code
22:31:18 <CaptainTobin> fuck ONE reason to keep urlbar history .. xpfe autocomplete or not.. is to allow it to store much more than what places was meant for
22:31:32 <CaptainTobin> like if it was turned around and used for a file manager location bar
22:31:42 <CaptainTobin> for instance
22:32:16 <CaptainTobin> the urlbar history its self being seperate from whatever regular the box's autocomplete method is valuable