Codebase Approachability and UI innovation

[Benjamin Smedberg]

I am a longtime user, experienced Mozilla developer and occasional Tbird
hacker. While I find the question of a new organizational home for Tbird
interesting, I think it is perhaps less important than how Tbird will
approach two key questions: how to improve the approachability of the
codebase, and how to experiment with UI innovation.

CODEBASE APPROACHABILITY

I have a fairly high tolerance for coding pain, and I have found the
mailnews codebase very difficult to navigate and hack effectively. There are
multiple causes for this, that I am going to list in no particular order.
David/Scott, feel free to correct/add to this list ;-)

1) Poor Model-View-Controller separation. The mailnews interfaces make an
attempt at model-view-controller architecture; but the separation is not
very well enforced and the models often make assumptions about the views
they are in. This causes several difficulties, including:

* it's hard to hack new views (alternative UI) for a model
* it's hard to write unit tests for the model when it depends on the view

As with the points below, documentation (overview and specific) is an
important step to know what parts of the code are model, and which are view.
This is especially important when dealing with the SeaMonkey/Thunderbird
split, which kinda-sorta shares a model implementation but has different views.

2) Pervasive C++

Large parts of the mailnews codebase are written in C++ that dates to the
earliest days of XPCOM. The string usage is especially arcane, mixing narrow
and wide strings and has very complex string usage. Some interfaces
explicitly break XPCOM rules or have specialized reference-counting procedures.

I believe that the Thunderbird codebase would benefit greatly from porting
large hunks of this code to JavaScript. JS code is inherently much more
typesafe, has much simpler string handling, and it has automatic support for
new XPCOM features such as cycle collection. And with the new
Components.utils.import feature, it may be possible to completely avoid
XPCOM for a large portion of the codebase, writing native JS APIs.

UI INNOVATION:

I feel, as I know many others do, that the UI of the traditional paned mail
client is in need of serious rethinking. I think that the open-source nature
of Thunderbird makes it an ideal candidate for this sort of radical
reworking. I'm not a very good UI designer, but imagine a local interface
that very closely mimics that of gmail... or an interface that uses tag
clouds and automatic tagging to route mail to various states.

In order to do this, I think we need to solve some of the MVC issues
mentioned above, but also need to actively support some "labs" projects to
experiment with UI. This could focus on consumers or enterprise separately.
It could implement the experiments as extensions or as rewriting the core
multi-pane mail view. The initial mockups might only be hooked up to one
kind of mail transport (POP/SMTP) or ignore signed mail in order to simplify
development. Does anyone have ideas about how we could attract experimental
UI designers to the project and be able to act on their suggestions
productively?

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

[Renaud Lepage]

On Aug 2, 10:07 am, Benjamin Smedberg <[hidden email]> wrote:

> I am a longtime user, experienced Mozilla developer and occasional Tbird
> hacker. While I find the question of a new organizational home for Tbird
> interesting, I think it is perhaps less important than how Tbird will
> approach two key questions: how to improve the approachability of the
> codebase, and how to experiment with UI innovation.
>
> CODEBASE APPROACHABILITY
>
> I have a fairly high tolerance for coding pain, and I have found the
> mailnews codebase very difficult to navigate and hack effectively. There are
> multiple causes for this, that I am going to list in no particular order.
> David/Scott, feel free to correct/add to this list ;-)
>
> 2) Pervasive C++
>
> Large parts of the mailnews codebase are written in C++ that dates to the
> earliest days of XPCOM. The string usage is especially arcane, mixing narrow
> and wide strings and has very complex string usage. Some interfaces
> explicitly break XPCOM rules or have specialized reference-counting procedures.
>
> I believe that the Thunderbird codebase would benefit greatly from porting
> large hunks of this code to JavaScript. JS code is inherently much more
> typesafe, has much simpler string handling, and it has automatic support for
> new XPCOM features such as cycle collection. And with the new
> Components.utils.import feature, it may be possible to completely avoid
> XPCOM for a large portion of the codebase, writing native JS APIs.
>
> --BDS

I may be a n00b in the Thunderbird Codebase, but isn't Javascript code
sort of very easy to hack? And even taking out the hack part, isn't it
a very limited language, whereas C++ is a very versatile language?
Javascript, in my head, should be limited to precisely that: scripts.
I'm just sayin...

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

[Benjamin Smedberg]

Renaud Lepage wrote:

