A (potential?) solution for SDK extensions...
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.
This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.
Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.
This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.
Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
A (potential?) solution for SDK extensions...
OK, so, our very active community member JustOff has created a few modified versions of popular SDK extensions by making them bootstrapped add-ons (which we support) and linking SDK module calls to the Jetpack modules that are part of our toolkit (in use by the devtools and also used by the Web Developer extension Tobin released). I've been thinking about this way of doing this for SDK extensions, and want to propose the following:
What I offer:
I will make a promise to not touch the Jetpack modules (in essence, freeze their code) in /toolkit, with the exception of security updates where needed, and keep these modules present in the browser indefinitely. This will allow extension developers to make Pale Moon targeted extensions that are originally built for the Mozilla Add-on SDK (with some work, and of course needing some changes for our UI if targeting Australis). For the sake of ease, let's call these types of converted extensions "PMkit" extensions (or PMK if you insist on a 3-letter-acronym).
In tandem, I will extend support for issues with the browser that uses extensions built this way to the same level as any other extension, provided the extensions are converted with care.
What I ask:
I ask in return that the way to convert SDK extensions to PMkit bootstrapped extensions is documented. General, clear guidelines that extension developers can use to go from a Firefox SDK extension to a PMkit extension. We have a (currently very underdeveloped) Wiki that can be used for this at https://developer.palemoon.org/
If that doesn't suit you, any other easily-manipulated document format should work.
What I offer:
I will make a promise to not touch the Jetpack modules (in essence, freeze their code) in /toolkit, with the exception of security updates where needed, and keep these modules present in the browser indefinitely. This will allow extension developers to make Pale Moon targeted extensions that are originally built for the Mozilla Add-on SDK (with some work, and of course needing some changes for our UI if targeting Australis). For the sake of ease, let's call these types of converted extensions "PMkit" extensions (or PMK if you insist on a 3-letter-acronym).
In tandem, I will extend support for issues with the browser that uses extensions built this way to the same level as any other extension, provided the extensions are converted with care.
What I ask:
I ask in return that the way to convert SDK extensions to PMkit bootstrapped extensions is documented. General, clear guidelines that extension developers can use to go from a Firefox SDK extension to a PMkit extension. We have a (currently very underdeveloped) Wiki that can be used for this at https://developer.palemoon.org/
If that doesn't suit you, any other easily-manipulated document format should work.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A solution for SDK extensions...
Well... I'm not an extension developer, but this issue does concern me, so I think that it's a great idea . And, with the advent to WebExtensions in Firefox, Pale Moon will probably be the last browser that will support Jetpack/SDK extensions, so for those developers that don't want to rewrite their extensions (or just don't care, or... just gave up on developing and extension that actually don't need regular maintenance), this is a great solution. In fact, I think that Pale Moon might even increase it's userbase in a few years, when the whole Jetpack/SDK support is drooped in Firefox.
I work in IT, so I deal with people and problems on a regular basis. In most cases, I'm the one who does fresh Windows installs on a PC/Laptop (when needed), but in some cases, they come preinstalled (basic office installs, Office, Acrobat, Chrome, Firefox...). In the last year, I've seen two preinstalled Windows PCs that came with Pale Moon instead of Firefox. I've never seen this before. Usually, I was the one that... kind of forced Pale Moon usage (where applicable), but this is a great sign. This actually means that people that are in IT have started to recognize Pale Moon as a better option than Firefox. And, let's face it, your regular user uses the browser that "the IT guy" says it's best for your needs . So, if this trend continues, the user base might grow exponentially in a few years when Jetpack/SDK is dropped in Firefox .
I've found replacements for most of my Jetpack extensions, so I've solved my problem... as long as Pale Moon doesn't drop extension support entirely .
I work in IT, so I deal with people and problems on a regular basis. In most cases, I'm the one who does fresh Windows installs on a PC/Laptop (when needed), but in some cases, they come preinstalled (basic office installs, Office, Acrobat, Chrome, Firefox...). In the last year, I've seen two preinstalled Windows PCs that came with Pale Moon instead of Firefox. I've never seen this before. Usually, I was the one that... kind of forced Pale Moon usage (where applicable), but this is a great sign. This actually means that people that are in IT have started to recognize Pale Moon as a better option than Firefox. And, let's face it, your regular user uses the browser that "the IT guy" says it's best for your needs . So, if this trend continues, the user base might grow exponentially in a few years when Jetpack/SDK is dropped in Firefox .
I've found replacements for most of my Jetpack extensions, so I've solved my problem... as long as Pale Moon doesn't drop extension support entirely .
Re: A solution for SDK extensions...
I would appreciate seeing that documentation as well. I was going to start adding some info on XUL extensions, but gave up on registering. It kept reloading each time I typed the last character in the challenge string.
Re: A solution for SDK extensions...
Thank you, Moonchild, for this step toward the community needs!
I would gladly devoted my time providing all the necessary documentation on how to adapt SDK-based addons to Pale Moon 27, but there is one big problem.
In my experience, Jetpack modules currently embedded in Tycho are randomly inconsistent not only in regard to Australis UI, but in unpredictable ways. The lack of workable debugger for bootstrapped extensions not allowed me to dig deep enough to try to fix errors if they arise from SDK itself. And considering that such patching was named hacking and declared as unsupported I do not even dared to ask for help on how to deal with such troubles properly.
Thus when I tinkered with SDK-based addons to allow them to run in Pale Moon 27 it was a kind of guesswork: let's run it, if it die (silently in most cases), let's comment a part of code and try again, and so on. Don't even ask me how the resulting extensions are even able to work, it's a miracle)
So I think that we will not be able to move on until we find the way to revive embedded Jetpack and only then we could name it PMkit and speak about convertion from SDK. But at least until someone will suggest how to debug Jetpack in Pale Moon 27, I have no idea how we can even take a step forward.
I would gladly devoted my time providing all the necessary documentation on how to adapt SDK-based addons to Pale Moon 27, but there is one big problem.
In my experience, Jetpack modules currently embedded in Tycho are randomly inconsistent not only in regard to Australis UI, but in unpredictable ways. The lack of workable debugger for bootstrapped extensions not allowed me to dig deep enough to try to fix errors if they arise from SDK itself. And considering that such patching was named hacking and declared as unsupported I do not even dared to ask for help on how to deal with such troubles properly.
Thus when I tinkered with SDK-based addons to allow them to run in Pale Moon 27 it was a kind of guesswork: let's run it, if it die (silently in most cases), let's comment a part of code and try again, and so on. Don't even ask me how the resulting extensions are even able to work, it's a miracle)
So I think that we will not be able to move on until we find the way to revive embedded Jetpack and only then we could name it PMkit and speak about convertion from SDK. But at least until someone will suggest how to debug Jetpack in Pale Moon 27, I have no idea how we can even take a step forward.
Re: A solution for SDK extensions...
Well, it's the inherent problem with targeting our toolkit modules; that would be the task of individual extension developers how to figure out how to talk to our platform and application code. The main thing that needs to be documented is the general steps required to convert an SDK-style extension to a PMkit-style extension; i.e.: changes in included files, changes in resource paths needed, etc.
As an extension developer it will always be easier to figure out what needs changing in the actual extension code you yourself wrote, rather than trying to hack existing code into working
There will always be an inherent risk doing it this way, using the toolkit modules, but it is at the same time also the only way forward to bring SDK extensions across that don't have an alternative, short of completely rewriting an extension from the ground up. I also understand that none of the toolkit jetpack modules we have in v27 are documented anywhere, which makes things more difficult as there will only be code comments to draw on. Not all of them may be useful as-they-are either because of inherent Australis-poisoning.
All this will undoubtedly take time to figure out -- but I want to offer this as a way forward regardless. If the modules are going to be a reliable base that will not change, then research and documentation can be made as and when there is time.
As an extension developer it will always be easier to figure out what needs changing in the actual extension code you yourself wrote, rather than trying to hack existing code into working
There will always be an inherent risk doing it this way, using the toolkit modules, but it is at the same time also the only way forward to bring SDK extensions across that don't have an alternative, short of completely rewriting an extension from the ground up. I also understand that none of the toolkit jetpack modules we have in v27 are documented anywhere, which makes things more difficult as there will only be code comments to draw on. Not all of them may be useful as-they-are either because of inherent Australis-poisoning.
All this will undoubtedly take time to figure out -- but I want to offer this as a way forward regardless. If the modules are going to be a reliable base that will not change, then research and documentation can be made as and when there is time.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A solution for SDK extensions...
registration problem mentioned above solved - was apparently due to UA spoofing in uMatrix
Re: A solution for SDK extensions...
It seems that my English isn't good enough to properly explain what makes me anxious and why.
The point is not that I do not understood how some SDK-based addon is working and therefore I have had problem to adapt it to Pale Moon. The trouble is that even some simple SDK calls linked to PMkit are silently dying deep inside the browser and I can't find nor way nor tool to even get the error message.
Now, imagine that the way to convert SDK extensions to PMkit bootstrapped extensions is documented and the developer falls into such situation. What will he do? I think he will throw the conversion attempt and goes away. So, until we can't rely on PMkit or at least provide the tool to debug it, there is no sense to involve the SDK developers, because a such false start will only bring the harm.
I fully admit that maybe missed something or I just do not have enough knowledge. I'll be very grateful if someone will suggest how to debug this freaking SDK/PMkit without debugger for bootstrapped code.
PS: Even among the addons that I've already patched the only one of the eight can be disabled or uninstalled safely. The others seven don't release their hooks and memory until browser restart.
The point is not that I do not understood how some SDK-based addon is working and therefore I have had problem to adapt it to Pale Moon. The trouble is that even some simple SDK calls linked to PMkit are silently dying deep inside the browser and I can't find nor way nor tool to even get the error message.
Now, imagine that the way to convert SDK extensions to PMkit bootstrapped extensions is documented and the developer falls into such situation. What will he do? I think he will throw the conversion attempt and goes away. So, until we can't rely on PMkit or at least provide the tool to debug it, there is no sense to involve the SDK developers, because a such false start will only bring the harm.
I fully admit that maybe missed something or I just do not have enough knowledge. I'll be very grateful if someone will suggest how to debug this freaking SDK/PMkit without debugger for bootstrapped code.
PS: Even among the addons that I've already patched the only one of the eight can be disabled or uninstalled safely. The others seven don't release their hooks and memory until browser restart.
Re: A solution for SDK extensions...
So far, I don't know enough about what you did to give any specific advice. But if you copy code files from omni.ja and add them to the extension's code folder, you can edit those added files. That means there is a relatively easy way to debug. It's what programmers did in the days before error consoles and other debugging tools. Insert a line or two of code that gives some output that lets you know the program is running at that point. I still do that at times anyway.
I downloaded your modified DeCentral Eyes but still haven't looked at it (nor installed it). I'm not going to have a day off until after Christmas so not likely to be tinkering with code much.
I downloaded your modified DeCentral Eyes but still haven't looked at it (nor installed it). I'm not going to have a day off until after Christmas so not likely to be tinkering with code much.
Re: A solution for SDK extensions...
And.. how is that different from not trying to begin with?JustOff wrote:What will he do? I think he will throw the conversion attempt and goes away.
I understand why this worries you, but a "debugging tool" isn't going to happen (who will write such a thing?...) and thus far nobody knows anything about what you did to make the 8 or so extensions work that you worked on. If that gets documented, there will at least be some basis to look at an think about to improve. Unless you'd rather keep your method a secret...?JustOff wrote:So, until we can't rely on PMkit or at least provide the tool to debug it, there is no sense to involve the SDK developers, because a such false start will only bring the harm.
I think a prerequisite would be to make them flagged as "requires restart"JustOff wrote:The others seven don't release their hooks and memory until browser restart.
In the end, it's quite possible that it's not a feasible way forward, but if nobody tries, then it'll never happen - the fact that you've been able to (in a relatively short time) hook the extensions into the PMkit modules tells me there's likely not too much of a gap there, though.
EDIT: it should be clear by anyone reading this thread that there are not going to be any guarantees that it'll work. At most what can be written is guidelines -- as many extensions there are, as many potential failures.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A solution for SDK extensions...
Indeed yes, it is easy debug sdk modules on not packed instance of the browser. And the way of GreenGeek simple and reliable, using it myself too
inside some module N..
Code: Select all
mycon = Cc["@mozilla.org/consoleservice;1"] .getService(Ci.nsIConsoleService);
mycon.logStringMessage("Hello");
Code: Select all
mycon.logStringMessage("Hello from module N");
Re: A solution for SDK extensions...
Unfortunately the call of consoleservice from some routines within the bootstrapped addon produces zero output in global browser console. We need to access the console in context of addon to see something, but the embedded Add-on Debugger isn't workable in Pale Moon 27 now. Even dump() doesn't helps.Fedor2 wrote:Indeed yes, it is easy debug sdk modules on not packed instance of the browser. And the way of GreenGeek simple and reliable, using it myself too
Ok, looks like now I got your point. I will write in detail on a specific example what I did with SDK-based addon to make it work in Pale Moon. I hope this will help to make step forward and may be we will find the proper way to debug and so on. But once again I want to warn all that such info should not be considered as a guide, but only as a study report and as a starting point for further investigations.Moonchild wrote:I understand why this worries you, but a "debugging tool" isn't going to happen (who will write such a thing?...) and thus far nobody knows anything about what you did to make the 8 or so extensions work that you worked on. If that gets documented, there will at least be some basis to look at an think about to improve.
Re: A solution for SDK extensions...
Yes, please document how to port SDK add-ons to PM. I would like to port my SDK add-on Infocon Watcher to Pale Moon. If I could do that without rewriting it in XUL, that would be great.
My other add-on IsAdmin is a XUL-based add-on and works on PM without modification. I will probably request to have it hosted on the Pale Moon add-ons site, if you want it.
My other add-on IsAdmin is a XUL-based add-on and works on PM without modification. I will probably request to have it hosted on the Pale Moon add-ons site, if you want it.
Re: A solution for SDK extensions...
What? JustOff documented his process in this very thread, as follows:Moonchild wrote:I understand why this worries you, but a "debugging tool" isn't going to happen (who will write such a thing?...) and thus far nobody knows anything about what you did to make the 8 or so extensions work that you worked on.
Which is...well...not very helpful to anyone trying to determine a more targeted way of updating extensions. And I agree that it is a miracle that any extension updated by this "guess which part to comment out and hope nothing critical breaks" method works at all.JustOff wrote:Thus when I tinkered with SDK-based addons to allow them to run in Pale Moon 27 it was a kind of guesswork: let's run it, if it die (silently in most cases), let's comment a part of code and try again, and so on. Don't even ask me how the resulting extensions are even able to work, it's a miracle
- TwoTankAmin
- Keeps coming back
- Posts: 777
- Joined: 2014-07-23, 13:56
- Location: New York
Re: A solution for SDK extensions...
As most know I am not well informed on all this stuff. But I just read this:
Cortana to open up to new devices and developers with Cortana Skills Kit and Cortana Devices SDK
https://blogs.windows.com/buildingapps/2016/12/13/cortana-skills-kit-cortana-devices-sdk-announcement/#JEoVyqQ6GugORCbP.97
Is the same SDK as in this thread? And if so, what does this mean for SDK extensions in general going forward?
Cortana to open up to new devices and developers with Cortana Skills Kit and Cortana Devices SDK
https://blogs.windows.com/buildingapps/2016/12/13/cortana-skills-kit-cortana-devices-sdk-announcement/#JEoVyqQ6GugORCbP.97
Is the same SDK as in this thread? And if so, what does this mean for SDK extensions in general going forward?
“No one has ever become poor by giving.” Anonymous
“Everyone is entitled to his own opinion, but not to his own facts.”" Daniel Patrick Moynihan
"The good thing about science is that it’s true whether or not you believe in it." Neil DeGrasse Tyson
“Everyone is entitled to his own opinion, but not to his own facts.”" Daniel Patrick Moynihan
"The good thing about science is that it’s true whether or not you believe in it." Neil DeGrasse Tyson
Re: A solution for SDK extensions...
"A software development kit (SDK or "devkit") is typically a set of software development tools that allows the creation of applications for a certain software package, software framework, hardware platform, computer system, video game console, operating system, or similar development platform."
https://en.wikipedia.org/wiki/Software_development_kit
It's a general term and has not a thing to do with PM's extensions.
https://en.wikipedia.org/wiki/Software_development_kit
It's a general term and has not a thing to do with PM's extensions.
- TwoTankAmin
- Keeps coming back
- Posts: 777
- Joined: 2014-07-23, 13:56
- Location: New York
Re: A solution for SDK extensions...
@ eskaton023
TY
TY
“No one has ever become poor by giving.” Anonymous
“Everyone is entitled to his own opinion, but not to his own facts.”" Daniel Patrick Moynihan
"The good thing about science is that it’s true whether or not you believe in it." Neil DeGrasse Tyson
“Everyone is entitled to his own opinion, but not to his own facts.”" Daniel Patrick Moynihan
"The good thing about science is that it’s true whether or not you believe in it." Neil DeGrasse Tyson
Re: A solution for SDK extensions...
As I promised, here it is: How to modify Firefox SDK-based addon to run in Pale Moon 27 by the example of RES (Reddit Enhancement Suite) with detailed comments.
I'm afraid that currently your addon cannot be ported to Pale Moon 27 without complete rewrite.IByte wrote:I would like to port my SDK add-on Infocon Watcher to Pale Moon. If I could do that without rewriting it in XUL, that would be great.
Re: A solution for SDK extensions...
Thanks for the explanation. I see it is a very minimalistic patch, just the bare minimum to get it running. And probably more likely to not work in the future. But it gives me ideas of how it could be done better, if there's a need.
Re: A solution for SDK extensions...
Maybe I'll write a XUL version then.JustOff wrote:I'm afraid that currently your addon cannot be ported to Pale Moon 27 without complete rewrite.IByte wrote:I would like to port my SDK add-on Infocon Watcher to Pale Moon. If I could do that without rewriting it in XUL, that would be great.
Why can't my add-on be ported, by the way? If I grab a version that was based on an older version of the SDK, might that help?
Re: A solution for SDK extensions...
Is there anyone out there that might want to try making TUMBLR Savior work properly? It's the one add-on I can't find any substitute for. The latest version is a Web Extension and doesn't work, but there are older SDK versions on the previous versions. It serves to block certain content from TUMBLR like XKIT but a bit simpler. I would try, but I'm hopeless with anything more complicated than HTML or CSS.
https://addons.mozilla.org/en-US/firefo ... /versions/
https://addons.mozilla.org/en-US/firefo ... se/421051/
https://addons.mozilla.org/en-US/firefo ... /versions/
https://addons.mozilla.org/en-US/firefo ... se/421051/