Call add-on sdk functionality from Positron

[Happy-Ferret]

I see that the add-on sdk is part of the source.
Does that mean we can somehow call into it from within Positron or is this merely a relic of its upstream mozilla-central/gecko-dev heritage?

[mykmelez]

You should be able to call into it (I haven't tried, so I can't say for sure), although it's also a relic of Positron's heritage, and it isn't intended to be part of the public API.

Is there an API in particular that you'd like to use?

[Happy-Ferret]

Nothing in particular (I did try the notifications module).
Unfortunately, Positron can't seem to discover those modules and if I supply the full path to notifications.js, it will just complain about not finding chrome (which, AFAIK, is built-in and doesn't have an absolute file system path).

[mykmelez]

Unfortunately, Positron can't seem to discover those modules and if I supply the full path to notifications.js, it will just complain about not finding chrome (which, AFAIK, is built-in and doesn't have an absolute file system path).

Right, I think you'd need to first load the Add-on SDK's loader, then use that to load the SDK's modules. Loading the SDK's loader entails doing something like what the SDK's bootstrap.js script does, which is quite complicated:

https://github.com/mozilla/positron/blob/master/addon-sdk/source/app-extension/bootstrap.js#L193-L258

However, it could probably be made to work via that code, perhaps with some modifications. (The devtools code uses a similar loader to load its modules.)

Out of curiosity, what's your use case for Positron?

[Happy-Ferret]

Thanks. I'll give that a try when I'm off work this weekend.

My use case is probably the worst kept secret in the history of secrets.
I've spent the past three years working on a Mozilla tech based desktop OS.

I've yet to mirror any of the code to my public Github repositories, but here's a screenshot from pre-Christmas 2016 (two apps -- one a code editor of my own making. The other an existing progressive web app I found -- and a preliminary but functional app manager).

As you can probably tell, I'm using XUL for the application windows still.

Any plans of specifying/implementing a CSS property similar to -webkit-app-region, btw?

[mykmelez]

My use case is probably the worst kept secret in the history of secrets.
I've spent the past three years working on a Mozilla tech based desktop OS.

Ah, fascinating! And how might you use Positron in your project? I'm also interested in whether SpiderNode support is a key requirement, or if it's merely a nice-to-have (or a "don't want").

[mykmelez]

Part of the reason I'm asking these questions is that I've been thinking about rebooting Positron—or starting a different project—that provides a simpler Mozilla-based application runtime that doesn't try to emulate Electron but rather provides a different (and more constrained) set of APIs (although it might still integrate SpiderNode, unsure). So understanding your use case better would be useful!

[Happy-Ferret]

I've only tried SpiderNode for a wee bit back around Christmas. I absolutely loved it back then though. First thing I tried there was the wonderful notification API (dunno what it is with me and notifications. I just love smooth, colourful popups. Lol)

I think strategically, refocusing Positron efforts would make more sense than starting a new project.
While "re-inventing the wheel" can be intellectually stimulating, Electron is here to stay and it would make sense to increase its surface area. People are more likely to write software for something they know and love than retrain for an entirely new system with no clearly visible benefit.

When Positron can reach feature parity with Electron, you essentially create a situation in which everyone's efforts and costs to market are reduced.

Not to forget about the hundreds upon thousands of node modules people are used to and will not let go easily.

EDIT: As for how I would use Positron in my OS: It could be (part of) the application runtime. My OS will support both, progressive web apps (either inside windows/surfaces or in more traditional web tabs) and fully standalone applications. Currently the latter are written against the XUL runtime, using a mixture of XPCOM, the addon-sdk and a loose, home grown collection of CommonJS modules/ES6 classes.

[mykmelez]

I think strategically, refocusing Positron efforts would make more sense than starting a new project.

Note that the two options (rebooting Positron and starting a new project) would likely have the same outcome, in that there'd be an application runtime project with a set of features that are different from the ones that Positron currently has (or expects to have in the future). The difference would only be whether we evolve the Positron codebase into that new thing or start a new project to implement it.

While "re-inventing the wheel" can be intellectually stimulating, Electron is here to stay and it would make sense to increase its surface area. People are more likely to write software for something they know and love than retrain for an entirely new system with no clearly visible benefit.

When Positron can reach feature parity with Electron, you essentially create a situation in which everyone's efforts and costs to market are reduced.

I definitely agree about Electron being here to stay. However, Positron cannot reach feature parity with Electron, at least not by reusing its implementations. That's my conclusion after doing a lot of work to reuse Electron's <webview> implementation in Positron, which is very specific to Chromium's internals, and thus very hard to reuse for Gecko.

I suspect that it would be hard to reach feature parity with Electron even if we didn't reuse its implementations, given their head start and momentum. However, it also isn't necessary in order to achieve worthwhile goals, as it's possible to be a viable application runtime with a useful subset of Electron's functionality. Especially if we can offer other benefits, such as the performance and stability improvements that Gecko will see in 2017 with the Quantum project.

Not to forget about the hundreds upon thousands of node modules people are used to and will not let go easily.

Yes, I agree, which is why I'm considering continuing to prioritize SpiderNode integration for a "rebooted Positron." Node provides not only a useful (albeit redundant, given NSPR and XPCOM) set of core system integration APIs, but it also offers a broad ecosystem of third-party APIs—and the loader to take advantage of them.

Node is also an easier target to hit, despite being a moving target itself, because of the Node community's efforts to achieve "VM Neutrality" (as described in https://blogs.windows.com/msedgedev/2016/11/29/node-chakracore-vm-neutrality/https://blogs.windows.com/msedgedev/2016/11/29/node-chakracore-vm-neutrality/).

[Happy-Ferret]

Ah. Alright.

Guess I misunderstood you a bit there.
As long as the resulting project is node compatible, I'm fine with either.

And I agree that we don't necessarily need all features.

Personally, the main feature I like about Electron isn't even in Positron.
Namely, frameless, transparent windows with a drag target.

[mykmelez]

Personally, the main feature I like about Electron isn't even in Positron.
Namely, frameless, transparent windows with a drag target.

Ah, that's good to know. It also seems like something that we should be able to implement in an application runtime on Gecko, since I think the underlying platform supports it.

[mykmelez]

Any plans of specifying/implementing a CSS property similar to -webkit-app-region, btw?

I just remembered that I hadn't answered this question. I don't have any plans at the moment, although it seems doable.

In general, I haven't been working much on Positron, which is why you don't see too many commits in the last couple months. I am still thinking about how to evolve/replace it, though. And I expect to spend more time on it (or something else that addresses similar use cases) this year.

[Happy-Ferret]

Glad to hear there will be more work on Positron/a possible alternative.
Let's make 2017 the year of the Firefox Desktop 😉