> I may be a n00b in the Thunderbird Codebase, but isn't Javascript code
> sort of very easy to hack? And even taking out the hack part, isn't it
> a very limited language, whereas C++ is a very versatile language?
> Javascript, in my head, should be limited to precisely that: scripts.

What do you mean by "hack"? Longtime evidence with Mozilla has shown that
code written in JavaScript is more readable, memory-safe, and versatile than
code written in C++, and in many cases can perform equally well. JS is
certainly not a very limited language, as evidenced by the fact that all of
our UI code is written in it.

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

[Jean-Marc Desperrier]

Benjamin Smedberg wrote:

> 2) Pervasive C++
>
> Large parts of the mailnews codebase are written in C++ that dates to the
> earliest days of XPCOM. The string usage is especially arcane, mixing narrow
> and wide strings and has very complex string usage. Some interfaces
> explicitly break XPCOM rules or have specialized reference-counting procedures.
>
> I believe that the Thunderbird codebase would benefit greatly from porting
> large hunks of this code to JavaScript. JS code is inherently much more
> typesafe, has much simpler string handling, and it has automatic support for
> new XPCOM features such as cycle collection. And with the new
> Components.utils.import feature, it may be possible to completely avoid
> XPCOM for a large portion of the codebase, writing native JS APIs.

I think the problem mostly is a huge amount of very bad C++, very
verbose and inefficient. I always felt reading the mailnews codebase
that at the start of the project it received all the worse coders so
that they would not disturb the browser code. Unfortunately that didn't
avoid

I've seen multiple level of indirection in the MIME code to add a
genericity that has just no point and has never been used in 8 years,
files like nsMsgDatabase.cpp that are just huge (148kb !) and contain
some non-sense code like this one :
http://lxr.mozilla.org/mozilla/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#3317
    if (err == NS_OK)
    {
        *result = (char *) PR_CALLOC(yarn.mYarn_Fill + 1);
... if allocation fails, returns  err = NS_ERROR_OUT_OF_MEMORY ...
    }
    else if (err == NS_OK)  // guarantee a non-null result
       *result = strdup("");

I could submit a patch for the above, but what would be the point when
what is really needed is a full rewrite ? And in that rewrite, we could
as well think about reducing the amount of C++ code in favor of js, but
the basic problem is not C++, it's bad code, and it could just as well
be bad js code than bad C++ code.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[Renaud Lepage]

On Aug 2, 11:27 am, Benjamin Smedberg <[hidden email]> wrote:

> Renaud Lepage wrote:
> > I may be a n00b in the Thunderbird Codebase, but isn't Javascript code
> > sort of very easy to hack? And even taking out the hack part, isn't it
> > a very limited language, whereas C++ is a very versatile language?
> > Javascript, in my head, should be limited to precisely that: scripts.
>
> What do you mean by "hack"? Longtime evidence with Mozilla has shown that
> code written in JavaScript is more readable, memory-safe, and versatile than
> code written in C++, and in many cases can perform equally well. JS is
> certainly not a very limited language, as evidenced by the fact that all of
> our UI code is written in it.
>
> --BDS

Sorry for my POV. As you can see, I am very not familiar with the
Thunderbird (and zilla in general) codebase.

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

[Jean-Marc Desperrier]

Jean-Marc Desperrier wrote:
> I always felt reading the mailnews codebase
> that at the start of the project it received all the worse coders so
> that they would not disturb the browser code. Unfortunately that didn't
> avoid

There's one word missing here. Can you guess what it is ? :-)

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

[Brian King-2]

Benjamin Smedberg wrote:

> I believe that the Thunderbird codebase would benefit greatly from porting
> large hunks of this code to JavaScript. JS code is inherently much more
> typesafe, has much simpler string handling, and it has automatic support for
> new XPCOM features such as cycle collection. And with the new
> Components.utils.import feature, it may be possible to completely avoid
> XPCOM for a large portion of the codebase, writing native JS APIs.

And in the process, merge mail/ and mailnews/ into one module. mailnews
is largely a legacy of the Suite, and last time I did a TB extension the
UI was pulling in files from both modules, seemingly randomly. There are
even some sub-modules trying to do the same thing (mailnews/compose/ <->
mail/components/compose/). I'm not sure though how much mailnews code
that Seamonkey is using that TB is not, and mail/ code that is exclusive
to TB.

