<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
  </head>
  <body smarttemplateinserted="true" text="#000000" bgcolor="#FFFFFF">
    <div id="smartTemplate4-template">
      <p>Dear Ben,</p>
      <p>on the detail of UI, thanks for starting the conversation.</p>
      <p>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.</p>
      <p>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).</p>
      <p>Also will we still be able to add custom icons to the folder
        tree?<br>
      </p>
      <p>just a few of my   UI thoughts...<br>
          Axel<br>
      </p>
      <style type="text/css">
.myName {
  text-shadow: 1px 1px 2px #DDD; 
  transition:font-size 0.5s;
}
.myName:hover, .myName a:hover 
{ font-size:13pt; text-shadow: 3px 3px 4px rgba(200,250,200,0.7);}
.moz-signature {opacity: 1.0 !important;}
.myName a { cursor: pointer !important; transition:font-size 0.5s;}
.myLogo {
  transition: all .4s ease-out;
}

.myLogo:hover {
  transform: scale(3) translate(-30px,-5px);
}
#mySignature, :not(blockquote) #mySignature {
  background: rgb(230,240,163); 
  background-image: linear-gradient(to bottom, rgba(230,240,163,1) 0%,rgba(210,230,56,1) 50%,rgba(195,216,37,1) 51%,rgba(219,240,67,1) 100%);
  color: #444; 
  box-shadow: 4px 4px 9px -2px rgba(0,0,0,0.65); 
  border-radius: 0.7em; padding: 0.8em 1.2em; 
  border: 1px dashed #8080A0; 
  font-size: 11pt !important;
  font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif; 
  width: 65%; 
}
.AddonList a {
  color: #666666; 
  font-size: 10pt !important;
}
</style>
      <div id="mySignature"> <b class="myName"><a
            href="mailto:axel.grude@gmail.com">Axel Grude</a></b> <br>
        Music Production and Composition <br>
        Thunderbird Add-ons Developer <span class="AddonList">(<a
href="https://addons.mozilla.org/thunderbird/addon/quickfolders-tabbed-folders/">QuickFolders</a>,
          <a
            href="https://addons.mozilla.org/thunderbird/addon/quickfilters/">quickFilters</a>,
          <a
            href="https://addons.mozilla.org/firefox/addon/quickpasswords/">QuickPasswords</a>,
          <a
            href="https://addons.mozilla.org/thunderbird/addon/zombie-keys/">Zombie
            Keys</a>, <a
            href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/">SmartTemplate4</a>)</span>
        <br>
        Visit my <a href="https://www.youtube.com/c/thunderbirddaily">YouTube
          Channel</a> for email productivity tips <img
          style="margin-top: 1em; float: right; box-shadow: 1px 1px 2px
          rgba(20, 20, 20, 0.4);" moz-do-not-send="false" class="myLogo"
          src="cid:part8.412BB0DC.5CF9135C@gmail.com" alt="Get
          Thunderbird!" height="15" width="94">
      </div>
    </div>
    <div id="smartTemplate4-quoteHeader">
      <style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
      <blockquote type="cite" style="margin-bottom: -20px !important;
        padding-bottom:20px !important;">
        <div id="newHeaderAG1" style="font-size: x-small; padding:1em;
          background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>MailExtensions
          API<br>
          <b>From:</b>Ben Bucksch <a class="moz-txt-link-rfc2396E" href="mailto:ben.bucksch@beonex.com"><ben.bucksch@beonex.com></a><br>
          <b>To:</b>Tb Council; Tb-planning <br>
          <b>Sent: </b>Tuesday, 05/06/2018 12:49:49 12:49 GMT ST +0100
          [Week 23]<br>
        </div>
      </blockquote>
    </div>
    <blockquote type="cite"
      cite="mid:8d2b23cc-bb46-0dd3-5d3d-2914f0fd001e@beonex.com"
      id="mid_8d2b23cc_bb46_0dd3_5d3d_2914f0fd001e_beonex_com" class="
      cite">Hello TB Council,
      <br>
      <br>
      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:
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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
      structures.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      I am proposing to attempt that. However, it's a big project, and I
      would need to be hired for that.
      <br>
      <br>
      Ben
      <br>
      _______________________________________________
      <br>
      tb-planning mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
      <br>
      <br>
    </blockquote>
    <br>
    <br>
  </body>
</html>