<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>Eyal - I hear you.</p>
<p>That's why I am still hoping we can do a "guided conversion" in
a public google hangout, just to show that it is possible.</p>
<p>I think the biggest thing is converting to the new build
process and then dealing with individual XPCOM breakages. AS far
as I understand overlays still work, as long as you overlay the
correct xul file (as Thunderbird itself won't have overlays). So
it shouldn't be impossible.</p>
<p>when you said "without preferences." - did you mean no settings
dialog, because of broken xul dialogs? That one is very easy to
fix and even backwards compatible (one line of code).<br>
</p>
<p>Axel<br>
</p>
<p><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.BDF2AEA5.1B536668@gmail.com" alt="Get
Thunderbird!" width="94" height="15">
</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>Re:
Extension development for beta<br>
<b>From:</b>Eyal Rozenberg <a class="moz-txt-link-rfc2396E" href="mailto:eyalroz@technion.ac.il"><eyalroz@technion.ac.il></a><br>
<b>To:</b>Thunderbird Planning (Moderated)
<a class="moz-txt-link-rfc2396E" href="mailto:tb-planning@mozilla.org"><tb-planning@mozilla.org></a>; Geoff Lankow
<a class="moz-txt-link-rfc2396E" href="mailto:geoff@thunderbird.net"><geoff@thunderbird.net></a> <br>
<b>Sent: </b>Monday, 10/29/2018 10:43 GMT ST +0000 [Week 44]<br>
</div>
</blockquote>
</div>
<blockquote type="cite"
cite="mid:5046c8df-414b-9c1a-c9ba-ee24eea06cd3@technion.ac.il"
id="mid_5046c8df_414b_9c1a_c9ba_ee24eea06cd3_technion_ac_il"
class=" cite">
<pre class="moz-quote-pre" wrap="">Without discounting the significance of this problem, I believe there's
a larger one. I'll generalize it from my personal experience because
everyone knows a biased sample of one person is good enough :-P
Anyway, I'm speaking as an extension (only) developer, of a
non-bootstrapped non-WebExtensions extension [1]. I've been chasing the
moving target of what I need to rewrite in my extension for a while now.
But, frankly, I'm tired of doing that. I published a (clearly-marked)
beta version targeted at TB 60, which works, but without preferences.
Well - I don't feel motivated to fix that. Seeing that there's more
breakage to handle for v63, and hearing now that I might need to address
v60 and v63 issues, my thoughts are: "Why would I even want to fix this?
I mean, next month there's going to be v64 alpha, or what-not, and
something else will break or be taken away, and I'll need to chuck my
hacks so for for yet another hack. I'm tired of this! Also, why do I
individually have to adapt my old preferences dialog to Chrome-style
extensions? Why don't _they_ adapt to _me_? I'm pretty sure the
transition can be automatized. Eh, f*** it, let them just wake me up
when things are stable once more and I'll attend to my extension then."
I tend to believe that similar, or worse, sentiments are shared by most
extension developers - or at least those who are mostly maintaining
rather than actively developing.
Eyal
[1] : Remove duplicate messages (alternate)
On 29/10/2018 10:37, Geoff Lankow wrote:
> We have a problem. Actually, a series of problems.
>
> Firstly. For an extension to run on ESR60, it must be:
>
> 1. an overlay extension with an install.rdf manifest, or
> 2. a bootstrapped extension with an install.rdf manifest, or
> 3. a WebExtension with a manifest.json
>
> C is very rare, because ESR60 supports so few of the WebExtension APIs.
> B isn't an issue yet but will become one soon, so I'm ignoring it for
> this conversation.
>
> For A to run on beta, it must have a manifest.json and /NOT/ have an
> install.rdf manifest. (At this point it's technically a WebExtension and
> we're just lying to the extensions back-end about what it's actually doing.)
>
> This leads to the second problem: it's impossible to have an extension
> that both has an install.rdf and doesn't have an install.rdf. Therefore
> an extension developer cannot make an extension that can run on both
> ESR60 and beta.
>
> (Side note: I've been trying to make a backport for ESR that can run an
> updated legacy extension, but I'm uncomfortable with the size of the
> changes.)
>
> The extension developer /could/ make a separate version of their
> extension which is only for beta. Given the other big changes in the
> platform, that's probably the best option anyway, but that takes us to
> problem three: they can't host the beta version of their extension on
> ATN, because ATN no longer has support for development channel
> extensions. I /think/ there's an ugly workaround involving uploading
> versions out-of-order such that the ESR version is the one displayed,
> but I really don't think developers should have to deal with that, or
> would bother. They could also self-host the extension but I think most
> wouldn't want to do that.
>
> We're left with a bunch of not-very-nice options, as well as all the
> other issues facing extension developers, which I think is just going to
> put a lot of developers off altogether, and we'll lose a large fraction
> of our extensions.
>
> GL
>
>
> _______________________________________________
> tb-planning mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
> <a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
>
_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
</body>
</html>