> UI INNOVATION:
> In order to do this, I think we need to solve some of the MVC issues
> mentioned above, but also need to actively support some "labs" projects to
> experiment with UI. This could focus on consumers or enterprise separately.
> It could implement the experiments as extensions or as rewriting the core
> multi-pane mail view. The initial mockups might only be hooked up to one
> kind of mail transport (POP/SMTP) or ignore signed mail in order to simplify
> development. Does anyone have ideas about how we could attract experimental
> UI designers to the project and be able to act on their suggestions
> productively?

Enterprise requests are for the most part not UI related, better LDAP
support being one example that comes to mind (see bug 86405 for a good
ol' favourite). So I don't see UI innovation being enterprise driven,
though I could be wrong.

You mentioned Mozilla Labs. Getting a TB project of this nature in there
would be a good incentive and increase the profile. We could send out a
'call for ideas', whittle down a shortlist, and choose one to implement
as a prototype. All the innovation is going on in the webmail space now,
but this doesn't mean the traditional client can't come up with
something different.

--
Brian King
www.mozdev.org - free project hosting for the Mozilla community
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[Ron K.]

On 8/3/2007 12:57 PM, Thunderbird leader Brian King by teletype announced:

> Benjamin Smedberg wrote:
>
>  
>> I believe that the Thunderbird codebase would benefit greatly from porting
>> large hunks of this code to JavaScript. JS code is inherently much more
>> typesafe, has much simpler string handling, and it has automatic support for
>> new XPCOM features such as cycle collection. And with the new
>> Components.utils.import feature, it may be possible to completely avoid
>> XPCOM for a large portion of the codebase, writing native JS APIs.
>>    
>
> And in the process, merge mail/ and mailnews/ into one module. mailnews
> is largely a legacy of the Suite, and last time I did a TB extension the
> UI was pulling in files from both modules, seemingly randomly. There are
> even some sub-modules trying to do the same thing (mailnews/compose/ <->
> mail/components/compose/). I'm not sure though how much mailnews code
> that Seamonkey is using that TB is not, and mail/ code that is exclusive
> to TB.
>
>  
>> UI INNOVATION:
>> In order to do this, I think we need to solve some of the MVC issues
>> mentioned above, but also need to actively support some "labs" projects to
>> experiment with UI. This could focus on consumers or enterprise separately.
>> It could implement the experiments as extensions or as rewriting the core
>> multi-pane mail view. The initial mockups might only be hooked up to one
>> kind of mail transport (POP/SMTP) or ignore signed mail in order to simplify
>> development. Does anyone have ideas about how we could attract experimental
>> UI designers to the project and be able to act on their suggestions
>> productively?
>>    
>
> Enterprise requests are for the most part not UI related, better LDAP
> support being one example that comes to mind (see bug 86405 for a good
> ol' favourite). So I don't see UI innovation being enterprise driven,
> though I could be wrong.
>
> You mentioned Mozilla Labs. Getting a TB project of this nature in there
> would be a good incentive and increase the profile. We could send out a
> 'call for ideas', whittle down a shortlist, and choose one to implement
> as a prototype. All the innovation is going on in the webmail space now,
> but this doesn't mean the traditional client can't come up with
> something different.

Brian, there is an effort in motion right now to generate ideas and
produce a summary report for peer review that can voice user concepts
that Team Thunderbird can draw from for future roadmap design.  The
dialog is here in dev.apps. thunderbird.

--
Ron K.
Don't be a fonted, it's just type casting
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[David Bienvenu]

Benjamin Smedberg wrote:
> 1) Poor Model-View-Controller separation. The mailnews interfaces make an
> attempt at model-view-controller architecture; but the separation is not
> very well enforced and the models often make assumptions about the views
> they are in. This causes several difficulties, including:
>  
Examples? Other than our use of RDF, which people who shall remain
nameless forced down our throats in the early days of Mozilla over my
strenuous objections :-( I'd love to get rid of RDF but it has got its
evil hooks into a lot of places.
> * it's hard to hack new views (alternative UI) for a model
>  
Correo seems to have managed to build a front end on  top of our
backend/model.
> As with the points below, documentation (overview and specific) is an
> important step to know what parts of the code are model, and which are view.
> This is especially important when dealing with the SeaMonkey/Thunderbird
> split, which kinda-sorta shares a model implementation but has different views.
>  
We must be thinking of different things when we talk about model and
view. When I think of the model, I think of classes like nsIMsgDatabase,
nsLocalMailFolder, nsMsgAccountManager, etc. And when I think of view, I
think of nsIMsgDBView, the xul template in the folder pane, etc. True,
Thunderbird and SM have somewhat different xul code, but the model is
exactly the same, and the interaction between the view and model is the
same.

Are you referring to pane layout when you say that SeaMonkey/Thunderbird
have different views? That stuff tends to get synced up occasionally,
when Scott sees that SM is doing pane layout in a nicer way...

- David


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

[Tony Mechelynck]

Benjamin Smedberg wrote:
[...]

> UI INNOVATION:
>
> I feel, as I know many others do, that the UI of the traditional paned mail
> client is in need of serious rethinking. I think that the open-source nature
> of Thunderbird makes it an ideal candidate for this sort of radical
> reworking. I'm not a very good UI designer, but imagine a local interface
> that very closely mimics that of gmail... or an interface that uses tag
> clouds and automatic tagging to route mail to various states.
>
> In order to do this, I think we need to solve some of the MVC issues
> mentioned above, but also need to actively support some "labs" projects to
> experiment with UI. This could focus on consumers or enterprise separately.
> It could implement the experiments as extensions or as rewriting the core
> multi-pane mail view. The initial mockups might only be hooked up to one
> kind of mail transport (POP/SMTP) or ignore signed mail in order to simplify
> development. Does anyone have ideas about how we could attract experimental
> UI designers to the project and be able to act on their suggestions
> productively?
>
> --BDS

About UI innovation, I've seen a number of Tb threads mentioning multitab
windows recently. I haven't delved very deeply into those threads, but what about:
1. any number of "message" tabs (or windows)
   - with "compose" or "view source" overlay displays in a manner analogous to
the browsers' "view source" window
   - optionally with a sidebar (see 2 below)
2. any number of "one folder's contents" tabs (or sidebar to the message
tab/window)
   -optionally with sidebar (see 3 below)
3. one "accounts and folders tree" tab (or sidebar to the single-folder
directories)

The current view (less the preview pane which is a security liability anyway)
could still be had by displaying one "folder directory" window with the
accounts-and-folders tree as sidebar, plus any number of message windows.

The "mailer start page" could still be displayed (at the user's choice) in the
first/only tab at startup (and in any tab via menus). (and what about some
widget in the "customize toolbars" bag of tools, to change its URL on the fly
between http://anything, file:///anything, and, most important, about:
about:config or about:buildconfig ? Yes, Tb _can_ already display about: or
about:buildconfig with no code changes)

Optionally (and maybe as an extension) the add-ons window (and maybe even the
Preferences) could also open in a tab, but that's for later if ever.


About message transports, write any (image) mockups you like, but IMHO any
implementation (even "bleeding-edge" trunk) should present POP/SMTP, IMAP and
NNTP the same way to the user. Also spop, snews, etc., or whatever they're called.


Best regards,
Tony.
--
Once upon a time, there was a non-conforming sparrow who decided not to
fly south for the winter.  However, soon after the weather turned cold,
the sparrow changed his mind and reluctantly started to fly south.
After a short time, ice began to form his on his wings and he fell to
earth in a barnyard almost frozen.  A cow passed by and crapped on this
little bird and the sparrow thought it was the end, but the manure
warmed him and defrosted his wings.  Warm and happy the little sparrow
began to sing.  Just then, a large Tom cat came by and hearing the
chirping investigated the sounds.  As Old Tom cleared away the manure,
he found the chirping bird and promptly ate him.

There are three morals to this story:

(1) Everyone who shits on you is not necessarily your enemy.
(2) Everyone who gets you out of shit is not necessarily your friend.
(3) If you are warm and happy in a pile of shit, keep your mouth shut.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[Eddy Nigg (StartCom Ltd.)]

Tony Mechelynck wrote:

> About UI innovation, I've seen a number of Tb threads mentioning multitab
> windows recently. I haven't delved very deeply into those threads, but what about:
> 1. any number of "message" tabs (or windows)
>    - with "compose" or "view source" overlay displays in a manner analogous to
> the browsers' "view source" window
>    - optionally with a sidebar (see 2 below)
> 2. any number of "one folder's contents" tabs (or sidebar to the message
> tab/window)
>    -optionally with sidebar (see 3 below)
> 3. one "accounts and folders tree" tab (or sidebar to the single-folder
> directories)
>  

I've played with it for a while and also have the latest lightning
installed from the nightly (very suggested). It makes a lot of sense in
my opinion, that the tabs are located in the messages and preview area.
Subsequently the calendar, proposed IM, compose mail, messages and
preview, etc are opened in the tabs, with keeping a clear view to the
Folders and Contacts on the sidebar. The contacts might become even more
important when IM is implemented. Switching between tabs just to see the
Folders (I have three different folder roots (two IMAP accounts and
about five POP3)) or the contacts is _very_ inconvenient! With the new
calendar layout it makes even more sense I think.

> The current view (less the preview pane which is a security liability anyway)
> could still be had by displaying one "folder directory" window with the
> accounts-and-folders tree as sidebar, plus any number of message windows.
>
> The "mailer start page" could still be displayed (at the user's choice) in the
> first/only tab at startup (and in any tab via menus). (and what about some
> widget in the "customize toolbars" bag of tools, to change its URL on the fly
> between http://anything, file:///anything, and, most important, about:
> about:config or about:buildconfig ? Yes, Tb _can_ already display about: or
> about:buildconfig with no code changes)
>  

Actually interesting, I have never seen that "start page", so I saw the
configuration option for it...When is this displayed?
> Optionally (and maybe as an extension) the add-ons window (and maybe even the
> Preferences) could also open in a tab, but that's for later if ever.
>  
Good idea!

--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Jabber:      [hidden email]
Phone:       [phone]
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[Tony Mechelynck]

Eddy Nigg (StartCom Ltd.) wrote:
> Tony Mechelynck wrote:
[...]

>> The "mailer start page" could still be displayed (at the user's
>> choice) in the first/only tab at startup (and in any tab via menus).
>> (and what about some widget in the "customize toolbars" bag of tools,
>> to change its URL on the fly between http://anything,
>> file:///anything, and, most important, about: about:config or
>> about:buildconfig ? Yes, Tb _can_ already display about: or
>> about:buildconfig with no code changes)
>>  
> Actually interesting, I have never seen that "start page", so I saw the
> configuration option for it...When is this displayed?

Currently, it is displayed in the Preview Pane in two circumstances:

a) at startup, if the appropriate checkbox has been checked (or left checked)
-- that means mailnews.start_page.enabled == true and Edit => Preferences =>
[x] When Thunderbird launches, show Start Page in message area

b) by using the menu: Go => Mail Start Page

The URL is user-selectable, which makes Thunderbird a browser (of sorts). It's
the only way (that I know of) to display about:buildconfig in Thunderbird. It
is also one of several possible ways of accessing about:config

Edit => Preferences => General => (Thunderbird Start Page) Location: [...] or
mailnews.start_page.url (string)

>> Optionally (and maybe as an extension) the add-ons window (and maybe
>> even the Preferences) could also open in a tab, but that's for later
>> if ever.
>>  
> Good idea!
>

Best regards,
Tony.
--
... the MYSTERIANS are in here with my CORDUROY SOAP DISH!!
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[Benjamin Smedberg]

David Bienvenu wrote:

> Benjamin Smedberg wrote:
>> 1) Poor Model-View-Controller separation. The mailnews interfaces make an
>> attempt at model-view-controller architecture; but the separation is not
>> very well enforced and the models often make assumptions about the views
>> they are in. This causes several difficulties, including:
>>  
> Examples? Other than our use of RDF, which people who shall remain
> nameless forced down our throats in the early days of Mozilla over my
> strenuous objections :-( I'd love to get rid of RDF but it has got its
> evil hooks into a lot of places.

Interactions around nsIMsgComposeService is the one I've had personal
experience with. At the time I was trying to hack it, it made assumptions
about the message window presentation (that it's a standalone window, and
that progress information was part of a separate UI entity).

> We must be thinking of different things when we talk about model and
> view. When I think of the model, I think of classes like nsIMsgDatabase,
> nsLocalMailFolder, nsMsgAccountManager, etc. And when I think of view, I
> think of nsIMsgDBView, the xul template in the folder pane, etc. True,
> Thunderbird and SM have somewhat different xul code, but the model is
> exactly the same, and the interaction between the view and model is the
> same.

OK, I wasn't very precise.

1) Thunderbird and SeaMonkey share a lot of the view code. The fact that
parts of the view (the XUL/JS) are forked and parts are not is extremely
confusing to occasional hackers such as myself, because it's very difficult
to figure out which files are included in what products.

2) It's not always clear what is the model and what is the view. If I were,
for example, going to replace the three-pane threaded message view with
gmail-style threads+tagging interface, where would I draw the line so that I
keep the model and completely replace the view?

