Now we have Electron and all my wildest dreams came true.
No XBL Components Left in Firefox
41–50 of 73 posts
Re: No XBL Components Left in Firefox
#42Earlier quoted context omitted.
What is the closest thing we have left that is close to “mostly declarative GUI”? QML? Tk? Please don't say Electron.
XAML, but it Microsoft-specific. While not completely uniform its use does extend across desktop and mobile. I wouldn't make the argument that it's intuitive or simple, but it is powerful.
Re: No XBL Components Left in Firefox
#43Earlier quoted context omitted.
"HTML5" + things like css grid and flexbox that you need to build UI in a sensible manner are pretty new inventions. XUL predates them dramatically, building UI in HTML at the time would have been an absolute nightmare. I know because I had to ship it in multiple applications
I understand that it probably was a better technology at the time. But are there any concepts/technologies in XUL that would be useful to add in the HTML standard?
[1] - https://www.w3.org/wiki/Text-overflow_middle_cropping
[2] - https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...
Re: No XBL Components Left in Firefox
#44Re: No XBL Components Left in Firefox
#45I'm not saying it was the right thing to do, but XUL and the component architecture were major reasons Mozilla took forever to be released, and then forever again to become usable.
And then a major reason why Firefox extensions became a thing long before using web tech was an option.
I tried to find uses for it back in the days, read a book and played around with it. What killed it for me was hooking into C meant dealing with Mozilla's internals a lot more than I would have preferred. These days serverless is common, but back then it was practically unheard of.
I did use Songbird [0] for a while, but it was always slow and buggy for me. And it never really went anywhere, not for a lack of trying from the looks of it.
ActiveX, Corba, Bonobo; they always seem to get so complex and bloated that no one wants anything to do with them when there are other options.
Re: No XBL Components Left in Firefox
#46Earlier quoted context omitted.
That's surprising. I wrote an extension back in the days, I think it was Firefox 1.5, I used XPCOM to use C code and it worked well. I don't remember stumbling into too many bugs. Actually I liked XUL and I thought that it has great future, because it was so much better for UI than HTML.
Would you care elaborating why it is better than HTML5?
Re: No XBL Components Left in Firefox
#47Earlier quoted context omitted.
I understand that it probably was a better technology at the time. But are there any concepts/technologies in XUL that would be useful to add in the HTML standard?
It's a minor problem, but CSS, unlike XUL, doesn't provide a way to crop text in the middle[1][2]. [1] - https://www.w3.org/wiki/Text-overflow_middle_cropping [2] - https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...
XUL texboxes avoided this problem by only supporting a single plain text string, but applying that constraint to HTML+CSS would be incredibly ugly (and people soon be complaining about that constraint, anyway).
Re: No XBL Components Left in Firefox
#48Earlier quoted context omitted.
userChrome.css still works, and if you already had one they automatically flip the pref on for you. It's default-off because it increases startup time.
I wonder, what's the 95% worst case latency for a stat on a 5400 RPM laptop drive from 10 years ago? Assuming of course that the drive is already spinning since it's reading a million other things from your profile. I bet it's negligible in almost every case.
Re: No XBL Components Left in Firefox
#49If I understand this correctly, do they mean Firefox desktop GUI is rendered using HTML elements? I understand chrome UI controls are based on skia. If yes, is this available as some kind of framework that can be used to develop custom desktop applications (like Qt)?
Re: No XBL Components Left in Firefox
#50>And now a major browser's UI is built with web components! Proud that you need to use your HTML/JS engine to render your UI instead of using faster native code? I mean you have the opportunity of getting rid of XUL and instead you change it... for something similar?
The browser UI was already rendered by Gecko, that's how XUL and XBL work. It's just that it's rendered by parts of Gecko that aren't used by anything else on the web, and so in honesty those paths probably had less optimization, not more.