Add customUI API
Categories
(Thunderbird :: Add-Ons: Extensions API, enhancement)
Tracking
(Not tracked)
People
(Reporter: TbSync, Unassigned)
References
Details
Add-on developers need to be able to add UI elements to Thunderbird. The customUI API proposed here is a very interesting approach:
https://thunderbird.topicbox.com/groups/addons/T07afba099782a5c5
|
||
Comment 2•4 years ago
|
||
Would be careful about adding such an API.
Longer term, the UI should correspond to a web page and be manipulated the way Web Extensions do changes to pages.
|
||
Comment 3•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #2)
Would be careful about adding such an API.
Longer term, the UI should correspond to a web page and be manipulated the way Web Extensions do changes to pages.
So you think we will get a UI freeze at some point, permitting add-ons to depend on fixed ids and their HTML element hierarchies? Otherwise a custom UI API would still be necessary. It is also the only option to permit add-ons to not require a catch-all permission and still affect the user interface, as accessing the UI directly gives an add-on access to everything the UI can do.
Don't get me wrong, I'd love an interface for add-ons to get direct UI access without having to write an experiment, but I think it will always come with the same caveats as experiments (unstable across major releases, potential for incompatibilities with other add-ons). So we should offer it for add-ons that need it, but also offer a more stable way for common tasks.
[For the record, I will not start to work on this without explicit approval of the overall API concept.]
|
|
||
Comment 4•4 years ago
|
||
The UI will always be changing, but ids are reasonable stable.
How things work between versions can't be predicted - updates to the add-on can/will be required if you're touching UI directly. But that's the same however you'd do such an api: it's not clear that whatever the add-on changes makes sense in UI version++.
|
|
||
Comment 5•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #4)
But that's the same however you'd do such an api: it's not clear that whatever the add-on changes makes sense in UI version++.
With a custom UI API it is the API implementation's task to ensure that the documented extension points will always have the documented behavior. An add-on picks a suitable location, and can then rely on the documented constraint to be held even if the whole UI gets redesigned, its frame just moves to a place where it makes sense. There is no need for version-specific behavior in the add-on.
Of course stuff might look out of place visually, or features might become redundant. And some locations might even phase out after being deprecated for a few major releases. But things should continue to work for at least 2-3 release periods without any changes, and migration beyond that should be very easy (and changes can be completely documented, which is not really feasible for the whole UI).
Again, I 100% agree that always having a direct way to manipulate the underlying UI is essential, just like having a direct way to implement other things that do not have an API is. And making that more accessible than experiments is a good plan. But without a custom UI API, most add-ons will be forced to only rely on these internal interfaces and thus need updating for every version of Thunderbird, as almost every add-on needs to deal with user interface to some capacity. Also, having the API would enable add-ons that use experiments or some future direct-UI-manipulation-API to use the same generic primitives (containers with add-on-scoped frames), which would make clean add-ons easier to implement.
That all being said, I feel like your comment questions the overall path we're on. I'm also fine if we abandon WebExtensions as a concept and go back to the ideas of legacy Add-ons (as in, add-ons rely on implementation details of a concrete version of Thunderbird instead of only accessing a generic interface that could theoretically be implemented even by a third-party host application). In that case, I'd propose to close here and to add a new bug to move something like the WindowListener API into the core: if we put some thought into the API design, I'm sure we can find something that is reasonably stable for both the status quo and a 'web page'-UI to be introduced at some later point in time.
Description
•