3) The model seems to have dependencies on the controllers and view. See,
for instance, nsParseMailbox.cpp, which I'm pretty sure is model (right?).
It applies filters (are they model?) and use nsIMsgComposeService
(controller with view dependencies).

I'm not sure that a strict MVC architecture would work very well (for
performance reasons, mainly), but I do think that the general MVC
architecture is the right fit for the codebase and it would be good to make
explicit decisions about which code is model, view, controller and then hook
them together more effectively. Dependencies that intentionally break the
normal MVC rules could then be documented and coders could work through them
explicitly.

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

[David Bienvenu]

Benjamin Smedberg wrote:
> Interactions around nsIMsgComposeService is the one I've had personal
> experience with. At the time I was trying to hack it, it made assumptions
> about the message window presentation (that it's a standalone window, and
> that progress information was part of a separate UI entity).
>  
Ugh, I'm sorry you had to have personal experience with the
nsIMsgComposeService. You're right; it's very hard to figure out what's
Model or View there.  I hate changing that code, and it always takes me
forever to figure out what's going on.

It is possible to use the compose service without a visible compose
window, e.g., MAPI blind send does not open a compose window, though it
does use the hidden app window.

 It's also possible to have progress information presented  in a
stand-alone progress window, or in the progress widget in the compose
window, or not at all. I believe you can attach whatever nsIMsgWindow or
nsIMsgStatusFeedback you want. And nsIMsgWindow is simply an interface;
you can provide whatever object you want that implements the interface.
It doesn't have to be a ui element. I don't believe there absolutely has
to be  a dom window in order for things to work; if that's not the case,
it should just be fixed. In general, we try to make it so that if no
nsIMsgWindow is passed into a method, we don't involve the UI in the
operation.
>  
> 1) Thunderbird and SeaMonkey share a lot of the view code. The fact that
> parts of the view (the XUL/JS) are forked and parts are not is extremely
> confusing to occasional hackers such as myself, because it's very difficult
> to figure out which files are included in what products.
>  
Yeah, that sucks. We share mailnews/base/prefs, and
mailnews/base/resources/content/threadPane.js, and xul, and
folderProps.js,xul. Beyond that, I don't think there's much xul that we
share.  That's probably something worth starting a doc on devmo about,
though. I could take an initial stab at that, if there's no such doc.

