thunderbird future?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

thunderbird future?

ISHIKAWA,chiaki
Just read something about it elsewhere (actually in SeaMonkey newsgroup)
and there is now a summary by the author of the memo reported a couple of
days ago:

https://blog.lizardwrangler.com/2015/12/03/thunderbird-update/

It is understandable that
mature e-mail client and cutting-edge web browser have different priorities.

We shall wait and see, but at least a compilation test bed where people can test
patches on systems which they don't have would be a requirement for TB's
long-term survival.

We can probably simply freeze the M-C portion and get on with it unless
serious security issues crops up.
(Unless we use browser within thunderbird, and only a limited set of
JavaScript add-on,
there should not be that much of a problem IMHO.)

My two cents worth.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Alice Wonder
I read about this on arstechnica.

There are IMHO a few shortcomings in Thunderbird but it is still the
best e-mail client out there and I hope that it does have long-term
survival wherever it ends up being maintained.

It's really really nice that I can use it on both Windows and Linux,
latter being primary, and I don't want to see it go into bitrot.

I'm hoping this ends up being the best thing for TB.

On 12/02/2015 10:42 PM, ishikawa wrote:

> Just read something about it elsewhere (actually in SeaMonkey newsgroup)
> and there is now a summary by the author of the memo reported a couple of
> days ago:
>
> https://blog.lizardwrangler.com/2015/12/03/thunderbird-update/
>
> It is understandable that
> mature e-mail client and cutting-edge web browser have different priorities.
>
> We shall wait and see, but at least a compilation test bed where people can test
> patches on systems which they don't have would be a requirement for TB's
> long-term survival.
>
> We can probably simply freeze the M-C portion and get on with it unless
> serious security issues crops up.
> (Unless we use browser within thunderbird, and only a limited set of
> JavaScript add-on,
> there should not be that much of a problem IMHO.)
>
> My two cents worth.
>
> _______________________________________________
> dev-apps-thunderbird mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

ISHIKAWA,chiaki
On 2015/12/03 16:51, Alice Wonder wrote:

> I read about this on arstechnica.
>
> There are IMHO a few shortcomings in Thunderbird but it is still the
> best e-mail client out there and I hope that it does have long-term
> survival wherever it ends up being maintained.
>
> It's really really nice that I can use it on both Windows and Linux,
> latter being primary, and I don't want to see it go into bitrot.
>
> I'm hoping this ends up being the best thing for TB.
>
> On 12/02/2015 10:42 PM, ishikawa wrote:
>> Just read something about it elsewhere (actually in SeaMonkey newsgroup)
>> and there is now a summary by the author of the memo reported a
>> couple of
>> days ago:
>>
>> https://blog.lizardwrangler.com/2015/12/03/thunderbird-update/
>>
>> It is understandable that
>> mature e-mail client and cutting-edge web browser have different
>> priorities.
>>
>> We shall wait and see, but at least a compilation test bed where
>> people can test
>> patches on systems which they don't have would be a requirement for TB's
>> long-term survival.
>>
>> We can probably simply freeze the M-C portion and get on with it unless
>> serious security issues crops up.
>> (Unless we use browser within thunderbird, and only a limited set of
>> JavaScript add-on,
>> there should not be that much of a problem IMHO.)
>>
>> My two cents worth.
>>
>> ________________________________

One other thing.

I learned that Japan where I live has the second largest TB user base
after Germany.
I have no idea why: there have been a few popular mail clients before.

In my case, I needed something that could work on linux and
cross-platform (on Windows, etc.). TB fit the bill and so I picked it up
about a dozen years ago.

Now, the move to ditch XUL may not fare well with Japanese user base.
I am not picky about the "theme" of TB. I can't care less.
But there seems to be a sizable portion of Japanese user base which
seems to like TB simply because of its customizability due to XUL.
If it is gone, I think some userbase will be gone, too.
I can't vouch for the percentage.
But when I searched some bug reports of issues I experienced a few years
ago (circa 2010 or earlier), I was flabbergasted to find that a BBS that
discussed TB issues had close to 80% or 85% of postings about UI
customization using XUL and changing themes. Hard to believe.

So when I first read about XUL being thrown away, I said to myself TB's
fate in Japan may not be great.

Anyway, one way or the other (merge or not merge/ditch) we need to make
the compilation infrastructure a little more stable. I am going to post
a discovery of the latest build failure in my next post.

TIA


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

