This is an extension and contains styles and xul changes for the message header area. It polishes some, solves some, adds some. Installation at the end [*] (larger explanation of elements and comments in the explanation.txt in zip) 1.General features: -collapsed only 1 row -real toolbar with icons/txt/customiz, also in collapsed (sorta collapsed one) -other actions goes in the toolbar, some more functions under it -twisty top/left (lack of imagination.. but to be in same place +/-) -header normal/all moved in header area (other actions) -scroll moved under toolbar area (all headers) -reduce spaces in header, move some, small styles, collapsed and expanded 2.Usage and some issues: -generally ok, context menu in toolbar (also in mail toolbar) does not really hide toolbar, customize toolbar buggish, should not use -can switch styles from "other actions" for real variants preview (ignore the styles in new window). -Tag button does nothing, so you can play with it to see styles and so. 3.Bugs it touches: -bug 456168 reduce space -(bug 456754 somehow touch ..) -bug 456830 only as idea -bug 456832 the X icon is more appropriate anyway -bug 457884 twisty /same position -(bug 465138 somehow) [*]Installation The extension structure is a work one, with top folder and respective folders simply inside the zip. No jar or xpi. For those that wanna try it but don't know this, see the readme.txt inside the zip. Take it as a xul mockup rather than the real thing, although it works and some may be useful. And excuse the poor writing behind it.

This looks and feels a lot better than the current design of tb3a3 with webmail-style rounded grey borders for the buttons. Icons are a must, and I also love the option to choose between icons, icons & text, or text-only buttons. All buttons in a row (including the "more actions"-button) looks a lot neater than before. On Win XP, I like style 3 best, as it is least cluttered (borderless buttons, no border for the button bar, buttonize on mouse-over). Twisty (for toggling single-line header vs. normal headers) in the upper-left corner of preview also feels right, might need another icon (black triangle arrow up for reducing, arrow down for expanding (or vice versa?)). Customizable choice of buttons is something I'd expect of any modern application. IMO, this mockup is really promising.

This updates the xul box layout to mach newer arrangement and tweaks a bit addresses and respective bubbles. Install new, see comment1, Update, unzip and replace all stuff in folders changes: -xul boxes id's etc to mach newer (so that it works ..) -no changes in the toolbar/menu styles -addresses bubbles: * added border transparent to default address so that hover don't move/shift fields up and down adding border ! * added .emaillabel {cursor: pointer !important;} .emailDisplayButton not enough to really do it ! * replaced tango with highlight collors to go for OS colors, debatable If there is an (orange?) match for exptoolbar bubbles then it should be that, I cannot see it anymore as exptoolbar does not work for me anymore Or could be -moz-appearance: menulist in general or derivation from it -reducing again the collapsed, though maybe not the best layout anymore [have to have something to distinguish from /to ..] note: I do not test on mac or lin, some things may look odd

I really like what you've done here. I think the single line collapsed view is a little difficult to achieve. I can understand the goal of a single line, but I think the real goal should be to show as much as necessary using as little space as needed. Perhaps just two lines for the collapsed view?

1. Glad you like it. If you can use something, even better. Actually I'd rather go for a more productive exploration of such. Parallel work or "yet another vision" is not the goal here. "Need a hand?" is more of it .. 2. -I think the bubble address should actually Not have pointer cursor (it does show the bubble) while the star Should have. To be clear that star does a different thing and is not just an indicator. -Should the bubble be bit dimm or something if hascard not true? hm, maybe too many variations .. 3. About the single line, I'd say these: -considering tb2 has single line and does ok, 2lines seam big. -considering the current 3 lines variant, 2 lines may seam small. Was that introduced as a form of negotiation ? ha, ha .. I'm not convinced myself of the optimal collapsed view solution. Introducing "to:" makes collapsed and normal almost same thing. If I add a small square for tag colors there you are. Collapsed should really be a brief .. I also see them as different on vertical or classic layout. I'll see if I can do a trick for 2 lines. It was there before, but maybe the layout was not the happiest.

(In reply to comment #3) > I really like what you've done here. I think the single line collapsed view is > a little difficult to achieve. I can understand the goal of a single line, but > I think the real goal should be to show as much as necessary using as little > space as needed. Perhaps just two lines for the collapsed view? Sometimes content is more important than "convenient function" A single line collapsed header is very important in some use cases. The attachments are from a newsgroup, but they could just as well be an e-card or newsletter. Take a look at the the attachments, and judge which is more pleasing to view. Of course an F11 function would be the better solution, showing content only.

Requesting "blocking" because it's a major UI change - "wanted" OK too. Could you please make the subject line in the expanded view *bold*? Thanks!

Great work! Would like to see a similar concept with TB3.

xpi form of attachment 350481 [details], with maxversion set to 3.0b2pre for current trunk there are definitely some nice aspects to this extension.

This extension was generated using an ECLISPE/ANT build process (see attached build_headerUI.xml). The resulted XPI can be used with normal extension installation process. The maxVersion is set to : 3.0b* Please see also "explanation.txt" for how to use this extension written by the author: ovidiu

The extension is a *huge* improvement over the current trunk builds! At last, the subject line in the "show details" mode is *bold*. Thank you!!! Some remaining issues: *Hide Details mode* - The items are vertically not aligned (From & To are higher than Subject & Date) - There are two buttons for going to "show details" mode. The left one is sufficient. - Either the Subject should be on a line of its own, or remove the To info in order to maximize the Subject's space (I already know that 99% of my e-mails are to me). - It would be great to show the tags' colors as small squares somewhere (on the right?). *Show Details mode* - Style_3 looks best and is the least obtrusive, but the buttons should also have an outline when they are not hovered. - The From line it too far left (not horizontally aligned). - Please capitalize the titles (From, Subject, To, Date, Tags) - The junk button's tooltip should change to "not junk" when the e-mail is already marked as junk. - The Tag button doesn't work. - The menu item "Header Options" doesn't do anything. - All menu items should be capitalized. But overall, it's already a huge improvement. :-) Can you put these changes into the trunk please?

This is with the XPI patch from the previous post. Showing the recipient(s) in the collapsed header view is a mistake IMO. It makes the subject much too short. I suggest, nay, beg you, to remove the recipients (even if there's only one, because that'll always be "me") from the collapsed header view.

Same issue as before, only that the much more important Subject is much too short even with a single recipient that has a long name. Please eliminate the recipient.

I agree with both of Peter's statements: (1) that Gunter's/Ovidiu's extension XPI (in comment 12) is a huge improvement over default appearance; and (2) that the "To" field data should only be displayed in the "expanded" header only. And Gunter, it looks great/ works well on Linux, too. BUT, the collapsed header is still being shown with the font size "110% of system standard", and IMO this is not desirable. Why do we want the header text fields to use larger fonts than EVERYTHING else on the whole screen, when the "subject" field can easily be too long to display in a single line at this font size?

Just to make it clear: the merit for the extension belongs to Ovidiu!!! He has had those superious ideas and wrote the code. Great job. Thanks ;-) I only made that code base available as a normal extension .. nothing else. So -- also I would have some remarks with the layout and functionality of 'headerui' -- I would like to see further steps to change the TB3 features set for the new message header .. and to clear the 'old' toolbar icons/functions. Anyone of the 'core' team working on that ?? How about the status there ??