> 2) It's not always clear what is the model and what is the view. If I were,
> for example, going to replace the three-pane threaded message view with
> gmail-style threads+tagging interface, where would I draw the line so that I
> keep the model and completely replace the view?
>  
nsIMsgDatabase, nsIMsgThread and nsIMsgDBHdr would be your model (I'm
assuming that gmail-style conversations are really threads - if you need
to build up your own idea of thread, you'd need to do that from
nsIMsgDatabase and nsIMsgHdr. We can argue about whether threads are
model or view, but threads have persistent attributes, like being
watched or ignored, so I consider them part of the model ).

The view code is nsIMsgDBView - you'd be creating your own view class,
and probably would have no need of the existing view classes.
> 3) The model seems to have dependencies on the controllers and view. See,
> for instance, nsParseMailbox.cpp, which I'm pretty sure is model (right?).
>  
It parses one model (the mailbox, or a set of msg headers) and converts
it to a second form of model, the msg hdr, so yeah. I guess the
application of filters is also a model thing, in that they make changes
to the model, mostly.  But filter actions can have a bit of a controller
sense to them - if we added a filter action to play a different sound
for a message,  it's hard to imagine how to do that in a way that
doesn't invoke the controller, other than sending a notification, or
setting an attribute on the msg hdr and checking for that later on.
> I'm not sure that a strict MVC architecture would work very well (for
> performance reasons, mainly), but I do think that the general MVC
> architecture is the right fit for the codebase and it would be good to make
> explicit decisions about which code is model, view, controller and then hook
> them together more effectively. Dependencies that intentionally break the
> normal MVC rules could then be documented and coders could work through them
> explicitly.
>  
You've certainly put your finger on a couple places where MVC are mixed
together. I think in general we separate the model and view but the
controller is mixed in both.