tanstaafl-2
In reply to this post by ISHIKAWA,chiaki
On 12/3/2015 1:42 AM, ishikawa <[hidden email]> wrote:
> We can probably simply freeze the M-C portion and get on with it
> unless serious security issues crops up. (Unless we use browser
> within thunderbird, and only a limited set of JavaScript add-on,
> there should not be that much of a problem IMHO.)

Personally, I never understood the addition of an integrated browser,
and would like to see it ripped out by its roots.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

WaltS48
In reply to this post by ISHIKAWA,chiaki
On 12/03/2015 10:04 AM, Tanstaafl wrote:
> On 12/3/2015 1:42 AM, ishikawa <[hidden email]> wrote:
>> We can probably simply freeze the M-C portion and get on with it
>> unless serious security issues crops up. (Unless we use browser
>> within thunderbird, and only a limited set of JavaScript add-on,
>> there should not be that much of a problem IMHO.)
>
> Personally, I never understood the addition of an integrated browser,
> and would like to see it ripped out by its roots.
>

How would users view HTML mail?

--
Linux Mint 17.2 "Rafaela" | KDE 4.14.2 | Thunderbird 45.0a1 (Daily)
You don't need zero-days when machines wherever are packed with old-days.
Go Bucs! (next season) Go Pens! Go Sabres! Go Pitt!
[Visit Pittsburgh]<http://www.visitpittsburgh.com/>
[Coexist · Understanding Across Divides]<https://www.coexist.org/>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Patrick Brunschwig-3
On 03.12.15 16:43, WaltS48 wrote:

> On 12/03/2015 10:04 AM, Tanstaafl wrote:
>> On 12/3/2015 1:42 AM, ishikawa <[hidden email]> wrote:
>>> We can probably simply freeze the M-C portion and get on with it
>>> unless serious security issues crops up. (Unless we use browser
>>> within thunderbird, and only a limited set of JavaScript add-on,
>>> there should not be that much of a problem IMHO.)
>>
>> Personally, I never understood the addition of an integrated browser,
>> and would like to see it ripped out by its roots.
>>
>
> How would users view HTML mail?

Do you need HTML 5, CSS 3 and AJAX to view HTML mail? A less
feature-rich HTML viewer than the Gecko rendering engine would probably
be sufficient for the needs of mail.

-Patrick

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

R Kent James
In reply to this post by WaltS48
On 12/3/2015 8:04 AM, Patrick Brunschwig wrote:
>
> Do you need HTML 5, CSS 3 and AJAX to view HTML mail? A less
> feature-rich HTML viewer than the Gecko rendering engine would probably
> be sufficient for the needs of mail.
>
> -Patrick
>

Many new communications technologies involve some sort of web page to
display messages, along with an API to allow those messages to be
listed. You could look at Thunderbird as a multi-view environment,
allowing you to sort and select using different fields in the message
matadata. Currently that is mostly done for email, but the same basic
idea could and should work with other message stream. Virtually all new
message streams require a full-featured web browser to display messages.

We have incurred a lot of the cost of maintaining this web browser, but
we have not received the benefits because we have not been able to
support robustly alternate message streams. I am hoping that the
JsAccount technology, which I still hope to land in TB 45, will allow
other stream types to be used. That would allow us to finally start to
get some real benefits from the HTML rendering technology built-in to
Thunderbird.

:rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Eric Valette-2
On 03/12/2015 17:39, R Kent James wrote:

> We have incurred a lot of the cost of maintaining this web browser, but
> we have not received the benefits because we have not been able to
> support robustly alternate message streams.


Basically, the way I see it most of the time was spend following the FF
evolution.

I know Bugs that are open analysed, impact a lot of people and still
have never been fixed for more than 5 yaers:
        1) Various bug in HTML composing,
        2) The master password being ask as many time as feature neede it : I
have 3 poping up in all my config (several mail accounts, several news
server),
        3) Slowness and data corruption as soon as you put your local mail on a
remote disk on Linux,
        4) Automatic setting to be able to correctly download mail from exchange,
        ...

So please focus on fixing bug also...

-- eric


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

ISHIKAWA,chiaki
On 2015/12/04 2:36, Eric Valette wrote:

> On 03/12/2015 17:39, R Kent James wrote:
>
>> We have incurred a lot of the cost of maintaining this web browser, but
>> we have not received the benefits because we have not been able to
>> support robustly alternate message streams.
>
>
> Basically, the way I see it most of the time was spend following the FF
> evolution.
>

