jdan.github.io/98.css love those retro UI CSS libs that require absolutely ZERO JavaScript vomit

although this one exhibits a rather odd rendering issue with checkboxes under SeaMonkey

if you (de)select a checkbox, the checkbox renders... wrong (the actual checkbox gets misaligned with the label and the tick mark)

everything else seems to Just Work™

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

tomman:

Developing

First, run npm install.

When will people ever figure out that insulting you and giving you good advice aren't mutually exclusive.

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

not a priority just something that would improve my process

i have a terrible time trying to navigate an hg repo on hgmo

CaptainTobin IanN_Away did the conversion. For mozilla we didn't keep the history. Just for comm. Ping me next weekend.

yeah I don't need the mozhistory i can get that from gecko-dev\

mozilla i mean

thanks dude

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

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

OH I looked into adding an inline toolbar onto the tabstrip from within the binding content.. it didn't go well.

component toolbar turned inline customizable toolbar will have to suffice along with stuff in the navigational toolbox of course

but i am going against some ancient construction inside that binding pulled from different incarnations of the orginal binding

CaptainTobin For mozilla github.com/mozilla/gecko-dev/tree/esr52

frg_Away: oh yeah that has been a key research url for years man

there IS a comm-releases mirror but it suffers from mangled history as much as any of the not-central branches

so history is fragmented duplicated erased restored and erased again

heh

and that is BEFORE the git conversion

a big part of my engineering involves this.. now even more so xr.binaryoutcast.com/aura-central/source/mach#48

so git history surfing is something I am VERY good at

hg history .. not so much

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.

oh well..

I am using thg. Much better than git and tortoise git.

i do this through a forge web interface github or code.binoc or rpmo

yeah i dunno

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.

Had lots of fun checkin in irc and DOMi initally but this is something I could repeat easywith a 52 based one :)

don't worry about the traditional extensions

just pure comm

thanks for reminding me tho

i need to reintegrate DOMi as a component

I'll hack some build files to build it as an extension for less.. not-mine application targets

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

ressurected IM fork

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

which basically makes the application its self fairly trivial .. it would all be about the extension provided protocols

which can be either libpurple or js components or even binary xpcom components

with no clear front runner in the non-encumbered-by-your-own-service-driving-everything world.. i could rise to the top

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

i need to fork fireftp into a full application

a mozilla based file transfer client.. what would I call it?

LOL

FTPZILLA OF COURSE

nah that won't work

hey therube

what would YOU call a classical mozilla-based ftp client?

helo capt'n

call it SeaMonkey, as ftp: still works here ;-)

well i was more half-joking about filezilla being called that but not using any moztech except maybe nss long ago

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.

well.. i think a dedicated ftp client is not worth the trouble but an ftp client enabled file manager IS

frg_Away: yeah

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

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.

frg_Away: do you see why I want no part of it

as soon as I figure out how to revert the toolkit deps on it JSDownloads will be killed completely.. extensions be damned

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"

i could help you do that just won't be until next year

if you want

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.

frg_Away: long for the days of nsBookmarks and nsHistory?

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

Before my time. I actually like the new library with history and bookmarks together.

I don't.. they are different functions

It did grow on me but I left downloads out. This is something not belonging in there.

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

THAT is what the main goal aside from removing "whore features" was behind xpfe to aviary toolkit

before Firefox became all consuming

Just like the sidebar is going into as a common shared component as well..

download manager.. my revamped phoenix incarnation permission managers and cookie manager

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

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

like if it was turned around and used for a file manager location bar

for instance

the urlbar history its self being seperate from whatever regular the box's autocomplete method is valuable