- David


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

[Mark Banner]

Benjamin Smedberg wrote:
> 2) Pervasive C++
>
> Large parts of the mailnews codebase are written in C++ that dates to the
> earliest days of XPCOM. The string usage is especially arcane, mixing narrow
> and wide strings and has very complex string usage. Some interfaces
> explicitly break XPCOM rules or have specialized reference-counting procedures.

Yes we need some improvement here.

> I believe that the Thunderbird codebase would benefit greatly from porting
> large hunks of this code to JavaScript. JS code is inherently much more
> typesafe, has much simpler string handling, and it has automatic support for
> new XPCOM features such as cycle collection. And with the new
> Components.utils.import feature, it may be possible to completely avoid
> XPCOM for a large portion of the codebase, writing native JS APIs.

I'm not sure if this is the right way to go. I heard at one time that
starting up with js components is slower than the C++ alternative (I
think it was a Firefox bug, but I don't know if it got resolved or not).
Given the amount of code in mailnews is much more than Firefox, have we
any idea how much startup/performance would be affected.

I'm also concerned that the mailnews code currently makes good use of
inheritance throughout its code base - I don't see a way to do that
without code duplication in js, though please point me in the right
direction if I am wrong.

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

[Benjamin Smedberg]

Mark Banner wrote:

> I'm not sure if this is the right way to go. I heard at one time that
> starting up with js components is slower than the C++ alternative (I
> think it was a Firefox bug, but I don't know if it got resolved or not).
> Given the amount of code in mailnews is much more than Firefox, have we
> any idea how much startup/performance would be affected.

The timing problems have been largely resolved through the use of the
fastload cache.

> I'm also concerned that the mailnews code currently makes good use of
> inheritance throughout its code base - I don't see a way to do that
> without code duplication in js, though please point me in the right
> direction if I am wrong.

JS can do inheritance... perhaps I don't understand the question you're asking.

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

[Craig-45]

Benjamin Smedberg wrote:

> I am a longtime user, experienced Mozilla developer and occasional Tbird
> hacker. While I find the question of a new organizational home for Tbird
> interesting, I think it is perhaps less important than how Tbird will
> approach two key questions: how to improve the approachability of the
> codebase, and how to experiment with UI innovation.
>
> CODEBASE APPROACHABILITY
>
> I have a fairly high tolerance for coding pain, and I have found the
> mailnews codebase very difficult to navigate and hack effectively. There are
> multiple causes for this, that I am going to list in no particular order.
> David/Scott, feel free to correct/add to this list ;-)
>
> 1) Poor Model-View-Controller separation. The mailnews interfaces make an
> attempt at model-view-controller architecture; but the separation is not
> very well enforced and the models often make assumptions about the views
> they are in. This causes several difficulties, including:
>
> * it's hard to hack new views (alternative UI) for a model
> * it's hard to write unit tests for the model when it depends on the view
>
> As with the points below, documentation (overview and specific) is an
> important step to know what parts of the code are model, and which are view.
> This is especially important when dealing with the SeaMonkey/Thunderbird
> split, which kinda-sorta shares a model implementation but has different views.
>
> 2) Pervasive C++
>
> Large parts of the mailnews codebase are written in C++ that dates to the
> earliest days of XPCOM. The string usage is especially arcane, mixing narrow
> and wide strings and has very complex string usage. Some interfaces
> explicitly break XPCOM rules or have specialized reference-counting procedures.
>
> I believe that the Thunderbird codebase would benefit greatly from porting
> large hunks of this code to JavaScript. JS code is inherently much more
> typesafe, has much simpler string handling, and it has automatic support for
> new XPCOM features such as cycle collection. And with the new
> Components.utils.import feature, it may be possible to completely avoid
> XPCOM for a large portion of the codebase, writing native JS APIs.
>
> UI INNOVATION:
>
> I feel, as I know many others do, that the UI of the traditional paned mail
> client is in need of serious rethinking. I think that the open-source nature
> of Thunderbird makes it an ideal candidate for this sort of radical
> reworking. I'm not a very good UI designer, but imagine a local interface
> that very closely mimics that of gmail... or an interface that uses tag
> clouds and automatic tagging to route mail to various states.
>
> In order to do this, I think we need to solve some of the MVC issues
> mentioned above, but also need to actively support some "labs" projects to
> experiment with UI. This could focus on consumers or enterprise separately.
> It could implement the experiments as extensions or as rewriting the core
> multi-pane mail view. The initial mockups might only be hooked up to one
> kind of mail transport (POP/SMTP) or ignore signed mail in order to simplify
> development. Does anyone have ideas about how we could attract experimental
> UI designers to the project and be able to act on their suggestions
> productively?
>
> --BDS

