Moonchild wrote:Your alternative proposal will cause confusion because resource paths and front-end assumptions inside the extension would be incorrect. From an add-on extension developer's point of view, what do you expect them to use anyway? JPM+Firefox would be the only option for that because we don't supply development and packaging tools for these kinds of extensions, ourselves, and JPM from Firefox doesn't know about Pale Moon as a target application either (our jetpack modules have explicit additions for Pale Moon as an application and front-end in a few places).
JPM does not care about the inside design of jetpack modules or any specific features of target applications. It can successfully test, run and package extensions for Pale Moon 27 (the same way that it does it for Firefox, Thunderbird, SeaMonkey, etc) without need of any adjustments in its code.
JPM + Pale Moon is enough for the full development cycle. I checked it.
If you're going to have to go in to change the paths anyway, then you should be explicit and change the manifest name while you're at it.
Do you really expect SDK extensions targeting FF38 and its front-end to be compatible with Pale Moon's application code? Because you seem to assume that they are, while those would be targeting Australis... Those need to be adjusted anyway.
You are right, but if we rename package.json the developers will need to do many unnecessary and unnatural steps just to be able to use JPM.
I don't intend for Pale Moon to come with extension SDK development tools (and somehow provide support for them with our non-existent SDK support team). If people want to use this, then they will have to take the extra steps.
Why? because of the very real risk that users (in many cases not developers) will otherwise hack install.rdf, add a Pale Moon ID as target application (which I'm sure a number already have since v25) and then expect it to "just work" while it can't (in many cases) -- and then load support for that off on us, because "it works for this other add-on".
How is this different from the situation when users will rename package.json and then expect it to "just work" while it can't (in many cases) and then load support because "it works for this other add-on"?
No, on the browser side it must be distinct and different from Firefox SDK to avoid any sort of confusion or muddling of the waters. JPM may be used on Firefox to create a base SDK extension to work from, but any conversion to PMkit will always have to be done manually or it will cause problems, and JPM can't be used to run and/or debug PMkit extensions, as far as I understood.
Fortunately it can be used, and it's cool! Even when Firefox will deprecate itself by removing support of XUL and SDK add-ons we will remain solid.
I know the SDK caters to lazy extension development to begin with, but I'd rather not feed more into that and letting developers assume we're "just another Firefox" to them when they need to take great care if they want to adjust their work for use on Pale Moon.
I'm going to write the guide that will explain these differences and how to properly adjust extensions created using SDK for Firefox to run with PMkit. And I think that possibility of using JPM is important, otherwise it will be the guide how to hack instead of how to develop.
