I've made some works about the vertical view of Thunderbird (see bug 213945 from comment 26). Take a look at the last screenshots: http://www.mozbox.org/pub/tb/
In addition, I'm interested in developing a way (a TreeBodyFrame hack too) to include the message content *in* the threadPane (see http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it seems to be faisable).
Since such developments will require a lot of work and many discussions (such patches are layout component related, it could impact all Mozilla products), I really need to know if the way chosen is the right way and if this is something that could interest you for TB3.
BTW, is there something like mozilla lab for Thunderbird ?
> I've made some works about the vertical view of Thunderbird (see bug > 213945 from comment 26). Take a look at the last screenshots: > http://www.mozbox.org/pub/tb/
> In addition, I'm interested in developing a way (a TreeBodyFrame hack > too) to include the message content *in* the threadPane (see > http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it > seems to be faisable).
Cool!
> Since such developments will require a lot of work and many > discussions (such patches are layout component related, it could > impact all Mozilla products), I really need to know if the way chosen > is the right way and if this is something that could interest you for > TB3.
My feeling is that it's certainly possible, but it'd be good to have that come out of a bigger discussion of _why_ different layouts might make sense for what interactions, what users, in what contexts, etc.
Bryan, your take?
> BTW, is there something like mozilla lab for Thunderbird ?
Not really, but I'm sure if you had a specific idea for something that made sense within Mozilla Labs, that we could work something out. What resources do you need?
> I've made some works about the vertical view of Thunderbird (see bug > 213945 from comment 26). Take a look at the last screenshots: > http://www.mozbox.org/pub/tb/
> In addition, I'm interested in developing a way (a TreeBodyFrame hack > too) to include the message content *in* the threadPane (see > http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it > seems to be faisable).
Now THIS looks kind of interesting. Perhaps one needs to get used to it, but....mmm...not bad ;-)
> I've made some works about the vertical view of Thunderbird (see bug > 213945 from comment 26). Take a look at the last screenshots: > http://www.mozbox.org/pub/tb/
> In addition, I'm interested in developing a way (a TreeBodyFrame hack > too) to include the message content *in* the threadPane (see > http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it > seems to be faisable).
> Since such developments will require a lot of work and many > discussions (such patches are layout component related, it could > impact all Mozilla products), I really need to know if the way chosen > is the right way and if this is something that could interest you for > TB3.
> BTW, is there something like mozilla lab for Thunderbird ?
>> I've made some works about the vertical view of Thunderbird (see bug >> 213945 from comment 26). Take a look at the last screenshots: >> http://www.mozbox.org/pub/tb/
>> In addition, I'm interested in developing a way (a TreeBodyFrame hack >> too) to include the message content *in* the threadPane (see >> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it >> seems to be faisable).
> Now THIS looks kind of interesting. Perhaps one needs to get used to > it, but....mmm...not bad ;-)
I agree it's an interesting alternative layout for mail when I realized it is using the Tb3 Tabbed Interface. Where I see a down side is how the layout would work for vision impared recipients. The need for smaller print to cram a subject line in below the Sender will reduce readability.
Has this been evaluated for news reading? News can generate some very long threads. Also, display of HTML content would need a zoom feature to enable images to render full detail. The Add-on that provides the Acrobat drag gripper should work nicely when a user zooms in on an image.
-- Ron K. Who is General Failure, and why is he searching my HDD? Kernel Restore reported BSOD use by Major Error to msg the enemy!
> I agree it's an interesting alternative layout for mail when I realized > it is using the Tb3 Tabbed Interface. Where I see a down side is how > the layout would work for vision impared recipients. The need for > smaller print to cram a subject line in below the Sender will reduce > readability.
Actually when I saw it I immediately thought about mobiles and smaller devices. It's an interesting approach.
Eddy Nigg (StartCom Ltd.) keyboarded, On 3/9/2008 10:35 PM :
> Ron K.:
>> I agree it's an interesting alternative layout for mail when I >> realized it is using the Tb3 Tabbed Interface. Where I see a down >> side is how the layout would work for vision impared recipients. The >> need for smaller print to cram a subject line in below the Sender >> will reduce readability.
> Actually when I saw it I immediately thought about mobiles and smaller > devices. It's an interesting approach.
Several years ago when MS was developing the Windows CE OS for Notebook computers they ran into a Font problem. All the stock fonts that MS was bundeling with Windows and Office products were either too large or poorly shaped to scall down to the smaller screens. The solution was having Mathew Carter, the elite font designer at Monotype, create a new font face which rendered clearly at 7 pixel size on the Notbook screens. The Nina family is a descendant of the sequence from Verdana to Tahoma then Trebuchet MS that Mathew Carter designed for the MS Web Font collection. Unfortunately Nina is no longer a free d/l from MS, and is now sold by Ascender Corp. which is the exclusive agent for the entire library of fonts developed by MS.
Not too far back in time, Bitstream designed the Vera families of sans and serif fonts for the Gnome Linux project. Those fonts, while copyrighted, were released under the GPL license which permits font designers to legally extend and revise the fonts. In my view, Mozilla Foundation should consider a similar arrangement that would permit shipping a sanserif font family with Fx and Tb as a system font to meet the needs of small screen mobile devices.
I have extensively revised the Fx and Tb themes UI with Nina in sizes from 8px to 13px. The tighter letter spacing yealds a lot more room for long subject or extensive threads before text begins to truncate.
-- Ron K. Who is General Failure, and why is he searching my HDD? Kernel Restore reported BSOD use by Major Error to msg the enemy!
On Sun, 2008-03-09 at 23:33 -0400, Ron K. wrote: > Not too far back in time, Bitstream designed the Vera families of > sans > and serif fonts for the Gnome Linux project. Those fonts, while > copyrighted, were released under the GPL license which permits font > designers to legally extend and revise the fonts. In my view, Mozilla > Foundation should consider a similar arrangement that would permit > shipping a sanserif font family with Fx and Tb as a system font to meet > the needs of small screen mobile devices.
Mozilla shipping the DejaVu fonts (the open-source descendants of Bitstream Vera) in their Windows and OS X builds (they should already come with most Linux distros) would be pretty cool.
David Ascher wrote: > paul.rou...@gmail.com wrote: >> Hi folks.
>> I've made some works about the vertical view of Thunderbird (see bug >> 213945 from comment 26). Take a look at the last screenshots: >> http://www.mozbox.org/pub/tb/
>> In addition, I'm interested in developing a way (a TreeBodyFrame hack >> too) to include the message content *in* the threadPane (see >> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it >> seems to be faisable).
> Cool!
Excellent stuff, I had been reading over that bug after it was sent to me last week.
>> Since such developments will require a lot of work and many >> discussions (such patches are layout component related, it could >> impact all Mozilla products), I really need to know if the way chosen >> is the right way and if this is something that could interest you for >> TB3.
> My feeling is that it's certainly possible, but it'd be good to have > that come out of a bigger discussion of _why_ different layouts might > make sense for what interactions, what users, in what contexts, etc.
> Bryan, your take?
Yes, certainly possible and I really like what you've done so far.
I'd like to see this tried out; if it was an extension I would have downloaded it by now and tested it. But I agree that there are a lot of open questions in my mind about the overall design of the layout and where it fits.
Reading the bug from the beginning led me to believe that this layout change is necessary *only* for the vertical view layout because of the decreased horizontal space available. While on a wide or normal view there is plenty of horizontal space available to the tree view and therefore it doesn't need to compact things into vertical space. However it is interesting to see the change applied to other layout types.
What's the vision here?
I feel like it's a great time to start the larger discussion of what makes sense (in terms of layouts) for different people and their email use. I'm doing a bit of screenshot gathering of some different systems right now, I'll get back with those.
> I've made some works about the vertical view of Thunderbird (see bug > 213945 from comment 26). Take a look at the last screenshots: > http://www.mozbox.org/pub/tb/
> In addition, I'm interested in developing a way (a TreeBodyFrame hack > too) to include the message content *in* the threadPane (see > http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it > seems to be faisable).
> Since such developments will require a lot of work and many > discussions (such patches are layout component related, it could > impact all Mozilla products), I really need to know if the way chosen > is the right way and if this is something that could interest you for > TB3.
> BTW, is there something like mozilla lab for Thunderbird ?
> Thanks
> Paul Rouget
hi,
do you have working code to implement this? nice job if so, the custom tree view in threadpane is perhaps some of the most complex code in Tb.
1. are you using <richlistitem> for the header info? with the advancements in that widget in Fx (new urlbar autocomplete) this is probably the way to go. 2. imo, this should be optional for all views not just vertical. 3. from my understanding, this is a heavily requested feature, and belongs in core, probably don't need a lot of usage case analysis for this one.. 4. changing into/out of different views and changing from 1 line to 2 or more in threadpane should be dynamic, no restart. 5. moving the messagepane inline with the threadpane messages is interesting. moving major DOM nodes can be tricky, but of the 3 in Tb, messagepane is easiest and lowest impact. 6. don't forget the impact of Lightning - i've found it the only extension that is problematic with DOM node moves (threadpane and folderpane), but it doesn't seem you would need to touch those higher than their <deck> parent.
On Mar 10, 3:26 am, "Ron K." <kill...@gisco.net> wrote:
> I agree it's an interesting alternative layout for mail when I realized > it is using the Tb3 Tabbed Interface.
Yes, using the Tb3 tabbed interface with such layout change make TB UI really compact.
> Has this been evaluated for news reading?
Seems to work.
On Mar 10, 3:35 am, "Eddy Nigg (StartCom Ltd.)"
<eddy_n...@startcom.org> wrote: > Actually when I saw it I immediately thought about mobiles and smaller > devices. It's an interesting approach.
Is there any effort or plan about Tb on mobiles devices ?
On Mar 10, 5:43 am, Bryan W Clark <clar...@gnome.org> wrote:
> I'd like to see this tried out; if it was an extension I would have > downloaded it by now and tested it.
I can provide a TB build including these patches (bugzilla patch is not up-to-date).
> Reading the bug from the beginning led me to believe that this layout > change is necessary *only* for the vertical view layout because of the > decreased horizontal space available. While on a wide or normal view > there is plenty of horizontal space available to the tree view and > therefore it doesn't need to compact things into vertical space. > However it is interesting to see the change applied to other layout types.
> What's the vision here?
These patches provide 2 new features: * give a way to add more content below the classic row * display the message in the thread pane.
Currently, I use this new space to display subject and preview, which makes sense for the vertical view. But it could host any other information (just the preview for instance). Such layout changes don't invalidate current layout, there just provide new way to custom the TB UI. I think this layout change don't have to be vertical view only related. A checkbox in the view menu let you switch between classic rows and mutliline rows.
On Mar 10, 4:38 pm, alta88 <alt...@gmail.com> wrote:
> do you have working code to implement this? nice job if so, the custom > tree view in threadpane is perhaps some of the most complex code in Tb.
Yes, screenshots are not mockup. Multiline rows seem to work well (no big bugs). Inline message is really tricky, lot of bugs. But it's an early draft ! The TB integration is poor.
> 1. are you using <richlistitem> for the header info? with the > advancements in that widget in Fx (new urlbar autocomplete) this is > probably the way to go.
No. It's a TreeBodyFrame (layout object wich displays object implementing nsITreeView) hack. It's very important to use a tree to display message list, for performance issues.
> 2. imo, this should be optional for all views not just vertical.
It is optional. Just selected "multiline" in the view menu.
> 3. from my understanding, this is a heavily requested feature, and > belongs in core, probably don't need a lot of usage case analysis for > this one.. > 4. changing into/out of different views and changing from 1 line to 2 or > more in threadpane should be dynamic, no restart.
It is almost dynamic. No need to restart, but currently, you have to switch between two folder to have "multiline" option taken into account. Actually, the integration in TB is not perfect (specialy about "subject" column display and primary column selection).
> 5. moving the messagepane inline with the threadpane messages is > interesting. moving major DOM nodes can be tricky, but of the 3 in Tb, > messagepane is easiest and lowest impact. > 6. don't forget the impact of Lightning - i've found it the only > extension that is problematic with DOM node moves (threadpane and > folderpane), but it doesn't seem you would need to touch those higher > than their <deck> parent.
The modifications are not really intrusive. I've extended a lot nsMsgDBView (and groupView), but I'm pretty sure Lightning will not be impacted.
> I've made some works about the vertical view of Thunderbird (see bug > 213945 from comment 26). Take a look at the last screenshots: > http://www.mozbox.org/pub/tb/
great stuff. This was requested by some people. I would consider couple of elements though: -have it optional -have also something like "quote collapse" (say activated by default for this thread preview, even if not for the main view) -have the attachments, if the case, like a drop down somewhere in the header (small something ..) for an even quicker access to that part ..
and -have some of it in TB3 ;)
> In addition, I'm interested in developing a way (a TreeBodyFrame hack > too) to include the message content *in* the threadPane (see > http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it > seems to be faisable).
only one thing: is this [message preview and message inside thread] a potential security issue? Hope not.
I just remember that some discussions in support group mentioned how the message pane means actually opening a msg and how some prefer not to use it but to open msg in a new window so that they can actually avoid opening by accident certain ones. In this case msg will be kinda opened by default ..
> Since such developments will require a lot of work and many > discussions (such patches are layout component related, it could > impact all Mozilla products), I really need to know if the way chosen > is the right way and if this is something that could interest you for > TB3.
> BTW, is there something like mozilla lab for Thunderbird ?
Ron K. wrote: > Eddy Nigg (StartCom Ltd.) keyboarded, On 3/9/2008 9:08 PM : >> paul.rou...@gmail.com: >>> Hi folks.
>>> I've made some works about the vertical view of Thunderbird (see bug >>> 213945 from comment 26). Take a look at the last screenshots: >>> http://www.mozbox.org/pub/tb/
>>> In addition, I'm interested in developing a way (a TreeBodyFrame hack >>> too) to include the message content *in* the threadPane (see >>> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it >>> seems to be faisable).
>> Now THIS looks kind of interesting. Perhaps one needs to get used to >> it, but....mmm...not bad ;-)
> I agree it's an interesting alternative layout for mail when I > realized it is using the Tb3 Tabbed Interface. Where I see a down > side is how the layout would work for vision impared recipients. The > need for smaller print to cram a subject line in below the Sender will > reduce readability.
> Has this been evaluated for news reading? News can generate some very > long threads. Also, display of HTML content would need a zoom feature > to enable images to render full detail. The Add-on that provides the > Acrobat drag gripper should work nicely when a user zooms in on an image.
or if it's considered only a preview, for such actions will have to just open the msg in a new window/tab
on the other hand, this readability makes me think of some more control over the size of the elements in text and the size of the "message pane inline with thread". Some resize handle for the vertical space assigned to that would do.
>> 1. are you using <richlistitem> for the header info? with the >> advancements in that widget in Fx (new urlbar autocomplete) this is >> probably the way to go.
> No. It's a TreeBodyFrame (layout object wich displays object > implementing nsITreeView) hack. It's very important to use a tree to > display message list, for performance issues.
one downside, although worth it for performance, of custom tree views is that styling <treechildren> currently is more difficult (mostly because it's not available in DOMi). and people will, rightly, want to style the multiline display.
i'm not familiar with TreeBodyFrame, but the thought was that <richlistitem> would be the final 'leaf', and thus not negate any of the performance advantage - but of course defer to your practical experience with the code.
also, is it truly multiline or 2 lines? perhaps new creative displays can be derived from multiline, so not limiting it to 2 lines architecturally would be nice.
> ---On 2008.Mar.10 10:46 AM, Paul Rouget wrote: >>> 1. are you using <richlistitem> for the header info? with the >>> advancements in that widget in Fx (new urlbar autocomplete) this is >>> probably the way to go.
>> No. It's a TreeBodyFrame (layout object wich displays object >> implementing nsITreeView) hack. It's very important to use a tree to >> display message list, for performance issues.
> one downside, although worth it for performance, of custom tree views > is that styling <treechildren> currently is more difficult (mostly > because it's not available in DOMi). and people will, rightly, want > to style the multiline display.
> i'm not familiar with TreeBodyFrame, but the thought was that > <richlistitem> would be the final 'leaf', and thus not negate any of > the performance advantage - but of course defer to your practical > experience with the code.
> also, is it truly multiline or 2 lines? perhaps new creative displays > can be derived from multiline, so not limiting it to 2 lines > architecturally would be nice.
The treeChildren are actually easy to style in userChrome.css and I use DOMi as an aid to ferret out the Selectors needed to apply font changes. Also I use a disassembled copy of the default theme to see the structure. The proposed JS modifying userChrome.js extension has been wrapped into the Mail Tweak extension that is found as a sup-project of the Journal extension at mozdev.org. With that extension installed a user can gain access to additional selectors in the folder pane tree view.
-- Ron K. Who is General Failure, and why is he searching my HDD? Kernel Restore reported BSOD use by Major Error to msg the enemy!
> only one thing: is this [message preview and message inside thread] a > potential security issue? Hope not.
> I just remember that some discussions in support group mentioned how > the message pane means actually opening a msg and how some prefer not > to use it but to open msg in a new window so that they can actually > avoid opening by accident certain ones. In this case msg will be kinda > opened by default .. >> Since such developments will require a lot of work and many >> discussions (such patches are layout component related, it could >> impact all Mozilla products), I really need to know if the way chosen >> is the right way and if this is something that could interest you for >> TB3.
Tb has a different security model than Outlook Express because the attachments are shown in a separate view container and can not auto-open. As for JS activation, the Tb default controls of JS are tighter than Fx so some JS functions that run in Fx can not in Tb. The support of Marquee is one example. When one adds the Unselect Message extension (After hacking the MaxVersion) the auto opening of messages in the view pane is stopped. The biggest advantage of the New Window view is dropping of any 3 pane view preference when message content is HTML designed for full screen viewing, or the use of the extension by Alta88 that adds a full screen view without the Tb chrome.
I think the only security issues are those that effect Tb as an application. Stability conflicts are a separate issue and use by a large body of testers is what keeps the "Known Conflicts" page at MozillaZine updated.
-- Ron K. Who is General Failure, and why is he searching my HDD? Kernel Restore reported BSOD use by Major Error to msg the enemy!
> I've made some works about the vertical view of Thunderbird (see bug > 213945 from comment 26). Take a look at the last screenshots: > http://www.mozbox.org/pub/tb/
> In addition, I'm interested in developing a way (a TreeBodyFrame hack > too) to include the message content *in* the threadPane (see > http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it > seems to be faisable).
This both looks very promising to me for a mobile device, I for one wouldn't want it in my usual desktop app though, where I can use screen estate differently.
>> ---On 2008.Mar.10 10:46 AM, Paul Rouget wrote: >>>> 1. are you using <richlistitem> for the header info? with the >>>> advancements in that widget in Fx (new urlbar autocomplete) this is >>>> probably the way to go.
>>> No. It's a TreeBodyFrame (layout object wich displays object >>> implementing nsITreeView) hack. It's very important to use a tree to >>> display message list, for performance issues.
>> one downside, although worth it for performance, of custom tree views >> is that styling <treechildren> currently is more difficult (mostly >> because it's not available in DOMi). and people will, rightly, want >> to style the multiline display.
>> i'm not familiar with TreeBodyFrame, but the thought was that >> <richlistitem> would be the final 'leaf', and thus not negate any of >> the performance advantage - but of course defer to your practical >> experience with the code.
>> also, is it truly multiline or 2 lines? perhaps new creative >> displays can be derived from multiline, so not limiting it to 2 lines >> architecturally would be nice.
> The treeChildren are actually easy to style in userChrome.css and I > use DOMi as an aid to ferret out the Selectors needed to apply font > changes. Also I use a disassembled copy of the default theme to see > the structure. The proposed JS modifying userChrome.js extension has > been wrapped into the Mail Tweak extension that is found as a > sup-project of the Journal extension at mozdev.org. With that > extension installed a user can gain access to additional selectors in > the folder pane tree view.
sure, but none of that is 'easy' ;) even for a user beginning to look into css and DOMi. the syntax for <treechildren> is different:
/* If this collapsed or expanded thread is selected, revert to highlight text color */ #threadTree > treechildren::-moz-tree-cell-text(container, closed, hasUnread, read, focus, selected), treechildren::-moz-tree-cell-text(container, hasUnread, read, focus, selected) { color: HighlightText !important;
none of that is discoverable even with DOM, need to code dive, as you said. yes, MailTweak's CSS Selector is very nice, but installing 2 extensions is a bit much. again, it's worth it for performance, but if <richlistitem> works then the simpler route should be taken.
A tree is smooth because only displayed row are built. That's why a rich content must be embedded in a tree, and why I chose to enhance the TreeBodyFrame rather using richlistbox. I've talked a bit wih Neil Deakin who said he will work on a rich version of the tree immediately after the FF3 release. I think we should consider this. If such element is available before the TB3 release, my work could be deprecated.