Yes, painfully so these days, especially build failures.

> I know Bugs that are open analysed, impact a lot of people and still
> have never been fixed for more than 5 yaers:
>      1) Various bug in HTML composing,
>      2) The master password being ask as many time as feature neede it :
> I have 3 poping up in all my config (several mail accounts, several news
> server),
>      3) Slowness and data corruption as soon as you put your local mail
> on a remote disk on Linux,
>      4) Automatic setting to be able to correctly download mail from
> exchange,
>      ...
>
> So please focus on fixing bug also...

A mature mail client benefits from these bug fixes, and so I am trying
my patches regarding point 3 above.



> -- eric
>
>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Jörg Knobloch
In reply to this post by Eric Valette-2
On 3/12/2015 18:36, Eric Valette wrote:
I know Bugs that are open analysed, impact a lot of people and still have never been fixed for more than 5 yaers:
    1) Various bug in HTML composing,

HTML composing bugs are mostly due to shortcoming in the Mozilla-Central editor.

I have fixed the most annoying ones for Thunderbird 38 and more fixes will be included in Thunderbird 45. Find a list below.

Which bugs are are you referring to in particular?

Jorg K.


Thunderbird dictionary and spell checking issues
https://bugzilla.mozilla.org/show_bug.cgi?id=368915 can't change language while in subject, language button
https://bugzilla.mozilla.org/show_bug.cgi?id=717292 (subject and body dict no synchronised, depends on next one)
https://bugzilla.mozilla.org/show_bug.cgi?id=967494 multiple compositions in different languages
https://bugzilla.mozilla.org/show_bug.cgi?id=1175908 invalid dict preference - it_IT --> it-IT (reg of 967494)
https://bugzilla.mozilla.org/show_bug.cgi?id=1176671 full spell check dictionary change (reg of 967494)
https://bugzilla.mozilla.org/show_bug.cgi?id=1169996 Don't lose eEditorMailMask (reg of 967494)
https://bugzilla.mozilla.org/show_bug.cgi?id=1168945 Problem with recycled messages (reg of 967494)
https://bugzilla.mozilla.org/show_bug.cgi?id=1203957 Update language when dictionary is removed
https://bugzilla.mozilla.org/show_bug.cgi?id=1219928 Spell checker shows spelling error in <style> block



Thunderbird message compose window, font indicator issues
https://bugzilla.mozilla.org/show_bug.cgi?id=1139524 font indicator 1
https://bugzilla.mozilla.org/show_bug.cgi?id=1148330 font indicator 2, handle sans-serif
https://bugzilla.mozilla.org/show_bug.cgi?id=1197687 font indicator 4: Variable width on Font > Menu



M-C / Gecko: Editor problems
https://bugzilla.mozilla.org/show_bug.cgi?id=1140617 pasting image loses font
https://bugzilla.mozilla.org/show_bug.cgi?id=1154791 missing spell underlines, take 2
https://bugzilla.mozilla.org/show_bug.cgi?id=756984 loosing style at the end of the line
https://bugzilla.mozilla.org/show_bug.cgi?id=1140105 Font menu, collapsed selection, Neil reported and abandoned
https://bugzilla.mozilla.org/show_bug.cgi?id=1141017 serif/sans-serif handling in editor
https://bugzilla.mozilla.org/show_bug.cgi?id=772796 Was: Deleting quotes causes preformats to be deleted (papercut), Now: Joining <div> and <pre>
https://bugzilla.mozilla.org/show_bug.cgi?id=1214377 fix TB specific problems in nsDocumentEncoder.cpp



M-C / Gecko: Spell checker clean-up
https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 FF spellchecker.dictionary (clean-up)
https://bugzilla.mozilla.org/show_bug.cgi?id=717433 FF spellchecker.dictionary (en-GB/en-US issue)
https://bugzilla.mozilla.org/show_bug.cgi?id=697981 Spell check underline updates
https://bugzilla.mozilla.org/show_bug.cgi?id=1204147 Content preferences written without user interaction
https://bugzilla.mozilla.org/show_bug.cgi?id=1193293 Content preferences ignored after restart
https://bugzilla.mozilla.org/show_bug.cgi?id=1204540 Spell checker test cleanup
https://bugzilla.mozilla.org/show_bug.cgi?id=1205983 contenteditable updates (697981 follow up)
https://bugzilla.mozilla.org/show_bug.cgi?id=1209414 Decent right click test for dictionary selection



