Bugzilla

Hi Alessandro, thanks for those information.

WebExtAPI allow to add buttons in 5 locations:
 * browser_action: main_toolbar and tabs_toolbar (next to the current calendar and tasks icons)
 * message_display_action: message_header_toolbar
 * compose_action: compose_toolbar and format_toolbar

For all these buttons the add-on defines a name, an icon and some other props and the API generates the core code to actually add the button. 

We can change the API to use different code to add the button, but we need to keep the interface compatible (see https://webextension-api.thunderbird.net/en/latest/composeAction.html). We can also move the locations, if the UI changes.

Completely removing a location is probably a no-go, we have to come up with an alternative place, where those buttons can be added (the add-on must work as before without having to change something).

Will you drop the tabs_toolbar after the spaces_toolbar has landed? I think we can just move those buttons. But adding a dedicated space_action is also something we should consider. I would take care of implementing that.

What is problematic is "too many add-on buttons", which why I am planning to add an overflow container but this probably should go hand-in-hand with a general overhaul of the customization UI. Are you planing to add an overflow container to the spaces_toolbar? At the moment users can customize the toolbar buttons including the add-on buttons. How is this going to be in the space toolbar? Is there a reason to not make it customizable like the others?

Besides raising questions on my own, did this answer your questions?

Hi Alessandro, thanks for those information.

WebExtAPI allow to add buttons in 5 locations:
 * browser_action: main_toolbar and tabs_toolbar (next to the current calendar and tasks icons)
 * message_display_action: message_header_toolbar
 * compose_action: compose_toolbar and format_toolbar

For all these buttons the add-on defines a name, an icon and some other props and the API generates the core code to actually add the button. 

We can change the API to use different code to add the button, but we need to keep the interface compatible (see https://webextension-api.thunderbird.net/en/latest/composeAction.html). We can also move the locations, if the UI changes.

Completely removing a location is probably a no-go, we have to come up with an alternative place, where those buttons can be added (the add-on must work as before without having to change something).

Will you drop the tabs_toolbar after the spaces_toolbar has landed? I think we can just move those buttons. But adding a dedicated space_action is also something we should consider. I would take care of implementing that.

What is problematic is "too many add-on buttons", which why I am planning to add an overflow container to the existing toolbars, but this probably should go hand-in-hand with a general overhaul of the customization UI. Are you planing to add an overflow container to the spaces_toolbar? At the moment users can customize the toolbar buttons including the add-on buttons. How is this going to be in the space toolbar? Is there a reason to not make it customizable like the others?

Besides raising questions on my own, did this answer your questions?