Modern guide to XUL?

[PseudoDistant]

I found the SDK for Firefox 52, but I'm still struggling with actually using it. It seems Firefox 52's WebIDE no longer works, and every guide I've found on how to set it up in VS Code refers to really old versions of VS Code and no longer even work with current builds.

Okay nevermind, the Gecko SDK I found (from Mozilla's archive) doesn't have a XPIDL binary, and the Python files seem to do nothing...

[athenian200]

I found the SDK for Firefox 52, but I'm still struggling with actually using it. It seems Firefox 52's WebIDE no longer works, and every guide I've found on how to set it up in VS Code refers to really old versions of VS Code and no longer even work with current builds.

I do have to admit, we haven't really managed to create a lot of resources to help people create new projects built on XUL/XPCOM in a serious way, despite trying to maintain that technology. Instead, we are providing a platform that allows existing XUL and XPCOM projects and their forks to continue working... in other words, everything is currently setup a lot more for legacy support of existing projects than it is for giving people what they need to create new ones.

It doesn't help that Mozilla has gotten rid of what little documentation existed, and allowed a lot of the tools associated with it to bitrot and become useless long before XUL itself was dropped.

I mean, I would like to do more on that front, but we've all had our hands full keeping UXP and our UXP applications alive. For instance, I didn't know that Mozilla had an SDK or that there was ever any kind of WebIDE. You probably know more about how this stuff was initially developed than I do.

[PseudoDistant]

I do have to admit, we haven't really managed to create a lot of resources to help people create new projects built on XUL/XPCOM in a serious way, despite trying to maintain that technology. Instead, we are providing a platform that allows existing XUL and XPCOM projects and their forks to continue working... in other words, everything is currently setup a lot more for legacy support of existing projects than it is for giving people what they need to create new ones.

It doesn't help that Mozilla has gotten rid of what little documentation existed, and allowed a lot of the tools associated with it to bitrot and become useless long before XUL itself was dropped.

I mean, I would like to do more on that front, but we've all had our hands full keeping UXP and our UXP applications alive. For instance, I didn't know that Mozilla had an SDK or that there was ever any kind of WebIDE. You probably know more about how this stuff was initially developed than I do.

Yea it looks like this.



Unfortunately, when you try to register a new app, it tries to download something, and fails immediately. It's not usable at all.
Do you know of a simple XPCOM project (that builds) that I could fork? That might be easier.

[PseudoDistant]

Yea it looks like this.

I should immediately clarify that I deleted my Firefox profile folder a long time ago, it's complaint of "This can occur if you've used this profile with a newer version of Firefox" is irrelevant, since it's a fresh profile.

[FranklinDM]

WebIDE is an entirely different and unrelated tool - it is used for remotely debugging Firefox OS or Firefox for Android. If you're looking into creating a binary XPCOM component (?), you might want to check existing extensions that make use of it instead, such as MinTrayR.

[PseudoDistant]

WebIDE is an entirely different and unrelated tool - it is used for remotely debugging Firefox OS or Firefox for Android. If you're looking into creating a binary XPCOM component (?), you might want to check existing extensions that make use of it instead, such as MinTrayR.

MinTrayR's use of XPCOM doesn't seem to match anything in UDN, nor does it actually seem to compile it's native code.. Do XPCOM binaries not compile?

EDIT: I saw the Makefile, and it clearly should do something, but the source files are still present in the XPI, even after installation. There seems to be no binary for it, unless I missed it.

[adoxa]

build.py does not build the binaries, looks like you have to do so manually; they are then generated directly in the lib directory (Windows) or via make install (or make cp).

[PseudoDistant]

build.py does not build the binaries, looks like you have to do so manually; they are then generated directly in the lib directory (Windows) or via make install (or make cp).

I don't get it, is `export-versionscript` how you define exposed functions in newer (post-UDN) XPCOM?

[mrnhmath]

Hello, I'm the responsible for restoring the XULRunner runtime into the platform, but I've yet to set up build infrastructure for XULRunner/Goanna SDK.

You can build the SDK by doing

Code: Select all

./mach build

from the UXP tree and then

Code: Select all

./mach sdk

from the resulting obj directory.

[PseudoDistant]

Hello, I'm the responsible for restoring the XULRunner runtime into the platform, but I've yet to set up build infrastructure for XULRunner/Goanna SDK.

You can build the SDK by doing

Code: Select all

./mach build

from the UXP tree and then

Code: Select all

./mach sdk

from the resulting obj directory.

Is there better XPCOM documentation than on UDN tho?

The SDK only does so much if I can't learn how to use it.
(I could read the source and try to figure it out myself, but that didn't go exactly as I'd have hoped last time I tried that on not Java code...)

[moonbat]

Is there better XPCOM documentation than on UDN tho?

Sadly, no - UDN itself is an archive of what was Mozilla's own moth eaten documentation at that point. Going through it one thing is clear - documentation was always Mozilla's Achilles' heel - despite having a powerful application platform that could create desktop applications using just XUL and Javascript with XPCOM components as necessary - lack of complete and well structured documentation means you just have to perform archaeology on what's left to find useful pages.

[adoxa]

I don't get it, is `export-versionscript` how you define exposed functions in newer (post-UDN) XPCOM?

Indirectly, as I expect it's the general way to indicate what the .so file should export (not really sure, I'm a Windows user).

