<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
  </head>
  <body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
    <br>
    <blockquote class=" cite" id="mid_55DE1E31_2050607_gmail_com"
      cite="mid:55DE1E31.2050607@gmail.com" type="cite">
      <div class="moz-cite-prefix">On 08/26/2015 02:44 PM, R Kent James
        wrote:<br>
      </div>
      <blockquote class=" cite" id="mid_55DE172C_1080104_caspia_com"
        cite="mid:55DE172C.1080104@caspia.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        It would be good to inform us of any binary extensions that are
        out there and your needs.</blockquote>
      <br>
      This is extremely crucial advice to add-on developers. Anything
      that cannot be satisfied with js-ctypes we should be well-informed
      of, because we're unlikely to be able to maintain this.<br>
      <blockquote class=" cite" id="mid_55DE172C_1080104_caspia_com"
        cite="mid:55DE172C.1080104@caspia.com" type="cite">We have no
        current plan for dealing with the XUL deprecation issue. We
        don't get invited to sit at the cool kids table anymore, so this
        is hitting us about the same time it is hitting you (though I
        suspect the discussion was public if we had looked hard enough).<br>
      </blockquote>
      <br>
      In a recent message, I've referred to the XUL/XPCOM issue as a
      "looming disaster" (to steal the term from a video game). XUL
      we're going to have to move away from, for sure. I do suspect,
      however, that there will remain a chrome/content divergence in the
      layout engine without HTML, and if that is the case, we should be
      able to use WebIDL to bridge JS and C++ in a post-XPCOM world (I
      already know at a high-level what needs to be done, and I've had
      support from bz about our use cases here in the past). I do have
      ideas on how to do that. It's very unclear to me how WebExtensions
      would handle custom WebIDL APIs, but if that is possible, we could
      use it.<br>
      <br>
      The bigger problem with the deletion of XUL is that XUL has some
      high-quality widgets that are very difficult to code in pure
      HTML--namely, I'm referring to the <tree> widget. Honestly,
      this is something that I feel Mozilla should be providing if they
      move away from XUL, but I doubt they will (judging from the
      response to the last XUL tree question on m.d.platform).<br>
    </blockquote>
    If XUL goes away is the plan to re-code the core UI in HTML5 as
    well? How are dialog overlays going to be implemented? What about
    toolbars, icon menus? There is an awful lot UI-goodness in XUL and
    extensibility in overlays, and overlaying is very simply on top - I
    hope there will be an adequate technology without losing
    functionality before Thunderbird even considers switching away from
    this.<br>
    <br>
    As somebody with 25+ years of desktop application experience I can
    only say that xul+css had been a dream come true, I hope this won't
    be squandered for the promise mobile platform compatibility. I still
    see Tb as a desktop fat client.<br>
    <br>
    Axel<br>
    <br>
  </body>
</html>