Empathy List Archives

JK

Jonathan Kamens

Sat, Mar 30, 2019 9:59 PM

I've just submitted to ATN my first attempt at porting Send Later to
Thunderbird 68. The datepicker/timepicker issue that I emailed the list
about earlier today is still outstanding, but I worked around that for
the time being by disabling the relevant functionality in the add-on. It
is still usable, it's just slightly less user-friendly.

https://thunderbird-webextensions.readthedocs.io/en/latest/how-to/extensions68.html
was very helpful. Thanks to Geoff Lankow and the other people who
contributed to it.

In the process of doing this I stumbled upon a number of issues that
were not documented anywhere, or at least not that I saw. I wanted to
run them past the people on this list and ask if anyone has any thoughts
about them or thinks that mention of any of them should be added to the
public documentation about porting add-ons to TB 68. Here they are:

I had been led to believe that <stringbundleset> and <stringbundle>
should work in XUL files, but whenever the overlay loader tried to
load my overlays with them in it, it complained about being unable
to resolve forward references. I eventually gave up and just removed
the bundle definitions from the XUL files. TL;DR I'm not convinced
that <stringbundleset> and <stringbundle> are actually working in
XUL overlays right now.
The aContext argument passed into the onDataAvailable method of
streamMessage consumers disappeared some time between Thunderbird 66
and Thunderbird 68, so anybody who has code that calls StreamMessage
(and possibly also StreamHeaders, I didn't look) and gives it a
consumer with an onDataAvailable method needs to update that method
to no longer expect aContext.
Apparently MailUtils.getFolderForUri was replaced with
MailUtils.getExistingFolder at some point, so I've updated my code
to reflect that.
The status bar in the main Thunderbird window works differently now
so I had to change my XUL code to reflect the change.
The global nsIMsgCompDeliverMode is now Ci.nsIMsgCompDeliverMode.
I ran into some problems with JavaScript not liking the fact that I
was trying to use functions named "import" and "export" in the
JavaScript module that handles dynamic scheduling functions, so I
renamed them to "_import" and "_export". Honestly, this could be a
red herring, but I thought I'd mention it just in case.

jik

I've just submitted to ATN my first attempt at porting Send Later to Thunderbird 68. The datepicker/timepicker issue that I emailed the list about earlier today is still outstanding, but I worked around that for the time being by disabling the relevant functionality in the add-on. It is still usable, it's just slightly less user-friendly. https://thunderbird-webextensions.readthedocs.io/en/latest/how-to/extensions68.html was very helpful. Thanks to Geoff Lankow and the other people who contributed to it. In the process of doing this I stumbled upon a number of issues that were not documented anywhere, or at least not that I saw. I wanted to run them past the people on this list and ask if anyone has any thoughts about them or thinks that mention of any of them should be added to the public documentation about porting add-ons to TB 68. Here they are: * I had been led to believe that <stringbundleset> and <stringbundle> should work in XUL files, but whenever the overlay loader tried to load my overlays with them in it, it complained about being unable to resolve forward references. I eventually gave up and just removed the bundle definitions from the XUL files. TL;DR I'm not convinced that <stringbundleset> and <stringbundle> are actually working in XUL overlays right now. * The `aContext` argument passed into the `onDataAvailable` method of streamMessage consumers disappeared some time between Thunderbird 66 and Thunderbird 68, so anybody who has code that calls StreamMessage (and possibly also StreamHeaders, I didn't look) and gives it a consumer with an onDataAvailable method needs to update that method to no longer expect `aContext`. * Apparently `MailUtils.getFolderForUri` was replaced with `MailUtils.getExistingFolder` at some point, so I've updated my code to reflect that. * The status bar in the main Thunderbird window works differently now so I had to change my XUL code to reflect the change. * The global nsIMsgCompDeliverMode is now Ci.nsIMsgCompDeliverMode. I ran into some problems with JavaScript not liking the fact that I was trying to use functions named "import" and "export" in the JavaScript module that handles dynamic scheduling functions, so I renamed them to "_import" and "_export". Honestly, this could be a red herring, but I thought I'd mention it just in case. jik

JK

Jörg Knobloch

Sat, Mar 30, 2019 10:31 PM

On 30 Mar 2019 22:59, Jonathan Kamens via Maildev wrote:

I had been led to believe that <stringbundleset> and <stringbundle>
should work in XUL files, but whenever the overlay loader tried to
load my overlays with them in it, it complained about being unable to
resolve forward references. I eventually gave up and just removed the
bundle definitions from the XUL files. TL;DR I'm not convinced that
<stringbundleset> and <stringbundle> are actually working in XUL
overlays right now.

Thanks for the feedback.

The other four items lack documentation, but the stringbundle stuff hit
the docs:

https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63#Removed_in_Thunderbird_63

Jörg.

On 30 Mar 2019 22:59, Jonathan Kamens via Maildev wrote: > I had been led to believe that <stringbundleset> and <stringbundle> > should work in XUL files, but whenever the overlay loader tried to > load my overlays with them in it, it complained about being unable to > resolve forward references. I eventually gave up and just removed the > bundle definitions from the XUL files. TL;DR I'm not convinced that > <stringbundleset> and <stringbundle> are actually working in XUL > overlays right now. Thanks for the feedback. The other four items lack documentation, but the stringbundle stuff hit the docs: https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63#Removed_in_Thunderbird_63 Jörg.

JK

Jonathan Kamens

Sat, Mar 30, 2019 10:55 PM

I'm confused. The documentation you referenced seems to say that
stringbundles /will/ work in Overlays: "In order to use stringbundles,
you need to load stringbundle.js in your XUL: <script type="application/x-javascript" src="chrome://global/content/elements/stringbundle.js"/>, but the XUL
Overlay loader takes care of this." What I'm trying to say is that I was
led to believe from reading the documentation that they would work, but
they didn't.

Am I misunderstanding the documentation? If so, then can you explain to
me what it's actually saying? Because I don't get it.

Also, one more item I forgot to mention in my last email --
AddonManager.getAddonByID's interface has changed. Rather than calling
it like AddonManager.getAddonByID(IdString, CallbackFunction), you now
have to know that it returns a promise and call it as
AddonManager.getAddonByID(IdString).then(CallbackFunction).

Do you think the items I've mentioned are worth documenting, and if so,
where would you suggest I document these items?

jik

On 3/30/19 6:31 PM, Jörg Knobloch wrote:

On 30 Mar 2019 22:59, Jonathan Kamens via Maildev wrote:

I had been led to believe that <stringbundleset> and <stringbundle>
should work in XUL files, but whenever the overlay loader tried to
load my overlays with them in it, it complained about being unable to
resolve forward references. I eventually gave up and just removed the
bundle definitions from the XUL files. TL;DR I'm not convinced that
<stringbundleset> and <stringbundle> are actually working in XUL
overlays right now.

Thanks for the feedback.

The other four items lack documentation, but the stringbundle stuff
hit the docs:

https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63#Removed_in_Thunderbird_63

Jörg.

Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I'm confused. The documentation you referenced seems to say that stringbundles /will/ work in Overlays: "In order to use stringbundles, you need to load stringbundle.js in your XUL: <script type="application/x-javascript" src="chrome://global/content/elements/stringbundle.js"/>, but the XUL Overlay loader takes care of this." What I'm trying to say is that I was led to believe from reading the documentation that they would work, but they didn't. Am I misunderstanding the documentation? If so, then can you explain to me what it's actually saying? Because I don't get it. Also, one more item I forgot to mention in my last email -- AddonManager.getAddonByID's interface has changed. Rather than calling it like AddonManager.getAddonByID(IdString, CallbackFunction), you now have to know that it returns a promise and call it as AddonManager.getAddonByID(IdString).then(CallbackFunction). Do you think the items I've mentioned are worth documenting, and if so, where would you suggest I document these items? jik On 3/30/19 6:31 PM, Jörg Knobloch wrote: > On 30 Mar 2019 22:59, Jonathan Kamens via Maildev wrote: >> I had been led to believe that <stringbundleset> and <stringbundle> >> should work in XUL files, but whenever the overlay loader tried to >> load my overlays with them in it, it complained about being unable to >> resolve forward references. I eventually gave up and just removed the >> bundle definitions from the XUL files. TL;DR I'm not convinced that >> <stringbundleset> and <stringbundle> are actually working in XUL >> overlays right now. > > Thanks for the feedback. > > The other four items lack documentation, but the stringbundle stuff > hit the docs: > > https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63#Removed_in_Thunderbird_63 > > > Jörg. > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > >

JK

Jörg Knobloch

Sat, Mar 30, 2019 11:15 PM

On 30 Mar 2019 23:55, Jonathan Kamens via Maildev wrote:

Do you think the items I've mentioned are worth documenting, and if
so, where would you suggest I document these items?

I would put them on this page
https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63, but Geoff may
have a different idea.

As for the stringbundle stuff, I didn't write that sections, so I don't
know.

As for the other items, we of course suffered through all of them:

context parameter: https://bugzilla.mozilla.org/show_bug.cgi?id=1531307

mozilla67

MailUtils.getExistingFolder: de-RDF -
https://bugzilla.mozilla.org/show_bug.cgi?id=453908 - TB 67

statusbar: https://bugzilla.mozilla.org/show_bug.cgi?id=1491660 - TB 65

global nsIMsgCompDeliverMode: That was really bad style and got removed
during some linting effort. No one should have relied on that global.
You're referring to this ESR60 code:
mail/components/compose/content/MsgComposeCommands.js: 36 var
nsIMsgCompDeliverMode = Ci.nsIMsgCompDeliverMode;

getAddonByID: https://bugzilla.mozilla.org/show_bug.cgi?id=1454202 -
mozilla61

I added the versions so if you add it to the document, you'll have the
right order.

There have been some many other things that I believe you're only
scratching the surface here. It all depends on which APIs the particular
add-on uses.

Jörg.

On 30 Mar 2019 23:55, Jonathan Kamens via Maildev wrote: > Do you think the items I've mentioned are worth documenting, and if > so, where would you suggest I document these items? I would put them on this page https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63, but Geoff may have a different idea. As for the stringbundle stuff, I didn't write that sections, so I don't know. As for the other items, we of course suffered through all of them: context parameter: https://bugzilla.mozilla.org/show_bug.cgi?id=1531307 - mozilla67 MailUtils.getExistingFolder: de-RDF - https://bugzilla.mozilla.org/show_bug.cgi?id=453908 - TB 67 statusbar: https://bugzilla.mozilla.org/show_bug.cgi?id=1491660 - TB 65 global nsIMsgCompDeliverMode: That was really bad style and got removed during some linting effort. No one should have relied on that global. You're referring to this ESR60 code: mail/components/compose/content/MsgComposeCommands.js: 36 var nsIMsgCompDeliverMode = Ci.nsIMsgCompDeliverMode; getAddonByID: https://bugzilla.mozilla.org/show_bug.cgi?id=1454202 - mozilla61 I added the versions so if you add it to the document, you'll have the right order. There have been some many other things that I believe you're only scratching the surface here. It all depends on which APIs the particular add-on uses. Jörg.

JK

Jonathan Kamens

Sun, Mar 31, 2019 1:47 AM

Thanks, I updated the docs.

jik

On 3/30/19 7:15 PM, Jörg Knobloch wrote:

On 30 Mar 2019 23:55, Jonathan Kamens via Maildev wrote:

Do you think the items I've mentioned are worth documenting, and if
so, where would you suggest I document these items?

I would put them on this page
https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63, but Geoff may
have a different idea.

As for the stringbundle stuff, I didn't write that sections, so I
don't know.

As for the other items, we of course suffered through all of them:

context parameter:
https://bugzilla.mozilla.org/show_bug.cgi?id=1531307 - mozilla67

MailUtils.getExistingFolder: de-RDF -
https://bugzilla.mozilla.org/show_bug.cgi?id=453908 - TB 67

statusbar: https://bugzilla.mozilla.org/show_bug.cgi?id=1491660 - TB 65

global nsIMsgCompDeliverMode: That was really bad style and got
removed during some linting effort. No one should have relied on that
global. You're referring to this ESR60 code:
mail/components/compose/content/MsgComposeCommands.js: 36 var
nsIMsgCompDeliverMode = Ci.nsIMsgCompDeliverMode;

getAddonByID: https://bugzilla.mozilla.org/show_bug.cgi?id=1454202 -
mozilla61

I added the versions so if you add it to the document, you'll have the
right order.

There have been some many other things that I believe you're only
scratching the surface here. It all depends on which APIs the
particular add-on uses.

Jörg.

Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Thanks, I updated the docs. jik On 3/30/19 7:15 PM, Jörg Knobloch wrote: > On 30 Mar 2019 23:55, Jonathan Kamens via Maildev wrote: >> Do you think the items I've mentioned are worth documenting, and if >> so, where would you suggest I document these items? > > I would put them on this page > https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63, but Geoff may > have a different idea. > > As for the stringbundle stuff, I didn't write that sections, so I > don't know. > > As for the other items, we of course suffered through all of them: > > context parameter: > https://bugzilla.mozilla.org/show_bug.cgi?id=1531307 - mozilla67 > > MailUtils.getExistingFolder: de-RDF - > https://bugzilla.mozilla.org/show_bug.cgi?id=453908 - TB 67 > > statusbar: https://bugzilla.mozilla.org/show_bug.cgi?id=1491660 - TB 65 > > global nsIMsgCompDeliverMode: That was really bad style and got > removed during some linting effort. No one should have relied on that > global. You're referring to this ESR60 code: > mail/components/compose/content/MsgComposeCommands.js: 36 var > nsIMsgCompDeliverMode = Ci.nsIMsgCompDeliverMode; > > getAddonByID: https://bugzilla.mozilla.org/show_bug.cgi?id=1454202 - > mozilla61 > > I added the versions so if you add it to the document, you'll have the > right order. > > There have been some many other things that I believe you're only > scratching the surface here. It all depends on which APIs the > particular add-on uses. > > Jörg. > > > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > >

JK

Jonathan Kamens

Sun, Mar 31, 2019 1:50 AM

Incidentally, regarding your comment, "There have been some many other
things that I believe you're only scratching the surface here. It all
depends on which APIs the particular add-on uses," I agree 100%, but it
seems to me that a reasonable first-pass filter of what to document is,
"If one add-on maintainer encountered a particular issue while upgrading
their add-on, the odds are higher that other add-on maintainers will
encounter the same issue, so it's worth documenting."

jik

On 3/30/19 9:47 PM, Jonathan Kamens wrote:

Thanks, I updated the docs.

jik

On 3/30/19 7:15 PM, Jörg Knobloch wrote:

On 30 Mar 2019 23:55, Jonathan Kamens via Maildev wrote:

Do you think the items I've mentioned are worth documenting, and if
so, where would you suggest I document these items?

I would put them on this page
https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63, but Geoff may
have a different idea.

As for the stringbundle stuff, I didn't write that sections, so I
don't know.

As for the other items, we of course suffered through all of them:

context parameter:
https://bugzilla.mozilla.org/show_bug.cgi?id=1531307 - mozilla67

MailUtils.getExistingFolder: de-RDF -
https://bugzilla.mozilla.org/show_bug.cgi?id=453908 - TB 67

statusbar: https://bugzilla.mozilla.org/show_bug.cgi?id=1491660 - TB 65

global nsIMsgCompDeliverMode: That was really bad style and got
removed during some linting effort. No one should have relied on that
global. You're referring to this ESR60 code:
mail/components/compose/content/MsgComposeCommands.js: 36 var
nsIMsgCompDeliverMode = Ci.nsIMsgCompDeliverMode;

getAddonByID: https://bugzilla.mozilla.org/show_bug.cgi?id=1454202 -
mozilla61

I added the versions so if you add it to the document, you'll have
the right order.

There have been some many other things that I believe you're only
scratching the surface here. It all depends on which APIs the
particular add-on uses.

Jörg.

Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Incidentally, regarding your comment, "There have been some many other things that I believe you're only scratching the surface here. It all depends on which APIs the particular add-on uses," I agree 100%, but it seems to me that a reasonable first-pass filter of what to document is, "If one add-on maintainer encountered a particular issue while upgrading their add-on, the odds are higher that other add-on maintainers will encounter the same issue, so it's worth documenting." jik On 3/30/19 9:47 PM, Jonathan Kamens wrote: > > Thanks, I updated the docs. > > jik > > On 3/30/19 7:15 PM, Jörg Knobloch wrote: >> On 30 Mar 2019 23:55, Jonathan Kamens via Maildev wrote: >>> Do you think the items I've mentioned are worth documenting, and if >>> so, where would you suggest I document these items? >> >> I would put them on this page >> https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63, but Geoff may >> have a different idea. >> >> As for the stringbundle stuff, I didn't write that sections, so I >> don't know. >> >> As for the other items, we of course suffered through all of them: >> >> context parameter: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1531307 - mozilla67 >> >> MailUtils.getExistingFolder: de-RDF - >> https://bugzilla.mozilla.org/show_bug.cgi?id=453908 - TB 67 >> >> statusbar: https://bugzilla.mozilla.org/show_bug.cgi?id=1491660 - TB 65 >> >> global nsIMsgCompDeliverMode: That was really bad style and got >> removed during some linting effort. No one should have relied on that >> global. You're referring to this ESR60 code: >> mail/components/compose/content/MsgComposeCommands.js: 36 var >> nsIMsgCompDeliverMode = Ci.nsIMsgCompDeliverMode; >> >> getAddonByID: https://bugzilla.mozilla.org/show_bug.cgi?id=1454202 - >> mozilla61 >> >> I added the versions so if you add it to the document, you'll have >> the right order. >> >> There have been some many other things that I believe you're only >> scratching the surface here. It all depends on which APIs the >> particular add-on uses. >> >> Jörg. >> >> >> >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >> >>

GL

Geoff Lankow

Sun, Mar 31, 2019 2:05 AM

Regarding string bundles, I'm not sure exactly what changed, but IMO the
best thing to do is take them out of your XUL completely and just use
Services.strings.createBundle.

I /think/ the comment on the wiki about stringbundle.js refers to
something different altogether.

GL

On 31/03/19 10:59, Jonathan Kamens via Maildev wrote:

I've just submitted to ATN my first attempt at porting Send Later to
Thunderbird 68. The datepicker/timepicker issue that I emailed the
list about earlier today is still outstanding, but I worked around
that for the time being by disabling the relevant functionality in the
add-on. It is still usable, it's just slightly less user-friendly.

https://thunderbird-webextensions.readthedocs.io/en/latest/how-to/extensions68.html
was very helpful. Thanks to Geoff Lankow and the other people who
contributed to it.

In the process of doing this I stumbled upon a number of issues that
were not documented anywhere, or at least not that I saw. I wanted to
run them past the people on this list and ask if anyone has any
thoughts about them or thinks that mention of any of them should be
added to the public documentation about porting add-ons to TB 68. Here
they are:

I had been led to believe that <stringbundleset> and
<stringbundle> should work in XUL files, but whenever the overlay
loader tried to load my overlays with them in it, it complained
about being unable to resolve forward references. I eventually
gave up and just removed the bundle definitions from the XUL
files. TL;DR I'm not convinced that <stringbundleset> and
<stringbundle> are actually working in XUL overlays right now.
The aContext argument passed into the onDataAvailable method
of streamMessage consumers disappeared some time between
Thunderbird 66 and Thunderbird 68, so anybody who has code that
calls StreamMessage (and possibly also StreamHeaders, I didn't
look) and gives it a consumer with an onDataAvailable method needs
to update that method to no longer expect aContext.
Apparently MailUtils.getFolderForUri was replaced with
MailUtils.getExistingFolder at some point, so I've updated my
code to reflect that.
The status bar in the main Thunderbird window works differently
now so I had to change my XUL code to reflect the change.
The global nsIMsgCompDeliverMode is now Ci.nsIMsgCompDeliverMode.
I ran into some problems with JavaScript not liking the fact that
I was trying to use functions named "import" and "export" in the
JavaScript module that handles dynamic scheduling functions, so I
renamed them to "_import" and "_export". Honestly, this could be a
red herring, but I thought I'd mention it just in case.

jik

Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Regarding string bundles, I'm not sure exactly what changed, but IMO the best thing to do is take them out of your XUL completely and just use Services.strings.createBundle. I /think/ the comment on the wiki about stringbundle.js refers to something different altogether. GL On 31/03/19 10:59, Jonathan Kamens via Maildev wrote: > > I've just submitted to ATN my first attempt at porting Send Later to > Thunderbird 68. The datepicker/timepicker issue that I emailed the > list about earlier today is still outstanding, but I worked around > that for the time being by disabling the relevant functionality in the > add-on. It is still usable, it's just slightly less user-friendly. > > https://thunderbird-webextensions.readthedocs.io/en/latest/how-to/extensions68.html > was very helpful. Thanks to Geoff Lankow and the other people who > contributed to it. > > In the process of doing this I stumbled upon a number of issues that > were not documented anywhere, or at least not that I saw. I wanted to > run them past the people on this list and ask if anyone has any > thoughts about them or thinks that mention of any of them should be > added to the public documentation about porting add-ons to TB 68. Here > they are: > > * I had been led to believe that <stringbundleset> and > <stringbundle> should work in XUL files, but whenever the overlay > loader tried to load my overlays with them in it, it complained > about being unable to resolve forward references. I eventually > gave up and just removed the bundle definitions from the XUL > files. TL;DR I'm not convinced that <stringbundleset> and > <stringbundle> are actually working in XUL overlays right now. > * The `aContext` argument passed into the `onDataAvailable` method > of streamMessage consumers disappeared some time between > Thunderbird 66 and Thunderbird 68, so anybody who has code that > calls StreamMessage (and possibly also StreamHeaders, I didn't > look) and gives it a consumer with an onDataAvailable method needs > to update that method to no longer expect `aContext`. > * Apparently `MailUtils.getFolderForUri` was replaced with > `MailUtils.getExistingFolder` at some point, so I've updated my > code to reflect that. > * The status bar in the main Thunderbird window works differently > now so I had to change my XUL code to reflect the change. > * The global nsIMsgCompDeliverMode is now Ci.nsIMsgCompDeliverMode. > I ran into some problems with JavaScript not liking the fact that > I was trying to use functions named "import" and "export" in the > JavaScript module that handles dynamic scheduling functions, so I > renamed them to "_import" and "_export". Honestly, this could be a > red herring, but I thought I'd mention it just in case. > > jik > > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

JK

Jörg Knobloch

Sun, Mar 31, 2019 12:07 PM

On 31 Mar 2019 03:50, Jonathan Kamens via Maildev wrote:

Incidentally, regarding your comment, "There have been some many other
things that I believe you're only scratching the surface here. It all
depends on which APIs the particular add-on uses," I agree 100%, but
it seems to me that a reasonable first-pass filter of what to document
is, "If one add-on maintainer encountered a particular issue while
upgrading their add-on, the odds are higher that other add-on
maintainers will encounter the same issue, so it's worth documenting."

Thanks for the great update to the Wiki page!

I didn't mean to express not to do it, it was rather an expression of,
well, to say it positively, the feeling that there is a lot left to
document.

Jörg.

On 31 Mar 2019 03:50, Jonathan Kamens via Maildev wrote: > Incidentally, regarding your comment, "There have been some many other > things that I believe you're only scratching the surface here. It all > depends on which APIs the particular add-on uses," I agree 100%, but > it seems to me that a reasonable first-pass filter of what to document > is, "If one add-on maintainer encountered a particular issue while > upgrading their add-on, the odds are higher that other add-on > maintainers will encounter the same issue, so it's worth documenting." Thanks for the great update to the Wiki page! I didn't mean to express not to do it, it was rather an expression of, well, to say it positively, the feeling that there is a lot left to document. Jörg.

JK

Jörg Knobloch

Sun, Mar 31, 2019 12:11 PM

On 31 Mar 2019 14:07, Jörg Knobloch wrote:

Thanks for the great update to the Wiki page!

I didn't mean to express not to do it, it was rather an expression of,
well, to say it positively, the feeling that there is a lot left to
document.

And in fact, it's very useful that you stepped forward to the tackle the
task to get add-ons going in TB 68 and to show that it can be done and
point out the pitfalls and the areas that need improvements. And very
early in the 68 cycle, so that's great. Thanks again.

Jörg.

P.S.: You're the only one I know of using the date/time pickers so that
hassle was somewhat special.

On 31 Mar 2019 14:07, Jörg Knobloch wrote: > Thanks for the great update to the Wiki page! > > I didn't mean to express not to do it, it was rather an expression of, > well, to say it positively, the feeling that there is a lot left to > document. And in fact, it's very useful that you stepped forward to the tackle the task to get add-ons going in TB 68 and to show that it can be done and point out the pitfalls and the areas that need improvements. And very early in the 68 cycle, so that's great. Thanks again. Jörg. P.S.: You're the only one I know of using the date/time pickers so that hassle was somewhat special.

maildev@lists.thunderbird.net

Lessons learned porting Send Later to Thunderbird 68