(In reply to comment #17) > .. and to clear the 'old' toolbar icons/functions. Please do not remove the existing toolbar icons. I use only those, even though I have been using the trunk builds with the header pane buttons available for months now. They are just not in a location that I prefer (or even like). Also, and equally important, the collapsed header pane (thankfully) doesn't have any buttons, so we still need the toolbar buttons anyhow. At a *minimum*, make the tootlbar buttons appear whenever the collapsed header is activated.

I think this extension was busted by checkin of bug 462684 In recent trunk builds I get: document.getElementById("messagePaneContext")NULL errors In bug 462684 checkin: - <browser id="messagepane" context="messagePaneContext" + <browser id="messagepane" context="mailContext" Anyone up to checking this out. This extension is absolutely necessary for me to fully use trunk builds.

Yep, making this change in overlay.js fixes the problem: //v1.01 - go over 3.0b1pre 20081126 03 35 45 var headerui = { onLoad: function() { // initialization code this.initialized = true; this.strings = document.getElementById("headerui-strings"); document.getElementById("mailContext") "mailContext" Vs "messagePaneContext"

(In reply to comment #20) > Yep, making this change in overlay.js fixes the problem: >... > "mailContext" Vs "messagePaneContext" Just checked with latest trunk and don't see any benefit for this change. No it's worseshowing the buttons from headerui and the 'normal' and also having two sections for the header in some situations. Recheck what you thought to have changed with headerui ...

I don't think this bug blocks tb3. Having a version of this addon on AMO would be good though.

(In reply to comment #22) > Having a version of this addon on AMO would be good though. I understand the focus on those bugs which correspond to functional BREAKAGE first, leaving even "pretty severe", L&F layout tweaks off the list. However, my *totally unqualified !!!!* opinion is different: we already experience confusing interactions between the Addon and the Trunk (Joe says "I got it!" in comment 20, and Gunter says "No you didn't!" in comment 21). And it's not just here within TB and within "almost the same" SeaMonkey-- lightning is also affected by changes in these layout elements, so it becomes a 4-ring circus with critical code hiding out on AMO-- where it's probably being "maintained" with totally incompatible, totally foreign source change control. Has Ovidiu already volunteered to take on a maintenance mess which could end up looks every bit as large as OneMan's recent headaches with FF 3.1 Tab Bar "enhancement" conflicts? There's definitely a light at then end of this tunnel-- Ovidiu and Gunter have provided it, and I'm delighted to have a way out of the extremely wasteful gray box of _nothing!_ clogging up extremely valuable vertical space. (We're all in agreement, I hope, that more and more TB users are migrating from 3x4 to widescreen layouts, making this more important than it used to be. And yet, we plan for TB 3.x to be way, way worse than TB 2.x ??) I'll conclude with tasteless analogy: So the "dark tunnel" of the message header degradation has a fresh, bright light, showing my a way out of this dark, dank, drippy place. Problem is, when I take a second look at the light, I notice that it seems to be flying towards me, at a very high rate of speed. Upcoming "Train Crash" via conflicting code seems almost inevitable-- heck, it's already happening. I fear that the interlocking authority could leave users in the lurch for weeks at a time, and all the flavors of sniffing out "TB or Seamonkey, "With or Without Lightning", and all the possible underlying official code Update versions could turn the Add-on into a nearly total nightmare.) And I ain't the brightest bulb here, but it looks a bit convoluted and messy already. So my vote would be: even if it delays TB by an extra TWO WEEKS, let's clean up the whole HeaderPanels mess NOW, and stop having all of these conflicting structures and listeners tying each all the shoe laces to shoe laces on other feet before they try "going out for run". If Gecko-2.0 and TB-4 are gonna happen "fast", then maybe we SHOULD just continue rooting around in the current mess. But I don't think that's gonna happen, I think TB3 is gonna be latest-and-greatest for a long time into the future. But I've got no basis for that SWAG, none at all. Dave, YOU are in charge here, and I'll be grateful with whatever you decide.... I just wanted to present my feelings, kinda loudly, for your consideration. :))

Sorry about small wording typos above-- I was up until 4 AM, back up at 7:30 today. I'm starting to lose it. :(

I can almost (but not quite) understand this bug not "blocking" Tb3, but to also mark it not "wanted" for Tb3 is IMO a huge mistake.

before I go to bed: Are TB/Lightning theme authors likely to get caught up in lot of extra work to handle the "pure mozilla" versus "enhanced by almost-standard, almost mandatory AMO-extension" code diffs?

(In reply to comment #25) > I can almost (but not quite) understand this bug not "blocking" Tb3, but to > also mark it not "wanted" for Tb3 is IMO a huge mistake. There's a ton of other priority work, big work, yet to be done for thunderbird 3, so I can see that additional push and energy for this issue will not likely come from drivers. On the bright side no one has said it can't be improved and it hasn't been said that patches won't be accepted. So the door is open to patches. (but there haven't been any patches) If someone submits a patch it is then possible for a reviewer to say "yes, this is acceptable" or "no, ..." For those that don't follow Bug 456168 - Headers take up too much space in new arrangement - I have uploaded a new image which shows the space impact, which is well understood but pictures help. attachment 356055 [details]

David, in line with what Rick and Peter have said, i. e. in full respect of your authority to place programming resources where they are most urgently needed... ...may I add another voice of concern that I, too, believe that it is a huge mistake to not mark this bug wanted for TB3. To put it bluntly, current rounded, big, flat "buttons" (or shall we call them clickable areas?) are an alien in TB3's design (apart from wasting even more space in the big waste-space area that the header currently is). I am not having TB as a native application to be offered functionality with the look and feel of the web, plus no flexibility at all (e.g. to go for iconized buttons without space-eating text). Rick's suggestion in comment #23 to "clean up the whole HeaderPanels mess NOW" might be an idea to consider. To this day, we cannot even select and copy multiple contacts from the header pane, or a single email address with its display name. It's obvious TB can't fix a legacy of too long a time without visible progress in TB within such a short time, but even more so, tangible improvements like they are provided by this bug are indeed a "light at the end of the tunnel" (to quote Rick). I think the improvements provided by this bug are huge, both visually and in terms of functionality. IMHO, this is too valuable to be left in the coding desert of addons, with all the code changes currently underway in TB3. Could you please make this at least "wanted TB3+"...!

(In reply to comment #21) > (In reply to comment #20) > > Yep, making this change in overlay.js fixes the problem: > >... > > "mailContext" Vs "messagePaneContext" > > Just checked with latest trunk and don't see any benefit for this change. No > it's worseshowing the buttons from headerui and the 'normal' and also having > two sections for the header in some situations. > Recheck what you thought to have changed with headerui ... All I can say is that starting at approximately: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090106 Lightning/1.0pre Shredder/3.0b2pre ID:20090106031241 The header reverted to the original large size. I'm using the un-jarred dev version, and making that change fixes it for me. That's with WinXP

(In reply to comment #28) > To this day, we cannot even select and copy multiple contacts from the header pane, or a single email address with its display name. view source and copy is the standard workaround. Can't say I've ever needed to use it. Edit message as new is another very suitable workaround if the goal is to get addresses into a new message. But this is a context menu issue - one I'd like to see, but not related to layout and so a separate bug. Probably already have bugs for them. I would add this bug is about UI polish, i.e. layout. ANd layout is hard enough, let's not add other issues in this bug please. wanted+, though desirable, won't change that fact that there are no patches. The code is there for anyone to submit patches.

(In reply to comment #30) MORE than > wanted+, !!! > won't change that fact that there are no patches. > The code is there for anyone to submit patches. Wayne, for me the question is: what is the goal for the new message pane header area?? From different postings, contributions and other discussions I saw there are "requirements" (for AB/LG), wishes etc but not a final consensus about a "final" layout AND how to change/reduce the current (TB2) toolbar layout --- or did I missed it?? There is the code proposal written by 'ovidiu', it's very much about showing alternatives and it's an extension approach. We all (??) understand we should have an modernized, streamlined toolbar and should bring the required UI ops nearer to the window/dialog in question -- the message pane. What is required is to get rid off the "the brightest bulb" (as with 'Rick Stockton's def), at least going back to TB2 layout for the messagepane header (also this would be a bad step), but better to have a more complete concept to serve all TB functions (msg, news, ab, lg, any more??) within the messagepane header. So time is running out, and FMPOV we need to have an answer for these questions: - who can define the requirements for the TB functions ?? who contribute for "his" TB function (fallen, dan, jcranmer, dmose, bienvenu, standard8)?? - is 'ovidiu headerui' the concept to guide the way for the required messagepane improvements - which toolbar elements could be removed as their functions will be on the messagepane header - should we have a "classic" toolbar beside the "modern" concept? For the patch: I never did any coding with the core products itself, only extensions. So for me: a code implementation as an extension would be possible (and I understood the same from 'ovidiu'). That finally brings the question is there a "coach" out there to support changing such an extension into the core product??

(In reply to comment #30, and comment #31) Wayne, the multi-selection request IS clearly a "different bugzilla ID", exactly as you said. But the comment is relevant here, I think, because THIS ONE is the bug in which those of us who "took a look", both competent coders and utterly non-competent people like me, have concluded that the whole header design seems like one of those 20 foot tall balls of twine which OCD farmers build in their cornfields-- held together with "paperclips, bits of old bubble gum" and etc, already turning into "slimy compost mush" at the core. That's why I requested consideration of spending some extra time on a comprehensive re-design NOW, rather than just flinging more and more little chunks of "string" onto the surface of the twineball. Again, I'm NOT a competent reviewer, but it looks to me like most of the MVC (and it doesn't even deserve that name, really) grew as an on-the-fly accident, mostly "designed" by snickers bars and coffee during various 3AM death-marches. A proposal to ask that external persons be responsible for the entire patch-- the objectives, AND the design, AND the implementation, seems likely to end up in with a lot of bad feelings, like the FF 3.1 "tab bar enhancements" have. A lot of the yelling and screaming about "why did you break that", happening AFTER various patches are DONE and their bugs are properly CLOSED/RESOLVED, could maybe have been avoided with some planning and documentation ahead of time-- a design. And yeah, "Development" is certainly allowed to do that (break things), but lack of a comprehensive data-structure design plan for TabBar features seems to have been pretty costly over there (just check out the "FF-Builds" Threads over at Mozillazine, and TPM's own forum). I think that the proposal "you write a functional Patch first, we'll review the requirements and toss most of your work Afterwards" is not good for this particular case, and it will result in code which is lower quality, more "fragile", and less extensible afterwards.But most important of all, it's almost certain to leave the initial Author feeling abused-- the "I wrote something really good, and some of the chunks you're ripping out break my heart, and I don't want to EVER work with Mozilla's core people again" syndrome. Many of the highly professional people who have authored "major" extensions, later partly diced and sliced into Firefox have FELT this, even though hardly any of them have ever TALKED ABOUT these feelings: Being highly professional, they know that (a) a lot of whining after it's over is unlikely to do any good for anybody; and (b) this sort of problem "we don't want that feature in here, rip it out" happens all the time, it's part of the job. But I'm whining NOW, ahead of time, because it might do plenty of good here. (And I will have the respect and consideration to DROP this "general" discussion with this "final" post, there will be no more flaming from me.) Even if the code somehow came out roughly the same at the end, (and it almost certainly wouldn't), I think that the the old style "requirements-and-design-first" project model is needed here, having clear and obvious advantages over the "extreme programming" approach of tossing in some code first, and then deciding what you'd like to keep later. I feel that Gunter's bullet-list of "we need to have an answer for these questions" is totally on target, well said. But per above, my impression about "coaching to help migrate extension into core" is: Hasn't much happened in Firefox and Mozilla, the "large scale" importations have nearly all been a painful mess with almost universal bad feelings among those who fought with each other, over and over and over. So hope that this one can be different-- a project in which PRIDE will be taken at the end-- not only in the final code, but also in the whole process of reaching it, with good feelings all around.

Lota coments here since I have not been around. Thank you for your interest. To clear a bit : I think there should be NO flag for this as it covers a bunch of things and it's not a normal rfe. The flags could go for parts of it like bold subject, too much space, toolbar/customizable buttons etc. Mostly under bug 456814 Please keep this constructive and let's *explore* what the header could be. Do not make this another place to push devs or criticize. That is not my goal. Just did it as extension as I got tired of mockups and asking for things and wanted to be realistic about it. And to produce something to help. Unfortunately I have no idea how to do patches now. Anyway, I would patch after this is more sane and make it into small parts as I said. After all, bigger features are explored as extensions (exptoolbar/expmes etc) and it's probably mandatory for front end. I just found out that extensions/xul are incredibly easy if know a bit of web design (Still have a lot to learn) But for xpi, I do not know yet what maintenance implies. First I'll have to have a saner setup as you have already seen. [important] To clear the idea of this bug: When the new header stuff arrived there where lots of negative reactions. So I did this in response to those reactions rather than to push devs. Cause reactions where channeled in 2 wrong directions: 1.focusing on small parts and taking them out of context, [partially cause of bug sys (so much for bugzilla prj management..) and partially cause people just do that] -Ui needs to be discussed in context. So let's explore it ;) [e.g. If I wanna have a big search line on top (exptoolbar) I'll have a small toolbar in header and so the subject will eventually go second line. And if it's bold or so you may just say it's not so bad after all..] 2.general rejection of an idea because it was not presented well enough [People wanna see tha thing not be asked to imagine and abstract. I do this every day and this is how it works] -I wanted to show all that generally may be a matter of polish and styles rather than just bad idea itself. [e.g. the buttons are not bad, but maybe you don't like the look or rigidity] ps. Thanks Günter and Wayne for xpi ver. I'll ask in extension group for your eclipse setup when I'll have time to follow. Thanks Joe for the js correction, did not see that. It does work. (Günter, may have to del the extension cache or others there, at least in Win.. or disable/enable or so ..) Peter thanks for pointing to various flaws and ideas, I have to deal with them and other changes. Rick, I hope to get SOME of the things used and not "my precious" entire thing. It happens to everybody, but I keep myself from falling in love with my ideas, I prefer people ;) [And generally, better a broken heart than an untouched one, ok?] Explanations above.

Brian, Is there an idea about the notifications under the header (scam, remote img ..)? or any change to that? that was not in the respective wiki etc (They do respect FF way though..) I'll try some changes to collapsed. I was thinking of a 1.5 line now :). With subject to seam part of body, but bumped into those notifications .. I'll try to show something as soon as possible.

(In reply to comment #21) > Just checked with latest trunk and don't see any benefit for this change.... Gunter, I rebuilt headerui.jar with this change (didn't do the whole *.xpi), and it seems to work as a good "fix" on yesterday's nightly. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090109 Lightning/1.0pre Shredder/3.0b2pre But I'm Linux, and immune to Windows Registry-based "preload-a-copy-which-might-be-stale-from-an-entirely-different-directory" issues. Would you, or anybody else, like me to rebuild the whole XPI of the *OLD* version (before ovidiu finishes his new one), and attach it to this bug? Might save some other people's time. (Easy for me.) I have another thought-- should we maybe even put it up on AMO as an "experimental"?

> Is there an idea about the notifications under the header (scam, remote img > ..)? or any change to that? that was not in the respective wiki etc (They do > respect FF way though..) The current notification bar, AFAIK, should continue to show up underneath the header. They didn't get any love or attention for tb3. > I'll try some changes to collapsed. I was thinking of a 1.5 line now :). With > subject to seam part of body, but bumped into those notifications .. Heh, slowly creeping up. :) That approach sounds interesting. If you have ideas for changing the notifications we could try to work out something better. > I'll try to show something as soon as possible. I'm really looking forward to it. Also wanted to say that I really liked your Comment #33. I don't think I could have described a better or more productive model of working on Thunderbird. The core needed to make some drastic changes, some of which may or may not be correct, but the obvious correct part is this kind of cooperation to find a working solution. It's evolution baby! And in bug 461098 I dropped a patch (attachment 356787 [details] [diff] [review]) with screenshot (attachment 356790 [details]) that might interest you. Let me know where I can help out more.

Based on 'ovidiu' headerUI I have done a little rework with his code. It's a slimer version with just icon-type 1, twisty changed to right, toolbar 'MessageHeader' customizable (but needs more rework) and adding 'tagging' etc .. (see readme.txt in XPI)

(In reply to comment #37) > Created an attachment (id=356852) [details] > headerUI.XPI -- some rework Nice gradual improvement! Some remaining issues: - The labels (from, subject, etc.) are indented too far left (wasted space) - "from" is more left, and "Subject" is way more right than the other labels - The "normal" view is too tall and causes a scroll-bar to appear (WinXP) - The "other actions..." button is taller than the other buttons and is too narrow - Make the collapsed view 2 lines tall. The 1.5 lines looks broken and crowded. - Collapsed view: remove the recipient. I already know the e-mail is to me. +--------------------------------------------------------+ | sender@pi-news.net 2009-01-14 | | *explore message header tweaks and variants for tb3* | +--------------------------------------------------------+ - The expand/collapse button icon should be a "+" and "-". - Remove the border around the buttons. Especially the curved blank space on the left of "reply" looks bad.

Comment on attachment 351875 [details] snapshot of the headers with working XPI is this ui-review? still applicable? Setting to clarkbw first as I myself am not sure...

Comment on attachment 351875 [details] snapshot of the headers with working XPI I don't think so. But most of this ui-review work is likely going to ovidiu if there is time available.

ovidiu, do you mind if I put this up in my hg source control [1]? Or do you already have it somewhere like bitbucket? And is this the latest version? I was planning on working on this a little more before the weekend. Thanks! [1] http://hg.mozilla.org/users/clarkbw_gnome.org/

Put it there. I have no other place. I think it needs maxver changed, otherwise may just work. I'd like to point to couple small small css issues I remember in this area in the default header thing, dealt with in this extension: [should I file separate bugs for such small things?] 1* .emailDisplayButton class should have a margin 1px transparent as it does have a margin on hover or click. Now this leads to small vertical shift of the from/subject/to fields when selected (try middle mouse button to see or tab to move focus) 2* remove cursor pointer from [mail-emailaddress] and leave it only for the star Currently it shows a bit of a finger cursor on the edges of the address. I find this clumsy and misleading on hover. 3* [mail-emailaddress] rounded top corners go for a little tab like feel when address context is opened with LeftMouse Click. Cute, a tabbish thing with the menu under it. But on rightClick, same popup opens following mouse coords and not aligned under the tabbish blue thing. Uh. Should we drop it? roundness? I think 1+2 have a solution in the extension css, 3 I have no idea whatta do

In reply to comment #41 -- @ Bryan W Clark (:clarkbw) Please have a look also at: http://compactheader.mozdev.org/index.html This is a very strict method to get back the "old" [+] [-] buttons in the header to switch between the new 'normal' header version (but without buttons) and the old very compact one line header (which would make a lot of people happy). Günter

I ended up rewriting most of this code into something else. I'll put up the source later tonight but for now I have a screenshot of what is happening so far: http://clarkbw.net/tmp/small-header.png

(In reply to comment #44) > I ended up rewriting most of this code into something else. I'll put up the > source later tonight but for now I have a screenshot of what is happening so > far: http://clarkbw.net/tmp/small-header.png looks nice. Is it just me or the archive word is not centered on the button (and the button could be made smaller) ?

(In reply to comment #45) > looks nice. Is it just me or the archive word is not centered on the button > (and the button could be made smaller) ? it does look off center, I'm not sure why it would be different than the others though. I'm going to try removing the ( other actions | v ) option from this compact view as well and maybe rearrange the expand / collapse action while adding the date back in. Similar to what Peter had but swapping the top and bottom lines: +------------------------------------------------------------------+ | *explore message header tweaks and variants for tb3* (buttons) | | sender@pi-news.net /to/ recipients@example.com 2009-01-14 | +------------------------------------------------------------------+

I like how this is evolving, but (as always) I am concerned about subject. how many char can be displayed? This bug for example is ~95 char in bugmail (and it isn't even very long) Is there a way to get space for ~130-150 char? Can the set of action buttons be displayed by mouseover of a much smaller area called, for example, "actions"?

(In reply to comment #44, comment #46) Bryan, is that a suggestion for re-introducing compact header? Or maybe not? Just in case you are trying this out for the default (normal-size) header, here's some problems I see: - limited length of subject problem mentioned by comment #47 - "to" caption between from and to headers is almost invisible, and it's very hard to tell to and from addresses apart when they are in the same row - personally, just the date is definitely not enough. I also need the time, and I guess most business users will More header polishing suggestions: - Bug 458635: Envelope tabbing in addresses makes unnecessary stops (star in header pane contacts shouldn't get separate focus using <tab>) - Bug 470659: Make focussed contacts actionable (pressing ENTER on contacts should open context menu, ctrl+c should copy full email address) (and, just for the record, playing with advanced ideas in bug Bug 470676) - Bug 470472: Left-Clicking on contact doesn't move focus indicator (double focus) I am also seeing weird layout in the current nightlies, with the subject and to-recipients being quite out of place, subject about 3mm below the line level of subject caption, and to-recipients about 3mm above line level of to-caption, so both are almost covering each other up. Perhaps a first stab at squashing bug 499410 and bug 511491 which both aim to get rid of wasted vertical whitespace?

(In reply to comment #48) > I am also seeing weird layout in the current nightlies, with the subject and > to-recipients being quite out of place, subject about 3mm below the line level > of subject caption This is Bug 494901

(In reply to comment #47) > I like how this is evolving, but (as always) I am concerned about subject. how > many char can be displayed? This bug for example is ~95 char in bugmail (and > it isn't even very long) > > Is there a way to get space for ~130-150 char? Can the set of action buttons be > displayed by mouseover of a much smaller area called, for example, "actions"? Good points as always. Your comment gave me the idea that I could try moving all the buttons (except the reply) into a menu popup. So maybe it would look more like this: +---------------------------------------------------------------------+ | *explore message header tweaks and variants for tb3* (reply |v) (v) | | sender@pi-news.net /to/ recipients@example.com 2009-01-14 | +---------------------------------------------------------------------+ Where the menu is something like: .-----------------. | Forward | |-----------------| | Archive | | Junk | | Delete | '-----------------' I'm also planning on trying icons instead of text but I think something like above could save even more space. (In reply to comment #48) > (In reply to comment #44, comment #46) > Bryan, is that a suggestion for re-introducing compact header? Or maybe not? > Just in case you are trying this out for the default (normal-size) header, > here's some problems I see: This is just an extension but I appreciate the comments. :) I started with the ovidiu header code but sadly I couldn't really understand what it was doing in a number of places. I started from scratch, copying pieces I could understand. I'm planning on getting to a number of the features it implemented that this doesn't however just getting the layout is tricky enough so I'm starting there. > - limited length of subject problem mentioned by comment #47 Agreed, this is a problem but I'm not seeing many solutions. If you have ideas I can try them. Subject on the bottom? I think that could get gain a little more space as it won't run into the buttons. I might try the new button layout as mentioned above. > - "to" caption between from and to headers is almost invisible, and it's very > hard to tell to and from addresses apart when they are in the same row Yeah I didn't have many options here either so suggestions are welcome. I can make the text dark but that just makes the to disappear among the addresses even more. I could add more padding on the sides so it stands out more. > - personally, just the date is definitely not enough. I also need the time, and > I guess most business users will Hmm, this isn't really up to me AFAIK though I could try. I get the date from the headers and so it shows whatever you normally see in the thread view for a date / time. > More header polishing suggestions: > - Bug 458635: Envelope tabbing in addresses makes unnecessary stops (star in > header pane contacts shouldn't get separate focus using <tab>) > - Bug 470659: Make focussed contacts actionable (pressing ENTER on contacts > should open context menu, ctrl+c should copy full email address) (and, just for > the record, playing with advanced ideas in bug Bug 470676) > - Bug 470472: Left-Clicking on contact doesn't move focus indicator (double > focus) These are good to keep track of. Sadly they are all likely out of the scope of not only what I'm capable of as a programmer (I'm just a designer!) and what this extension can do. > Perhaps a first stab at squashing > bug 499410 and bug 511491 which both aim to get rid of wasted vertical > whitespace? We've got someone helping with the current headers right now and dmose is working at moving the headers to a <grid> layout which could alleviate a lot of the random spacing issues that aren't easily solvable. Thanks for the comments!

(In reply to comment #50) > Good points as always. Your comment gave me the idea that I could try moving > all the buttons (except the reply) into a menu popup. I don't like this idea. So I have to use one mouse click more foe example to delete the message. > I'm also planning on trying icons instead of text but I think something like > above could save even more space. This would be a better solution. You can try this with the actual CompactHeader Addon (https://addons.mozilla.org/de/thunderbird/addon/13564) > (In reply to comment #48) > > Bryan, is that a suggestion for re-introducing compact header? Or maybe not? > > Just in case you are trying this out for the default (normal-size) header, > > here's some problems I see: > > This is just an extension but I appreciate the comments. But your proposal looks almost like the extension in two row configuration. > > - limited length of subject problem mentioned by comment #47 > > Subject on the bottom? I think that could get gain a little > more space as it won't run into the buttons. Again, the extension has this already. This is a good gain.

While I'm generally in favor of making the header pane as small as possible, I think the exception is the Subject. It would be so nice if this would wrap, even if it makes the header pane *occasionally* bigger (e.g. for Bugzilla mail which currently requires moving the mouse to the message list to see the tooltip, which IMO is one of the most painful things about Thunderbird). I also favor the idea of using icons in the header pane, with tooltips to describe the icons.

(In reply to comment #51) > (In reply to comment #50) > > Good points as always. Your comment gave me the idea that I could try moving > > all the buttons (except the reply) into a menu popup. > > I don't like this idea. > So I have to use one mouse click more foe example to delete the message. Reply and Delete are the most common actions so it probably makes sense to have both shown at minimum. However I always use the delete key, I don't think I ever actually click the delete button so I was just going with some personal preference. > > I'm also planning on trying icons instead of text but I think something like > > above could save even more space. > > This would be a better solution. You can try this with the actual CompactHeader > Addon (https://addons.mozilla.org/de/thunderbird/addon/13564) Yes, I saw the screenshots but I haven't tried it out yet. I don't like the icon beside the button look as it takes up much more room and I don't think it helps with anything except maybe the junk icon. Perhaps if there were better icons I would feel differently but it would still be using a lot more horizontal space. > But your proposal looks almost like the extension in two row configuration. Right, like I said in comment 3 I don't think the single row is a goal I would personally want to achieve. Instead the goal I've been looking for is more of a balance of the important information vs. space. Though I want to say cheers to the add on developer for making the single line header a lot better than the TB2 one by removing the header names and cleaning up the space. It is looking good. > > > - limited length of subject problem mentioned by comment #47 > > > > Subject on the bottom? I think that could get gain a little > > more space as it won't run into the buttons. > > Again, the extension has this already. This is a good gain. I can try this but I think working on the buttons would be my next step as it could have good gains either way. I went with subject on top originally because I'm mostly seeing the opposite problem as described. Bugs are an obvious example where the subject line is usually long and the recipient list is very short. However most other mails that I see in the wild have the opposite problem of many recipients and medium length subjects. My inbox as an example has a much greater percentage of subjects that fit within the column width than subjects that overflow. Of course the real issue is that when the subject line is long (longer than the space provided) I find I'm most likely to need to read the whole thing. "Birthday party extravaganza for the old man turning 40 this year" is a subject I don't mind if it gets truncated. Perhaps if there was an alternate widget for the recipients list that collapsed it into a very small area and used a popup like menu for the details. +--------------------------------------------------------------------+ | sender@pi-news.net /to/ you and_3_others_v_ (reply |v) (v) | | *explore message header tweaks and variants for tb3* 2009-01-14 | +---------------------------------------------------------------------+ This widget, "/to/ you and_3_others_v_" could take advantage of a rollover tooltip that showed all the recipients and onclick would act like the current "more" system to expand the list of recipients out. It could be something to try at least. It would put the subject at the bottom, allowing for the most room, and limit the recipient list area to a small and manageable size.

Ok, didn't get to the alternate recipients widget or trimmed down the message buttons but I did swap the subject and got subject wrapping working. http://clarkbw.net/tmp/subject-2nd-wrapping.png http://clarkbw.net/tmp/subject-2nd-wrapping-w-highlight.png That is a lot nicer. I'm using and HTML DIV element instead of the textbox like the old header. So with the right CSS I can still do focus and selection. I am missing the context menus but if I needed to I think I could steal them from the commonDialog http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/commonDialog.js It seems worth having to rewrite select all + copy functions in order to get subject wrapping for this. Resizing the window works just fine as the subject continues to fill available space. Maybe this weekend I could work on that recipients widget thing.

Wow, looks really promising! Maybe a "from" can be inserted before the sender address?

(In reply to comment #51) > CompactHeader Addon (https://addons.mozilla.org/de/thunderbird/addon/13564) The add-on rocks! Thanks! I've settled on the following settings in the compact view: - two rows (subject on bottom - oh well, that's the price of those damn buttons) - buttons showing: Reply, Forward, Delete (could the others be in a drop-down?) - buttons type: icons-only (no text on buttons) I think that works best and should be the default setting. I couldn't find an e-mail subject that was too long to show completely. :-) Requests/Suggestions: It would be awesome if you could find a way to also display the *Tags* in the compact view. Perhaps between the recipient and the buttons? Could you put "at" between the date and the time to make it more readable? Could you make the "maxversion" work with the nightly builds? I really hope this add-on makes it into Thunderbird per default ASAP.

Just posted some comment about the above mentioned extension (https://addons.mozilla.org/de/thunderbird/addon/13564) see here:http://forums.mozillazine.org/viewtopic.php?f=29&t=1405155&start=45 I didn't followed Bryan's work (sorry for that), but can anyone explain the difference .. seems both are doing very much the same. What would be the best of both?? Günter

Ok, the source code is up on my HG repo if anyone wants to take a look. http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/ Particularly if you're looking for the subject wrapping code you want to look at: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/file/e0da41c2b259/src/content/ovidiuheader.xul#l74 - and - http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/file/e0da41c2b259/src/skin/overlay.css#l4 I should have the context menus working soon as well so you can right click on the subject and date elements. I also have a released version of the XPI available. However this header add-on doesn't play well with other header add-ons; something we should probably change in TB to make these easier to code. http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/raw-file/tip/release/ovidiuheader.xpi

I think the other XPI has a bit more functions and config possibilities. I would recommend to coop with those authors ... both of you are on the right track!!! Günter

I don't know why but I can select all header entries in Thunderbird 3.0 beta 3 and copy them with the context menus without any problems. So there seems to be no need for this: <!--you can't get text selection from description or label, so HTML it is--> line 74 following in ovidiuheader.xul

(In reply to comment #60) > I don't know why but I can select all header entries in Thunderbird 3.0 beta 3 > and copy them with the context menus without any problems. In the Thunderbird headers we use a text input box, basically a form text input, but styled so it appears like a label. This gives you text selection and the context menu for free. However you can't get line wrapping in a text box just like you can't get it in an HTML <input> tag. In a couple of iterations of the header I had tried both a label and description element but I couldn't get them to allow both selection of text and proper line wrapping. The context menu has to be faked with this div layout but there were only two menu items needed and the code has been written other places so it is not hard to port over. I'd like to be able to use a description or label element but I tried for a good amount of time to make it happen and it doesn't seem possible. The commonDialog is the only instance I've seen where someone is doing what we need but it doesn't provide line wrapping like we need. If someone figures it out I'll rework the code but AFAIK this is the only way to do it.

This works for me: var xultmp = document.createElement("textbox"); xultmp.id = "collapsedsubjectValue"; xultmp.flex = "1"; xultmp.setAttribute("class", "collapsedHeaderValue plain"); xultmp.setAttribute("readonly", "true"); xultmp.setAttribute("multiline", "true"); xultmp.setAttribute("rows", "1"); xultmp.setAttribute("height", "15px"); xul4.appendChild(xultmp, xul4); In xul this translates to: <textbox id="collapsedsubjectValue" multiline="true" height="15px" rows="1" flex="1" readonly="true" class="collapsedHeaderValue plain"/> I don't know why, but the scroll bar does not appear. But if you click into the subject field, you can scroll with the cursor keys, mark text and copy it with the context menu.

I tried that textbox before and couldn't get it to flow the layout correctly. I tried again tonight with your example and here's what I inserted to test. XUL - <div id="collapsedsubjectValue"/> + <textbox flex="1" id="collapsedsubjectValue" + class="collapsedHeaderValue plain" + readonly="true" + multiline="true" + wraparound="true" + cols="400" + style="width:auto;"/> CSS #collapsedsubjectValue { -moz-user-select: text; -moz-user-focus: normal; font-weight: bold; color: WindowText; - display: inline; + /*display: inline;*/ +} +#collapsedsubjectValue > .textbox-input-box { + width: 100%; } There seem to be real problems getting it to only use the amount of height that is necessary. In order to force it to flow the width correctly I had to add the last CSS selector you see in the there, otherwise it would just retain whatever smallest width it last used. However as you resize the window and a subject wraps to more lines than before the textbox doesn't give this height back to the layout; instead it keeps whatever height it used. I tried adding some height:auto in various places but that didn't work. I don't think this element offers the same kind of layout as the HTML DIV; I tried to make that change but just couldn't get it to work the same. I'm not sure it's really worth saving the textbox content menu since due to the readonly status it is half items that aren't useful; undo, paste, and cut are all disabled and always will be. If we create a new context menu from the common dialog we'll just have the two items that matter; select all and copy. Can get these changes to work, feel free to grab the source code I have up there; it seems to be impossible or just out of my abilities as a xul hacker.

Adding some message tag display support early this morning. http://clarkbw.net/tmp/compact-headers-tagging-support.png I'll update my source code soon so others can take a look at how I did it. It seems that in order to get tag support working well for these headers we really need a tag notification service. I created bug 513319 to request a tag notification service that replaces the current function based update mechanism. With my patch (attachment 397320 [details] [diff] [review]) applied from bug 513319 you would get tagging support that updates as you tag messages. Without that patch new tags only show up as you select messages, not as you are viewing messages and tagging them.

(In reply to comment #64) > Adding some message tag display support early this morning. > http://clarkbw.net/tmp/compact-headers-tagging-support.png It's great to have Tags in the compact header. Thanks! But are Tags really worth using up a whole *extra* line? How about putting Tags on the top row, between the recipient and the (non-text) buttons? Most users will have 1 Tag, and having enough space for 2 Tags should cover 99% of use-cases. +-------------------------------------------------------------------------+ | bugzilla@mozilla.org* You* Important Work Personal [Reply] [Forward] | | [Bug 466025] explore message header tweaks and variants 22:05 | +-------------------------------------------------------------------------+ That way, we keep the all-important vertical space. :-)

@Comment #64 I very much appreciate the works which is done so far. See also my comment for Bug 512375 Comment #16 From Günter 2009-08-28 09:39:15 PDT Also to meet the different goals I would suggest/ask the following points: (sorry I don't have access to the nightly and can't check the patch for it) - is it possible to move the button beside the date up to the button line? I understand it's for the [other actions] menu. Placing it there is much easier to use it also with extensions like "compactHeader" and seems to me more consistent for the standard and also together with extensions. And it would free the place for tag button (see below) - about:tags: -- a message with tags should be seen as such also with that "standard compact" header. So the idea adding it is OK, but with additional line? -- pro: you can see all / con: vspace -- tags with the first line (as Peter mentioned with #65)? I would like to just add there only the 'first' from the header with something like a [+] button (twisty/shevron .. a small one) - [Tag] as separate button/icon on the header pane -- because tags are an important feature to organize things, I would like to see a direct possibility to get access to the tags popupmenu (as with the tweak "compactHeader.xpi) - last not least .. the "you" (not to repeat discussion from other places, will it be scratched to get back the 'normal' addressing info coming in with the message (a MUST for company acceptance!!!)?

(In reply to comment #66) > -- tags with the first line (as Peter mentioned with #65)? I would like to > just add there only the 'first' from the header with something like a [+] > button (twisty/shevron .. a small one) The number of tags shown should depend on the amount of available horizontal space. If the space is there, why not show all the tags? As the space becomes limited, Tags could be the first item to be shortened (and *then* show the chevron).

Good points about likelihood of more than 2 tags at a time, I'll try removing the additional line next round. I can try placing tags up in the top area though the space is cramped and I don't think it relays the right context. With the tags up by the names is looks more like a property of the name than the message. I'm going to try placing the tags beside the subject instead since they should be as likely to fit there and at worst would cause the subject to wrap if enough space wasn't available. I'll see how it goes. For now, I did a little extra hack to make removing of tags possible via the mouse. See video: http://clarkbw.net/tmp/compact-headers-selecting-and-removing-tags.html

that was a really easy swap of some code! here's what it looks like with the tags beside the subject. I feel like there is lots more horizontal room there and when the subject wraps it doesn't take a full line on the first wrap so you still get to see it all and we avoid the (more) issues in the recipients area. As a bonus because of how the (X) buttons line up you can just keep clicking to remove all the tags at once without moving your mouse.

(In reply to comment #69) > Created an attachment (id=397341) [details] > compact header w/ tags by the subject Wrong file attached? :-\

bleh, sorry. getting more coffee now!

There are some things that the CompactHeader add-on does better than the current add-on here. e.g.: - Collapse/expand button in consistent location (top-left) - Buttons can be shown as icon-only (smaller & better to recognize) - way to add tags - customizable (1 or 2 lines, icons or text button, which buttons shown) Please try https://addons.mozilla.org/en-US/thunderbird/addon/13564 Polish suggestions: http://forums.mozillazine.org/viewtopic.php?p=7378525#p7378525

(In reply to comment #72) > There are some things that the CompactHeader add-on does better than the > current add-on here. e.g.: Thanks for the suggestions! > - Collapse/expand button in consistent location (top-left) I like the size of this twisty expander in the compact header ext however I didn't like how it creates a left margin that both the subject and the addressing areas get bumped over by. The expander I have is in a consistent location (bottom-right) so I can't see changing that unless there is a better place. > - Buttons can be shown as icon-only (smaller & better to recognize) I did a little work to recognize the mode selection of the toolbar (see attachment). I now have something working which changes all the buttons into icons only if you've selected icons only for the toolbar. That feels pretty good to me and I don't have to create another set of prefs just for this header. However there is a problem that we don't have icons for this size. I suppose I could create some as I only need a few to finish things off. > - way to add tags Are people adding tags via the header? I'll have to try that extension again but I thought tagging was only available from the detailed header view and not the compact one. I'm really surprised to see people adding more functionality to the header. Are people not using the tag toolbar item now? > - customizable (1 or 2 lines, icons or text button, which buttons shown) This is where my extension would not compete very well. I'm more than willing to share my code and thoughts while I explore and I'm hoping ovidiu is still paying attention and perhaps working on his. However it seems silly for me to implement everything that extension has, when that extension provides it. The future of my extension would be to take what I consider the best designs and incorporate those. If you want customization and options you should stick with the compact header extension as it is giving you exactly that. If what you see in my extension is interesting then go ahead and try it or take my code and use it in your extension. Assuming the developer of the compact header extension chooses your default suggestions we'll end up looking very similar in the default configuration; which is very interesting.

(In reply to comment #73) > > - Buttons can be shown as icon-only (smaller & better to recognize) > > I did a little work to recognize the mode selection of the toolbar (see > attachment). sheesh, sorry about the extra mails

It's great to see header design work in progress, which I really appreciate! (In reply to comment #65) > Most users will have 1 Tag, and having enough space for 2 Tags > should cover 99% of use-cases. I'm not going to repeat discussions from elsewhere, but that sort of wild guesses should no longer form the basis of contemporary UI design. The above assumption is just completely unfounded given the lack of sustainable, large-scale usage data. However, such assumptions will become self-fulfilling prophecies because they will prolong the existence of an outdated tagging system that indeed has been designed on the basis of 1-Tag-per-message, which is a pain for any serious attempt to use individualized, message-based multiple tags as we now do it for bookmarks, web content etc. Try tagging in Firefox to see what's missing in Thunderbird (Bug 370076 - Create tags for messages by typing with the keyboard / Port Firefox tagging UI to Thunderbird...) (In reply to comment #73) > Are people adding tags via the header? Yes, Bryan, there are... ;) > I'll have to try that extension again but I thought tagging was only > available from the detailed header view and not the compact one. It's included for both types of header, but not configurable (yet). > I'm really surprised to see people adding more functionality > to the header. Are people not using the tag toolbar item now? Isn't it a good sign that people are adopting the "new header" approach of using the contextual header buttons? After all, rumour has it that main toolbar buttons are doomed to disappear... And again, in view of bug 370076, akward tagging from a distant toolbar menu is likely to become obsolete - sooner or later. Having tags always near the message for both compact and detailed header is a first small step in the right direction.

@75 Thomas GREAT, thanks for you comments. Why is it surprisingly that people really use / or would like to use the features for a messages as close as possible to the message? Yes, I also feel .. but sorry .. I recognized with many discussions with users a feature set has to come directly with the 'source' it will work for. Not only to be used, but also to be recognized to get used and get a 'normality' for it. Günter

I think it's great that people are adopting the "new header" approach. And I want to say again that it's great to see all this innovation happening in this space with new ideas and approaches. Also, if anyone has the ability I think bug 513319 really needs the eye of someone who can actually program. If you want to show tags reliably in your header extension (or any other extension) then that needs to be fixed. In the mean time I softened out the tags in the header view so they aren't so bright and eye catching. See attachment 397818 [details] for the screenshot.

(In reply to comment #77) > I think it's great that people are adopting the "new header" approach. I'm not sure that is the case. I'm using the CompactHeader add-on to minimize/eliminate the impact of the (IMO useless) buttons in the header. Hardly an "adoption". BTW: I really hope that the compact header view will be re-introduced into the default builds - ideally with non-text icons, as in the CompactHeader add-on. > And I > want to say again that it's great to see all this innovation happening in this > space with new ideas and approaches. Me too. But I think it was because the inflicted pain was so great. > In the mean time I softened out the tags in the header view so they aren't so > bright and eye catching. See attachment 397818 [details] for the screenshot. Your mock-up looks very good. I'd like to see the tags softened out even more.

(In reply to comment #78) Let's put it this way: we are all eager to see the "new header" getting better than it currently is... but yes, I fully agree with what Peter said. And it'll continue to be painful for at least as long as we cannot even choose between text / text+icon / or icon-only layout, and probably also choose which buttons (not) to show. BTW, another reason why the new header buttons are so unpleasant for the eye is that they stand out oddly because they aren't flat like all the rest of the UI - at least on Windows XP (including main toolbar buttons, some of which will survive the great purge, or not?). Couldn't you make them flat like those, with "buttonize on hover"? Really, it's striking at first sight, the raised buttons with dark-blue border look totally alien and you think like - who tacked these on? Good news: Dan Mosedale took a stab at making the header pane resizable to accomodate expanded content with less scrolling (bug 511408).

In reply to comment #79: With the CompactHeader add-on (https://addons.mozilla.org/de/thunderbird/addon/13564) you can choose between text+icon/icon-only layout of the buttons. Also you can switch on/off the buttons individually.

Providing a choice between text and icons is part of bug 505169, which in turn likely depends on bug 465138 putting the header buttons on a "real" toolbar.

(In reply to comment #78 and comment #79) Have you tried adding an option to the Compact Header view to remove the buttons instead of just icons-only? if they are actually unused I would think that makes the most sense. (In reply to comment #79) > (In reply to comment #78) > BTW, another reason why the new header buttons are so unpleasant for the eye > is that they stand out oddly because they aren't flat like all the rest of the > UI - at least on Windows XP (including main toolbar buttons, some of which will > survive the great purge, or not?). Couldn't you make them flat like those, with > "buttonize on hover"? Do you mean like the "other actions" button? The code that supports that button could be used on the regular buttons if you wanted to try them only appearing on hover. I agree that I don't like the way the drop down button looks, especially on windows but that's a toolkit issue that isn't easily solved.

Just to clarify: When speaking about "buttons" the reply, forward, archive, junk and trash buttons are considered (and not the menu button "other actions")? In the discussion about the CompactHeader add-on there was an interesting suggestion: Why not make the buttons "floating" so that they always stay at the first line of the header pane, even if you scroll downwards in the expanded header view (with all header items turn on). Could this be done somehow with a panel (https://developer.mozilla.org/en/XUL/PopupGuide/Panels, https://developer.mozilla.org/en/XUL%3apanel), in which the button box is transfered? This panel had to stay at the position of the first line of the header pane, even if the header is scrolled. On the other hand, if the header pane itself is moved around, it also has to move. I have no idea if this could work?!?

@Bryan I tried to follow your work but was not able to find a build including the ongoing work. Do you have a pointer so I can download it. I haven't hg access and so this would help me a bit more understand how to "merge" the 'compactHeader.xpi' things to the standard base Günter

I'm very aware we are late with the development/changes for the header and I don't want to add fuel to fire. But going back to the initial state of this bug and tweaks made by Ovidui you see there the [Other Actions] button was in the very first line together with the other buttons. See https://bugzilla.mozilla.org/attachment.cgi?id=351875 I don't understand why this was skipped. If it's because of the text version of the button, that text isn't required at all!! A plain button (like a pull down) equal sized with the others would do very well. And a configuration to switch icon .. text .. icon/text (as with other toolbars) would be helpful also! I'm adding a PIC to show how it could look like with icons only. That also has a button [+/-] which should be added by extensions (like the 'compactHeader') .. and that has to be placed onto the same line as well. I don't like the twisty at the left, it requires to move the cursor to much. From working with the compactHeader code it seems hard (at least for me) to add a button to the very right of the standard header buttons. Any advice here?

We really need to have separate buttons for Reply and Reply All. I know the combined button is going to confuse a lot of "normal" users. When I receive a message that was sent to multiple users, about 50% of the time I want to reply only to the sender. Since the default action in that case is to Reply All, it costs me twice the number of clicks and additional brain-power to select just "Reply" from the drop-down with the combined button. Additionally, I'm sure a lot of "normal" users will Reply All to everyone in a list when it is not warranted and without realizing it, thus annoying a lot of people. Therefore, please make separate Reply and Reply All buttons!

(In reply to comment #85) > Created an attachment (id=398109) [details] > I'm adding a PIC to show how it could look like with icons only. Great improvement! Putting the "Other Actions" menu on the same row and making it a non-text icon is a very good idea. Putting the Normal/Compact view button on the far-right is also a great idea. I'd make the + and - signs less thick though. The Tag button should either also be on the same row as the other buttons, or it should be on the same row as the tags. The Tag button also needs a better icon picture. Perhaps something like this: http://brandautopsy.typepad.com/photos/examination_room/toe_tag_color.html ;-)

@87 my fault .. I oversaw there is a standard tag symbol .. at the moment installable from the palette to the maintoolbar

(In reply to comment #86) > We really need to have separate buttons for Reply and Reply All. I know the > combined button is going to confuse a lot of "normal" users. > When I receive a message that was sent to multiple users, about 50% of the time > I want to reply only to the sender. ... > Additionally, I'm sure a lot of "normal" users will Reply All to everyone in a > list when it is not warranted and without realizing it, thus annoying a lot of > people. That's exactly why I posted Bug 511924, but proposing a slightly different solution: Need option / preference to switch off changing default values for new "reply" dropdown button (to make "reply (to sender)" the default instead of "reply all" for many recipients). It's not necessarily the combined button that is the problem, but the changing default commands of that button. Comments on this should go in bug 511924, not here. (In reply to comment #85) "Other Actions" as a large text button in the middle of nowhere never looked right, and the small icon button with down-arrow as seen in Bryan's attachment #397818 [details] uses almost no space and thus would perfectly fit on the right side of all the other buttons (that's more logically coherent as well!), as in ovidiu's original and recommended by Günter. (In reply to comment #82 and comment #83) Yes, my suggestion was to make all buttons in header pane visually look and behave like "other actions" button does now, which is what I call "buttonize on hover". (In reply to comment #82) Not sure what Bryan is trying to tell me, but I can't try or code anything yet and my idea was more like maybe Bryan or other developers could try this... ;)

(In reply to comment #84) > @Bryan > > I tried to follow your work but was not able to find a build including the > ongoing work. Do you have a pointer so I can download it. The latest source code is always available here to browse: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/file/tip/src If you wanted to get the code on your local machine you don't need hg access, you can just clone what I have. HG access would just allow you to commit to the repo. Grab the code like this: hg clone http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/ > I haven't hg access and so this would help me a bit more understand how to > "merge" the 'compactHeader.xpi' things to the standard base > Günter If you want the latest released version of the code you can grab it from here: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/raw-file/tip/release/ovidiuheader.xpi If you drag that link into the Thunderbird add-on manager window it should just install. However my header code doesn't play well with other header extensions, something I think is due to the platform implementation making it difficult to understand if the user is choosing your header or something else. So I'd recommend you disable other header extensions when you install mine. (In reply to comment #85) ovidiu also filed bug 511625 for this I believe > Created an attachment (id=398109) [details] > header design example Very cool! > From working with the compactHeader code it seems hard (at least for me) to add > a button to the very right of the standard header buttons. Any advice here? I'm not sure how to add this in either, I tried a couple different methods but couldn't seem to figure out how to get a button in there. You can add a button to the end of the line (e.g. insertafter="compactButtonBox") and it looks about the same. (In reply to comment #89) > That's exactly why I posted Bug 511924, Thanks for posting that bug! See my comments there. > (In reply to comment #85) > "Other Actions" as a large text button in the middle of nowhere never looked > right, and the small icon button with down-arrow as seen in Bryan's attachment > #397818 [details] uses almost no space and thus would perfectly fit on the right side of > all the other buttons (that's more logically coherent as well!), as in ovidiu's > original and recommended by Günter. Yes, also see bug 511625 > (In reply to comment #82 and comment #83) > Yes, my suggestion was to make all buttons in header pane visually look and > behave like "other actions" button does now, which is what I call "buttonize on > hover". This is all done in CSS, see the following sections of code for the .msgHeaderView-flat-button http://mxr.mozilla.org/comm-central/source/mail/themes/qute/mail/messageHeader.css#208 > (In reply to comment #82) > Not sure what Bryan is trying to tell me, but I can't try or code anything yet > and my idea was more like maybe Bryan or other developers could try this... ;) Heh, I could try it; don't know that I can really make it happen. We tried this once in the beginning but decided that the flat text didn't look button-y enough that people would find them. But your point is valid that they are eye catching as buttons and especially with that windows blue border around them.

@Bryan, thanks for leading the way to grap your code. Just installed on TB3.0b3 and Shredder/3.1a1pre (!!after bumping the max.version), here some comments: TB3: - with long 'from' address the 'more' it inserted, clicking that will show some more infos with the 'from', but the buttons are moving to the right, also it's clipped, how much is pending on the length of the address ... and no possibility to switch back (also noted somewhere before) - with 'compact' mode the button text is hidden, but no icons! Sh3.1: - as noted at some other place the positioning of subject/date are not correct (Gecko prob!?). Also the open/close arrows are stretched. - there are other items with the [other action]: Open in window, in tb, view source, menu sep, save as, print. Think is because of the standard code, hope this can be configured/changed. Tagging: - (now) I see using the tag service from the main-toolbar will add the tag to the selected message but doesn't update the message header shown. With our other CompactHeader.xpi we have added the tag-service with a button and that does it well! For the header data as well with the displayed header. - adding the tags to the compact header also is ok, as long as there are not too many (which will wrap the subject to two or even three lines. I would prefer to limit it to eg. 2 or three and have a button to get the whole tag menu. - also the 'x' for deleting a tag isn't necessary .. just consumes v-space .. - pointing to a tag button in the header area will change the cursor, but no further actions!??

If you want a context menu for the subject, add this to the xul file: <popup id="XXXcopyPopup" popupanchor="bottomleft"> <menuitem label="&copyCmd.label;" accesskey="&copyCmd.accesskey;" oncommand="goDoCommand('cmd_copy')"/> <menuitem label="&all.label;" accesskey="&all.accesskey;" oncommand="this.doCommand(nsMsgViewCommandType.selectAll)"/> </popup> <div id="collapsedsubjectValue" context="XXXcopyPopup" /> I couldn't get the selectAll command to work. But there is another problem: If the subject length is to long, the first line of the compact header view is shrinking. You can see it e.g. at the size of the buttons in the first line. Also this warning appears in the error console: Warning: XUL box for div element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://messenger/content/messenger.xul Line: 0

(In reply to comment #91) > @Bryan, > thanks for leading the way to grap your code. That's what it is there for, thanks for taking a look and the feedback. > Just installed on TB3.0b3 and Shredder/3.1a1pre (!!after bumping the > max.version), here some comments: > TB3: > - with long 'from' address the 'more' it inserted, clicking that will show some > more infos with the 'from', but the buttons are moving to the right, also it's > clipped, how much is pending on the length of the address ... and no > possibility to switch back (also noted somewhere before) I hadn't thought about truncating the addresses shown in the compact view, that would be something to try. > - with 'compact' mode the button text is hidden, but no icons! I only used an arrow for now. I have been thinking that a [+] / [-] like the compact header has would be good but I need a larger size icon for the space that I'm using. > Sh3.1: > - as noted at some other place the positioning of subject/date are not correct > (Gecko prob!?). I believe I've seen some bugs about this. > Also the open/close arrows are stretched. I'm pretty sure this is my problem but I've been waiting on a better solution instead of fixing what I have. > - there are other items with the [other action]: Open in window, in tb, view > source, menu sep, save as, print. Think is because of the standard code, hope > this can be configured/changed. I think those recently landed in the core. > Tagging: > - (now) I see using the tag service from the main-toolbar will add the tag to > the selected message but doesn't update the message header shown. > With our other CompactHeader.xpi we have added the tag-service with a button > and that does it well! For the header data as well with the displayed header. But AFAIK tags don't appear in the compact view with the compact header. I've been trying the extension out for a couple days now and it only seems to show tags in the detailed view (as is the default). I'll have a look through the code to see how you've setup a tag listening service. > - adding the tags to the compact header also is ok, as long as there are not > too many (which will wrap the subject to two or even three lines. I would > prefer to limit it to eg. 2 or three and have a button to get the whole tag > menu. That path seemed to difficult for me. At first I tried to choose 2 tags to show but that isn't the correct measure. Really it seems you want to "show tags until you cause the subject to wrap excessively"... something that is difficult to express in code. > - also the 'x' for deleting a tag isn't necessary .. just consumes v-space .. It does take up some extra space and could cause further wrapping of the subject but it seems useful enough (to me) to warrant it. Instead of going for the menu button to remove the tags I have a one click method and through several clicks I could delete them all. > - pointing to a tag button in the header area will change the cursor, but no > further actions!?? Ah yes, I'm waiting on the gloda facetting search. Right now you'll only see a message in your error log when you click on the tag text itself. Once the gloda faceting search lands I'll be able to open a search for messages with the tag you clicked on. For now, it doesn't do anything. (In reply to comment #92) > If you want a context menu for the subject, add this to the xul file: > <popup id="XXXcopyPopup" popupanchor="bottomleft"> > <menuitem label="&copyCmd.label;" accesskey="&copyCmd.accesskey;" > oncommand="goDoCommand('cmd_copy')"/> > <menuitem label="&all.label;" accesskey="&all.accesskey;" > oncommand="this.doCommand(nsMsgViewCommandType.selectAll)"/> > </popup> > > <div id="collapsedsubjectValue" context="XXXcopyPopup" /> > > I couldn't get the selectAll command to work. Oh sweet thanks! I can't seem to get the popup to appear for some reason but I'll keep trying it; this is really simple looking and I want to get it in. > But there is another problem: If the subject length is to long, the first line > of the compact header view is shrinking. You can see it e.g. at the size of the > buttons in the first line. I've seen this and I'm not sure why that is happening. Perhaps I need to set some kind of minimum height on the button box area so it stops getting cut off. > Also this warning appears in the error console: > Warning: XUL box for div element contained an inline #text child, forcing all > its children to be wrapped in a block. > Source File: chrome://messenger/content/messenger.xul > Line: 0 Yes, I'm not sure how to make this stop. If I don't use a text child then wrapping didn't happen automatically but there might be another solution to this.

Are you developing this add-on using Linux. You use the file chrome://messenger/skin/icons/folder-pane.png in the overlay.css. This file is only in the gnomestripe theme directory. Windows (Vista?) is using the file chrome://messenger/skin/icons/mail-toolbar-small.png for the icons (qute theme). This file mail-toolbar-small.png is also available in the gnomestripe directory. But there seem to be inconsistencies between this files. I will check if there is already a bug file in bugzilla. Otherwise I will add one...

... Bug 515091 - main-toolbar.png and main-toolbar-small.png inconsistent in themes qute, pinstripe, and gnomestrip

(In reply to comment #93) > (In reply to comment #91) > > With our other CompactHeader.xpi we have added the tag-service with a button > > and that does it well! For the header data as well with the displayed header. > > But AFAIK tags don't appear in the compact view with the compact header. I've > been trying the extension out for a couple days now and it only seems to show > tags in the detailed view (as is the default). I'll have a look through the > code to see how you've setup a tag listening service. It would be great if Tags also appeared in the compact view. Really, really great! Either find a space there for it and/or limit the number of Tags shown and/or truncate the Tags when they bump into a neighboring header and/or *display Tags as colored squares* (without text) in the compact view. Colored squares! Hmmm... :-) > > - also the 'x' for deleting a tag isn't necessary .. just consumes v-space .. > > It does take up some extra space and could cause further wrapping of the > subject but it seems useful enough (to me) to warrant it. Instead of going for > the menu button to remove the tags I have a one click method and through > several clicks I could delete them all. I don't think users will want to remove tags very often (after all, they added the tag for a reason). When will an e-mail ever become not-"Family" or not-"Work"? So I don't think the increased h-space is justified.

If you haven't seen a screenshot or tried the latest version here's an ascii art version of what I have, just to keep people updated. Average message: +------------------------------------------------------------------------+ | sender@pi-news.net /to/ you (reply |v) (forward) (...) (D) | | *explore message header tweaks and variants for tb3* 2009-01-14 | v | +------------------------------------------------------------------------+ Message with 2 tags: (subject wraps to give space) +------------------------------------------------------------------------+ | sender@pi-news.net /to/ you (reply |v) (forward) (...) (D) | | *explore message header [important|x] [personal|x] 2009-01-14 | v | | tweaks and variants for tb3* | +------------------------------------------------------------------------+ Keep in mind the size of the ascii art versus the size of your screen. This is causing the subject to wrap after 2 tags which isn't (often) the case on 1024x768. I'm working to integrate attachment 399123 [details] [diff] [review] provided by herb in comment #94, thanks for the patch! (In reply to comment #95) I've been doing most of the development on Linux and Mac and the icon situation is a little mixed up to say the least. It's likely that you'll need skins for each system in the extension. I don't remember how to do that but I'll try to make it another example in the wiki if I figure it out. (In reply to comment #96) > ... Bug 515091 Thanks for filing this! (In reply to comment #97) > It would be great if Tags also appeared in the compact view. Really, really > great! Either find a space there for it and/or limit the number of Tags shown > and/or truncate the Tags when they bump into a neighboring header and/or > *display Tags as colored squares* (without text) in the compact view. Colored > squares! Hmmm... :-) Right now I bump the subject over. I have no idea how you would truncate the tag like you're talking about but I'm sure it's possible. > I don't think users will want to remove tags very often (after all, they added > the tag for a reason). When will an e-mail ever become not-"Family" or > not-"Work"? So I don't think the increased h-space is justified. I was looking at the tags this way. Since the Thunderbird tagging system is limited I assume that most people only have a few tags (1 or 2) per message. I've been designing for tags like Important and Later that are included in the defaults. These are much more ephemeral "quick tags" to help you process mail and I don't think are designed for long term tagging, though that is possible. The other "quick tag" aspect is the 1,2,3,4,5 assignment of the tags for quickly adding and removing tags. I think it all depends on how you use tags and I don't think there is clear data pointing to one type of usage or another being dominant. The downside of this [x] is that if you don't remove tags very often you'll have an extra x or two taking up some horizontal space but that's not too much to worry about.

Just to warn others that with the patch that landed from bug 499410 your compact header extensions may break slightly. The XBL widgets have changed such that they only provide the Value element and not the Name element as well. This is likely a good thing for most compact header views. I made some changes to add in two button icons (reply and forward) for the icons + text mode and have full theme support for icons only in each platform. The header buttons watch whatever the toolbar does, there's no preference other than that. See screenshot on mac: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/raw-file/tip/release/screenshot.png Also now that gloda faceting search has landed you can click on a tag name and something will actually happen! A new tab should open up a search for messages with that tag you clicked. You can see exactly how I did this if you look at the function here: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/file/c3e886ebe59b/src/content/ovidiuheader.js#l186

Comment on attachment 399123 [details] [diff] [review] Add context menus with copy to subject and date header fields thanks for this herb! I pushed the copy context menu just a minute ago. http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/rev/d66d0bd03cf5

Regarding Reply & Reply All button(s) and text vs. image buttons, please see newly filed bug 516141 and bug 516140. PS. Try the most-awesome https://addons.mozilla.org/en-US/thunderbird/addon/13564

I think the problem described in comment 92 is depending on bug 489609 and bug bug 492645.