I think I am indeed gonna abandon the xpfe emulated toolbar grippys

what do you think tomman

least you aren't a commie like _nuke

njsg: I seriously don't think anyone would miss em

least the per-toolbar customization isn't tied to it.. I do need to standardize them and perhaps add the methods to the bindings or a jsm or something

man.. will the toolkit even be reconizable once i am done lol?

well consistancy sure ain't a thing in the mozsphere

how do you feel about it IanN_Away

IanN[m]:

conceptually i mean.. not having the toolbar grippys

at all

i don't use them but there are some people that do

toolbargrippy {display: none !important;} probably the first userChrome.css I ever used :)

CaptainTobin: ^

a-865: well frg added a pref

a-865: they're hidden as default anyway but I think CaptainTobin is talking about removing the code that supports them

i am just gonna ditch the binding

I mean I love them but the actual impl hasn't ever been as easy to maintain as the xpfe binding

I've been using that CSS since somewhere around the turn of the century, whenever Mozilla first showed up on OS/2

good riddance to grippies

some accidental hotkey strike would make things disappear without knowing how to recover :(

Is the pref in the pref panel?

yes

yes, under appearance

soic

:)

there we go IanN_Away a-865 njsg

the xpfe emulated grippy toolbar shit is gone I also removed the last component bar icon and moved the new inline customizable toolbar to the end of the status bar ordinal enforced.. tho i had to set a higher ordinal for the statusbar resizer in the binding

but no biggy

small toolbar mode with text on the size is now the default

I think visually.. it is quite ready to launch but shellservice needs finished

I think it looks very nice in its native windows look

i will have to reinstall an 8.1 and 7 vm to do some spot checks make sure my changes haven't caused a style regression

I dunno if i am gonna keep the netscape 7 new tab text label but i find it fun that just adding the attr had it show up styled exactly right

frg_away: If I were to prep a build vm a vmware vm for you do you think you could poke at trying to get nss past my brickwall at some point

NewTobinParadigm I finally found some time yesterday to check nss and nspr dependencies. This is basically all needed. 1769627-102a.patch is optional and a few others too to make later ones apply clean(er)

series file excerpt: paste.debian.net/1255019

Build is stable for a week now including mail and I don't think anything left lurking in the shadows here. ymmv.

nss and nspr are unmodified 1:1 copies. Just still compiling the old dbm module for migrations from pre 2.53.1

The grippie disable pref is not set in release builds as default. Just in the prereleases. In release builds you need to set it one time. I frequently misclicked and did hide the menu or a toolbar and I wasn't alone so it got added. I don't use them but as IanN_Away stated they probably still have a few fans left and we try not to do a mozilla with ui features. Does not mean they won't be...

...chopped one day or that the ui stays unchanged :)

frg_Away: yeah for 56 but 52-base still can't get past what 3.64 i said?

i was just thinking if i prepped a windows build env and prepped it for building maybe you could see what i see

gonna set up a build vm for your base as well

a build vm or a vhd for native boot

CaptainTobin I am totally swamped. Could take a look at the build log if you have one. I really have use for a clone or two of me :)

i can do a build log but it will be a bit i'd have to lay down the newer version and make mods

i haven't messed with it since april

so obviously it isn't super duper critical

heh

but i also kinda promised to do some work for you guys and maybe i should actually do it at some point?

remember the non-fxa infected weave backend

I'll file a proper bug in a few days but what I plan to do once I get a build env for seamonkey is to first port the tycho weave backend do any settling in adjustments then we will upgrade the bits and make a toolkit sync client fe/be and just have seamonkey provide the couple of bits specific to it while the majority of the component is contained.. chrome addresses are easily overridden not to immidiately break themes

CaptainTobin having sync running would be cool. I am not sure if ewong has the time to set up a server but at least anyone could set up a private one.

well once it is working again then you guys can decide if you are gonna provide a small server for the few hundread that actually can still be bothered to care about what they are using BUT if you do I and my users get to use it for continued maintaince of the component remember?

hell i'd likely still do it anyway i just might not be AS nice about it LOL

check out that tree much cleaner than it was before i dealt with it

of course you note the classic as fuck heirarchy but i suppose you'll want your skin and locale files in their central-ish locations ;)

odd, Palefill suddenly stopped working

at first I thought "oh no, what new Chromeism had the GitHubs and GitLabs deployed this week!?"

tried updating the addon (there was an update released last week), but nothing

the console was giving the dreaded "window.customElements is undefined" crapola

then I decided to restart SeaMonkey and that magically fixed everything! (although the old process hung after closing all windows, so I had to SIGTERM it)