668998 - TB 5.0 compose pane addressing fields are ugly, and don't match style of compose window.

Status: RESOLVED DUPLICATE of bug 867166

(Thunderbird :: Theme, defect)

Description

[rocktman3]

Attachment: TB compose panes.doc

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0a2) Gecko/20110701 Firefox/6.0a2
Build ID: 20110701042007

Steps to reproduce:

Opened a compose pane.


Actual results:

An ugly compose pane opened.


Expected results:

A more elegant compose pane, such as in the 3.1.x, should be available.

Comment 1

[rsx11m]

Can you be more specific what exactly you'd like to change other than going back to the old-style composition layout? I've added a reference to your MZ thread, but some suggestion how to improve the appearance of an "empty gray space" in the address-type part of the widget would be helpful.

Comment 2

[Oliver Prygotzki]

a) The dropdown menu 'To:/Cc:/Bcc:/…' looks ugly and displaced.

b) The little 'Id-Card'-icon on the left side of the recipient input fields seems to have no function and no meaning.

Comment 3

[Andreas Nilsson (:andreasn)]

With the introduction of the better line up between the items introduced recently there is the drawback that there is now a big empty space to the left. I wonder if that could be helped with showing less amount of lines by default. Maybe only one extra line and then keep on adding more beneath it (we would still need to figure out exactly when to start adding the scrollbar though).

Comment 4

[Andreas Nilsson (:andreasn)]

Attachment: mockup of two lines only

This is under Linux, but it shows the idea of a smaller gap.

Comment 5

[rsx11m]

(In reply to comment #3)
> I wonder if that could be helped with showing less amount of lines by default. 

Judging from forum questions, many users have problems already to figure out how to add the 5th address (apparently most are using the mouse these days to get to the next line rather than finishing entering an address with the "Enter" key, which automatically gets them into the next line). Thus, reducing this to just seeing two address lines may be even more confusing (always showing the scroll bar may help as a clue, but still wouldn't show those users how to open another line if needed). Also, if you have auto-bcc/cc or reply-to addresses set, those may occupy both lines already before you get a chance to enter even the first address. Thus, for several reasons, that's not a good solution.

Comment 6

[Oliver Prygotzki]

This dropdown – with the dropdown indicator on the left (!) side BTW – is an affront!

Proposal:
0. Put the dropdown indicator on the right like any other app on MacOS X – at minimum!
1. Make the appearence an option under Preferences › Composition!
The option might be to show the dropdown on-click on the little 'Id-Card'-Icon.
2. Examine other MUAs! – how do they do it? Copy the good stuff, get rid of the **** stuff!

Comment 7

[Wayne Mery (:wsmwk)]

I'm for moving forward for a win-win, but not back to 3.x style. It seems like we should be doing something in that space - perhaps "+" widget. And I'd be for reducing the address lines for better overall appearance, dependent on improving discoverability - is there no bug for that?

Comment 8

[rocktman3]

Actually, I'm for a 3.1.x style. It's simple & effective.

Comment 9

[rsx11m]

(In reply to comment #7)
> I'd be for reducing the address lines for better overall appearance,

Changing it from a hard-wired 4 to an (equally hard-wired) 2 wouldn't help much for the reasons stated in comment #5. The initial value should be based on any headers added by default for [b]cc and reply-to/followup-to headers at least, along with some mechanism to explicitly add another line to the list and focus it. And yes, I think this should be a separate bug independent from appearance.

(In reply to comment #6)
> with the dropdown indicator on the left (!) side BTW 

It has been like that in 3.x as well, but it didn't look like a menu, rather like a button, thus the difference in appearance didn't quite make it look the same. The old design had a dark background for the selector, whereas unused fields had a plain white background and the line borders continued throughout the address-type side. This has now been replaced by the solid background, which gives the "empty" appearance when those lines aren't used, and for some reason the menu button looks nicer in Windows 7 and on Linux with its rounded corners and the more button-like appearance. A respective mockup for Windows XP was shown in bug 654686 attachment 529974 [details], if you want to revisit that idea for this part.

Comment 10

[Vincent (caméléon)]

(In reply to comment #7)
> It seems like we should be doing something in that space - perhaps "+" widget. > And I'd be for reducing the address lines

I'd love to see that too.

Comment 11

[Wayne Mery (:wsmwk)]

confirming - although it's not clear yet which direction this will take.

and to add fuel to the fire, I've just noticed that in smaller screen mode (like netbook size - actually, a laptop running remote desktop), I'm finding 3 blank address lines a quite annoying impact on (pure wasted) screen space. looks like maybe 10% of vertical space?  Do we need a additional bugs to get the needed improvements?

Comment 12

[Vincent (caméléon)]

(In reply to comment #11)
> and to add fuel to the fire, I've just noticed that in smaller screen mode
> (like netbook size - actually, a laptop running remote desktop), I'm finding
> 3 blank address lines a quite annoying impact on (pure wasted) screen space.

Completely agree with that, so marking as blocking tb-netbooks bug.

Comment 13

[rsx11m]

Two possible solutions for the "how many rows?" issue:

 * make it user-configurable by a pref, thus the user who wants to see 2 lines
   only is as happy as the one who wants 6 or 8 in the composition window;

 * make it dynamic, i.e., if n lines are needed for pre-filled cc/reply items
   and the first "To" entry, show n+1 lines on opening, then allow to expand
   with each new entry until 4 is reached, then show the scrollbar if more.

The latter would certainly be more complex as it involves dynamic changes to the listbox, but may be the most satisfactory for various use cases.

Comment 14

[Vincent (caméléon)]

Sorry, does this bug deals about :
a. the "empty gray space" (initial question) 
b. the useless 3 address line?

A clarification (and maybe a change of the bug title) is required, although solve problem "b" should also solve problem "a" (but the opposite is not true).