56.90 KB, image/png
63.90 KB, image/png
117.06 KB, image/png
37.08 KB, image/png
1.47 KB, text/plain
71.17 KB, image/png
18.62 KB, patch
|Details | Diff | Splinter Review|
34.70 KB, text/html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199) Gecko/2008070208 Firefox/3.0.1 Build Identifier: version 3.0a2pre (2008070903) With Thunderbird having a tab interface, it now makes sense to have the compose window default to opening in a new tab versus in a new window. This should probably be a default option but then also have a separate keyboard shortcut; maybe CTRL+N could be used for new window like it is now and CTRL+SHIFT+N could be used for opening in a new tab. I really think the default should be changed to open in a new tab, but people don't really like change, so maybe give them the option now and change it in the future? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Right on! Though since I'm pretty sure that down the road we're going to work on an inline reply / compose I wonder if it's going to be worth fitting the current compose window into a tab. It might make sense to leave the current compose window as is and then push forward on the new inline compose / reply as a separate piece that lives in tabs. Good points about the default changing, maybe with a new inline compose people won't mind the change.
Not just the one compose window either. I might be composing several mails at once. Each should have its own tab a la Eudora.
(In reply to comment #2) Me too!!
I'd thought the whole point of Mozilla taking over the Eudora project was to keep the Eudora program current for users that have used the program for years. I'm not sure I understand the whole debate on rather we should have tabs or not. Eudora is Eudora. Why are we trying to re invent the wheel? What I've seen so far is nothing like Eudora! Please, let's stick with the style that has made Eudora the great program it always been and bring it up to date.
(In reply to comment #4) > I'd thought the whole point of Mozilla taking over the Eudora project was to > keep the Eudora program current for users that have used the program for years. > I'm not sure I understand the whole debate on rather we should have tabs or > not. Eudora is Eudora. Why are we trying to re invent the wheel? What I've > seen so far is nothing like Eudora! Please, let's stick with the style that > made Eudora the great program it always been and bring it up to date. Eudora made a decision to switch from closed source code to Open Source and chose to adopt the Mozilla Mail/News code base as the starting point for the next generation of Eudora.
Personally I think we should use the tab feature as much as possible. Creating new message, replies, adressboek all stuff that is opening a new window in 2.0 should be opening a tab in 3.0?
(In reply to comment #7) I second that, we should use the tabs as much as possible. I think a set of choices in the "Reading & Display" tab under the Advanced Options should be available to users so that they may choose whether to open new messages (and/or replies, and forwards) in tabs or new windows. This goes for the Address Book and Lightning dialogs for new Events and Tasks.
I don't think the question here is whether we should be using tabs, that seems to be easily agreeable. :) I think the question that needs some real thought and work are these: What do we do with the menu items from the compose menu inside a tab? * We don't want to fill the compose menu items into the current main menu as it will just make the current menu system overwhelming with a number of options that only work when in the compose tab. What do we do with the toolbar in the same respect? * A toolbar inside the tab item is an easy solution, but looks bad and cuts down on usable space.
(In reply to comment #9) >What do we do with the menu items from the compose menu inside a tab? Remove main menu, eventually the compose menu inside a tab, too. I'd inspire by Opera's M2 mail client.
blocking‑thunderbird3-; not a bl ocker, and getting the full blown editor in a tab will likely be quite tricky... if it's ever done
Well, the behaviour of the tabs appears to be screwed. The following items show completely different behaviour from how Win-Eudora-7 acts: 1) When you open a message in a tab, it uses the whole width of the window, including the space where the mailbox/folder pane is. That's really ****. I want the mailbox/folder pane to always be visible unless I explicitly turn it off. In Eudora-7, since the mailboxes are visible, as I recall I can then drag the mail item to a different mailbox. 2) Also ****, is that if a tab is for a mailbox, you can change which mailbox the tab is for. If I single-click on a mailbox in the mailbox/folder pane, it switches that tab to another mailbox. If I double-click it, that mailbox opens in another tab. Both these actions should open a new tab (only if necessary) and switch to it. 3) I can double-click a mailbox as often as I want and I get a succession of new tabs, all for the same mailbox. Dopey or what. Bizarre.
In regards to Bryans comment, it's simple, follow the format of Eudora. That program works very well, and until development was suspended, it was among the top email programs out there. It still would be if it could do HTML email. Basically, if it works, don't fix it.
I just want to add my $.02... I also think that the tabbed message windows feature is not entirely thought through. Make the whole main area tabbed is fine for opening up different components of the application in separate tabs (e-mail, calendars, address book, et cetera). However, when browsing and composing e-mail messages, I think the best solution for using tabs is making the message pane tabbed. Maybe as its own tab list, entirely separated from the "application component tabs"? This way you could open up a few messages in the background for reading later, and also starting a new message or a reply without having tons of application windows open, and always having access to the mailbox tree view. Also, I think it should be possible to force a message window to be open in a new tab by using an alternative click method; 1) MOUSE3: Open message in new tab (foreground) 2) CTRL+MOUSE3: Open message in new tab (background) Regards, kchr
If some people use Microsoft Office 2007, you will see that the buttons in the toolbars are actually IN a tab. So the idea would be to have the toolbar, INSIDE tabs so when you change mode (from main message vew mode to mail creation mode), the toolbar's tab would be enabled or not. To conclude, there would then be 2 tab bars, one for the toolbars and one, like it is already shown in the current version. This would take up the same amount of space for which ever mode thunderbird is currently in!
While I certainly don't mind if we can choose whether to compose mail in a tab or in a separate window, I personally hope that we're not forced to only compose in a tab. The nice thing about using separate windows is that I can quickly see if I have unfinished drafts by looking at the Windows TaskBar. If the drafts are only in TB's TabBar then it would be too easy to forget about them IMO. At the least, I hope that when I close TB that it will prompt for unsaved drafts in tabs like it currently does for those in separate composition windows.
I would really like having all the features tabbed (opening, reading, composing, address book). Now it's halfway through and really uncomfortable to use. It would be better if we are able to operate all in tabs.
Since Eudora stopped supporting their product back in 2006, I recently moved over to TB. Eudora managed to do everything in the same window, which I liked very much, but tabs would be even spiffier! :) FWIW, I know 2 other Eudora users who are sticking to the old program because they hate the idea of being forced to use multiple windows for one E-mail program. - Bill
Thank you for you comments. We realise this is a much wanted option. We're not doing this at this time as it would significantly delay Thunderbird 3. Please don't comment just saying you would like us to do it. If you want to help us with the implementation then please do comment or let us know - that would be useful.
I agree with Clothears on 1) and I would like to add a suggestion: When you reply to a message, it would be helpful to replace the message content by the compose window (whatever the layout: tab or "thunderbird 2.x mode"). It would avoid opening a new window/tab and closing it when the reply is sent.
Created attachment 415164 [details] Screenshot: UI proposal for tabbed composition (In reply to comment #9) > I think the question that needs some real thought and work are these: > What do we do with the menu items from the compose menu inside a tab? > What do we do with the toolbar in the same respect? Easy! With respect to the UI, don't mix them, just swap. Actually, don't change anything about the current UI set of commands available when composing, apart from adding the search box. In a compose tab, show compose menus and compose toolbar /instead/ of main menus and main toolbar. (Mixing wouldn't work both ways: can't use most main commands in compose, can't use most compose commands in main window). Technical implementation is another question, this is about the UI only. Bryan, what do you think of the proposed UI (see screenshot)?
Comment on attachment 415164 [details] Screenshot: UI proposal for tabbed composition nice work on the mockup! But I don't want to swap out the buttons as it creates a lot of flicker in the toolbar as you're switching through tabs and means we have to make sure that other buttons that might be useful in a global context are not gone (like get mail or compose or Address Book) Maybe start by placing those toolbar items inside the tab itself. We lose a little vertical space but gain some consistency.
I did not know there was a flicker problem. Is there a bug related to this ? I like Thomas' idea about swaping the buttons. It is like new Microsoft Office 2007 GUI (OpenOffice.org prototypes implements the same concept): buttons change with tabs. I don't think there are useful buttons we would like to keep in a global context. In my profile, these are (maybe these are not the default settings): * Get Mail: useless when composing an email * Write: same * Address book: probably should be replaced by "Contacts" ?
(In reply to comment #27) > I did not know there was a flicker problem. Is there a bug related to this ? The flicker problem is when all the buttons clear out. This is just a general UI issue. If a person goes from one tab to the next and each tab can change the toolbar then the toolbar flashes buttons as you select new tabs. > I like Thomas' idea about swaping the buttons. It is like new Microsoft Office > 2007 GUI (OpenOffice.org prototypes implements the same concept): buttons > change with tabs. It's a good idea but I think the toolbar swapping has some problems that would need to be addressed or avoided. If I understand correctly you're talking about the ribbon bar? With the ribbon bar you always have a way to change the tab context using the "upper tabs" of home, insert, etc. Such that buttons aren't completely lost. > I don't think there are useful buttons we would like to keep > in a global context. In my profile, these are (maybe these are not the default > settings): > > * Get Mail: useless when composing an email > * Write: same > * Address book: probably should be replaced by "Contacts" ? Removing these buttons presents a bit of a usability issue. We'll essentially create an extra task people have to perform in order to use those actions which I think we consider "global". Here are some example use cases. You're writing an email in a tab and while writing realize you need to send another email to someone else. You look for where the "Write" button normally is but it doesn't exist there anymore. (to complete the task you have to change tabs and then click write) You're writing an email and your plane announces it is boarding now. You want to make sure you've grabbed any last emails before you leave. You look for the Get Mail button however it's not there while you're writing an email. People might start to learn that certain toolbar buttons are only present when looking at certain tabs. However unlike the ribbon bar where this is a "soft mode" - meaning even when the toolbar changes you can change it back without changing what you're doing. We would be created a "strict mode" where you would have to alter your behaviour to get the buttons back. Other solutions are possible, like having a ribbon bar like system but that is pretty complex in design and programming for what I feel like is somewhat little gain.
Created attachment 415619 [details] Screenshot 2: tabbed composition with 2 toolbars (main & composition) (In reply to comment #26) > (From update of attachment 415164 [details]) > Maybe start by placing those toolbar items inside the tab itself. We lose a > little vertical space but gain some consistency. Let's try that idea... -> see attached screenshot #2 with 2 toolbars: - main/global toolbar and - composition toolbar inside the tab. To be honest: That's not it. But let's look at that in more detail (as I've learned from Bryan we always need to balance everything, like cost and benefit...) Costs: - We are loosing *a lot* of valuable v-space (that's *in addition* to our traditional composition header, which takes a lot of space already and we already have bugs filed against that). - The UI looks bloated and cluttered (again, *in addition* to all the existing complexity of the traditional header) - We are confusing normal users *a lot* as to what the *relevant* functions in this composition context are - The global functionality we add (get mail, write) will be irrelevant for most users in this context, and we're not helping advanced users a lot (as I will show below) Benefits? (In reply to Bryan's comment #28) IMO the use cases cited are not very convincing. I think they are too power-userish, and they wouldn't outweigh the costs, at all. But maybe we can find another solution which is better than Screenshot 1 and Screenshot 2 (see compromise proposal below). > You're writing an email in a tab and while writing realize you need to send > another email to someone else. - Ctrl+N takes you right there; I'd think that users who actually write multiple emails simultaneously are probably advanced enough to know the shortcut (it's also available from File Menu with 2 clicks) - the Write button might be confusing for some users when they are already writing - Consider implementing a [+] tab like in FF (after the rightmost tab) to write a new message (perhaps the button could have dropdown [ + |v] so that you can also open a new tab for a search, folders, addressbook etc.) > You're writing an email and your plane announces it is boarding now. You want > to make sure you've grabbed any last emails before you leave. - that's pretty power-userish, IMO... ;) - Ctrl+[Shift]+T (or Ctrl+D, after we've fixed that) - set automatical downloads to every 5 mins if you need them so urgently - in most cases, you'll want to view your msgs after downloading; so you'll open an inbox tab anyway! iow, for most people it won't be intuitive to download msgs while composing without even leaving the compose window > People might start to learn that certain toolbar buttons are only present when > looking at certain tabs. Actually, we have all learned for the past 5 yrs of using Thunderbird 2, where composition was composition and inbox was inbox. By putting composition in a tab, we're already making access to those unrelated actions *a lot* easier than it was before. > However unlike the ribbon bar where this is a "soft > mode" - meaning even when the toolbar changes you can change it back without > changing what you're doing. We would be created a "strict mode" where you > would have to alter your behaviour to get the buttons back. Actually, the use pattern of 'single toolbar' UI proposal (Screenshot 1, attachment 415164 [details]) is only marginally different from a full-fledged ribbon bar. Compare: a) Ribbon bar: 3 clicks (click "home" ribbon tab, click "write" (-> new tab foregrounded), click to return to your original composition tab) b) Composition toolbar only (Screenshot 1): 3 clicks (click "Inbox/Folder" tab, click "write" (-> new tab foregroudned), click to return to your original composition tab c) Global toolbar AND composition toolbar (Screenshot 2): 2 clicks (click "write" (-> new tab foregroudned), click to return to your original composition tab). So we're saving 1 click (at a very high cost both space and usability, as shown above). > Removing these [considered 'global'] buttons presents a bit of a usability > issue. Actually, we are also creating a big usability issue by showing too many toolbars and buttons, many of which will be irrelevant in composition context for normal users (see above). Hey Bryan, what happened to your legendary drive to protect the average user? ;) The Way Out (Compromise): UI Proposal #3: Single compose toolbar with customization - with a lot of good will, let's assume there are some users who want their "Write" and "Get mail" buttons always available. - so it's different users, different needs -> Customization will solve the problem: - have a single compose toolbar only (attachment 415164 [details]), to avoid all the "costs" problems - technically for composition tab: hide main toolbar, show composition toolbar (will avoid the flickering, and allow for next point) - provide full toolbar customization for compose toolbar: -> (power) users who need "get mail" and "write" buttons always, can just add these to their compose toolbar -> by default, we'll just have the traditional, no-fuss compose toolbar, thus avoiding any confusion for most users - implement [+] tab for writing new msgs etc. as proposed above
I agree with Thomas, how less UI, how better to avoid confusion but with all other things not to far away. although I can do little help, I will refer to the work others have done for Thunderbird - by the TB Lightning folks. Maybe there is something to do with? https://bugzilla.mozilla.org/show_bug.cgi?id=464783
(In reply to comment #29) > Created an attachment (id=415619) [details] > Screenshot 2: tabbed composition with 2 toolbars (main & composition) > > (In reply to comment #26) > > (From update of attachment 415164 [details] [details]) > > Maybe start by placing those toolbar items inside the tab itself. We lose a > > little vertical space but gain some consistency. > > Let's try that idea... -> see attached screenshot #2 with 2 toolbars: > - main/global toolbar and > - composition toolbar inside the tab. > > To be honest: That's not it. > But let's look at that in more detail (as I've learned from Bryan we always > need to balance everything, like cost and benefit...) > > Costs: > - We are losing *a lot* of valuable v-space (that's *in addition* to our > traditional composition header, which takes a lot of space already and we > already have bugs filed against that). > - The UI looks bloated and cluttered (again, *in addition* to all the existing > complexity of the traditional header) > - We are confusing normal users *a lot* as to what the *relevant* functions in > this composition context are > - The global functionality we add (get mail, write) will be irrelevant for most > users in this context, and we're not helping advanced users a lot (as I will > show below) I disagree strongly with this. Win-Eudora had one button bar which could be configured, and more importantly, could be moved and docked elsewhere. I always had mine docked near the right-edge of the window, and arranged so that it was two buttons wide and as tall as needed. That took care of the "major" buttons such as NewMail, Prefs, GetMail, etc. Any button showing there, which had no meaning in the context of the tab I was viewing, was simply greyed out. Composition had its own formatting controls anyway. Having the button bar vertical solved most of the vertical space problem. > Benefits? > > (In reply to Bryan's comment #28) > IMO the use cases cited are not very convincing. I think they are too > power-userish, and they wouldn't outweigh the costs, at all. But maybe we can > find another solution which is better than Screenshot 1 and Screenshot 2 (see > compromise proposal below). > > > You're writing an email in a tab and while writing realize you need to send > > another email to someone else. > > - Ctrl+N takes you right there; I'd think that users who actually write > multiple emails simultaneously are probably advanced enough to know the > shortcut (it's also available from File Menu with 2 clicks) > - the Write button might be confusing for some users when they are already > writing > - Consider implementing a [+] tab like in FF (after the rightmost tab) to write > a new message (perhaps the button could have dropdown [ + |v] so that you can > also open a new tab for a search, folders, addressbook etc.) Why should I as a user have a rigmarole to open a new compose window in addition to the four I've already got, just because I'm in one now? The action I take (namely, click a button that I've configured to exist) should be consistently the same whatever I'm doing now. > > You're writing an email and your plane announces it is boarding now. You want > > to make sure you've grabbed any last emails before you leave. > > - that's pretty power-userish, IMO... ;) > - Ctrl+[Shift]+T (or Ctrl+D, after we've fixed that) > - set automatical downloads to every 5 mins if you need them so urgently > - in most cases, you'll want to view your msgs after downloading; so you'll > open an inbox tab anyway! iow, for most people it won't be intuitive to > download msgs while composing without even leaving the compose window > > > People might start to learn that certain toolbar buttons are only present when > > looking at certain tabs. > > Actually, we have all learned for the past 5 yrs of using Thunderbird 2, where > composition was composition and inbox was inbox. By putting composition in a > tab, we're already making access to those unrelated actions *a lot* easier than > it was before. > > > However unlike the ribbon bar where this is a "soft > > mode" - meaning even when the toolbar changes you can change it back without > > changing what you're doing. We would be created a "strict mode" where you > > would have to alter your behaviour to get the buttons back. > > Actually, the use pattern of 'single toolbar' UI proposal (Screenshot 1, > attachment 415164 [details]) is only marginally different from a full-fledged ribbon bar. > Compare: > > a) Ribbon bar: > 3 clicks (click "home" ribbon tab, click "write" (-> new tab foregrounded), > click to return to your original composition tab) > > b) Composition toolbar only (Screenshot 1): > 3 clicks (click "Inbox/Folder" tab, click "write" (-> new tab foregroudned), > click to return to your original composition tab > > c) Global toolbar AND composition toolbar (Screenshot 2): > 2 clicks (click "write" (-> new tab foregroudned), click to return to your > original composition tab). So we're saving 1 click (at a very high cost both > space and usability, as shown above). > > > Removing these [considered 'global'] buttons presents a bit of a usability > > issue. > > Actually, we are also creating a big usability issue by showing too many > toolbars and buttons, many of which will be irrelevant in composition context > for normal users (see above). Hey Bryan, what happened to your legendary drive > to protect the average user? ;) > > The Way Out (Compromise): > UI Proposal #3: Single compose toolbar with customization > > - with a lot of good will, let's assume there are some users who want their > "Write" and "Get mail" buttons always available. > - so it's different users, different needs > -> Customization will solve the problem: > > - have a single compose toolbar only (attachment 415164 [details]), to avoid all the > "costs" problems > - technically for composition tab: hide main toolbar, show composition toolbar > (will avoid the flickering, and allow for next point) > - provide full toolbar customization for compose toolbar: > -> (power) users who need "get mail" and "write" buttons always, can just add > these to their compose toolbar So if I'm in a mail viewing tab, I click one button to start composing. If I'm in a compose tab, you asking me to click a *different* button to make another compose tab? This is really silly and unacceptable.
I think people are trying to think too deep in this situation. The solution is simple, maybe not the programming part, but the user interface situation is easy to visualise. Basically, when someone wants to compose a new e-mail, the action of clicking or focus in a tab makes the toolbar change depending on the type of tab opened. Thunderbird is ALREADY doing this for one if its tab functionnalities. When you open an e-mail, a new tab opens with the e-mail contents, in the go to menu, certain options are greyed out. So the solution is to create another toolbar, positioned at the same place of the actual toolbar visible only when we are in a tab for a message composing. The other toolbar, the one everyone sees, is invisible. If you go back to your message list tab, the compose toolbar is made invisible and the original toolbar is made visible. No hassle about moving/hiding or renaming buttons. It's like two picture boxes (Because I program in VB, this is why I use this example), hide a picture box and show the other and vice versa. Two toolbars in one area. That's my point of view. I never vies Thunderbird's source code but I think that this solution can be achieved pretty quickly. The rest of the programming will be to move all the compose menus and object into a tab instead, that might be a bit longer. To resume: the fact of clicking on a tab or the fact that a tab has the focus, the menus and toolbar changes to what is needed in that toolbar. David
(In reply to David's comment #32) > I think people are trying to think too deep in this situation. You should specify which people you mean ;) Let's say it was encouraged by Bryan's comment #9, "the question that needs some real thought and work"... > The solution is simple, maybe not the programming part, but the user > interface situation is easy to visualise. [...] > To resume: > the fact of clicking on a tab or the fact that a tab has the focus, the menus > and toolbar changes to what is needed in that toolbar. FTR: David, that's exactly what I proposed in Screenshot 1 (attachment 415164 [details]), comment 25 and, with modifications, in comment 29. I also thinks it's easy, but maybe Bryan thinks it's difficult ;) So I tried to discuss Bryan's alternative (Screenshot 2, attachment 415619 [details]) and propose a compromise in my comment #29.
Sorry if my comment seemed agressive, that's not what I wanted. I am just anxious to see Thunderbird work in tabbed mode completely! It would be one of the rare FREE Mail clients to do so with so much flexibility. At a user's point of view, that thing seems simple to do. But in the programmer's eyes, it's probably much more complicated. I use this software at work and, I can tell you that, my two monitors are full of windows. Working with only one window in Thunderbird would help me sooooo much!
Why don't we look at the Yahoo! Mail interface? To me it looks like a perfect example of a tab interface for Thunderbird.
You just need to take a look at Lotus Notes 8.5 interface if you want a fully tabbed mail client.
How about splitting the message panel vertically for composition? I have been using vertical view layout so far. Composition of a short quick answering e-mail should be very reliable in this way. Ideally, a user should have possibility to choose a way of composition (similarly to have an option to compose plain/html e-mails). I would consider: new window, new tab, new panel option. Hopefully, it does not mean to rewrite a lots of code.
I support this. I was searching the options and the web for a way to open the compose window in a tab. I'd like my TB to use only tabs and no other windows just like my Firefox.
I think, that Tabs are really unnecessary for ready mails, because whe I like to read a mail, I click on it and read it in the message area. Why should I open it in a tab. But tabs are useful, when you like to compose a mail. I can't understand why this possibility didn't exists.
I'm probably not adding much to the discussion already, but here are some alternative proposals for the toolbar problem: 1) put all toolbars in tabs. This way it would not be surprising or inconvenient to see buttons changing. This would also mean that Get Mail/Write/whatever buttons could be available from customization palette. 2) Redesign the area where From, To, and other fields are located (not sure how to call it). With one recipient per line, that area is quite underused – it could surely accommodate some buttons. 3) I really like the idea of in-line reply. For me personally, it would render Thunderbird tabs/windows useless in 90% of the cases, but they're just tabs, and I'm not pitying. :) Now the menu problem. So far it seems unsolved, but: 0) (just a note) If Toolkit learns to hide menus in latest versions of Windows in accordance with the OS setting, the flicker would become a smaller problem, only relevant to SOME Windows users and Linux users. 1) The menus could be put inside tabs too, basically resulting in a design similar to Firefox 4.0 mockups and Google Chrome (the latter doesn't seem to have a menu at all). 2) I just did a quick check, and the Compose menu only seems to have three new menu items: Insert, Format, Options. Let's focus on them for a minute. * Insert is basically a duplication of the "Insert" button in composition toolbar, with just a few extra items. I think those extra items could easily be consolidated into that button. * Format basically duplicates function of all the other buttons in composition toolbar, again, with just a few extra items. Those could be consolidated into composition toolbar as well. * Options. This one seems to mostly duplicate the Compose window toolbar (and its optional buttons), but a few functions are unique. I guess it won't be surprising that I'll propose to merge them into that toolbar, right? :) In this case, the menu problem would simply be solved by using only one global menu.
I believe I can solve everyone's problems and reservations for the proper use of a tab bar. When we check out the better points above, we see that how we apply it is what makes the difference. Also, overlooking the obvious application of the bar when first released has shown a certain degree of shortsightedness, and lent itself to the frustration that so many of us have with the shortcomings of the software package as a whole. I believe this demonstrates that the user wants an improvement. First of all, let us agree that the tab bar is a great idea and a huge improvement. Let us also agree that it has tremendous potential to improve usability and productivity. Applying it to use as a place to hold emails under composition is an obvious usefulness, and once you see Lightening setting in one of the tabs, that too will be recognized as an obvious use as well. And let's not forget the address book and other similar components. Expaning the usefulness of the tab bar is much better than fiddling with windows and menus. The issue of toolbar or menubar space when editing is a non-issue because of the fact that the tabbed window for any email message already wastes a huge amount of space for the "From" and "Subject" lines, as well as for a number or buttons, another row for the time, and one for a dropdown list entilted "other actions", and yet another bar that states, for example, "this is a draft message" with an "Edit" button. What is dumb is for the user to be given the ability to open a draft message in a tab, but then forcing them to use another window to edit the same document. This poorly designed section can be improved in any number of ways to give the user a customizable bar for necessary menus and buttons on a per-tab basis. Changing the main menu and button bars is not necessary. Problem solved. The issue of overlap of parts also shows a poor integration of components. If there is an editor, it should be callable from any other component, and its edit window should be embedable in any space desired. If not, there is a serious programming problem that needs to be addressed by the project director. Each part of the project should be a stand-alone component that can be combined and reused in any useful manner within the email client software. Problem solved. Also, the issue of number of tabs should be handled in the same manner as in Firefox or Opera; there would just be a performance and/or memory limit depending upon one's own computer. No need to re-invent the wheel. Problem solved. The issue of the use of a directory tree within the tab is one of personal preference and should be a toggle option just like it is in any other tab. If one can turn it off in their main view tab, then it should be available to turn on or off in any other tab on a per-tab basis in like manner. Problem solved. The issue of trying to substitute keyboard shortcuts for buttons is the exact same thing as using a CLI instead of a GUI. We are past that, and dragging people back to memorization of keyboard key sequences is unacceptable in all software design. Problem solved. Just stick a customizable button/menu bar in each tab as needed, and embed the editor in the message tab. Now I realize that the application of these solutions depends upon the coders imagination. However, there is always a way to solve every problem, and we don't throw in the towel just because we think it is difficult or because we can't think of how. That is not our job here. Rather, we are just to state how things should be within the confines of the existing framework. That in and of itself gives the coders a huge amount of direction and understanding of the final product. I trust them to figure it out in the same fine manner they always do. As in all things, the tab bar issue is one that needs better direction. IMHO, I found it very surprising that the ability to use the tab bar to create a new message was not implemented. This should be the predominate focus at this point in time. I also believe that all the fine commentors here have brought us to a clear understanding of the finished product, and I hope the the project will immediately integrate our ideas. Thanks.
I dont't have read all statements. sry.... I think Tabs are cool. And we should use it. But i think we should develop a GUI that survives the next time. MS is a bad example for GUI building. They make an quasi-Standard with MS-DOS since 1980 an in Office 2007 they discard her own standards and develop an new way. Tabs are OK. So if we improve the GUI we should start with Tabs in the AB. For every Range of Letter one TAB (A..D,E..I,...)
Hi, I have an idea how to achieve both mentioned aims to save space and to make the GUI intuitional at the same time. I'd suggest to combine all actions in one singe Toolbar as sketched in these two mockups: Inbox: https://bugzilla.mozilla.org/attachment.cgi?id=424470 Write: https://bugzilla.mozilla.org/attachment.cgi?id=424471 The globally relevant actions Write, Address Book and for Lightning users also Calendar and Tasks are placed on the left side of this toolbar and visible all the time. All tab-specific actions are aligned to the right. For the inbox tab this would be Get Mail, Tag, and the search field. They only make sense in this context. If the user opens a write tab, they disappear and Send, Spell, Attack, Security and Save buttons appear. I'd love to see something like this in Thunderbird. Tabs make nowhere else so much sense to me as for writing multiple mails in one window. exek3y
Hi, Some months ago I post the Bug 518897: a proposal of UI design for TB3, the idea and the mockup screenshots (sorry, it are a bit poor) have similarities with the last posted here by firstname.lastname@example.org (great work!), with all in tabs and groups of tabs. I think a mix of the ideas can be good. What do you think about this? Another and comlementary idea is the fast reply: a short textbox at bottom of read messages pane to write a short answer (without text format, without attachments).
The attachments are all nice examples. The basic theme that I see in these is that the various toolbars and buttonbars can be appropriately merged. Currently, they are scattered all around. (I never understood Mozilla's design ideas with regard to this. Even old WordPerfect allowed a person to customize each from within the program and without add-ons.) As has been pointed out by others, making the bars context sensitive is a great way to go. I can't imagine that it would be too difficult to tie the bars to the appropriate tabs, rather than making them a part of the base application. Also, cleaning up the wasted space is always a great idea, and has been shown as possible by the attachments. And the way to accomplish the ideas which have been made is to make sure that the interface is tied to dependence on the tabs displayed, either by keeping separate sets of bars, or by making the top portion of the screen separate for each tab, or by tying each button and/or menu item to the different tabs. These methods should keep the maximum user customization available while solving the problems and cleaning up the interface at the same time. At this point in time, all that needs to be done is to check with the people working on directing that part of the interface. Perhaps they will join us here. There is clearly a consensus that this needs accomplishing, and also that this idea should not have been overlooked in the first place. In the words of Larry the cable guy, "Let's git-r-done!". Thanks.
(In reply to comment #47) That's exactly what I'd like to propose. IMHO, it's the finest solution, as we don't change TB appearance that much, make things context sensitive and avoid the flicker problem. The only other solution I'd consider among everything said is having everything inside the tab. But the split toolbar and menu bar seems more elegant to me. As for the programming part, I thought about some alternatives: 1.Each button, menu and item could have a flag or switch stating whether it's a global item or in which context it belongs, so that the UI can easily tell which ones to show, when and where. 2.Buttons, menus and items descriptors could have separate 'classes'. 3...or use different commands or sintaxes, depending on the same. 4.A separate file could contain a table of which item belongs where. 5.Global items could be contained in separate files from those context-specific. Then we'd have a file for each context. All of them imply a backwards compatibility issue that would have to be addressed.
Created attachment 439225 [details] dtd file with possible implementations of proposed behaviours Tried to organize my ideas (first four, as 5 is quite obvious) in an actual file.
Just adding that I'm a C++ beginner, not yet a skilled Mozilla programmer, so the file won't really work. It's only intended to picture the ideas. Thinking about backwards compatibility: 'till everything is contextualized, the UI could consider old stuff from main app as global and old stuff from extensions (such as Lightning) as context-specific. Dunno if this is possible though, just sharing a thought.
Calling all Thunderbird programmers! Any interest out there on our suggestions? Any feedback? Any at all?
I like the "Screenshot: UI proposal for tabbed composition (56.90 KB, image/png) 2009-11-30 09:21 PST, Thomas D." layout better than the " Screenshot 2: tabbed composition with 2 toolbars (main & composition) (63.90 KB, image/png) 2009-12-02 05:40 PST, Thomas D." layout. The latter has an extra toolbard that would take up too much screen space. I generally use larger fonts so the first would work better. Maybe have an option between the 2 layouts. Thanks, David Paul
I just had a related problem. This shows the depth that the tab issue reaches within the program. When right-clicking on an attachment and selecting to open it, it doesn't open a new tab for viewing. Instead it opens another Thunderbird window, but this one is entitled "nullThunderbird". Very strange. Anyone else have that weird problem?
sure. Here's one way to repro: 1) Save any e-mail as .eml file 2) open the saved file with a text editor, remove the Subject header, save the file 3) open the saved file with Thunderbird I even saw "nullLanikai" for a moment when opening the .eml file with the Subject header intact. Removing it only makes that more visible.
Yeah, I'm not sure what's going on with the program, but I do notice the problem with things like these. It does appear to be a problem with the overall programming, and not just the oversight of an obvious functionality such as proper utilization of tabs. I believe that these two examples indicate that there may be a hidden complexity that is hampering the programmers of the UI. I believe I speak for most users when I state that I just want to have the functionality of the program to be more intuitive. If I select to view an attachment, it should have gone directly to a new tab. I must confess that I'm a little confused about the reasoning behind the current functionality. IMHO, it seems that the user is forced to remain in the dark as to why things are the way they are. Anyone have any further insight? By the way everyone, don't forget to vote for this enhancement.
In this post cum video Alex Faaborg explains the new tabs-on-top model for Firefox 4 that I believe could be successfully applied to Thunderbird too: http://blog.mozilla.com/faaborg/2010/06/24/why-tabs-are-on-top-in-firefox-4/
Getsatisfaction reports that request the same as this bug should be tagged "Bug 449299". To view the list: http://bit.ly/ccLFlB -> http://getsatisfaction.com/mozilla_messaging/tags/bug_449299
@Bryan (more below): This bug should certainly be flagged wanted-thunderbird+. This bug should also be flagged [UXprio] in the Whiteboard field, I believe...: - With about 100 votes, currently the highest number of votes for *any* TB bug - This enhancement is very topical on getsatisfaction, too, 155 people currently have the problem of the main report, which MozMessaging marked as "Planned". The other reports also have a lot of "votes", although we can't know how many of the votes intersect: http://getsatisfaction.com/mozilla_messaging/topics/compose_reply_in_a_new_tab-knj0 (155 people have this problem) /new_message_and_address_book_in_new_tab (115 people) http://getsatisfaction.com/mozilla_messaging/topics http://getsatisfaction.com/mozilla_messaging/topics/write_new_email_in_tab (36 people) http://getsatisfaction.com/mozilla_messaging/topics/a_new_tab_for_composing_not_a_window (13 people) http://getsatisfaction.com/mozilla_messaging/topics/tabs_improvement_on_tb_3_for_mac_sys (3 people) This bug is currently not included in the list of UX priorities for TB 3.2, which seems to focus on smaller tabs-related issues: https://wiki.mozilla.org/Thunderbird:UX/Priorities/3.2#Tabs What worries me is that I am not aware of any roadmap / time frame for this bug (please let us know if there is). In view of the great interest of users for this enhancement, as referenced above, I therefore suggested this bug to be included into the list of UX priorities for TB 3.2 on the TALK page: https://wiki.mozilla.org/Talk:Thunderbird:UX/Priorities/3.2 Note that expecting this for TB 3.2 might be too early, but this enhancement should really be roadmapped and given a time-frame. @Bryan: Any information/feedback on this bug by developers would also be appreciated by the many contributors who tried to provide ideas (regardless of the feasibility of those ideas). At the same time, contributors should be aware that the team of TB developers is small (http://www.mozillamessaging.com/en-US/about/staff/), and perhaps we can't expect them to explicitly react to each and every idea in this bug.
Getsatisfaction links (typo fix, sorry) http://getsatisfaction.com/mozilla_messaging/topics/compose_reply_in_a_new_tab-knj0 (155 people have this problem) http://getsatisfaction.com/mozilla_messaging/topics/new_message_and_address_book_in_new_tab (115 people) http://getsatisfaction.com/mozilla_messaging/topics/write_new_email_in_tab (36 people) http://getsatisfaction.com/mozilla_messaging/topics/a_new_tab_for_composing_not_a_window (13 people) http://getsatisfaction.com/mozilla_messaging/topics/tabs_improvement_on_tb_3_for_mac_sys (3 people)
This is also the second-most wanted feature for Postbox: http://support.postbox-inc.com/entries/99490-compose-windows-as-tabs-in-the-mail-window Unfortunately, Thunderbird is blocking users from getting the feature!
There is an addon which adds this functionality for the address book: http://lucdischert.free.fr/realisext.html https://addons.mozilla.org/af/thunderbird/addon/67147/ Perhaps it is possible to build a similar addon for composing messages to get started.
(In reply to comment #65) > Getsatisfaction links (typo fix, sorry) [...] The best would be that one of the MoMo GS administrators merge all these "ideas" into one. Can you do that Roland? ;)
At least something seems moving: http://mozillalabs.com/messaging/2010/09/03/2756-bugs-found/
Evidently another bug I started at 598500 is seen as a duplicate of this. However, there is a little difference, so I guess I'll just list it here. I wrote: "Whenever users open a draft message to edit it, or they open a new message, or they try to work on their add-ons manager window, etc., the pop-up windows (which should have been tabs) block all the program functions and displays." With this reduced functionality to Thunderbird, the tab issue is causing a loss of productivity across the board. I hope it is moved to the very top of the list.
I absolutely agree. Please can the Thunderbird development community focus its attention on implementing a 'compose new e-mail in a tab' feature for TB 3.2. This is the single biggest productivity change that can and should be implemented and until it's done, the full power of tabs will never be realised and without it they're somewhat pointless. Naturally, this should also include the ability to reply to and forward an e-mail in a tab. The act of constantly looking down in the task bar and working out which entry to click to get back to the composition window, whilst consulting several e-mails in the the Inbox opened as tabs is very inefficient. A valiant attempt has been made to create this functionality in Tool Tabs for Thunderbird - see https://addons.mozilla.org/en-US/thunderbird/addon/229487/ but this really should be included natively in Thunderbird as a core feature. Some people also want to see the Address Book viewable in a tab. The above add-on also provides this functionality, thought this is less important as the Address Book is probably not consulted as frequently as new mail is composed. The Lightning calendar is already natively displayed as a tab. For those users that don't want this feature, an option similar to reading e-mail in tabs should be provided - see Advanced > Reading & Display > Open messages in: 'A new tab' or 'A new message window' with the default being in a new tab. Many thanks. Nigel
Well said, Nigel. And I can't imagine who wouldn't want everything in tabs.
Nigel's points are all valid, and I just have to reiterate this point - the lack of tab support for the compose window is also holding back Postbox and other Thunderbird-based clients. I can't think of any feature that should be prioritized over this one.
Nigel's points are quite true in my view. I think this should be given top priority in terms of new functionality.
We would welcome patches ....
Let's not just patch the program, but rather fix it correctly.
Disclaimer: this is not a very useful comment. From my little bugzilla experience, I can say Mozilla folks don't use it as a forum. I think comments saying "this feature is so awesome, please code it" are frustrating the developers. Plus, these comments does not help to read interesting messages. Of course, I guess mockups are still welcomed. KitchM: patches are not "bad fixes", just see them as "bricks". This may change the way you read Ludovic message ;-)
The developers are aware of this request. One of the problems with the current UI is that it tends to be a bit heavyweight, especially for including in tabs. Although it may seem simple, taking the existing standalone window and just sticking it in a tab isn't necessarily the best option from the user experience perspective. If people want to help with this, the best way would be to put together extensions and get feedback on those extensions. I'm sure Bryan would be willing to provide comments on experiments.
That may be, Mark. But it is too subjective for a lot of folks to grasp. I know that I would like to experience the editor within a tab so that I could judge for myself if there was too much overhead with that method of use. It remains a little difficult to get our heads around something if we have not experienced it.
I agree with KitchM (comment 80), as an end user, it's irrelevant to me whether the present UI is heavyweight for tabs. If being heavyweight is an obstacle to including compose/reply/forward e-mail in a tab, then redact the relevant code as required. I disagree with Mark (comment 79). Sticking the current compose window in a tab would work fine for me. Talk of implementing compose-in-a-tab as an extension raises the question why didn't Mozilla implement all tabs as an extension, and why did they highlight it as one of the principle new features in v3.0 if they weren't committed to fully implementing it? That decision looks short-sighed now; surely compose-in-a-tab was discussed along with view-in-a-tab at the time tabbed e-mail was conceived? In my my view, the Mozilla community should get that functionality out in a final release as soon as possible and then let the Thunderbird user-base tell the developers how it can be improved in future versions - release early, release often! If an extension is really needed to garner user feedback, take a look at 'Tool Tabs for Thunderbird'. It's experimental and buggy, but I would be more than happy if core Thunderbird code could replicate its UI and behaviour. Perhaps the Mozilla community could drive this project forward, with the ultimate aim of integrating its functionality in the main application?
(In reply to comment #79) > If people want to help with this, the best way would be to put together > extensions and get feedback on those extensions. What is the role of https://addons.mozilla.org/thunderbird/addon/223389/ in this regard? Is this considered a viable candidate?
(In reply to comment #82) > (In reply to comment #79) > > If people want to help with this, the best way would be to put together > > extensions and get feedback on those extensions. > > What is the role of https://addons.mozilla.org/thunderbird/addon/223389/ in > this regard? Is this considered a viable candidate? It's an experiment and it's what compose in a a tab might look like: https://wiki.mozilla.org/Thunderbird/Experiments#Compose_in_a_tab
Last time I discussed this with various folks (disclaimer: I'm the author of the aforementioned compose in a tab experiment), the conclusion was that a large overhaul of the compose codebase was required. Some extensions might already allow you to open the compose window in a tab, but it's nothing more than a quick hack. The problem is, as I said previously, the compose codebase is ancient, and makes various assumptions that don't stand anymore. I'm currently busy finishing another experiment (thunderbird conversations), but I plan to resume work on compose in a tab soon. This will probably imply some large patches to the compose/ codebase, and I'll be pushing them to bug 539299, so you can track progress there.
Again, let's just stick it in a tab and see what happens, warts and all.
Thunderbird is used heavily at our university. One of the things that keeps happening over and over is someone has a message open in another window, is interrupted, and the message doesn't get sent. At the end of the day, they are rushed, and just shut down quickly, not realizing the message is still sitting there--and they don't think to check their draft folder the next day. This has had an effect on some fairly important situations. The task bars are getting full as it is, people are routinely sitting with two monitors just to keep things sorted out. Putting the compose window into Thunderbird in a tab so it's easier to track things would be really useful.
The first thing that came into my mind when tabs first came to Thunderbird was: Why is there no new tab for new messages. I think this should go without saying!!
Folks: We know that compose in a tab is wanted. There are experiments coming out soon, and we'll invite feedback on them when appropriate. However, as per the bugzilla etiquette please do not comment on this bug (or other bugs) unless you have something that is actually moving this bug towards a fix. Comments along the lines of "I want this" or "we should have this because" are not useful to getting this bug resolved. Etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Other discussion areas: https://wiki.mozilla.org/Thunderbird/CommunicationChannels
Come on Thunderbird devs, the current crop of major version number releases have just been tinkering around the edges. The excuse that the 'compose codebase is ancient' doesn't really cut the mustard. If anything, the fact that it is so ancient should be motivation enough to bring it up to date with a re-write that can accommodate this feature. Compose in a tab is THE most useful feature that is currently missing from Thunderbird. All the other tweaks that have been rolled out since v3.1 have largely just been cosmetic.
This can't be that hard. Please help make this a priority at Mozilla... it is with your users :-)
I agree. This feature should be put in the very first place of the priority list of the thunderbird developers.
I also agree. Please consider this feature request, and thanks for the good work in making the best email client (without compose in tab ;)
Joshua, chirst.stark, J-F Bohémier, please read comment #88. You're doing nothing constructive, and Bugzilla is not a user forum. So unless you have technical points that can help solve this problem, you're wasting the 95 other subscribers bug's time, since each comment you add sends an email to these people. Etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Other discussion areas: https://wiki.mozilla.org/Thunderbird/CommunicationChannels
No offense, folks. I too feel that this is a most important issue. However, the owners of the code have their own agenda, and that is not the same as ours. We need to keep that in mind. If we want a better product, the FOSS community wants us to do it ourselves. And if we don't thank and encourage them enough, they will stop doing whatever it is they do. Please hold your comments as they are not appreciated. Thanks.
No offense either, but ignoring the clients isn't a very smart attitude in a product development. We're talking about something that every client would benefit from - it's not the demorkification of the backends, which nobody would notice. Here there are the reasons why this work is not being done: http://mozillalabs.com/messaging/2010/09/03/2756-bugs-found/ So certainly your "keep your mouths shut" isn't going to make the product more usable either. Open source doesn't come in god's grace, and isn't developed with "thanks and encouragements", but with money - the reason here is that Thunderbird is not seeing it.
Still not implemented? Oh well. I've used Thunderbird in the past, but I'm using Opera as my e-mail client now. I however no longer use it as my primary browser (using FF now), so I'd like to switch back to thunderbird and get rid of Opera completely. Won't do it until this feature is implemented though.
I believe that if a team of developers would start working on this feature, they could raise a pretty amount of funding on Kickstarter :)
In the meanwhile, they're planning to integrate instant messaging: https://wiki.mozilla.org/Features/Thunderbird/Instant_messaging_in_Thunderbird there must definitively be some PHB in the Mozilla offices.
(In reply to ms-studio from comment #98) > I believe that if a team of developers would start working on this feature, > they could raise a pretty amount of funding on Kickstarter :) Definitely! I've been searching for years for systems that would allow me to pay for much needed features. Will gladly pay 20$ to have a workable, tabbed mail composer that would allow me to edit HTML and make decent tables.
Perhaps a Kickstarter appeal could be organised to fund the parity-Postbox bugs and exceed the Postbox mail app's user experience? It is based on Thunderbird, so there's no reason it's UX improvements couldn't be implemented. https://bugzilla.mozilla.org/show_bug.cgi?id=737347
Not really interested to use Thunderbird for instant messaging. I might give Instantbird a try in the future, but Thunderbird? Nope.
@Geoffroy Ménard: "allow me to edit HTML and make decent tables" Try the Stationery add-on, which allows you to edit HTML: https://addons.mozilla.org/thunderbird/addon/stationery/ @Jáchym Toušek: "Not really interested to use Thunderbird for instant messaging" I agree. Thunderbird is a fantastic email client, but I would not use it for IM.
This discussion is starting to remind me of the "Please we want to have a one-Window-Gui" discussion with GIMP. Now finally after five years we have a single window mode. With this discussion we are also getting close to the fith year. If some programmer is able to program a little addon that already almose does the job, how can the mozilla organization fail??
This discussion is starting to remind me of the "Please we want to have a one-Window-Gui" discussion with GIMP. Now finally after five years we have a single window mode. With this discussion we are also getting close to the fith year. If some programmer is able to program a little addon that already almost does the job, how can the mozilla organization fail??
@christ - I doubt that GIMP had/has a marketing department though, which obviously has a perverse leverage inside Mozilla.
Would you mind moving this general discussion to a forum or newsgroup where they belong? You are spamming some 200+ people who were voting here or are in the CC list to follow the bug, and your comments aren't helpful towards a solution. Thanks.
It's questionable where this discussion belongs to. It would be 100% ignored in a forum or newsgroup. Here at least those 200+ people are aware.
That's not really questionable. Please read comment #88 and comment #93 before adding more noise (and sorry for adding another piece to the pile). Complaining in tracking bugs like this one is not useful and simply wastes people's time. Most of those 200+ (e.g. me) are not developers, are common Thunderbird's users perfectly aware of this problem since they're ALREADY following this bug.
(In reply to Geoffroy Ménard from comment #100) > (In reply to ms-studio from comment #98) > > I believe that if a team of developers would start working on this feature, > > they could raise a pretty amount of funding on Kickstarter :) > > Definitely! I've been searching for years for systems that would allow me to > pay for much needed features. Will gladly pay 20$ to have a workable, tabbed > mail composer that would allow me to edit HTML and make decent tables. I'd chuck in $20 too, if that's what it would take to hire a decent software engineer for a one-off job to overhaul the ancient editor code that would allow compose mail in a tab to be implemented. Whether or not it helps towards a technical solution is irrelevant. Raising the profile of this bug (actually I consider it a massive oversight for a feature that should have been included when tabs first appeared) through frequent posts is the only way to keep reminding the developers of Thunderbird how passionate end users are for this productivity feature to be implemented.
(In reply to Nigel Binns from comment #110) > (In reply to Geoffroy Ménard from comment #100) > Whether or not it helps towards a technical solution is irrelevant. Raising > the profile of this bug (actually I consider it a massive oversight for a > feature that should have been included when tabs first appeared) through > frequent posts is the only way to keep reminding the developers of > Thunderbird how passionate end users are for this productivity feature to be > implemented. That is not the way to raise the profile. We are quite aware of the requests for this feature, however we are a small team, and it is not our highest priority at the moment. Comments along the lines of "I want this to" only serve to spam the team and bug and as a result waste further time. Please re-read our etiquette before posting again. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html I don't like to threaten, but if people persist in violating the etiquette, then we will disable their bugzilla accounts. We need bugzilla to be a nice place for our developers and volunteers to work and spamming this bug with comments will actually make working on it harder. Let me assure you that we are currently working on ways to encourage more community involvement which may lead to this being implemented quicker. In the meantime, the Thunderbird Conversations add-on  has an in-line reply feature that may partially implement what you want. Thank you all for your passion for Thunderbird, please respect our working practices and moderate it when posting here. If you want to discuss anything in this comment, please email me direct, and I'll be happy to chat further to you. https://addons.mozilla.org/en-US/thunderbird/addon/gmail-conversation-view/
No compose in a tab since 2008 and nobody working on it ! It is a shame as it is a number one bug to solve ! If it was made perhaps less people would have not gone to webmail !
I think the only way of having this integrated is to pay a Thunderbird-programmer directly. I did this with clementine for the moodbar integration and it worked fine. So just find out who the programmers are and offer them an amout of money for this feature. Let's say a few hundred Euros, if it is this hard to integrate it as it is said....
Be careful everyone, or you will be spanked by the powers that be. The fact is that this is from the FOSS community and they do not want to do anything other than in the way they wish it to be. No amount of coaxing or threatening to pay will make any difference. They feel that they are doing this for free out of the goodness of their hearts as a part-time effort, and if you don't like it, you must make patches for them or go away. My suggestion is to become a programmer and let them have your patch work, knowing they may not accept it anyway if it does not fit their plan. I feel that the ultimate solution is to take the code and rework it under a new set of standards and directions and to pay a new team to do what we wish. There is no substitute for quality software even if one must pay twenty or thirty dollars US.
Just for the record, I implemented a stub composition window in a tab as part of Thunderbird Conversations (it's an addon). You can trigger it by hitting Ctrl-Shift-N, and you can customize in the addon's options whether it appears in a new tab or in a new window. It's very bare-bones and only allows you to do plain-text email; also, it relies on Gloda being enabled for auto-completing. There's no such thing as saving as a draft; you can't edit existing drafts with it either. If you restart Thunderbird, your draft is lost. However, I've been using it daily for quite a few months now, and it's pretty stable. The various shortcomings could probably be fixed easily; it's just that I don't have time to do this right now. The code is pretty clean, and anyone could build upon that to provide a real composition window. I'd be happy to see anyone steal this, improve it to integrate an external editor (say, aloha), monkey-patch the right bits of Thunderbird and see how much work would be required. I think we would be happy to provide guidance (at least, I am) and directions to develop a replacement compose window in a tab, and consider various options when it has reached the point where it's stable and mature enough so that we can consider replacing the regular window with it. Cheers, jonathan
Hi Jonatan, Thunderbird Conversations doesn't seem to be available for Icedove 10. As already mentioned above this addon also works very well: https://addons.mozilla.org/de/thunderbird/addon/compose-for-thunderbird/
For those who would like to put money where their mouth is, you can pledge an amount of cash for this feature thanks to the Freedom Sponsors crowdfunding platform: http://www.freedomsponsors.org/core/issue/119/ Who knows, maybe a monetary incentive will be more successful in motivating a programmer than reading this lenghty collection of rants :) (In reply to Geoffroy Ménard from comment #100) > (In reply to ms-studio from comment #98) > > I believe that if a team of developers would start working on this feature, > > they could raise a pretty amount of funding on Kickstarter :) > > Definitely! I've been searching for years for systems that would allow me to > pay for much needed features. Will gladly pay 20$ to have a workable, tabbed > mail composer that would allow me to edit HTML and make decent tables.
(In reply to ms-studio from comment #117) > http://www.freedomsponsors.org/core/issue/119/ > Who knows, maybe a monetary incentive will be more successful in motivating > a programmer than reading this lenghty collection of rants :) With this comment, I've added a whiteboard entry* to point to the crowdfunding initiative for promoting this bug. On behalf of everyone interested in this feature, thanks ms-studio for kickstarting the crowdfunding! Nice idea. :) OT *: Because of several bugzilla shortcomings like Bug 577847 and bug 577842, apart from whiteboard, there's currently no other more prominent or readable field at the top of the bug to place the pointer and/or URL.
Hi everyone. I need this bug/feature so much that I'm willing to pay 20.00 bucks for it. This offer is registered at FreedomSponsors (http://www.freedomsponsors.org/core/issue/119/allow-opening-compose-window-in-new-tab-write-messages-in-tabs-writing-composing-mail). Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too) I'll then check it out and will gladly pay up! If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors!
RIP Mozilla Thunderbird... Your last day was on November 27, 2012 https://wiki.mozilla.org/Thunderbird/StatusMeetings We waited since 2008 for "compose in a tab" but nobody at Mozilla was competent or interested enough to do it and now people are using webmail. We will miss you
It may sound more convenient to have 'write' in a new tab, but I prefer to be able to actually see my incoming mails and my address book whilst I'm writing a new emails. It would be a huge inconvenience to prevent clear viewing of emails whilst composing. So if the option to compose in a new tab is ever created as an option, it should be an option and not default.
Created attachment 712065 [details] Screenshot of composition in a tab I've been slowly working on this feature for the past 2 weeks in my spare time. I've been logging my progress on my wiki http://4abf.net/wiki/Moving_compose_into_its_own_tab_in_Thunderbird_-_A_coding_experience#Get_quoting_the_reply_to_work and on freedomsponsors http://www.freedomsponsors.org/core/issue/119/allow-opening-compose-window-in-new-tab-write-messages-in-tabs-writing-composing-mail. This feature will be completed within the next month.
Excellent work, Liam!
Hi Liam, First of all, thanks for tackling this. I'm really happy to see someone step up and take the matter in their own hands. However, I would like to make sure we can work together towards this patch being integrated -- unfortunately, this is not as simple as "fixing it" and then asking for inclusion in Thunderbird. There are certain quality standards for the project, and we expect submitted patches to hold up to those standards. Moreover, with such a drastic change, you need to coordinate with other people (UX, UI) to make sure the change works and fits seamlessly. Finally, this is not just UI work; there are certain parts of the backend that have the assumption of a compose window hardcoded in. The code changes are probably both in-depth and in-breadth. Here are some tips that will help you make sure your patch has the best chances of being integrated : - there was a thread that I started some time ago; is it available online at https://groups.google.com/d/topic/tb-planning/IkeM3_Vixs0/discussion and you may want to read it; although it is not directly related to what you're trying to achieve, it contains important information about which parts of the backend assume the existence of a separate compose window. I assume you've had to touch nsIMsgComposeService and friends -- have you been there yet? - there is some (scarce) information at https://wiki.mozilla.org/Compose_In_A_Tab ; you may want to check it out - last time I remember us discussing this, there were some UI elements that needed to change; for instance, you will probably want to composition window to share the menu bar with the main 3-pane window (you don't want two separate menu bars); similarly, you probably want the mail toolbar to turn into a composition toolbar when the composition tab is active; these are quite radical UI changes that need both a significant code effort and UI discussions; I suggest you open up sub-bugs that depend on this one to tackle these small sub-tasks; - assuming we want to keep both the composition window (standalone) and the composition window (in a tab), this means there will be a lot of code duplication. An easy way out of this is to replace the standalone composition window with a regular 3-pane window with just one tab, this one tab being a composition tab. That way, we would get rid of the code duplication. Alas, this is not yet possible: every 3-pane window must have, well, a mail 3-pane tab open; there are several places in the code that make this assumption, and we need to identify these, remove them, and make sure we can open a thunderbird "main" window with an arbitrary tab, not necessarily a mail-3pane one. This probably warrants another bug, and I wouldn't be surprised if this sub-task turned out to be a significant one. I definitely do not want to discourage you; quite the opposite, actually (I'd be happy to review patches). Simply put, there are a lot of expectations related to this bug, and it's easy to whip up a quick hack that solves the problem on the surface, but that solves nothing and that is a maintainance nightmare. Such a patch would definitely be rejected, and I'd be very sorry if that were to happen to you. Let me know what you think about all this; if you're serious about tackling the various sub-tasks, we can start a thread on tb-planning trying to identify the technical items that need to be done, file bugs about them, and get the various people that have the "right" knowledge involved in the discussion (standard8, bienvenu, squib, jcranmer, myself). Cheers! jonathan
(In reply to Jonathan Protzenko [:protz] from comment #124) > Hi Liam, > > First of all, thanks for tackling this. I'm really happy to see someone step > up and take the matter in their own hands. However, I would like to make > sure we can work together towards this patch being integrated -- > unfortunately, this is not as simple as "fixing it" and then asking for > inclusion in Thunderbird. There are certain quality standards for the > project, and we expect submitted patches to hold up to those standards. > Moreover, with such a drastic change, you need to coordinate with other > people (UX, UI) to make sure the change works and fits seamlessly. Finally, > this is not just UI work; there are certain parts of the backend that have > the assumption of a compose window hardcoded in. The code changes are > probably both in-depth and in-breadth. > > Here are some tips that will help you make sure your patch has the best > chances of being integrated : > - there was a thread that I started some time ago; is it available online at > https://groups.google.com/d/topic/tb-planning/IkeM3_Vixs0/discussion and you > may want to read it; although it is not directly related to what you're > trying to achieve, it contains important information about which parts of > the backend assume the existence of a separate compose window. I assume > you've had to touch nsIMsgComposeService and friends -- have you been there > yet? > - there is some (scarce) information at > https://wiki.mozilla.org/Compose_In_A_Tab ; you may want to check it out > - last time I remember us discussing this, there were some UI elements that > needed to change; for instance, you will probably want to composition window > to share the menu bar with the main 3-pane window (you don't want two > separate menu bars); similarly, you probably want the mail toolbar to turn > into a composition toolbar when the composition tab is active; these are > quite radical UI changes that need both a significant code effort and UI > discussions; I suggest you open up sub-bugs that depend on this one to > tackle these small sub-tasks; > - assuming we want to keep both the composition window (standalone) and the > composition window (in a tab), this means there will be a lot of code > duplication. An easy way out of this is to replace the standalone > composition window with a regular 3-pane window with just one tab, this one > tab being a composition tab. That way, we would get rid of the code > duplication. Alas, this is not yet possible: every 3-pane window must have, > well, a mail 3-pane tab open; there are several places in the code that make > this assumption, and we need to identify these, remove them, and make sure > we can open a thunderbird "main" window with an arbitrary tab, not > necessarily a mail-3pane one. This probably warrants another bug, and I > wouldn't be surprised if this sub-task turned out to be a significant one. > > I definitely do not want to discourage you; quite the opposite, actually > (I'd be happy to review patches). Simply put, there are a lot of > expectations related to this bug, and it's easy to whip up a quick hack that > solves the problem on the surface, but that solves nothing and that is a > maintainance nightmare. Such a patch would definitely be rejected, and I'd > be very sorry if that were to happen to you. > > Let me know what you think about all this; if you're serious about tackling > the various sub-tasks, we can start a thread on tb-planning trying to > identify the technical items that need to be done, file bugs about them, and > get the various people that have the "right" knowledge involved in the > discussion (standard8, bienvenu, squib, jcranmer, myself). > > Cheers! > > jonathan I completely agree with you on all of this. I don't intend for the screenshot of functionality above to be integrated - it was merely for show. That's a very intuitive idea about making the compose message window simply another 3pane instance. I hadn't considered it and yes, it would make for much more readable code. I think we should start discussing as you suggested on tb-planning, this bug thread is getting big. Anyways I'm supposed to be doing schoolwork, so I'll get on with it. I'll check back tomorrow and maybe then we can get engrossed in planning.
Thanks, Liam. Many of us appreciate your fine efforts. However, as you read above, the original programers made the error of hard-coding bad ideas into the mix. When that happens, such as the poor editor in use, it makes the whole thing unweildy, inefficient and a real bear to change. At this stage, the program needs to be redone, and that will be an enormous problem. But, again, thanks very much for the fine effort. You are appreciated.
To start. I understand Mozilla has an IRC network as well as multiple other forms of collaboration (mailing lists, newsgroups, etherpad etc.). What is the preferred method to just dump information and discuss it? Up until this stage I've been using my wiki to dump info. Planning. * Get the UX people and devise an alternative interface for message composition. Main issue is positioning the menu bar. * Explain to me the difference between code in mailnews and mail. It seems there is a lot of repetition. * Find all the references to the management of compose windows according to the above, and list them on the wiki. * Document what the previous code for instantiating compose windows did, remove the window specific bits (nsMsgWindow) and replace them with calls to a single compose tab manager (mozMsgComposeTabManager) that will decide whether the tab will open in the current window or a new one. All the calling code gets is a mozMsgComposeTab. Use the most suitable language - JS. * Implement the functionality of nsMsgWindow in mozMsgComposeTab. Simple enough. If only Maths came to my mind like such. I must get on, I'll check back later, but until then I have a lot of work to do.
For casual discussion, the IRC channel is probably the way to go (most developers live in North America so there may be a timezone difference). For summaries, tb-planning would be a good idea. https://wiki.mozilla.org/Thunderbird/CommunicationChannels has all the details.
(In reply to Liam Zebedee Edwards-Playne from comment #127) > * Explain to me the difference between code in mailnews and mail. The code in mail/ is thunderbird-only, the code in mailnews/ is shared code with seamonkey (which has it's own bits in suite/).
I've been doing a lot of work today. I've redone my build environment so now I use incremental builds (takes 2 seconds now - so much better). I've created a new JS module msgComposeTab.js, rewritten [nearly] all of the calls to OpenComposeWindow/OpenComposeWindowWithParams to this new JS module. Currently, I'm porting OpenComposeWindow to JS, and I need help reacting to something. OpenComposeWindow implements forward inline using a template message (nsMsgComposeService.cpp:514) which uses LoadDraftOrTemplate calling DisplayMessage (??) to show the compose window. I've tried reading through MXR to find somewhere where I can instead reroute the call to open the window to instead open a tab, but I'm having major troubles finding it. Should we reimplement forward inline properly rather than relying on LoadDraftOrTemplate?
See an email I posted to tb-planning - https://mail.mozilla.org/pipermail/tb-planning/2013-February/002665.html
2008 to 2013 is a very long time. I don't know why no one really cared to add this feature. :(
Because it is open source and the programmers are only doing what they want to. They do not cater to the end user necessarily, and they say they don't get paid. They are making it as they want it to be done. The usual response is if you don't like it, don't use it. Oh well, I hope that explains it. :(
Bought Outlook. Thunderbird is done.
@ Keith Man: Who cares, Microsoft fanboy
Hey Keith Man, christ.stark, I'd just like to point our our etiquette guidelines: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Please read this before commenting further. Thanks! -Mike
We waited since 2008 for "compose in a tab" but nobody at Mozilla was competent or interested enough to do it and now people are using webmail. Liam was our last chance to have it. Unfortunately he didn't received any help from Mozilla... Thank you Liam to have tried. You was nearly the only one since 2008...
I, too, offer my thanks again for the efforts of the few. I realize that the best deal now is if someone offers an add-on for these basic functions that Mozilla will likely never implement.
(In reply to ludobm from comment #137) > We waited since 2008 for "compose in a tab" but nobody at Mozilla was > competent or interested enough to do it and now people are using webmail. > Liam was our last chance to have it. Unfortunately he didn't received any > help from Mozilla... > Thank you Liam to have tried. You was nearly the only one since 2008... ludobm, I believe we all share the disappointment, as TB community, about Mozilla's ever-waning commitment to bug fixing and innovation in TB (more precisely, Mozilla is no longer financing innovation and general bug fixing in TB, but has pledged to maintain security and stability of TB and to provide the framework for community-driven innovation - for details, see https://wiki.mozilla.org/Thunderbird/New_Release_and_Governance_Model). What this means is that Mozilla employees are no longer paid for innovative coding work like this bug, and will provide most of their support for TB in their free time, for free. On that background, I see a couple of very welcoming and cooperative replies, especially from Mozilla's Mike Conley: https://mail.mozilla.org/pipermail/tb-planning/2013-March/thread.html#2675 From there I believe the ball is currently in Liam's field - pls correct me if I'm wrong. Afasics, we haven't heard from Liam for 2 months, but I think it's premature to assume that he has stopped working on this, and I see no indication or confirmation thereof. Compose-in-a-tab is a large project and it won't be built in a day. Liam, would you please give us a ping if there's any specific outstanding questions where you need advice... In the meantime, I suppose being negative won't help much, so I suggest that all of us should be as supportive and cooperative as we can... ******************************************************************************** Here's an idea what YOU can do to support this RFE if you are not a coder: ******************************************************************************** There's a crowdfunding initiative for this bug where you can pledge your financial support for getting this RFE realized, here: http://www.freedomsponsors.org/core/issue/119/ There are 154 votes for this RFE, and 113 users cc'ed, but as of today, only 10 people have pledged their support on the crowdfunding site. If all of us would pledge say 10$ or 20$, that would bring up total offers from current 200$ to something between 1200$ and 2200$, which sounds like a more attractive and slightly more realistic incentive compared to the size of the task...
Hey guys. Nothing has changed since I was last working on it. I sent an email to tb-planning a while back, detailing every step necessary to implement this functionality. I did get one promising reply from Mike Conley, but I didn't receive this (I mustn't have subscribed to the list) until I had started on other projects, and by that time it didn't seem like there was enough supporting helpers to collaborate with, considering my workload at school. None the less, I would still be interested in completing this feature. The part that really blocked me was LoadDraftOrTemplate - I still have no idea when the logic stops and the code for actually opening the window starts. If we are to complete this feature, we need to improve collaboration. Firstly, define who is going to be helping and in what ways. I am already coding, but do I need to share my code with others? Who will talk with the UX people? Secondly, we must agree on where we will discuss everything - this issue is best for sharing progress, and IRC is good for shorter problems, but it would be nice to have a log of all discussed stuff (wiki, mopad?). Finally, it would be nice for everyone to stop posting "moved to Outlook" and "TB is dead" ****, this stuff is not necessary.  https://mail.mozilla.org/pipermail/tb-planning/2013-February/002665.html  https://mail.mozilla.org/pipermail/tb-planning/2013-March/002679.html
The thing is, not many people understand that hairy code in detail :( A large part of the work is exactly that of trying to understand what it does. And when you do, try to understand what 1000 other things it does... Not to set you down, but this bug is not an easy one to fix properly. I do suggest you try to break it down to pieces as much as possible - otherwise it's not reviewable. And yes, share your code as much and soon as you can. (Some public hg repo perhaps? Or even WIP patches to this bug.) I wouldn't worry about UX at this point - first make it work, then once it basically works try to get it landed preffed off. Once it's polished and has had a lot of testing it may be turned on by default, but certainly not in this bug. The #maildev channel on irc is one of the best places to ask questions. You can create a wiki page for it if you want, but discussion is what you want then this bug may be one of the best places.
Hi Liam, I'm the author of compose in a tab, an experiment a did a few summers ago to see how we could implement this <https://addons.mozilla.org/en-US/thunderbird/addon/compose-for-thunderbird/>. Unfortunately, I have pretty much zero time right now, so I never got around to replying to your email on tb-planning. I just took a look at my experiment, and I didn't go as far as having to modify LoadDraftOrTemplate. What I did instead, in order to get the "quotable HTML" for a message, was display the message into a hidden iframe, then get the html contents of that iframe, before wrapping them into a <blockquote>. 203 iframe.webNavigation.loadURI(url.spec+"?header=quotebody", The code is in the addon, in modules/compose.js (beware, the code is old, and the composition code of Thunderbird Conversations is the one that I maintain right now, because it doesn't do HTML, meaning it's somehow simpler). What I mean to say is that you could somehow, as a first step, circumvent some of the hairy routines found in Thunderbird and replace them with saner JS equivalents, and then later on fix, in smaller bits, the various C++ bits, if that means getting there faster for you. To answer your initial question more specifically, I believe the code starts streaming the message, then ends up jumping into mimedrft.cpp through various hoops. That file contains, in particular, a CreateComposeWIndow function which, I believe, is responsible for setting up the compose window after the message has been run through libmime, libmime being somehow is responsible for "quoting it as html". Hope that helps, jonathan
(In reply to Liam Zebedee Edwards-Playne from comment #140) > None the less, I would still be interested in completing this feature. Liam, thanks for the update, that's great news! I can certainly assist with UI considerations & evaluations and "talk with the UX people" (I was the first to try and drive this forward by offering an early UI proposal, see attachment 415164 [details]), but I tend to agree with Magnus comment 141 that > I wouldn't worry about UX at this point - first make it work...
Do I understand correctly that the implication is that the code was never properly commented and/or documented?
(In reply to KitchM from comment #144) > Do I understand correctly that the implication is that the code was never > properly commented and/or documented? Some of the code in question was written at Netscape and is unchanged since they open sourced it. Mozilla code is supposed to be self documenting but that is not exactly how I would describe code from Netscape. But here is the source. http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgComposeService.cpp
Yikes, Matt. When I read that code I got shivers running down my spine. That isn't hardly commented properly at all. Half of the comments are notices of errors and other problems and work left undone. There was definitely no programming manager on the project. rsx11m, I hate to contemplate the complexity of the rest. It is an absolute wonder that it works as well as it does. Thanks, Friends, for opening our eyes. It was worse than I thought.
Do this bugs fixed for Thunderbird 24?
No, 24.0 is feature-frozen by now.
(In reply to rsx11m from comment #150) > No, 24.0 is feature-frozen by now. Is it a feature-project for Thunderbird 25?
(In reply to arthur.quarante.deux.dent from comment #151) > (In reply to rsx11m from comment #150) > > No, 24.0 is feature-frozen by now. > > Is it a feature-project for Thunderbird 25? howdy email@example.com, please read comment# 146 & comment# 147. the likelihood of this showing up in tbird anytime this year [or next year] is ... unlikely in the extreme. take care, lee
Liam, are you still working on this bug? Either if yes or no, please could you attach your latest patch? If you have stopped working on it your WIP patch could help an other contributor to not starting at zero and has to make the same findings you had done. If you are still on it, it would be a good backup.
No, not anymore. This was what I had done up until my leaving - https://gist.github.com/liamzebedee/5055929. I also wrote out an entire plan of tasks that had to be completed before this feature would be complete: https://mail.mozilla.org/pipermail/tb-planning/2013-February/002665.html Cheers, Liam.
As an end user, I very much hope that Susurrus's recommendation gets implemented. That it has been suggested in 2008 does not make me particularly confident though. However, it would absolutely make sense. So please, developers, get your programming head on and realise this. Thanks a lot.
I use thunderbird for decades ... I work with multiple monitors and composing a new mail pops up in the other monitor. It is very annoying! To keep thunderbird windows in a consistent working order I have to move every new window around. Please, implement this feature. Thank you for the great work on thunderbird!
+1. The current behavior is particularly annoying on MacOS when using Thunderbird maximised - that is very convenient - as the composition window is created to be maximised, too - very inconvenient instead.
Wish this is possible for a long time!!!
I just added my vote. I'm a satisfied user for many years, and I really hope this feature will be available soon!
Also ! It's a huge feature which should be available for a long time now ! How was this possible that it have not been implemented since many YEARS now, so much hard ?? It seems to me an evidence... !! Thanks for all the annexe job however ! :)
Please remember that "me too!" or "how come this hasn't been implemented?" comments bring nothing to the discussion. Be assured that fixing this bug is far from trivial; comment #111 is pretty clear. Please also remember that proofs of concept exist: the latest version of Thunderbird Conversations has an option for composing _html_ emails in a tab (comment #115). While this is no perfect solution (it lacks many features of the regular composition window), it can serve as an interim solution, or as a base for someone who would be willing to push the proof of concept further. Best, ~ jonathan
While I am not an expert on all the features of Bugzilla, a failure to provide a poll so that people could vote on one side or the other of an issue makes leaving a comment of support the only option. Not only would a poll solve the perceived "problem" of the "me too's", but would help all people understand what will receive the most focus. Outside of a proper software director, this might be of some help to the coders.
There is the facility to vote for this at the top of this page and many people have voted for it. But you are correct, there is no option to show any other preference. I suppose this is because it is not really a bug, but a request for functionality. Hence more discussion will be inevitable, but please do not just add a 'me too' when you can Vote. Offer useful information / ideas which may be of assistance to the developers. I also ask those who read these inputs to be a little more understanding in these situations where it is a functionality request not a bug. I personally have no objection to it providing that it is not default - there must be an option to switch it off or on. I would switch it off and never use it. I like to see my incoming emails or use other emails as reference whilst composing emails; multi-tasking, so putting the Write message in a new tab would drive me round the bend. There are other considerations like the 'Mail Toolbar'. Would some additional buttons be needed to be included within the Write window so allowing access to eg: Address Book or could this be added in the Write Customise tab menu? The 'Menu Bar' in the Write window is very different from the 'Menu Bar' currently visible in tabs. So, even if reading an email in a tab, you still have access to the main Menu Bar, but this may not be possible if a different Menu Bar is loading 'outside of the tab' when you have a Write message tab in focus. Could this cause an issue? Have people thought about how they would need to work, having to hide or close a Write tab just to see an email or have access to the main toolbars. At the moment using a separate window, there is instant access to both without closing or hidding tabs, so much quicker if you use the email client alot. I'm sure there are other considerations too.
Well, I cannot find the vote option, but maybe I'm missing something. However, along those lines, another flaw of Bugzilla is the lack of links to "feature" or more appropriately, "usabilitiy" requests. This makes it impossible to move a bug to the other spot by those who are doing triage. Getting back to the issue, every need for a window should open in a tab. That is the default implication in this sort of thing. One can consider that usage in Firefox if one needs further proof. A separate window is usually the option by context menu request. I do not like having to jump back and forth between various windows in the client. I often am editing two e-mails while using my calendar which makes 3 windows and I find that to be the real time waster. Regarding the details, each TB tab must have appropriate toolbars. An editing tab should display the WYSIWYG tools. By the way, this concept might solve the lousy editor problem by allowing an addon editor just as one might add something like Lightning. These become new tabs automatically.
I've always thought one of the advantages of tabs, apart from neatness, is to serve as a stack. Useful for replies to e-mails you know you have to get through in the hour/day, and just want to jot down the first sentence or some sudden ideas. In Thunderbird as it stands, five half-written e-mails later and you have either a cascade of windows, or a littering of draft messages across incontiguous account folders. A simple stack, together with persistance across sessions, is convenient way to deal with such situations. That said, I value the minimalism of Thunderbird above all else. I like a clean interface, and unlike the add-on offerings I don't necessary need formatting toolbars and hardcoded window colours in my compose or any other window (that said, I am stuck on v17 for similar reasons so I'm not sure what I can expect here). I value the ability to keep the user background colour and every part of the interface consistent throughout Thunderbird operations, and I hope composing in tabs will preserve this.
(In reply to Anje from comment #163) > At the moment using a separate window, there is instant access to both > without closing or hidding tabs, so much quicker if you use the email client > alot. Do you use multiple monitors? If not, how do windows provide you with access to both?..
(In reply to KitchM from comment #164) > Well, I cannot find the vote option, but maybe I'm missing something. You missed the "(vote)" link which points to https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=449299#vote_449299 > However, along those lines, another flaw of Bugzilla is the lack of links to > "feature" or more appropriately, "usabilitiy" requests. On the advanced search form you can select "Enhancement" from the "Severity" field. Here are all the ones for Thunderbird's Compose Window: https://bugzilla.mozilla.org/buglist.cgi?list_id=10885621&bug_severity=enhancement&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=Message%20Compose%20Window&product=Thunderbird
Thanks but I still don't see it. Do you have a screenshot?
(In reply to KitchM from comment #168) > Thanks but I still don't see it. Do you have a screenshot? Bugzilla fields can be hidden through customisation. I won't attach a screenshot but here's another project's screenshot showing the normal position of the "Importance" section of bugs which has both the severity and the "(votes)" link: https://wiki.waze.com/wiki/images/thumb/b/be/Bugzillacomments.png/750px-Bugzillacomments.png
Found it; Thanks much.
This enhancement would greatly improve the usability and value of Thunderbird, please move Compose to a New Tab thank you.
Please don't add other comments, as the team is already aware of this problem, and this is not a public chat. The reason for the feature not being added is simply that the codebase is a clusterf*ck, and the development team has not the resources for such operation - they have been allocated for other features, for example, adding an Instant Messaging client which nobody uses.
(In reply to seafood983 from comment #172) > Please don't add other comments, as the team is already aware of this > problem, and this is not a public chat. Hi seafood983, what a foxy way of adding your own comment... ;) > The reason for the feature not being added is simply that the codebase is a > clusterf*ck, and the development team has not the resources for such > operation - That much may be true - there was a gifted developer from outside who tried this and gave up because of the code complexity and personal time limits / changed priorities (see comment 154). Indeed, the development team currently does not have the manpower/resources for this. Please note that Mozilla has basically stopped to provide their manpower/finance for developing Thunderbird. So the development team are now VOLUNTEERS who dedicate their free time to advance the project. So there might be limitations of time, skill, courage, or experience to tackle this particular big feature. We are focusing more on fixing bugs, whereas this is a larger feature request. E.g., we believe it's more important to fix those bugs which will make TB unpredictable when your folder gets bigger than 4GB, where your proprietary information gets sent to the wrong recipient, or where random information from unrelated email gets sent to your recipient (we've now fixed the largest parts of all of these legacy problems for TB 38). > they have been allocated for other features, for example, adding > an Instant Messaging client which nobody uses. Seafood983, that's outdated, hence misleading information. While I personally agree with the sentiment (the time for adding the instant messaging client would have better been spent on fixing bad bugs or other important RFEs), this happened when *Mozilla (Messaging)* was still developing TB, so this is really several years ago and the current volunteer development team cannot be blamed for that in any way. Let's also be fair and acknowledge that there are other major areas of the TB UI that might be even more relevant than this RFE. E.g., the current address book has major design flaws which are much more disturbing than having to compose in separate windows (which even has some advantages depending on personal POV). At least composing generally works, whereas there are many things in AB which just cannot be done due to bugs and current design shortcomings. E.g. imagine that so far it wasn't possible to search across ALL of your address books with a single search (which was worse because of forced duplication of contacts due to other design shortcomings). We've now implemented a cross-AB for TB 38 search to address that major shortcoming. Another example: Mozilla changed their toolkit-autocomplete component. So TB did not have a choice; we had to swallow and implement the new thing for our recipient-autocomplete consumer. Combined with intentional changes of autocomplete search pattern on our side, the result was that autocomplete broke left, right, and center. We're still busy clearing the aftermath. So that's the wrong recipient stuff. The inconvenience of not having "compose in a tab" might be very small compared to sending confidential information to the wrong recipient... So this RFE is looking for a volunteer who has the skill, will, and experience to implement this; there's a WIP patch / tasks outline referenced in Comment 154... Could YOU be the hero to tackle this?
(In reply to Thomas D. from comment #173) > shortcomings). We've now implemented a cross-AB for TB 38 search to address > that major shortcoming. Typo fix: We've now implemented a cross-AB search for TB 38 to address that major shortcoming > So this RFE is looking for a volunteer who has the skill, will, TIME and > experience to implement this; there's a WIP patch / tasks outline referenced > in Comment 154... Could YOU be the hero to tackle this?
Created attachment 8601482 [details] [diff] [review] WIP patch V. 1 by Liam Zebedee Edwards-Playne (2013-02-28) FTR Here's a WIP patch, coded by Liam Zebedee Edwards-Playne, as of 2013-02-28, where he stopped working; Screenshot 3 attachment 712065 [details] has the same date but it's not immediately clear if it's showing the actual UI results of the patch or just a handmade mockup of the UI. Source: https://gist.github.com/liamzebedee/5055929 (see comment 154)
Created attachment 8601508 [details] Outline L1: Plan for moving compose into a tab (by Liam Zebedee Edwards-Playne; 2013-02-12) FTR When Liam Zebedee Edwards-Playne started to work on this bug, he made a fine plan how to get started on this, including many useful details like references to involved files etc. The snapshot of the plan was taken 2013-02-12. This is certainly helpful for anyone who wants to pick this up. I've linkified a few source files, otherwise unchanged. BMO attachment description: Outline L1: Plan for moving compose into a tab (by Liam Zebedee Edwards-Playne; 2013-02-12)
(In reply to Thomas D. from comment #176) > Created attachment 8601508 [details] > Outline L1: Plan for moving compose into a tab (by Liam Zebedee > Edwards-Playne; 2013-02-12) > > FTR > > When Liam Zebedee Edwards-Playne started to work on this bug, he made a fine > plan how to get started on this, including many useful details like > references to involved files etc. The snapshot of the plan was taken > 2013-02-12. This is certainly helpful for anyone who wants to pick this up. > > I've linkified a few source files, otherwise unchanged. > > BMO attachment description: > Outline L1: Plan for moving compose into a tab (by Liam Zebedee > Edwards-Playne; 2013-02-12) Source (snapshot dated 2013-02-12; no longer available): http://4abf.net/wiki/Moving_compose_into_its_own_tab_in_Thunderbird_-_A_coding_experience#Get_quoting_the_reply_to_work
Anyone who wants to see this bug fixed: PLEASE PLEDGE A FINANCIAL INCENTIVE for the volunteer developer who will dedicate lots of his time to implement this! -> https://freedomsponsors.org/issue/119/ There are 128 users CC'ed on this bug. But as of today, the bounty is only at 145$, which seems very small compared to the amount of work needed to implement this, and compared to the number of people cc'ed. If all of us would only pledge 15$, the incentive would go up to 2000$. Which is slightly more realistic to attract someone. (In reply to Thomas D. from comment #177) > (In reply to Thomas D. from comment #176) > > Created attachment 8601508 [details] > > Outline L1: Plan for moving compose into a tab (by Liam Zebedee > > Edwards-Playne; 2013-02-12) > [...] > Source (snapshot dated 2013-02-12; no longer available): > http://4abf.net/wiki/Moving_compose_into_its_own_tab_in_Thunderbird_- > _A_coding_experience#Get_quoting_the_reply_to_work As described by Liam Zebedee Edwards-Playne from comment #122: > Created attachment 712065 [details] > Screenshot of composition in a tab > > I've been slowly working on this feature for the past 2 weeks in my spare > time. I've been logging my progress on my wiki > http://4abf.net/wiki/Moving_compose_into_its_own_tab_in_Thunderbird_- > _A_coding_experience#Get_quoting_the_reply_to_work and on freedomsponsors > http://www.freedomsponsors.org/core/issue/119/allow-opening-compose-window- > in-new-tab-write-messages-in-tabs-writing-composing-mail. > > This feature will be completed within the next month. I like the determination of that - where there's a will, there will be a way! :)
FTR: Liam's first attempt of getting started with this (more hackish, probably, but TB is sometimes known for its affinity to hacks...): https://gist.github.com/liamzebedee/4760832
(In reply to Thomas D. from comment #173) > (In reply to seafood983 from comment #172) > > Please don't add other comments, as the team is already aware of this > > problem, and this is not a public chat. > > Hi seafood983, what a foxy way of adding your own comment... ;) Thanks for your patient answer :-) Unfortunately I don't have the specific programming skills, but I do what I can, so I've increased the sponsoring 50$ :-)
Where does one send money to support the project? I can't find it anywhere.
(In reply to KitchM from comment #181) > Where does one send money to support the project? I can't find it anywhere. Here: https://freedomsponsors.org/issue/119/allow-opening-compose-window-in-new-tab-write-messages-in-tabs-writing-composing-mail But right now the project is aborted. It's worth pledging money to attract developers, but somebody must pick it up.
(In reply to seafood983 from comment #182) > https://freedomsponsors.org/issue/119/allow-opening-compose-window-in-new- > tab-write-messages-in-tabs-writing-composing-mail > > But right now the project is aborted. It's worth pledging money to attract > developers, but somebody must pick it up. I have and idea. There are lots of freelancer "hubs" on the net (like elance.com, fl.ru and many others). We can post a job description in one of them (or several) and offer the money we collected in freedomsponsors.
Is Thunderbird abandonware?
> I have and idea. There are lots of freelancer "hubs" on the net (like > elance.com, fl.ru and many others). We can post a job description in one of > them (or several) and offer the money we collected in freedomsponsors. In order for something like this to be taken seriously as professional job, a few thousand dollars should be offered. That wouldn't be a massive amount actually - it would require each complainer on this thread to put the money where his mouth his, and offer 15/20$ (I've offered 50/75$), but unfortunately, few people did it.
> The reason for the feature not being added is simply that the codebase is a > clusterf*ck, and the development team has not the resources for such > operation - they have been allocated for other features, for example, adding > an Instant Messaging client which nobody uses. ^this. > Is Thunderbird abandonware? Sadly, yes, it is somehow. Mozilla stated some time ago that TB is "finished" and they only want to fix critical things, as they need the dev people on features that no one needs and nobody ever wanted... But still, I have some hope that one day this basic function will get implemented.
(In reply to quadronom from comment #186) > > Is Thunderbird abandonware? > > Sadly, yes, it is somehow. Mozilla stated some time ago that TB is > "finished" and they only want to fix critical things, as they need the dev > people on features that no one needs and nobody ever wanted... > But still, I have some hope that one day this basic function will get > implemented. No, it is not. I know the press has done its best to cause this impression, just because Mozilla itself is not investing the same amount of resources and statements on Thunderbird's future are just shorted to "Mozilla doesn't care". But please remember, there is a team of Mozillians working on Thunderbird. Calling it abandonware is, to me, discrediting their work. Please don't tread the rumor mill. Aside from that, such discussion is not meant for this bug. Please keep the discussion here on the point and technical. Please see comment 88 and others.
Your right. There is nothing to be gained by this type of discussion. If the programmers had been listening to the many bugzilla posts regarding problems like this, they would have fixed the problems. Or perhaps they are doing something they want to do that may not have anything to do with the users' desires. Such is the case with freeware. I would pay for the software if I thought the money would go to new needed code, but that cannot be guaranteed. It ain't WordPerfect. So I will just try to be satisfied that I have anything to use at all. Reducing our expectations is what we should all learn to do.
(In reply to KitchM from comment #188) > Your right. There is nothing to be gained by this type of discussion. If > the programmers had been listening to the many bugzilla posts regarding > problems like this, they would have fixed the problems. Or perhaps they are > doing something they want to do that may not have anything to do with the > users' desires. Such is the case with freeware. To a certain extent, of course the developers are doing what they want. There still needs to be a fun factor to developing on an open source project. But, they are also listening to the users in fixing other issues that are either critical to keep releasing Thunderbird (users want this), or also requested by various users. Fixing this specific issue is just a big amount of work, so it is of course not the number one bug someone would pick in their free time. I do still hope that we can fix this issue eventually, but please give us the time and/or find a developer willing to work on it. As this bug has collected a very high volume of comments and the bugzilla etiquette has been discussed multiple times, I'm going to restrict commenting for this bug. This of course doesn't mean I want to cut off anyone, I just don't think discussions here will be helpful in fixing the bug. You can still vote or CC yourself to get updates. If you'd like to discuss this after having read all 188+ comments, please visit the mozilla.dev.apps.thunderbird newsgroup. Thank you for your understanding!