163.50 KB, image/png
102.47 KB, image/jpeg
192.76 KB, image/png
135.92 KB, image/png
60.24 KB, image/gif
41.42 KB, image/png
106.07 KB, patch
|Details | Diff | Splinter Review|
118.05 KB, image/png
32.72 KB, image/png
Users occasionally want to keep a particular message open while browsing their mail, open multiple messages simultaneously for quicker reading of messages over a slow network connection, or otherwise access multiple messages at the same time. Thunderbird currently supports this with its "open message in new window" feature, which displays one or more messages in separate windows. Firefox has shown that keeping a particular page open and browsing multiple web pages simultaneously is easier when the pages are loaded into tabs. The same is true for email messages, which would be easier and more convenient to switch between if they could be opened in tabs rather than individual windows. Thunderbird should let users display messages in tabs.
This patch implements tabbed message display in Thunderbird. It adds an option to the Preferences -> Advanced -> "Open new messages in" preference to open messages in "a new message tab." When so set, hitting return with messages selected in the thread pane opens those messages in tabs within the message pane. Users can also explicitly open messages in tabs by right-clicking them and selecting "Open Message in New Tab" from the context menu. When no tabs are open, Thunderbird behaves the same as it does today: you select a message in the thread pane, and the message gets displayed in the message pane. When some tabs are open, the first tab always displays the message currently selected in the thread pane, so you can continue to browse messages in the thread pane. Note that while this patch builds for me on Linux, on Mac OS X my build can't find the nsBrowserStatusFilter component, which tabbrowser depends on. I haven't tried building on Windows yet.
JFTR: the respective MailNews bug is bug 196760.
Got any screen shots?
Yes, here's a screenshot showing Thunderbird with three tabs open: * the first tab displays the message currently selected in the thread pane: firstname.lastname@example.org -> Inbox -> fontos Balaton * the second tab displays the bugmail for your comment requesting a screenshot: email@example.com -> Lists -> bugzillad -> [Bug 297379] ... * the third tab displays another message: firstname.lastname@example.org -> Inbox -> terrestrial extra-solar planet found? I used classic view, but it works the same in the other views. Although I can't show it in a screenshot, switching tabs updates the headers, the attachments list, and the junk/phishing/remote content notification bars to reflect the relevant meta-data for the message loaded into the selected tab in addition to displaying that message's content. Note also that tabs, like windows, can display messages from disparate folders; they aren't restricted to the folder currently selected in the folder pane.
That looks sweet -- nice work, Myk! Another thought I had for tab usage was to display attachments in separate tabs. Though if both these features were landed, that could lead to two unrelated rows of tabs, which people might (or might not?) find either confusing or baroque.
(In reply to comment #5) > That looks sweet -- nice work, Myk! Another thought I had for tab usage > was to display attachments in separate tabs. Indeed, the description and a comment on bug 223340 suggest solving that problem by putting attachments into tabs. Besides fixing that bug, I expect that attachments as tabs would also more clearly connect each piece of content in the content pane with the attachment from which it comes. At the moment, an attachment's content is distinguished from the main message's content only by a horizontal bar which provides no context (f.e. the name of the attachment). > Though if both these features were landed, that could lead to two unrelated > rows of tabs, which people might (or might not?) find either confusing > or baroque. Folks have previously proposed various other uses for tabs, f.e. bug 218999. We should certainly be judicious in their use so as not to promote confusion, but I can imagine Thunderbird accommodating multiple clearly-distinguished tab sets, although there would be issues to work out (like ctrl-pageup/down behavior), and these issues will become more pertinent as additional functionality like Lightning's calendaring makes it into Thunderbird's main interface. In any case, I think there's a good case to be made for messages as tabs. It's analogous to the move from windows to tabs in Firefox for the primary pieces of content the applications enable users to access (pages for Firefox, messages for Thunderbird). And it more elegantly solves the common problem of how to leave a message open for later reference while otherwise browsing your mail than the cumbersome current approach of opening a separate window for each such message.
This patch is made against the tip (the previous one was against the 1.1a1 release tag) and includes a fix for a regression in the previous patch in the code for accessing attachments.
Attachment #185910 - Attachment is obsolete: true
This patch fixes a bug in how the previous patches handled the user's "open new message in" preference for users who never set the preference. Also, the Mac OS X build problem went away after I upgraded my Mac tree to the tip today. I had previously been compiling against a 1.1a1-tagged tree, so perhaps something has been fixed between then and now, or maybe the 1.1a1 tag is missing some necessary file.
Attachment #186351 - Attachment is obsolete: true
Test builds for Mac and Linux are now available from the URL listed in the URL field of this bug report.
Scott, this patch implements tabbed message browsing in Thunderbird. It adds UI for opening messages in new tabs instead of new (or existing) message windows and modifies message display and command infrastructure to be tab-aware. Tabbed message browsing adds no fundamentally new functionality to Thunderbird. What it does do, however, is improve multiple message navigability in the same way that tabs improved multiple web page navigability in Firefox. Messages in tabs are simpler to switch between than messages in windows and make it easy to leave a set of messages perpetually open for later reference. Neil Rashbrook has pointed out that this feature may call for the creation of a thread pane specific command controller, but I thought I'd let you take a look at the current version and provide your input. See attachment 186166 [details] for a screenshot of tabs in action, and let me know if you have any questions about the functionality or suggestions for improving it.
*** Bug 318435 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > When some tabs are open, the first tab always displays the > message currently selected in the thread pane Wouldn't it be more intuitive if the selected message always appears in the *active* tab? I would hate having an important 1st (but inactive) tab being overwritten (with no "Back" button). I might be misunderstanding what you said, though. BTW: Great new feature! When do you anticipate landing it? :-)
I tested the test 1.5 build posted here: http://www.melez.com/mykzilla/2005/12/tabbed-message-browsing-in-thunderbird.html Bugs: 1) Reload Tab/Reload All Tabs causes the raw message text to be loaded, as opposed to the formatted message. Is reload even needed for mail messages? 2) Switching folders returns to first tab and overwrites message there with a blank pane. This does not seem intuitive. 3) With multiple tabs open, and focus on any tab except the first, selecting another message in the list opens it in the first tab and focuses it. Is this intentional? Again, it does not seem intuitive. 4) New Tab does not work. Other: 1) I've got an extension that grabs the email address of a message via the message 'onselect' event. This does not fire when tabs are switched, thus the UI does not get updated.
If I wanted the mailboxes themselves to be tabs rather than only messages (like Eudora), should I open another bug? Besides wanting to switch mailboxes with tabs (why only messages?), this would also move tabs to the top of the window, a more logical place than the middle of the window, particularly considering that the tabs are independent of the mailbox currently opened. This would also allow for all views (mailbox, message, new message, etc) to be handled by tabs and remove the need for new windows (see dependent bugs).
Tabs in thunderbird is a great idea... would it be a better idea to have the tab strip along the top of the window (below the toolbar or menubar) so that individual folders could be loaded in tabs too, as well as messages? Would make it fast to switch between my favorite folders, which I can do pretty easily with Gmail in the browser.
Patch works well. I noticed one thing though: the tabs are lost when switching from Vertical layout to Wide layout (doesn't seem to happen when switching between layouts in any other sequence).
(In reply to comment #16) > Tabs in thunderbird is a great idea... would it be a better idea to have the > tab strip along the top of the window (below the toolbar or menubar) so that > individual folders could be loaded in tabs too, as well as messages? Loading folders in tabs is a great idea. For users who regularly access just a small subset of their folders, navigating between them as tabs would be easier than browsing the complete list. My only question is whether it's better to have a single tab group for both folders and messages or separate groups for each. A single tab group is less complex, and it sidesteps the issue of which tab loads the message currently selected in the thread pane (the current patch always loads the selected message into the first tab; some testers have suggested loading it in the current tab instead). But I suspect that users navigate between folders and navigation between messages are relatively distinct activities, and mixing their tabs makes each kind of navigation harder, because users have to browse between all tabs when they only care about a subset.
A single tabgroup is what Eudora does. I would say implement that first, then go for the second idea and make an option.
(In reply to comment #19) > A single tabgroup is what Eudora does. And the same is true with Lotus Notes. No windows there. Everything is in tabs, including mail composition screens. Unlike the rest of Notes' interface, the tab implementation is a joy to use. Prog.
i agree with ben's previous post about tabs at the top of the window. i have the preview panel disabled, and that makes tabs unusable. having them at the top would really help out. plus the whole folder thing.
this is also no close tab button like in firefox. hopefully that will be fixed too.
Myk - fair point. Lots of room to investigate in this space. I'm going to try out your patch. There is a definite advantage to having a bunch of folders loaded at startup and being able to switch between them without the load time of a traditional folder, losing selection state between switches etc (although one might argue that that should just be better performance for the switching action, better selection saving, etc).
> But I suspect that users navigate between folders and navigation between > messages are relatively distinct activities, and mixing their tabs makes each > kind of navigation harder, because users have to browse between all tabs when > they only care about a subset. > Using the 'favicon' on each tab to distinguish between emails, replies, folders etc with their standard icons would solve this to a certain extent, while keeping things simple enough for anyone to understand. To be honest I think it could be taken further, with the 'Mail Start Page', address book and in the case of lightning, calendar opening in tabs as well, each with their associated icons. This would allow the user to immediately identify the subset they are looking for, even though they may be mixed among other tabs. The other option would be to automatically reorder the tabs along the single tab bar in groups, so keep Folders together, then emails, then replies etc
I just played with one of the test builds and I must say I'm absolutely delighted with it. Tabbed UI is an excellent addition to Thunderbird, and at this early stage there's only one bug that I really find annoying: When a tab has focus, pressing Delete deletes the displayed message as expected, but it doesn’t close the tab. This makes it difficult to go over a large number of messages (e.g. bugmail) opened in tabs, as deleting them doesn’t get rid of their tabs, nor switches focus to the next tab. When deleting a tabbed message, I’d like to see the tab closed and next tab get the focus (rather than the first one as it is in this build). The easiest to understand and most consistent solution would probably be to employ the same close-tab logic used in the browser. In other words, TB should switch to the next tab (the one on the right) unless the last tab (rightmost one) is reached. In this case, the program should close the existing tab, but keep focus on "new" last tab (the one just previously displayed to the left). BiDi side note: In right-to-left localizations such as Hebrew and Arabic, both "right" and "rightmost" above would actually be "left" and "leftmost". In addition to this issue, there’s a spatial-UI nit I think is worth mentioning: Attempting to open a message that's already open in a tab, opens a duplicate tab. I think a more logical behavior would be to switch focus to the one already open. Thanks for working on this Myk, I can’t wait to see this land. Prog.
The above is how Lotus Notes works. If you delete a message (or a calendar entry, or send the message you are composing) that tab closes, and the last used tab (different from firefox, but not necessarily better) is focused. However, while Notes does have 1 set of tabs at the top of the screen, if you are opening several folders in the mail portion, they are NOT opened in seperate tabs. They are handled the same way thunderbird does now, with a panel down the left. Personally, i'd like to see a single tab bar along the top to handle both of the various views... folders and messages. Favicon usage would also be helpful (necessary) to identify types of tabs. I love it so far. keep up the good work.
(In reply to comment #18) > But I suspect that users navigate between folders and navigation between > messages are relatively distinct activities, and mixing their tabs makes each > kind of navigation harder, because users have to browse between all tabs when > they only care about a subset. Myk, I would argue that one may well want to look at two messages in two different folders side by side. I myself do that sometimes.
> Myk, I would argue that one may well want to look at two messages in two > different folders side by side. I myself do that sometimes. Sure. As far as I can tell, though, both implementations would allow that. My current implementation certainly does, and it sounds like Ben's suggestion would allow it, too. The trick is to figure out what design is the most usable for the majority of our users (as well as which small set of variations can accommodate the special needs of most of the rest). There are a number of possibilities to explore, and we would be better off if we had working prototypes of the major versions to compare and test. Perhaps there are some code modifications that would make building such prototypes easier. I'll take a look.
(In reply to comment #0) > Users occasionally want to keep a particular message open while browsing their > mail, open multiple messages simultaneously for quicker reading of messages over > a slow network connection, or otherwise access multiple messages at the same > time. Thunderbird currently supports this with its "open message in new window" > feature, which displays one or more messages in separate windows. > > Firefox has shown that keeping a particular page open and browsing multiple web > pages simultaneously is easier when the pages are loaded into tabs. The same is > true for email messages, which would be easier and more convenient to switch > between if they could be opened in tabs rather than individual windows. > > Thunderbird should let users display messages in tabs. Feature request: Also Thunderbird should let users edit messages in tabs, like in Lotus Notes. Also Thunderbird should let users to change tab positions: for entire window like in Firefox or in message frame.
Hi Myk, that's really great work, VERY useful! An idea for another usability option: "Open thread in tabs" could open each message of the same thread (of a newsgroup or mail folder) in tabbed order. It would only be tricky if the thread is very long, there should be some limit for the maximum number of tabs which are opened automagically... For example, if the rest of the thread is too long, it could be shown with "+" sign which instead opens a pulldown menu. But that's just a "proposed idea", I don't know if it works.
It seems that accented characters on the subject dos not display correctly on the tab. They appear as if the encoding is wrong. Apart from that, I'd like some control like "middle-click" to open message in new tab.
Hi Myk, Just downloaded the 1.5 version (I love it). But I strongly agree with https://bugzilla.mozilla.org/show_bug.cgi?id=297379#c25 - when we press 'delete', the tab should be closed, not left empty. I personally prefer the current 'top of preview panel' implementation to the idea of putting the tab bar at the top of the window. The big advantage of tabs as you said in comment 10, is improved multiple message navigability. If I have to shove the mouse all the way back to the TB Window top in order to switch tabs or close tabs, that's (IMHO) 80% of the advantage lost. My habit has become (1) select all my new messages; (2) whack <Enter> to get 'em into tabs; (3) read 'em in order and close their tabs using the little TV-screen shaped icon on the right of the tab bar. BTW, I'd definitely go with the traditional "red X" tab closing icon. I wasn't sure if the "TV" was going to do what I wanted, the only hint was the placement.
(In reply to comment #31) > Apart from that, I'd like some control like "middle-click" to open message in > new tab. I strongly agree, for two reasons: First, it's the traditional method which Mozilla/Seamonkey and FF users expect. But also (more important), it allows the TB user to manage the tabs entirely via mouse... without having to go to the keyboard. Switching your hand from the mouse to whack the 'Enter' key after you've selected your messages doesn't sound like a big thing to us... be we *like* vi. (Yeah, I know that some of us say they like emacs... thogh I can't imagine why.) But please take a moment to actually try it a few times and observe how you feel. You'll see that it's actually very tiring to leave the mouse, perch your hand over the keyboard, then go back to the mouse and settle in. People re-adjust their hand on the mouse after first landing on it, and during this readjustment, they're feeling UNCOMFORTABLE. And again, you're the people who love using 3-key shortcuts. Multiply your discomfort by a suitable factor for "grandma user", and I think you'll agree with Marc and I, middle-click would be a VERY good thing.
the screenshot doesnt show any tv icon, nor did i see one when testing. what platform are testing on? im using windows nt 5.1
> It seems that accented characters on the subject dos not display > correctly on the tab. They appear as if the encoding is wrong. I see this also in message body on new tabs with Japanese. View -> Character Encoding shows correct encoding, but display is wrong. screenshot: http://level.s69.xrea.com/mozilla/image2/20051209_tbtab4.png In this case, two tabs show same message.
(In reply to comment #34) > the screenshot doesnt show any tv icon, nor did i see one when testing. what > platform are testing on? im using windows nt 5.1 > I'm using the 1.5 patch on Linux (Mandrake 2006). Also, I only see the empty little "TV-shaped box" when I mouse over it's location. Unless I'm right there, nothing is shown.
>> It seems that accented characters on the subject dos not display >> correctly on the tab. They appear as if the encoding is wrong. > I see this also in message body on new tabs with Japanese. This was solved by selecting View->Character Encoding->Auto-Detect->Japanese.
(In reply to comment #36) > (In reply to comment #34) > I'm using the 1.5 patch on Linux (Mandrake 2006). Also, I only see the empty > little "TV-shaped box" when I mouse over it's location. Unless I'm right there, > nothing is shown. I upgraded to Myk's trunk version (gecko rv:1.9a1), no change: icon still appears as a gray "TV-shaped box" when I mouse over it (otherwise totally invisible). I've not applied any theme, but I do have lots of extensions.
The more I think about it, the more I think Ben's idea of a single tab group across the top has merit. But it's hard to know what works best (or which variations work best, if tabs work well in several configurations, just as the three-pane interface has three distinct layouts) without prototypes to compare. If the message pane, thread pane, and compose message windows could be encapsulated as XUL pages that could be placed in arbitrary tabs within the three-pane interface, then we could create several prototypes with tabs in different places (or a single, reconfigurable prototype) and get user testing and feedback on which implementations work best. This seems like the right approach. Thoughts?
i completely agree. another idea, since youre already cranking out prototypes, why not implement them all and allow the user to decide. similar to the 3 different layouts you can select. maybe 2 or 3 different tab positions. that is if its not too much work for the selector and having multiple implementations doesnt add too much to the download size.
Myk, any chance you could set up Lotus Notes and Eudora and try them out? It might save you some time deciding which feature / interface layout is worth your time and which one is better skipped. Note that although Notes is primarily a Domino-server client, it also supports IMAP, so you don't really need a Domino backend to evaluate its tab implementation. Prog.
(In reply to comment #41) Myk, this is how it look in Lotus Notes. http://www.egmar.ro/lotus-mail.PNG
(In reply to comment #42) Whatever you do, *please* don't put any buttons below the tabs. I must use Notes at work, and this is very disorienting/ugly. Ideally, the current buttons could "adjust" to whatever content is being displayed in the active tab (kind of how the awesome WordPerfect does it with the "Property Bar"). So if a Calendar tab is active, its buttons are show across the *top*.
Ack! I have to disagree. Having a single toolbar which changes its function is a huge usability no-no. It makes it impossible for a beginning user to know what button does what, and when a certain button will show up. The problem with notes isn't actually those buttons. It is the fact that Notes wasn't really intended as a mail-reader. Or in fact intended for anything it does really. :-P In that second screenshot, you see (one of) the user's mailboxes. notice how (within the tab) the design is much like thunderbird's design. Folders down the left, messages down the right. When a message is opened, you get what the first screenshot shows. A message is opened in a full screen tab. The problem here is not the buttons or the tabs. (Frankly, they belong where they are) The problem is that the buttons dont pertain to the content of the tab. They instead pertain to some sort of "amorphous task". If you are going to have a mail reader, then the mail-reader buttons should stay above--at the mailreader level. The message specific buttons should follow the tabs. I'd claim that the real problem is that the buttons are within the message listing frame. "New Memo" ? That is clearly a Mail specific action and should be at the top (Still within the "mailbox" tab in notes, not necessarily in TB). "Reply"? well that can pertain to multiple messages and should be at the top too. So on and so forth. The actual toolbars in Notes are reserved for tasks that pertain to *its* hierarchical top-level: working with "Databases". Obviously this should be done pragmatically. Moving buttons all over the place would be worse than anything, but keeping relevant tasks close to the components to which they relate is an important tenet of Fitz Laws, so please don't make some shape-shifting toolbar. Instead,, just do the tabs and buttons right (or even easier, don't get bogged down by resistance to change like the Notes developers)
Changing buttons in the toolbar is atleast bad for two reasons: (1) The reason Comment #44 pointed out and (2) people with accessibility. The reason the Human Interface Guide makes such a huge warning for using changing button actions and changing layout is due to screen readers, that people with accessibility use. I am not sure if buttons inside tabs is accessibility friendly. An answer to this question could the HIG people likely responce to quickly. Here is another idea. What if all buttons were present at all time, and those that can't be used in the current UI state are shaded? E.g. Main toolbar: [Write] [Reply][Reply All][Forward] [Delete][Junk] [Stop] Second toolbar: [Send] [Attacht] [Spell] [Save]
Could you post the patches for the 1.5 build? Or email them to me?
> Could you post the patches for the 1.5 build? Or email them to me? Sure, here it is.
(In reply to comment #47) > Created an attachment (id=206020)  > patch v5 for the 1.5 branch > > > Could you post the patches for the 1.5 build? Or email them to me? > > Sure, here it is. That worked very nicely. I had to make a small change to threadPane.js to work on the current Branch. This is a very nice feature.
I`ve corrected the patch in threadPane.js.
Here's how imagined tabbed email when I was using kmail 2 years ago: http://bugs.kde.org/show_bug.cgi?id=86327 Since then I've switched to thunderbird. I still think that having a single set of high level tabs is a good idea. Each tab should contain a particular activity: folder list, message, compose, address book, etc. Within a tab, the view can be switched between list / list + preview / message mode. The folder list on the left hand side should toggle like the bookmarks sidebar in firefox. I agree with others here who say the tabs should be top level, not just within the preview pane. Having tabs might also make it easier and more natural to repeatedly cut and paste messages between folders. E.g. 1. Select some messages. 2. Cut. 3. Switch to the destination folder (either a new tab or Ctrl-PgDn to one you already had open). 4. Paste. Another related suggestion I made was to have a location bar in thunderbird. This would have the same Ctrl-L shortcut as in firefox. You could then jump to a particular folder by typing in the location bar with autocomplete. This would be useful for people who have lots of folders on several accounts. Ideally it would be implemented alongside something like the Quick File extension, which makes moving messages between folders easy and fast with the keyboard. Maybe words typed into the location bar could be used in a kind of I'm Feeling Lucky mode, to try and guess the best mailbox or view to open. E.g. if my personal mail username is maffew and I want to open my email folder about bikes, I could type "maffew bikes" and it would open the folder. The existing Ctrl-K search box should stay alongside the location bar. The Ctrl-K box is more for searching within a folder, whereas the location bar would be for navigating between accounts and folders. I'm not sure a location bar would be as helpful in thunderbird as it is in firefox, because ultimately the locations are much more constrained in thunderbird than in firefox. But it's interesting to think about.
A screenshot of Sylpheed http://sylpheed.good-day.net/ja/ which have tabs above the message plane. I would assume that the tabs reads "Message", "Full Header", and "Attachments".
I'm being assigned away from Thunderbird work at the end of January, which unfortunately doesn't give me enough time to do the next phase of this work, so I'm unassigning the bug from myself to properly reflect its state. This is on the list of Thunderbird 2.0 feature ideas, though, so hopefully mscott or another Thunderbird hacker will pick it up and make it happen for 2.0.
Assignee: myk → nobody
At this mock up ( which comes from Bug #306125 ) do I propose that the notebook widget is used rather than tabs. The mock up shows Header, Message, and Attachment notebooks, and several other could be considered. E.g. GPG. Tabs could then be placed under the toolbar like suggested in Bug #218999 Having the attachments in their own notebook ought to solve Bug #223340
Any chance for an update for Release 1.5? I had four patch failures when I tried to apply the most recent set.
Has anyone tried the New Yahoo Mail Beta ? It's a interesting layout. I'm just laying it out there.
A comment like that is useless. Attach a screenshot.
You can view a tiny "demo" in flash which describes the different objects. http://overview.mail.yahoo.com/us/
What's under the "Others" tab?
That's a good point. I don't know. I got it from http://claws.sylpheed.org/screenshots.php
tabbed display is not very bright as it: * is implemented in the application * prevents intelligent window managing like beryl / mac os it should be removed from the code.
@soloturn give me functionality before eye candy any day of the week
A user of one of the "Thunderbird 1.5 with tabs" builds I made with this patch a couple years ago recently asked me if it would be possible to update the patch for Thunderbird 2.0. After some wrangling, I got the patch to apply and behave itself in my testing, and I spun some builds for Linux, Mac, and Windows: http://www.melez.com/tabmail/thunderbird-18.104.22.168.en-US.linux-i686.tar.gz http://www.melez.com/tabmail/thunderbird-22.214.171.124.en-US.mac.dmg http://www.melez.com/tabmail/thunderbird-126.96.36.199.en-US.win32.installer.exe Note that the Thunderbird developers are implementing a different version of tabs for Thunderbird 3 over in bug 218999, so there's no point in updating this patch for the trunk, and I'm going to close this bug.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Works great. Thanks!! Patrick
Here's the patch updated to the 188.8.131.52 release tag. I've also built versions of the application with this patch and uploaded them to my website: http://www.melez.com/tabmail/thunderbird-184.108.40.206.en-US.linux-i686.tar.gz http://www.melez.com/tabmail/thunderbird-220.127.116.11.en-US.mac.dmg http://www.melez.com/tabmail/thunderbird-18.104.22.168.en-US.win32.installer.exe Note that the Mac version no longer works on Mac OS X 10.2, since my build machine has been upgraded to 10.5, and I no longer have the 10.2.8 SDK installed. It should work on 10.3.9+, 10.4, and 10.5, however (although support for 10.5 may be incomplete). For my future reference, here's the command I used to generate the patch: cvs diff -pu mail/components/preferences/advanced.xul mailnews/mailnews.js mailnews/extensions/bayesian-spam-filter/src/nsBayesianFilter.cpp mailnews/mime/emitters/src/nsMimeHtmlEmitter.cpp mailnews/mime/public/nsIMimeMiscStatus.idl xpfe/components/build2/Makefile.in xpfe/components/build2/nsModule.cpp mail/base/content/commandglue.js mail/base/content/mail3PaneWindowCommands.js mail/base/content/mailCommands.js mail/base/content/mailContextMenus.js mail/base/content/mailWindow.js mail/base/content/mailWindowOverlay.js mail/base/content/mailWindowOverlay.xul mail/base/content/messageWindow.js mail/base/content/messenger.xul mail/base/content/msgHdrViewOverlay.js mail/base/content/msgMail3PaneWindow.js mail/base/content/utilityOverlay.xul mail/locales/en-US/chrome/messenger/messenger.dtd mail/locales/en-US/chrome/messenger/preferences/advanced.dtd mailnews/base/public/nsIMessenger.idl mailnews/base/public/nsIMsgDBView.idl mailnews/base/resources/content/mailWindow.js mailnews/base/resources/content/threadPane.js mailnews/base/src/nsMessenger.cpp mailnews/base/src/nsMsgContentPolicy.cpp mailnews/base/src/nsMsgDBView.cpp mailnews/base/src/nsMsgGroupView.cpp toolkit/content/widgets/browser.xml toolkit/content/widgets/tabbrowser.xml > ~/297379v7.diff
Attachment #281628 - Attachment is obsolete: true
It looks and feels just like tabs in Firefox =) Would it be possible to have "Write" to open in a tab as well?
(In reply to comment #66) > It looks and feels just like tabs in Firefox =) > > Would it be possible to have "Write" to open in a tab as well? Unfortunately that's hard to add to this patch, but I believe the implementation of tabs on the trunk may do it.
> Unfortunately that's hard to add to this patch, but I believe the > implementation of tabs on the trunk may do it. Sounds very cool! =) I have submitted bug #404045 "inline editor (Single Window Mode)" which a screenshot/mock up. I think mail tabs would come to its full potential, if the user could write an email in one tab, and browse emails in others. Btw. This bug status is RESOLVED (WONTFIX). Is that correct?
(In reply to comment #68) > I have submitted bug #404045 "inline editor (Single Window Mode)" which a > screenshot/mock up. That looks great, you should post about it in the Communications forums: https://labs.mozilla.com/forum/index.php#3 > I think mail tabs would come to its full potential, if the user could write an > email in one tab, and browse emails in others. I agree. > Btw. This bug status is RESOLVED (WONTFIX). Is that correct? Yes, that's correct, as there is a different implementation of tabs on the trunk.
Thanks for the forum link. I have now added a thread, so hopefully something could be worked out. https://labs.mozilla.com/forum/index.php/topic,309.0.html
Myk can you tell me what relationship this thread has to Penelope, if any? With all the upheaval around MailCo, David Asher seems to think Penelope is not a Mozilla project at all, despite it using the Mozilla wiki, bugzilla etc. I believe Eudora's combination of 'Session Restore' (as Mozillians call it when your application opens how you left it) and everything opens in a tab is brilliant. This is a very mature user experience as Eudora implemented it several years ago. I don't understand what is on the trunk for Fx3, what is due in Penelope, etc. All I want is a version of Eudora 7 that is an ongoing product. Is this unreasonable? I don't need a stupid virus-infecting 'preview pane'. I disable this immediately upon installing Eudora. I don't need rich text email, this is also asking for virus and spam and hence I disable this too. But most importantly I want my sub-windows for emails and mailboxes to open in tabs, essentially like the already do in Eudora (except the tabs are styled like buttons and the 'tab bar' is at the bottom of the main window).
(In reply to comment #71) > Myk can you tell me what relationship this thread has to Penelope, if any? Sorry, but I'm not very familiar with Penelope, so I'm not the right person to answer this question. > I believe Eudora's combination of 'Session Restore' (as Mozillians call it > when your application opens how you left it) and everything opens in a tab > is brilliant. This is a very mature user experience as Eudora implemented it > several years ago. I agree, this seems like great functionality to have in an email client, just as it's very useful in a browser. > I don't understand what is on the trunk for Fx3, what is due in Penelope, etc. The functionality on the trunk is the implementation of tabs being worked on in bug 218999. I don't know what's due in Penelope.
(In reply to comment #72) > > I don't understand what is on the trunk for Fx3, what is due in Penelope, etc. > > The functionality on the trunk is the implementation of tabs being worked on in > bug 218999. I don't know what's due in Penelope. Oh, I think it will be bug 375993.
Thanks Myk bug 218999 seems to have a few screenshots including one of email *and* mailboxes opening in tabs. Cool. Re Penelope, seems that maybe it is a Qualcomm-only project and therefore essentially a fork of Thunderbird. This is very disappointing since it is such a waste to not pool the resources of Mozilla and Qualcomm to produce better results. I think it's rather bizarre what has happened with Penelope. Initially it was all hype from Mozilla, then nothing. Perhaps I misread the original PR. Hmmmm Here is a Penelope bug I posted https://bugzilla.mozilla.org/show_bug.cgi?id=375993 that relates to this bug, for anyone interested.
myk, thanks for the new build! in case you're tweaking this still.. i've noticed that if nothing is ever opened in a tab, the window title follows Tb behavior, but upon opening the first tab, subsequently the title is changed as per Fx style. could you make a pref? the title overwrites the Nightly Tester Tools title customization also.. second, i've implemented a dnd of a threadpane item into a tab for myself - any way to make the threadpane selection happen onlick instead of onmousedown? lastly - tabbed message pane is the only way to go. imo.
I know this is a little late - but heres how Eudora does its "Tabs"
You need to log in before you can comment on or make changes to this bug.