The “Asian crisis”
https://bugzilla.mozilla.org/show_bug.cgi?id=1225904 CJK: Encoding problem when encoding long unicode string.
https://bugzilla.mozilla.org/show_bug.cgi?id=1225864 CJK: Don't wrap/chop through long CJK strings when serialising
https://bugzilla.mozilla.org/show_bug.cgi?id=653342 CJK: format=flowed, set “disallow line break” flag
https://bugzilla.mozilla.org/show_bug.cgi?id=26734 CJK: Implement delsp=yes for format=flowed and ISO-2022-JP




_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Eric Valette-2
In reply to this post by Eric Valette-2
On 05/12/2015 23:37, Jörg Knobloch wrote:

> On 3/12/2015 18:36, Eric Valette wrote:
>> I know Bugs that are open analysed, impact a lot of people and still
>> have never been fixed for more than 5 yaers:
>>     1) Various bug in HTML composing,
>
> HTML composing bugs are mostly due to shortcoming in the Mozilla-Central
> editor.
>
> I have fixed the most annoying ones for Thunderbird 38 and more fixes
> will be included in Thunderbird 45. Find a list below.

If you paste part of a mail, no just replying that has different font
color/type, you may end up unable to edit the color or the font type.

Also, you may send something that, when received, has a different look
and feel because the font size/type have changed but you did not see
while composing and are unable to fix it. It may be bugs in original
mail but the cut and paste should do some sanitization...

the default background color for reading is configurable (I use grey to
protect eyes) is also used when sending meaning the backround color is
used when composing,

Bullet and numbering handling is also bugged when you delete some text
inside a bullet or want to remove a bullet...

That's what comes it mind at the moment... I use TB 38 and still have
mos of thoses...


-- eric


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Yonggang Luo
Is that possible to choose a `Pure HTML` editor instead of the current one?

In our company, we choose pure html KindEditor instead, that's may fixes
some problem.s?
Or even we can choose Google's Closure Editor?

That's looks good to use.

On Sun, Dec 6, 2015 at 9:49 PM, Eric Valette <[hidden email]>
wrote:

> On 05/12/2015 23:37, Jörg Knobloch wrote:
>
>> On 3/12/2015 18:36, Eric Valette wrote:
>>
>>> I know Bugs that are open analysed, impact a lot of people and still
>>> have never been fixed for more than 5 yaers:
>>>     1) Various bug in HTML composing,
>>>
>>
>> HTML composing bugs are mostly due to shortcoming in the Mozilla-Central
>> editor.
>>
>> I have fixed the most annoying ones for Thunderbird 38 and more fixes
>> will be included in Thunderbird 45. Find a list below.
>>
>
> If you paste part of a mail, no just replying that has different font
> color/type, you may end up unable to edit the color or the font type.
>
> Also, you may send something that, when received, has a different look and
> feel because the font size/type have changed but you did not see while
> composing and are unable to fix it. It may be bugs in original mail but the
> cut and paste should do some sanitization...
>
> the default background color for reading is configurable (I use grey to
> protect eyes) is also used when sending meaning the backround color is used
> when composing,
>
> Bullet and numbering handling is also bugged when you delete some text
> inside a bullet or want to remove a bullet...
>
> That's what comes it mind at the moment... I use TB 38 and still have mos
> of thoses...
>
>
>
> -- eric
>
>
> _______________________________________________
> dev-apps-thunderbird mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>



--
         此致

罗勇刚
Yours
    sincerely,
Yonggang Luo
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

R Kent James
In reply to this post by Eric Valette-2
On 12/6/2015 6:09 AM, 罗勇刚(Yonggang Luo)  wrote:
 > Is that possible to choose a `Pure HTML` editor instead of the
current one?
 >
 > In our company, we choose pure html KindEditor instead, that's may fixes
 > some problem.s?
 > Or even we can choose Google's Closure Editor?
 >
 > That's looks good to use.

There was an effort about 4 years ago to investigate alternate HTML
editors, or making the editor pluggable. I was not that close to those
investigations, but what I recall is that they concluded that alternate
editors were not feasible at the time.

Yet clearly a pluggable editor would be of great interest, as the more
technically savvy would probably prefer a pure HTML editor.