[PseudoDistant]

Sadly, no - UDN itself is an archive of what was Mozilla's own moth eaten documentation at that point. Going through it one thing is clear - documentation was always Mozilla's Achilles' heel - despite having a powerful application platform that could create desktop applications using just XUL and Javascript with XPCOM components as necessary - lack of complete and well structured documentation means you just have to perform archaeology on what's left to find useful pages.

Damn, looks like I have a fun few weeks ahead of me.

[soundmodel]

Maybe we could start a XUL doc project. I am also interested in it as an app framework. I started with Mozilla Web API, which is fine for general use.

OTOH, the Mozilla-side argument seems to be that HTML5 is more useful than XUL by now.

[Moonchild]

OTOH, the Mozilla-side argument seems to be that HTML5 is more useful than XUL by now.

That's nonsense. HTML5 (i.e. WebExtensions) runs in a web container and only has access to what little APIs have been made available to it. By definition it cannot do all that XUL can.
XUL, on the other hand, can import the HTML namespace and use html5 elements inside it if it wants, and get access to HTML elements inside XUL.
So it's literally the other way around.

[PseudoDistant]

That's nonsense. HTML5 (i.e. WebExtensions) runs in a web container and only has access to what little APIs have been made available to it. By definition it cannot do all that XUL can.
XUL, on the other hand, can import the HTML namespace and use html5 elements inside it if it wants, and get access to HTML elements inside XUL.
So it's literally the other way around.

Really, Mozilla's just been stripping back because Baker wanted more mons...
I distinctly remember some Mozilla developer releasing a statement on "what really happened" and why they killed XUL sometime a couple years back, and it could be summarized to:
"We had a lot of development costs, we needed to support developers, and some developers didn't like when some things broke because of an update."
Yeah no shit, that's called "maintaining a framework", they just outsourced that work to Google.
I really believe UXP is the last hope for the modern web, Mitchell Baker's spawn that succeeded her isn't going to fix anything.
Sorry for being doomer, I'm just very passionate about the non-corporate web. I come from a better time, it hurts.

[athenian200]

Really, Mozilla's just been stripping back because Baker wanted more mons...
I distinctly remember some Mozilla developer releasing a statement on "what really happened" and why they killed XUL sometime a couple years back, and it could be summarized to:
"We had a lot of development costs, we needed to support developers, and some developers didn't like when some things broke because of an update."
Yeah no shit, that's called "maintaining a framework", they just outsourced that work to Google.
I really believe UXP is the last hope for the modern web, Mitchell Baker's spawn that succeeded her isn't going to fix anything.
Sorry for being doomer, I'm just very passionate about the non-corporate web. I come from a better time, it hurts.

Yeah. This is why we're here. Truth be told, the state of XUL in our current codebase isn't ideal, but it is much better than modern Mozilla... by the time we forked off, Mozilla had already started the process of removing the less frequently used parts of XUL that most users playing around with extensions and themes wouldn't notice. We forked off the last working state with full support for XUL as used by themes, extensions, and applications, but that particular state isn't well-documented, and most documentation is from the earlier era back when Mozilla still cared. I think we have the highest compatibility possible with the majority of extensions created for Firefox that we can have, without compromising on other things.

[PseudoDistant]

Yeah. This is why we're here. Truth be told, the state of XUL in our current codebase isn't ideal, but it is much better than modern Mozilla... by the time we forked off, Mozilla had already started the process of removing the less frequently used parts of XUL that most users playing around with extensions and themes wouldn't notice. We forked off the last working state with full support for XUL as used by themes, extensions, and applications, but that particular state isn't well-documented, and most documentation is from the earlier era back when Mozilla still cared. I think we have the highest compatibility possible with the majority of extensions created for Firefox that we can have, without compromising on other things.

I really can't understand the people who think Mitchell Baker is some sort of messiah. I've heard people praise her achievements, while completely ignoring what she actually does.
Thank you for working on and maintaining one of the last usable web browsers out there.. If only more devs would look at XUL again...

[mrnhmath]

@PseudoDistant If you're still interested, the correct command for generating the Goanna/XULRunner SDK
from the XULRunner objdir is

Code: Select all

make client.mk sdk

instead of

Code: Select all

./mach sdk

Apologies for the noise, I'm just getting back on work.

[PseudoDistant]

@PseudoDistant If you're still interested, the correct command for generating the Goanna/XULRunner SDK
from the XULRunner objdir is

Code: Select all

make client.mk sdk

instead of

Code: Select all

./mach sdk

Apologies for the noise, I'm just getting back on work.

You're good.
Of course I'm interested. I unfortunately have a few issues I need to address right now, but I absolutely need a non-Chromium alternative, even if that means I have to get my hands dirty with Chromium (I created a page on my site, but the gist of it is "I want to make ChromeTab because I don't want to use ChromeTab in the future").
I really hope Pale Moon and Basilisk pick up, with Mozilla continuing down the road of enshittification, I don't want to live in a Chromium world.