Open RealRaven2000 opened 3 years ago
it will become harder to change or augment the existing UI of Thunderbird Core
Does this mean that you'll no longer be able to offer an option to change the behavior of the native TB "n" key? By default, it prompts when moving to a next unread message that's in a different folder, but QF offers an option to suppress that prompt. Will QF still be able to suppress it?
it will become harder to change or augment the existing UI of Thunderbird Core Does this mean that you'll no longer be able to offer an option to change the behavior of the native TB "n" key? By default, it prompts when moving to a next unread message that's in a different folder, but QF offers an option to suppress that prompt. Will QF still be able to suppress it?
I think it will still be possible to have user-defined shortcuts - should be covered here: https://thunderbird-webextensions.readthedocs.io/en/latest/commands.html
As regards changing Thunderbird internal options, I will need to investigate. It's just a flag in about:config so that is still available for manual change but of course I prefer if there is a UI for that. A good place to ask this question would be the Addon Developers chat on matrix: https://app.element.io/#/room/#tb-addon-developers:mozilla.org
Just a heads up for commenters - I am locking this conversation for non-contributors because this is purely a documentation thread and I avoid it becoming too long / hard to read. I will probably clean up some of the comments as well - hope you don't mind. We can always start a new issue as a discussion thread for this area. If you are a code contributor feel free to add a comment, but keep the discussion short if possible.
In yesterday's Zoom meeting John moved out the RSA modules into separated ES6 "msj" files, we then encountered the main problem of having many calls to the "hasPremiumLicense()" function which needs to be changed to async. This will have a knock on effect to many modules. The strategy decided instead will be to put the license validation logic in the background and run it on startup, then broadcast copies of the validation state to all windows that will implement listeners for this event and use local copies for caching state. It will also require a communication down to the background script from the options window when a new license is entered or the license is removed.
For all changes related to issue #147 we created the new branch ESR78-backgroundLic which can be later used for upmerging - this will be a while until it is functional again.
There is more ongoing work with the RSA module - John managed to re-implement the Licenser running via the background page in the ESR78-backgroundLic branch - the next step will be implementing a passive "cached" version for the part of the Licenser that holds information about the current licensing status to be consumed synchronously by the legacy parts of the front-end code. And there will be a broadcast to all windows that implement a "licensing listener" to update the information if a new license is enterd (and on Add-on startup).
This way I can keep thing like my beloved "getters" (which are not supported by ES6 modules) and have minimal refactoring effort on the front-side. One thing I had to change in my preparation was to remove the parameter and "license validation check" logic of QuickFolders.Util.hasPremiumLicense(reset)
- which only was called twice from the code with a truthy reset
argument. I will probably also convert the method into a getter for clarity.
A lot of work happened in the meantime, just decided to check in the latest changes.
extensions.quickfolders.debug.premium.licenser
as beforeTest version: QuickFolders-wx-5.6pre187.zip
After having gathered some experience with SmartTemplates I found out that the new APIs create a roadblock against users updating. My theory is that users have "automatic updates" enabled but aren't updated because they need to click on the "QuickFolders needs new permissions" menu item which is hidden under the hamburger menu. This menu is not presented to the users automatically, so they have to actually open the hamburger menu with intent to get the update. This is counter-intuitive which leads to a large portion of users staying behind - see [issue #165] for the data on this.
I am currently doing a test with SmartTemplates 3.6 where I removed the APIs and necessary permissions to see whether the imbalance between up-to-date users and users with the older version (which didn't require added permissions) will quickly level out. This would mean that the way that permissions are currently handled inefficiently by the platform (toolkit) leading to many out-of-date Add-ons. Since I am sensitized to this issue I now also found that I had some outdated Add-ons on Waterfox (read: Firefox classic) without noticing: it only displays a small yellow square with an explanation mark on top of the hamburger menu. This isn't strong enough as a signal to prompt the users for updating their Add-ons.
John Bieling suggested that our Add-ons could do the check whether a new version exist themselves (he provided me an experimental Add-on that queries the thunderbird.net api address looking for the latest hosted version) and then prompt the user to allow installing it. Other than scrapping web APIs altogether, this may be the only workaround that is currently available to us. As we absolutely must have permissions for native mail extension (mx) conversion I will start on creating a strategy for this.
This Issue will document the process of rewriting QuickFolders code to eliminate as much of the internal XPCOM calls that it currently uses by the official API calls instead. While QuickFolders is in the "Mail extension with experimental APIs" stage, APIs cannot be called directly from the current, privileged code. Instead we are going to use John Bieling's notifyTools library to establish a 2-way messaging channel to the background script and execute backend code (asynchronously) through ES6 modules which will live in the API folder as experimental libraries.
This is an important part of the transition to being a pure "mail extension" (without experiment) but also will yuield some other benefits:
While these are good things we have to also remember that some things are currently (and may never be) possible without using legacy / experimental code:
We have a conversion meeting with John Bieling and some other Add-on developers this evening and will start one conversion in QF as a pattern to move forward.