My recent work involves a set of code called JsAccount which is designed
to make pluggable account types possible in Thunderbird, plus a lot of
what I have done historically is to improve the ability of addons to
modify things in Thunderbird. Jcranmer has been working on a js
replacement for the whole send and compose backend. With those efforts
were are learning some of the issues about replacing parts of the Send
backend, and hopefully would lead to some major changes in the editor as
well.

For Thunderbird 45, Jörg Knobloch has put substantial effort into fixing
some of the more glaring editor bugs, so this actually is one of the
areas that should see significant improvement in TB 45. If your (Eric's)
issue was not one of the ones touched, well all I can say is patches are
welcome.

:rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Yonggang Luo
How far of your newly JsAccount would be able to released?
Where is the code of JsAccount

On Mon, Dec 7, 2015 at 3:09 AM, R Kent James <[hidden email]> wrote:

> On 12/6/2015 6:09 AM, 罗勇刚(Yonggang Luo)  wrote:
> > Is that possible to choose a `Pure HTML` editor instead of the current
> one?
> >
> > In our company, we choose pure html KindEditor instead, that's may fixes
> > some problem.s?
> > Or even we can choose Google's Closure Editor?
> >
> > That's looks good to use.
>
> There was an effort about 4 years ago to investigate alternate HTML
> editors, or making the editor pluggable. I was not that close to those
> investigations, but what I recall is that they concluded that alternate
> editors were not feasible at the time.
>
> Yet clearly a pluggable editor would be of great interest, as the more
> technically savvy would probably prefer a pure HTML editor.
>
> My recent work involves a set of code called JsAccount which is designed
> to make pluggable account types possible in Thunderbird, plus a lot of what
> I have done historically is to improve the ability of addons to modify
> things in Thunderbird. Jcranmer has been working on a js replacement for
> the whole send and compose backend. With those efforts were are learning
> some of the issues about replacing parts of the Send backend, and hopefully
> would lead to some major changes in the editor as well.
>
> For Thunderbird 45, Jörg Knobloch has put substantial effort into fixing
> some of the more glaring editor bugs, so this actually is one of the areas
> that should see significant improvement in TB 45. If your (Eric's) issue
> was not one of the ones touched, well all I can say is patches are welcome.
>
> :rkent
>
> _______________________________________________
> dev-apps-thunderbird mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>



--
         此致

罗勇刚
Yours
    sincerely,
Yonggang Luo
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

R Kent James
The core parts of JsAccount would be in the tree (hopefully in
Thunderbird 45), so would be fully released. This is based on the
SkinkGlue technology (https://bitbucket.org/rkentjames/skinkglue). See
bug 1229647.

On 12/7/2015 8:16 AM, 罗勇刚(Yonggang Luo) wrote:

> How far of your newly JsAccount would be able to released?
> Where is the code of JsAccount
>
> On Mon, Dec 7, 2015 at 3:09 AM, R Kent James <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 12/6/2015 6:09 AM, 罗勇刚(Yonggang Luo)  wrote:
>     > Is that possible to choose a `Pure HTML` editor instead of the
>     current one?
>     >
>     > In our company, we choose pure html KindEditor instead, that's
>     may fixes
>     > some problem.s?
>     > Or even we can choose Google's Closure Editor?
>     >
>     > That's looks good to use.
>
>     There was an effort about 4 years ago to investigate alternate
>     HTML editors, or making the editor pluggable. I was not that close
>     to those investigations, but what I recall is that they concluded
>     that alternate editors were not feasible at the time.
>
>     Yet clearly a pluggable editor would be of great interest, as the
>     more technically savvy would probably prefer a pure HTML editor.
>
>     My recent work involves a set of code called JsAccount which is
>     designed to make pluggable account types possible in Thunderbird,
>     plus a lot of what I have done historically is to improve the
>     ability of addons to modify things in Thunderbird. Jcranmer has
>     been working on a js replacement for the whole send and compose
>     backend. With those efforts were are learning some of the issues
>     about replacing parts of the Send backend, and hopefully would
>     lead to some major changes in the editor as well.
>
>     For Thunderbird 45, Jörg Knobloch has put substantial effort into
>     fixing some of the more glaring editor bugs, so this actually is
>     one of the areas that should see significant improvement in TB 45.
>     If your (Eric's) issue was not one of the ones touched, well all I
>     can say is patches are welcome.
>
>     :rkent
>
>     _______________________________________________
>     dev-apps-thunderbird mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Yonggang Luo
I've seen this, and found it's a bit complicated, I may have an alternative
way to do that.


On Tue, Dec 8, 2015 at 1:06 AM, R Kent James <[hidden email]> wrote:

> The core parts of JsAccount would be in the tree (hopefully in Thunderbird
> 45), so would be fully released. This is based on the SkinkGlue technology (
> https://bitbucket.org/rkentjames/skinkglue). See bug 1229647.
>
>
> On 12/7/2015 8:16 AM, 罗勇刚(Yonggang Luo) wrote:
>
> How far of your newly JsAccount would be able to released?
> Where is the code of JsAccount
>
> On Mon, Dec 7, 2015 at 3:09 AM, R Kent James <[hidden email]> wrote:
>
>> On 12/6/2015 6:09 AM, 罗勇刚(Yonggang Luo)  wrote:
>> > Is that possible to choose a `Pure HTML` editor instead of the current
>> one?
>> >
>> > In our company, we choose pure html KindEditor instead, that's may fixes
>> > some problem.s?
>> > Or even we can choose Google's Closure Editor?
>> >
>> > That's looks good to use.
>>
>> There was an effort about 4 years ago to investigate alternate HTML
>> editors, or making the editor pluggable. I was not that close to those
>> investigations, but what I recall is that they concluded that alternate
>> editors were not feasible at the time.
>>
>> Yet clearly a pluggable editor would be of great interest, as the more
>> technically savvy would probably prefer a pure HTML editor.
>>
>> My recent work involves a set of code called JsAccount which is designed
>> to make pluggable account types possible in Thunderbird, plus a lot of what
>> I have done historically is to improve the ability of addons to modify
>> things in Thunderbird. Jcranmer has been working on a js replacement for
>> the whole send and compose backend. With those efforts were are learning
>> some of the issues about replacing parts of the Send backend, and hopefully
>> would lead to some major changes in the editor as well.
>>
>> For Thunderbird 45, Jörg Knobloch has put substantial effort into fixing
>> some of the more glaring editor bugs, so this actually is one of the areas
>> that should see significant improvement in TB 45. If your (Eric's) issue
>> was not one of the ones touched, well all I can say is patches are welcome.
>>
>> :rkent
>>
>> _______________________________________________
>> dev-apps-thunderbird mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>>
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>
>
>


--
         此致

罗勇刚
Yours
    sincerely,
Yonggang Luo
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird future?

Jonathan Protzenko
In reply to this post by R Kent James
On 12/06/2015 11:09 AM, R Kent James wrote:

> On 12/6/2015 6:09 AM, 罗勇刚(Yonggang Luo)  wrote:
> > Is that possible to choose a `Pure HTML` editor instead of the
> current one?
> >
> > In our company, we choose pure html KindEditor instead, that's may
> fixes
> > some problem.s?
> > Or even we can choose Google's Closure Editor?
> >
> > That's looks good to use.
>
> There was an effort about 4 years ago to investigate alternate HTML
> editors, or making the editor pluggable. I was not that close to those
> investigations, but what I recall is that they concluded that
> alternate editors were not feasible at the time.
I think you're referring to that summer I interned at the (now defunct)
Mozilla Messaging. There's three sub-problems.
1. Behavior of the editable area (e.g. "I lost the formatting after
hitting <Enter>!"). That's a core gecko component called "editor" over
which we have little control.
2. The HTML editor (i.e. whatever calls "doCommand" on the
contentEditable) along with the UI (the "bold", "increase font size"
buttons, etc.) is an old piece of code that hasn't changed much since
Mozilla was open-sourced. Most dialogs are clunky (insert image, I'm
looking at you) and could be much better. One way to remedy both 1. and
2. would be to switch to a modern HTML editor (e.g. Aloha Editor) that
doesn't rely on contentEditable. The effort to implement that would be
moderate.
3. The global architecture with a fixed number of all-similar
composition windows. Most of the C++ code relies on the assumption that
there's a single implementation of the composition window. Fixing this
properly would require quite some time investment.

The experiment that I did (https://github.com/protz/Compose) attempted
to fix all 3 at the same time. It demonstrated the feasability of
replacing 1. and 2., but fixing 3. properly was out of scope and I only
did some lightweight monkey-patching and never fixed the core underlying
C++ assumptions.

My sentiment is that no developer really uses HTML composition, thus
meaning that there is little incentive to fix 1. and 2.. Fixing 3. would
be great, but that's just too much hassle imho.

Cheers,

Jonathan
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird