Earlier quoted context omitted.
XUL was pile of garbage riddled with bugs. I've made Todo app in remote XUL and every 30 minutes of development I encountered some major functional bug. Idea was great but implementation was terrible. I've used many UI frameworks over the years but when I see three letters XUL, the first flashback I have are all those bugs.
Remote XUL? Never even heard of that. My experience writing regular local client xul with HTTP calls went pretty snoothly
No XBL Components Left in Firefox
61–70 of 73 posts
Re: No XBL Components Left in Firefox
#62XUL was amazing, and they abandoned it. This obsession with making everything "web" friendly is backsliding desktop into horrible, non-native UI.
XUL was like the early internet: full of amazing possibilities, open, and security-oblivious. Web extensions are severely limited, mostly because of security considerations, that is, to protect against malicious code. Web is no more a friendly children's sandbox it was in 1995.
> security considerations, that is, to protect against malicious code.
Only in the "cannot fuck up your computer" kind of way. All addons I've installed still require "Access your data for all websites", thus have full access to my online life. Thus I only install addons from sources/authors i trust, just like back when jQuery was the coolest thing.
Re: No XBL Components Left in Firefox
#63That's a non-trivial amount of hard work going down the drain right there. I'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 an…
> 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.
The only experience I've had with any of these technologies that didn't end up inducing nausea was ATL. It made COM/ActiveX tolerable for common, simple use cases. I learned the CRTP while writing ATL components and applied it in my own C++ work to some success.
Re: No XBL Components Left in Firefox
#64Earlier quoted context omitted.
JavaFX and QML are pretty much based on XAML.
Xaml and Javafx where released within 6 months of each other I kinda expect parallel implementation rather than copying. Just form the dates in Wikipedia
JavaFX was initially J3, and then it was rebooted into XAML like.
Also you're forgetting Longhorn SDK was available as preview before the project was canned.
But yeah just conspiracy theories from my side.
Re: No XBL Components Left in Firefox
#65That's a non-trivial amount of hard work going down the drain right there. I'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 an…
They only get so complex when people insist into plugging a square into a round pet, like using said technologies from C, writing everything by hand.
Using ActiveX, nowadays COM/UWP, is never an issue from Delphi, C++ Builder, .NET, Visual C++ via MFC, C++/CX, C++/WinRT, Eiffel.
Re: No XBL Components Left in Firefox
#66Earlier quoted context omitted.
JavaFX and QML are pretty much based on XAML.
Xaml and Javafx where released within 6 months of each other I kinda expect parallel implementation rather than copying. Just form the dates in Wikipedia
MXML. The Markup system for Adobe Flex is almost certainly the inspiration for both.
Re: No XBL Components Left in Firefox
#67XUL was amazing, and they abandoned it. This obsession with making everything "web" friendly is backsliding desktop into horrible, non-native UI.
What is the closest thing we have left that is close to “mostly declarative GUI”? QML? Tk? Please don't say Electron.
Lazarus/Freepascal. Cross platform, real native x86_64/ARM/Atmel/Etc.
Re: No XBL Components Left in Firefox
#68Earlier quoted context omitted.
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.
With a 5,400 rpm, just the slow rotation can introduce a wait time of 11 ms. Seek time from moving the arm can incur up to 20 ms (although some of that might overlap with the rotation time). And if it's a ten year old HDD, there might be a re-read necessary. Even if the average read time would be just 20ms per file, cutting out ten of these reads saves 0.2 seconds, which is already noticeable to humans. And that's un…
> On a sidenote, laptops with 5,400 RPM drives are still sold.
And in the case of Apple also 4k iMacs. They even knowingly hide it now via a (non-existing?) footnote, seemingly hoping nobody clicks the "technical specs" button.
Re: No XBL Components Left in Firefox
#69Earlier quoted context omitted.
XUL is just themed to look like GTK it's no more native than HTML is.
If whatever’s rendering eventually maps to native API calls I’d consider it native, and I’m pretty sure GTK does native calls. If XUL really did mimic GTK (which I’m pretty sure it doesn’t, a lot of other GTk apps had the same feel as Firefox back when most of its UI was native dialogs) then it’s the best damn mimic job I’ve ever seen
XUL had bindings to supported native widgetsets.
Re: No XBL Components Left in Firefox
#70Earlier 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?
I think that XUL had better layout engines, suitable for apps instead of web pages. May be with modern CSS this gap is closed. Also native controls were nice.