Open jobisoft opened 3 weeks ago
tomaszkrajewski
commented
3 weeks ago For addon usability perspective the best place to locate combo is next to subject field. For me, and other personally known users, it's huge improvement on efficiency.
There was also other way to initiate releases ago -> via suboptions (submenu) under Write message button, but stopped to work some TB updates ago.
No way to inject around subject when working as WebExtension ?
jobisoft
commented
3 weeks ago Another WebExtion-ish approach (if you do not like the button in the toolbar) would be to have a menu entry in the context menu of the Subject field. But adding a button "somewhere" in the Thunderbird UI is not compatible with the WebExtension framework.
You can remain an Experiment and use the full-access-permission to create the button in the current location, if this really is what your users want. This would change the outlined roadmap and replace the 4th task with creating a dedicated Experiment for the button. But this will require you to continue to manually push updates for each new Thunderbird release (and we are going to release monthly).
The UI interface in the main window could be solved by a context menu entry of the write-message-button. Modifying the existing button is not possible through WebExtension currently. You could also add your own write-message-button which your users can use instead (and let them hide the original one).
tomaszkrajewski
commented
3 weeks ago 1/ I sense that, at least for me, the acceptable solution will be to have dedicated button for new message with prefixes in the messenger window (as you wrote) and context menu on subject and content (as it's now) on message window.
Plus regular button from toolbar for the ones who likes it.
2/ Build process & extra files - for me it takes now 5 secs to build + 30 secs to click in TB to propagate new artifact - years ago TB was having some cache, there was need to restart to be sure that modified files are picked; I'd be happy to move forward, but I need to trust the changes ;). Is there any up to date complete tutorial/guide how to work with development (publicDist, setting the version) ?
jobisoft
commented
3 weeks ago The way to develop now is to use the temporary install. Go to the add-on manager, select the gear icon and select debug add-ons. There, select to install a temporary add-on. In the opened file picker select the manifest.json file of your project. The add-on will be installed directly, without creating an xpi. You can make changes to your code and just select reload, which will reload your add-on and pick up the changes. I will try to find a more detailed guide. All I have now is
https://developer.thunderbird.net/add-ons/hello-world-add-on
jobisoft
commented
3 weeks ago FYI: we do not have to make strategic decisions now. For me the most important part is that you are active around here and responsive. Otherwise it would have been risky for me to invest time into actual changes. The work required here is much greater compared to AlertSwitch.
From our discussion in AlertSwitch I learned that you would like to keep some sort of build process for versioning and debugging. Would you be OK with me removing the current build process and you later add a more simplified process back in, or would you like to modify the current code before I start contributing? In order for me to contribute, the source must be hot-loadable. It would be OK for me, if I manually have to replace two or three placeholders (version, debug, ...) to make the source directly runnable, which I do not commit back. But I would like to avoid the building during development.
tomaszkrajewski
commented
3 weeks ago Today i've spent some time to see AlertSwitch after changes and see how to debug / replace addon. Tommorow I'll conclude your MR & my expectations, then I'd update the build for SubSwitch to let you focus on things where I'm lost.
tomaszkrajewski
commented
2 weeks ago Please see the updated subswitch repository, for me it worked to temporary load addon from src directory. The build process of the releasable extension lightened a little.
tomaszkrajewski
commented
1 week ago @jobisoft I see that you initiated some activities by cloning the repo. Are you one the subject? How to move forward?
jobisoft
commented
1 week ago Yes, thanks for these changes. I will file a few PRs shortly. The next steps are:
messenger.WindowListener.registerChromeUrl()messenger.WindowListener.registerDefaultPrefs()messenger.WindowListener.registerOptionsPage()That will be the part which keeps you from moving forward. The next step is then the decision about the UI elements you want to keep using. Reduced comfort but pure WebExtension vs. Experiment code with custom UI elements.
jobisoft
commented
1 week ago PR for the locale files has been filed: #8.
tomaszkrajewski
commented
3 days ago A. Concerning frontend functionality. I believe we need in the message compose window the 2 ways to play 1/ button on toolbar to pick the prefix (as SignatureSwith works) 2/ button under right mouse click over the window (as it's now) + over the message header (as you've proposed)
B. Concerning 'backend' functionality, there is hook on when replying a message to look for the prefix and use this one. I like this feature.
C. As the nice to have, future development, I will try to proceed with the button on the messenger window for new message with already chosen prefix. But for me its future.
How to move forward with A & B ? What about HTML instead of XUL in options & discovery dialogs?
jobisoft
commented
3 days ago It is too early to think about frontend or backend functionality changes. In the end, you will be able to have the same features as now by using Experiments for the parts which are not doable via standard WebExtension APIs. But as I outlined earlier, some things will never become available through WebExtension APIs. Switching to a WebExtension UI entry point could be considered, to reduce your maintenance work, even if that is not a perfect match.
The next big step is converting your options page from XUL to HTML. I filed PR https://github.com/tomaszkrajewski/tb-subswitch/pull/9 which gets you going and shows how to load and save the existing preferences in the new HTML options page. But it will need more work. I will be available for questions and support (and you are also invited to join the weekly add-on developer channel to discuss update related issues). This issue is of course also a good place to discuss the update process.
Once the HTML options dialog is done, and we can purge the old XUL dialog, we can tackle the discovery dialog.
Hi, this is John from Thunderbird's add-on team. I would like to make a few proposals on how to move forward. I also offer to help to actually implement the proposed changes.
This add-on is still using the Windowlistener API which was created 4 years ago to help add-on devs to make the transition to the new WebExtension technology. With Thunderbird 128, we are no longer supporting the API anymore. While you could update the API on your own, I highly suggest a different path and turn this extension into a pure WebExtension.
From what I can see, the main feature of this add-on is the dropdown selector in the subject line in the message composer. This is not possible with WebExtensions, but we can get very very close: We can add the exact same button (with a menu dropdown) in the toolbar of the message composer:
If this is acceptable, we can convert this extension to a pure WebExtension, reducing your update work to a minimum. This will allow your users to switch to Thunderbird's monthly release channel (the work needed to update your current legacy Extension each month to be compatible with the current release will probably not be feasible).
The next steps would then be the following:
We could file for each task a separate issue to keep track of the work. Looking forward to hearing from you.