Apologies, but testing is fun.

Best regards,
Jeremy Morton (Jez)

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

[w.b.kranendonk]

On Aug 2, 4:07 pm, Benjamin Smedberg <[hidden email]> wrote:
> UI INNOVATION:
>
> I feel, as I know many others do, that the UI of the traditional paned mail
> client is in need of serious rethinking. I think that the open-source nature
> of Thunderbird makes it an ideal candidate for this sort of radical
> reworking. I'm not a very good UI designer, but imagine a local interface
> that very closely mimics that of gmail... or an interface that uses tag
> clouds and automatic tagging to route mail to various states.
>
It is a bit of an old thread by now to dig up, but subject-wise it is
the nearest I could get to.

I am in favour of the suggested tag clouds. Still, coming back to the
traditional panes, would it be an extra to be able to "blend" various
leaves of a tree structure? After tagging individual mails or threads
with some tems, one could tick "on" those tags and the messagelist
could give a structured view of the messages contained in the various
folders / under the various tags.

Is it useful to put some functionality like this in the client
directly, or would it be preferable to have it in an extension?

Regards,

Boudewijn

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

[w.b.kranendonk]

On Aug 4, 9:29 am, Tony Mechelynck <[hidden email]>
wrote:

> Benjamin Smedberg wrote:
>
> [...]
>
>
>
> > UI INNOVATION:
>
> > I feel, as I know many others do, that the UI of the traditional paned mail
> > client is in need of serious rethinking. I think that the open-source nature
> > of Thunderbird makes it an ideal candidate for this sort of radical
> > reworking. I'm not a very good UI designer, but imagine a local interface
> > that very closely mimics that of gmail... or an interface that uses tag
> > clouds and automatic tagging to route mail to various states.
>
> > In order to do this, I think we need to solve some of the MVC issues
> > mentioned above, but also need to actively support some "labs" projects to
> > experiment with UI. This could focus on consumers or enterprise separately.
> > It could implement the experiments as extensions or as rewriting the core
> > multi-pane mail view. The initial mockups might only be hooked up to one
> > kind of mail transport (POP/SMTP) or ignore signed mail in order to simplify
> > development. Does anyone have ideas about how we could attract experimental
> > UI designers to the project and be able to act on their suggestions
> > productively?
>
> > --BDS
>
> About UI innovation, I've seen a number of Tb threads mentioning multitab
> windows recently. I haven't delved very deeply into those threads, but what about:
> 1. any number of "message" tabs (or windows)
>    - with "compose" or "view source" overlay displays in a manner analogous to
> the browsers' "view source" window
>    - optionally with a sidebar (see 2 below)
> 2. any number of "onefolder'scontents" tabs (or sidebar to the message
> tab/window)
>    -optionally with sidebar (see 3 below)
> 3. one "accounts and folderstree" tab (or sidebar to the single-folder
> directories)
>
> The current view (less the preview pane which is a security liability anyway)
> could still be had by displaying one "folderdirectory" window with the
> accounts-and-folderstreeas sidebar, plus any number of message windows.
>
> The "mailer start page" could still be displayed (at the user's choice) in the
> first/only tab at startup (and in any tab via menus). (and what about some
> widget in the "customize toolbars" bag of tools, to change its URL on the fly
> betweenhttp://anything, file:///anything, and, most important, about:
> about:config or about:buildconfig ? Yes, Tb _can_ already display about: or
> about:buildconfig with no code changes)
>
> Optionally (and maybe as an extension) the add-ons window (and maybe even the
> Preferences) could also open in a tab, but that's for later if ever.
>
> About message transports, write any (image) mockups you like, but IMHO any
> implementation (even "bleeding-edge" trunk) should present POP/SMTP, IMAP and
> NNTP the same way to the user. Also spop, snews, etc., or whatever they're called.
>
> Best regards,
> Tony.
> --
> Once upon a time, there was a non-conforming sparrow who decided not to
> fly south for the winter.  However, soon after the weather turned cold,
> the sparrow changed his mind and reluctantly started to fly south.
> After a short time, ice began to form his on his wings and he fell to
> earth in a barnyard almost frozen.  A cow passed by and crapped on this
> little bird and the sparrow thought it was the end, but the manure
> warmed him and defrosted his wings.  Warm and happy the little sparrow
> began to sing.  Just then, a large Tom cat came by and hearing the
> chirping investigated the sounds.  As Old Tom cleared away the manure,
> he found the chirping bird and promptly ate him.
>
> There are three morals to this story:
>
> (1) Everyone who shits on you is not necessarily your enemy.
> (2) Everyone who gets you out of shit is not necessarily your friend.
> (3) If you are warm and happy in a pile of shit, keep your mouth shut.

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