axel.grude at gmail.com
Tue Jun 5 12:06:17 UTC 2018
on the detail of UI, thanks for starting the conversation.
There are many many many more places where Add-ons expand UI - you listing just a few
probably shows that even you may underestimate the problem.
Let's take the account manager -Add-ons still need a way to add decks and modify
existing ones. The Filter list - add-ons need a way to extend the search interface and
add toolbars. The filter editor - Add-ons need a way to add new UI elements and code.
Even if XUL is scrapped Add-on will need a way to interfere with the dialog document
tree possibly just with DOM methods. Many Add-ons need a way to create (floating)
dialogs that are not restricted to a single tab. If you have an Add-on that styles the
main interface you need it's settings outside of a tab for instant feedback (because
the change more than likely may affect the 3pane window and can't be seen while
looking at an "options tab"). A floating dialog may also be used to things like
correction / lookup features in mail / composer content and ideally should not be
restricted to the window's client area. That's why I repeatedly asked about the future
of non-modal windows (Thunderbird has plenty of these).
Also will we still be able to add custom icons to the folder tree?
just a few of my UI thoughts...
*Axel Grude <mailto:axel.grude at gmail.com>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders
QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys
Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email
productivity tips Get Thunderbird!
> *Subject:*MailExtensions API
> *From:*Ben Bucksch <ben.bucksch at beonex.com>
> *To:*Tb Council; Tb-planning
> *Sent: *Tuesday, 05/06/2018 12:49:49 12:49 GMT ST +0100 [Week 23]
> Hello TB Council,
> I had asked quite a while ago whether I could be hired to work on the architectural
> foundations of the Thunderbird future. In the Council, with feedback from other
> Council members, we had together decided to use the address book as test bed. That
> would allow to iron out the framework details on how to implement the foundation,
> from how backend modules are loaded (JSM, or require(), or ES6 modules, or Electron
> modules, or what have you) and backend<->frontend communication (given that each
> window might run in its own process, and we need shared data, that's far from
> trivial), over XUL overlay replacements, to localization and to widget sets. Now, a
> new topic just came up:
> Firefox 45 killing bootstrapped/restartless addons. That kills pretty much all of
> our existing extensions. We have to decide how to proceed. Either we maintain the
> addon manager code to keep them alive, or we create a MailExtensions API. The latter
> is not at all trivial, it's a completely new architecture.
> I would like to propose to design such a MailExtensions API. I would take somelike
> STEEL, at least this level of abstraction in the API. Then, make a similar (not
> identical) API as part of the WebExtensions API. This would allow to implement some
> functions in Thunderbird.
> An open question is how such extensions can hook up in the Thunderbird UI. The
> problem is much harder than in the browser. In the browser, you only have toolbar
> icons, and that's it. In Thunderbird extensions, we want toolbar buttons, but also
> mail header UI, and maybe a (single) place to add menu items. Still, extensions need
> to add new mail account types, implement content decoding for PGP, new UI like
> gmail-style "Conversations". I personally depend on an extension for my phone
> provider that adds a button next to each phone number in the address book and lets
> me call the person with one click. How to continue to support all that kind of UI
> hookup needs to be worked out. I could imagine that we define certain data types,
> like "mail window", "folder", "message header", and "address contact" or "phone
> number", and the extension can add a little UI there, e.g. a button with icon, or a
> text. Thunderbird would then be able to place this UI itself, not the extension
> choosing the exact place. The list of UI places available would be relatively small,
> maybe 10 or 20. The extension UI would then get a reference to the object next to
> which it is placed, so that it can operate on that data, e.g. call that phone
> number. In other words, we invert the control: The extension says "I want to add
> something to phone numbers", and Thunderbird places the extension UI, and gives a
> reference to the contact and phone number, instead of the extension picking the
> exact UI place and picking the data from some internal Thunderbird window data
> Exposing some high level data APIs, like accounts, folders, messages, and allowing
> to add account types and content handlers, as well add exposing a certain number of
> UI hookup places, all with a well-defined API, would dramatically reduce the API
> surface that Thunderbird exposes, and allow extensions to continue to work even in
> face of drastic chances in Thunderbird.
> In fact, if the extension API is done well enough and abstract enough, it might be
> possible to even let a completely new re-implementation of Thunderbird based on HTML
> be able to support the same extensions, with minimal or no changes, similar to how
> Firefox supported some Chrome WebExtensions. However, in order to achieve that, the
> API needs to be abstract enough and well thought out.
> I am proposing to attempt that. However, it's a big project, and I would need to be
> hired for that.
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 846 bytes
Desc: not available
More information about the tb-planning