Thunderbird 8.0 folder view switching arrows missing

RESOLVED FIXED in Thunderbird 48.0

Status

defect
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: sfystone, Assigned: aceman)

Tracking

8 Branch
Thunderbird 48.0
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 21 obsolete attachments)

3.93 KB, image/png
Details
21.38 KB, image/png
Details
2.98 KB, image/png
Details
943 bytes, image/png
Details
21.38 KB, patch
jorgk
: feedback+
Details | Diff | Splinter Review
4.42 KB, image/png
Details
Reporter

Description

8 years ago
Posted image tb7.png (obsolete) —
User Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110930134807

Steps to reproduce:

Start up Thunderbird.


Actual results:

Between menu bar and folder view, there is no folder view scroll bar. As th8.png attached.


Expected results:

There should be a folder view bar at the top of the folder pane,  As tb7.png attached.
Reporter

Comment 1

8 years ago
Posted image tb8 (obsolete) —
Reporter

Comment 2

8 years ago
Reproduced on Solaris 11 and Fedora 15. Thunderbird 8.0
This is by design. It's available thru the view menu. and there is an extension that brings it back if your really need it (https://addons.mozilla.org/en-US/thunderbird/addon/folder-pane-view-switcher)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Depends on: 667245
Resolution: --- → WONTFIX

Updated

8 years ago
Duplicate of this bug: 701080

Updated

8 years ago
Duplicate of this bug: 701063

Updated

8 years ago
Duplicate of this bug: 702513

Comment 7

8 years ago
Per bug 667245 comment #67, apparently a user-configurable option is considered, given the overwhelmingly negative feedback received on this change, thus you may want to follow the discussion there as well.

Comment 8

8 years ago
Please restore the little arrows to change folder view. I change between views all the time and it's a pain having to go through the menu bar. Why remove perfectly good functionality? Thanks for the work on Thunderbird.

Comment 9

8 years ago
OK. I installed the extension. Works OK.
Duplicate of this bug: 701439
Can somebody rename this to "folder view arrows missing" ? THe current title is misleading (its not a scrollbar) and may lead to further duplicates. thanks.
Summary: Thunderbird 8.0 folder view scroll bar missing → Thunderbird 8.0 folder view switching arrows missing
In bug 464973, aceman is working to restore a feature (folder pane columns) that was removed in the same era as the folder view arrows in this bug. The issues are similar, namely that a feature was removed because the active developers mostly did not use it, but it had important functionality that was missed by many people.

I'd like to reopen the discussion on folder pane views UI as well, after bug 464973 lands.   Its removal got a lot of complaints, which to me indicates that the decision to remove it in the first place relied on faulty data.

From the discussions in bug 667245 which removed it (and my own experience), the arrow buttons are not ideal, and perhaps a menu dropdown would be better. In bug 464973, when the folder columns are displayed, the column header for the main area is just "Name" which is pretty self evident. Although it might be tricky, replacing that "Name" with a widget that would allow easy access to folder pane view would not take any additional space in the folder pane area, and would make the folder pane view switch much more accessible.

But that is just a suggestion. The main point of reopening this is to discuss whether we could add back in core a method to more easily switch folder pane views, which is currently an extension.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Assignee

Comment 13

5 years ago
Are we talking the "All folders" item in the screenshot, or just the arrows?
So you want a way to switch folder views quickly instead of going to View -> Folders?
From what I know some of these widgets are actually still in the TB core, they are just hidden by default. Notice patch https://bug667245.bugzilla.mozilla.org/attachment.cgi?id=548965 only sets attributes to disable them, it does not remove any xul/code.
So we could just make the widgets toggleable via a menu item (similarly to bug 464973) and disabled by default.
Assignee: nobody → acelists
Assignee

Comment 14

5 years ago
Posted patch WIP patch (obsolete) — Splinter Review
This is the infrastructure needed to make the current folder mode switcher toggleable. Now we can talk about how to make the widget better. But I do not think it is possible to put the menulist into the column header. We could put the menulist in place of the current "folderpane-title" label. If there would be a clever way to somehow reuse the menupopup id="menu_FolderViewsPopup" .
Attachment #8540975 - Flags: feedback?(kent)
Attachment #8540975 - Flags: feedback?(bwinton)
Comment on attachment 8540975 [details] [diff] [review]
WIP patch

Review of attachment 8540975 [details] [diff] [review]:
-----------------------------------------------------------------

This UI looks good to me, with a couple of nits.

But recently I decided that I could not stand the scroll arrows, and modified the standard extension to use a dropdown box instead. IMHO huge improvement! I'll post the addon as an example.

::: mail/base/content/folderPane.js
@@ +303,5 @@
>    },
>  
>    /**
> +   * Toggle displaying the folder mode swither widget above the folder pane.
> +   * @param aSetup  Set to true if the widget should be set up according

Nit: "switcher" not "swither"

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +145,5 @@
>  <!ENTITY messagePaneVertical.accesskey "V">
>  <!ENTITY showFolderPaneCmd.label "Folder Pane">
>  <!ENTITY showFolderPaneCmd.accesskey "F">
> +<!ENTITY showFolderModeSwitcherCmd.label "Folder Mode Switcher">
> +<!ENTITY showFolderModeSwitcherCmd.accesskey "F">

"F" is already used
Attachment #8540975 - Flags: feedback?(kent) → feedback+
Posted file FolderPaneSwitcher@kamens.us.xpi (obsolete) —
This is a modification of the addon with the arrows replaced by a dropdown box. IMHO, this finally makes this UI usable. I hate the arrows.

Plus I really like exposing the compact versions of the views! There is a lot of useful UI here that we have been hiding.
Attachment #8541301 - Flags: feedback?(acelists)
(In reply to Kent James (:rkent) from comment #16)
> Created attachment 8541301 [details]
> FolderPaneSwitcher@kamens.us.xpi
> 
> This is a modification of the addon with the arrows replaced by a dropdown
> box. IMHO, this finally makes this UI usable. I hate the arrows.

We tried that briefly around when we removed the UI entirely, but removed it. I don't think that's a very good spot for this feature to begin with, but I wouldn't mind seeing it in the context menu for the folder pane. While I know some people like to switch between views depending on what they're doing, I don't think that's common enough to make it take up space in the primary UI.

I'd also be ok with an off-by-default main toolbar widget for tweaking this.

> Plus I really like exposing the compact versions of the views! There is a
> lot of useful UI here that we have been hiding.

I really think we should be focusing on *reducing* the amount of UI we show, not increasing it. Rather, we should be focusing on maximizing the size of the message pane, since displaying email is the most important thing Thunderbird does. We might not easily be able to compete with Gmail, where the message takes up almost the whole screen*, but we really need to do better than we are now.

* Message tabs sort of work, but they're pretty crap right now, to be honest.
(In reply to Jim Porter (:squib) from comment #17)
> (In reply to Kent James (:rkent) from comment #16)

> 
> I really think we should be focusing on *reducing* the amount of UI we show,
> not increasing it. Rather, we should be focusing on maximizing the size of
> the message pane, since displaying email is the most important thing
> Thunderbird does. We might not easily be able to compete with Gmail, where
> the message takes up almost the whole screen*, but we really need to do
> better than we are now.
> 
> * Message tabs sort of work, but they're pretty crap right now, to be honest.

> "focusing on *reducing* the amount of UI we show"

I would agree, mainly because the folder tree is a fairly terrible piece of UI to use - lots of scrolling and difficult D+D. I don't use it anymore since QuickFolders does a way better job of navigating and showing new mails. I don't really have a better solution than using this Addon, sorry guys. I practically never click on the folder tree, and all mail movements are done with Tabs or quickMove (sort of like in postbox / nostalgy where you enter one or two letters of the folder name). 

As regards the different folder views, there too many which makes toggling between them confusing.

One thing that could improve the folder tree would be some collapsing logic (similar to folders in Windows Explorer) which hides some of the complexities of a big folder tree.
(In reply to Jim Porter (:squib) from comment #17)
> > This is a modification of the addon with the arrows replaced by a dropdown
> > box. IMHO, this finally makes this UI usable. I hate the arrows.

I agree a dropdown kind of thing is probably the best we can do with the smallest amount of wasted screen space.
(I think the compact option should be a a separate checkbox there though, like the menu has it.)

> We tried that briefly around when we removed the UI entirely, but removed
> it. I don't think that's a very good spot for this feature to begin with,
> but I wouldn't mind seeing it in the context menu for the folder pane. While
> I know some people like to switch between views depending on what they're
> doing, I don't think that's common enough to make it take up space in the
> primary UI.

It's probably underused because it's cumbersome to switch between them. What would be nice would be the ability to combine them all. I'd love to have the folder pane (be customizable into) something like this, so you don't have to switch all the time. 

 Favorite folders
 ----------------
 Inbox
 mozilla

 All Folders
 ----------------
 Account 1
 ...
 Account 2
 ...


> I really think we should be focusing on *reducing* the amount of UI we show,
> not increasing it. Rather, we should be focusing on maximizing the size of
> the message pane, since displaying email is the most important thing

In height yes, but sideways I don't think that's a problem. Reading text that's wide is not nice at all. 
(E.g. bugzilla limits width of comments to what, ~125chars, for readability.)
Assignee

Comment 20

5 years ago
(In reply to Magnus Melin from comment #19)
> would be nice would be the ability to combine them all. I'd love to have the
> folder pane (be customizable into) something like this, so you don't have to
> switch all the time. 
> 
>  Favorite folders
>  ----------------
>  Inbox
>  mozilla
> 
>  All Folders
>  ----------------
>  Account 1
>  ...
>  Account 2
>  ...
Outlooks has something like this and it is the first thing I disable :) But of course people's workflows vary:)
Assignee

Comment 21

5 years ago
(In reply to Jim Porter (:squib) from comment #17)
> I'd also be ok with an off-by-default main toolbar widget for tweaking this.
So what is the difference to the patch I have attached? The switcher widget is off-by-default and can be exposed via a menu checkbox.
(In reply to :aceman from comment #21)
> (In reply to Jim Porter (:squib) from comment #17)
> > I'd also be ok with an off-by-default main toolbar widget for tweaking this.
> So what is the difference to the patch I have attached? The switcher widget
> is off-by-default and can be exposed via a menu checkbox.

I was thinking it would make sense in the main toolbar customization dialogue. That simplifies the patch quite a bit, and I'm all for minimizing the maintenance burden of off-by-default features.
Assignee

Comment 23

5 years ago
You mean having it in the Customize palette and being able to drop it somewhere on the toolbars?
Could work, but then I do not know how to make the area above the folder tree being able to get something dropped to it (e.g. like empty toolbars expose themselves when the Customize mode is enabled).
(In reply to :aceman from comment #23)
> Could work, but then I do not know how to make the area above the folder
> tree being able to get something dropped to it (e.g. like empty toolbars
> expose themselves when the Customize mode is enabled).

I don't think we really need to make this part work. It would look a little nicer, but this is a non-default feature that only a small fraction of users will see. I imagine that having the dropdown be on the mail toolbar would be fine for most people who want this.
"I imagine that having the dropdown be on the mail toolbar would be fine for most people who want this."

I guess I don't understand why you want it there, instead of above the folder pane. Isn't UI supposed to be as close to the feature where it applies as possible? What is the objection to having it above the folder pane, when it is only enabled for those who want it?

It takes up one line in the folder pane, yes - but by having it enabled you can conveniently use the many folder views that do not take up so much space. The net effect is actually fewer lines used in the folder pane most of the time.
Comment on attachment 8540975 [details] [diff] [review]
WIP patch

Squib seems to be channelling my thoughts here, so let's turn the f? over to him…  :)
Attachment #8540975 - Flags: feedback?(bwinton) → feedback?(squibblyflabbetydoo)
(In reply to Kent James (:rkent) from comment #25)
> I guess I don't understand why you want it there, instead of above the
> folder pane. Isn't UI supposed to be as close to the feature where it
> applies as possible? What is the objection to having it above the folder
> pane, when it is only enabled for those who want it?

It's a lot less code to do it the way I suggested, and I think minimizing maintenance burden is pretty important for a feature that's not part of the default UI.
If we add it we should make it good, which is not in the main toolbar.
Given the choice, I'd rather not add the feature at all, since I think we should be focusing our limited resources to things that are in the default configuration of Thunderbird. That's not to say that all off-by-default features should be WONTFIXed, but that we need to focus on the bugs that will benefit the greatest number of users. I really don't think this bug qualifies, hence I think we should minimize the amount of work we do on it (both now and in the future).

If Thunderbird were in a state where all the primary/on-by-default features worked great, I'd be singing a different tune here. Until then, I think bugs like this are a distraction, at best.
Comment on attachment 8540975 [details] [diff] [review]
WIP patch

This isn't the way I think we should go; as I said above, I think this is a lot of code for a feature that's off by default and whose usefulness I'm honestly not sure about (I picked a single folder mode and have stuck with it forever; for finding a particular folder, I'd rather have a search field in the folder pane).

That's not to say that I'll fight tooth and nail to prevent this from landing (even though I *am* submodule owner of this area), but I'm certainly not going to encourage it.
Attachment #8540975 - Flags: feedback?(squibblyflabbetydoo) → feedback-
OK squib, you don't use this feature. Others do, including myself who uses this extensively. As far as I can tell, your argument so far has simply been "I don't use this feature, therefore it is not important and not worth even a minimum amount of effort." The feature has never worked correctly, yet with some simple changes we can make it available to our users. Some of us have found this useful, and those of us who do believe that others would find it useful if we just made this little effort to fix it. I don't understand why you are so against this.

"this is a lot of code" - huh? This is a really small patch. What code are you talking about that seems excessive?
Yes, this is quite a bit of code for something that we get for free if we use the mail toolbar's customization. I've yet to see a coherent argument in this bug for why that's not sufficient. While it might be ever-so-slightly nicer to put this above the folder pane, I don't think that's worth more than a couple lines of code. You'll note that I haven't argued that this bug should be WONTFIX (only that there are many better bugs to be working on), and that I'd be ok - if not exactly happy - with a mail toolbar-based version of this landing. Heck, I'm not even going to obstruct this bug if other people really want to push this forward (unless you count posting comments), but I'm not comfortable with giving it my rubber stamp at this time.

More generally, I'd like to see a convincing argument (preferably with some evidence) that a significant population of our users would use this feature; let's just say 5% as an arbitrary minimum*. I'm frankly tired of seeing major problems in Thunderbird linger while developers scratch their own itches. To be sure, as a volunteer for Thunderbird, I understand the desire to make things better for oneself, and that's exactly how I got started. However, it's impossible to ignore the differences in Thunderbird's developer community between then and now. When I got started, there were several full-time employees charged with improving Thunderbird. Now, we have a handful of volunteers and some paid staff (I think?) who help ensure that Thunderbird doesn't completely collapse under its own weight.

To be clear: we have no shortage of things we could be working on to improve the lives of *every* user, and it's disheartening to me to see the few developers we have left spending their time on features that will be disabled by default. I really don't believe this is the best way to benefit our users. If you feel that it's the best way, then carry on, but you'll find no support from me in this bug.

* This applies to other bugs as well as this one, and is the rule I try to use on the rare occasion I have time to write patches for Thunderbird these days. It would be great if we had ever managed to use Test Pilot to do studies about how people use Thunderbird, but we didn't.

Comment 33

5 years ago
I very much need the functionality to switch between folder views. I have many folders and many filters moving stuff into those folders. I have no convenient way to show unread messages across all folders, except to use the add-on. The add-on works well and gives me a view of only those folders with unread messages.

I do applications for a living, but not Thunderbird. I see folder views as an essential part. As an essential part, an add-on should not be required to get that. Software is about meeting diverse user needs, but also about steering users and possibly structuring what their needs are. If there were sufficient resources, I think folder views should be part of the core application, but there do not appear to be resources to accomplish that. The fact programmers in past removed the functionality because they didn't use it themselves, is too bad, but we are speaking of the present. If the code can be salvaged and pasted back in with little effort, it should be, otherwise time is better spent elsewhere. I'm happy. I have the add-on. It works real well. If the functionality gets put back it will be because someone chooses to contribute their time in that way.

I am commenting because when the functionality disappeared, I posted, complaining about it, and I'm near the top of this thread. Thanks
David: would you have an issue with the folder mode selector being on the mail toolbar (where "Get Messages", "Write", etc live)? I think it's reasonable to allow users to put this on their toolbar. My only real concern is with adding yet another set of functions to handle customization of something that's off by default.

Of course, I still think we should prioritize things that everyone will see, but I'm not going to obstruct this bug if others really believe that this is the best use of their time.

Comment 35

5 years ago
I click on the folder view arrows a lot, many times in a session. With the add-on they're visible and immediately available. I would not want to have the click path extended. I think there's an option to hide the main toolbar having FILE, EDIT, VIEW. I like my toolbar visible. But the toolbar can be customized, too. If I was going to stick folder-view arrows somewhere I would add them as a customization item to appear on the main toolbar, similar to the way navigation arrows can be put on the main toolbar through customization. Thanks for asking.
(In reply to David McDivitt from comment #35)
> If I was going to stick folder-view arrows somewhere I would add them as a customization item to
> appear on the main toolbar, similar to the way navigation arrows can be put on the main toolbar
> through customization.

This is what I'm suggesting. I think it's the best place for this widget to go.
So we are back to my comment 25 - the best place to put a UI element is as close to the affected widget as is reasonably possible, which puts it as a dropdown over the folder pane. The toolbar is farther removed from the affected widget, so is a poorer place for it. So what is the rationale for putting it there? The toolbar is already pretty full by default when you have Lightning installed, so I don't see how you can argue that there is free space there. We've already agreed that this feature will not be displayed by default, so it takes up zero space for the users that have it disabled.
(In reply to Kent James (:rkent) from comment #37)
> The toolbar is farther removed from the affected widget, so is a poorer place for it.

The bottom border of the mail toolbar *touches* the folder pane.

> The toolbar is already pretty full by default when you have Lightning installed, so I don't see
> how you can argue that there is free space there.

We are, by definition, talking about users with non-default configurations. They can add or remove widgets as they like, or even add extra toolbar rows if they run out of space. (That said, a good candidate for removal from the main toolbar would be the Tag button, since it would probably make more sense on the message toolbar. This requires making the multi-message summary have a customizable toolbar, though. Another good candidate would be to integrate the filter button with the Gloda box somehow.)

> We've already agreed that this feature will not be displayed by default, so it takes up zero space
> for the users that have it disabled.

My argument for putting this in the mail toolbar is that it lets us use the existing toolbar customization code instead of writing new code to configure a single widget that only a small percentage of users will want. I simply don't think it's worth committing yet more code to customize the UI when the existing code we have already suffices (and if it's not sufficient for you, that's part of why Thunderbird supports add-ons).
Assignee

Comment 39

5 years ago
I do agree the patch https://bugzilla.mozilla.org/attachment.cgi?id=8540975 is quite a lot of code to just toggle the visibility of the widget. It is 13KB for each of the widget, it is not shared in any way.
The same code must be duplicated e.g. for bug 464973.
I like the idea with dropping the widget onto a(ny) toolbar. I just do not think it will look nice if the only sound place it could be dropped is before "Get mail" button.

So I'll see if it is possible to make a predefined toolbar (empty by default) that only spans the width of the folder pane (so as to not leave empty space to the right of it above message pane as a standard custom toolbar would do). squib are you willing to help with this approach?
Posted image Folder-Config-Full.png (obsolete) —
I wanted to suggest rolling the view switch into the column headers, but then I found that the column headers are also now managed by an addon "Extra Folder Columns 1.1.5". 

By looking at this, I *did* realize that the other addon (Folder Pane Switcher 1.1) which only displays 2 arrows for switching views is also extremely wasteful. My proposal would be to use the code of Extra "Folder Columns 1.1.5" and extend the dropdown with the view choices, as shown on the screenshot - which I whipped up with Photoshop. The Addon adds the dropdown for adding "Unread, Total, Size" columns and could easily be used for view switching as well.

It also looks nicer as the folder column area aligns nicely with the folder column area of the thread pane.
I (In reply to Jim Porter (:squib) from comment #38)
> (In reply to Kent James (:rkent) from comment #37)
> > The toolbar is farther removed from the affected widget, so is a poorer place for it.
> 
> The bottom border of the mail toolbar *touches* the folder pane.
> 
It is not quite ideal (as the buttons in the toolbar can be rearranged, and you can have custom toolbars in between - QuickFolders and tag toolbar to name but a few) - so I think the ideal place is still the folder pane itself; but it would certainly be a good compromise from the configurability POV as users can remove it. 

I have added a screenshot that shows how it could be rolled in with a "folder columns" widget (I believe we might have had columns like this Tb3, not too sure), there is an addon that adds various information into a column header area. I personally like the extra information and having size displayed - but it would have to be configurable to be optional as some users might regard this as "clutter". 

I am aware that as a QF user myself (who never clicks or drags within the tree, although having 350+ folders) I am not as invested in making the folder pane "as tall as humanly possible" so YMMV.
Assignee

Comment 42

5 years ago
(In reply to Axel Grude [:realRaven] from comment #40)
> Created attachment 8543238 [details]
> Folder-Config-Full.png
> 
> I wanted to suggest rolling the view switch into the column headers, but
> then I found that the column headers are also now managed by an addon "Extra
> Folder Columns 1.1.5". 

That is an interesting idea! Is that a mockup only, or can you actually add the code to add those items to the small dropdown? There is already a patch in bug 464973 to fold that extension into core TB so you could build on that.

There is also a suggestion previously in this bug, to make the whole "Name" column header be a dropdown. But I don't know how to code that nicely yet. There is a possibility to make it <treecol><menulist>...</treecol> (which produces a Name label and BESIDES it the dropdown). But then we also need to override onmousedown and onclick handlers to actually allow clicks onto the dropdown because they alreay have other meanings on column headers (like change sort order or reorder columns).
(In reply to :aceman from comment #39)
> So I'll see if it is possible to make a predefined toolbar (empty by
> default) that only spans the width of the folder pane (so as to not leave
> empty space to the right of it above message pane as a standard custom
> toolbar would do). squib are you willing to help with this approach?

That part's honestly pretty trivial; just put a <toolbar> in the right spot. The only challenge would be collapsing it when it's empty. That might be doable with just CSS though, and I think I'd feel ok with something like that.

Axel's mockup might be an even better way to manage this though (but it does force you to have the column headings in order to get the mode switcher, and I'm not sure if people would like that).
Using the treecol picker as a normal menu to switch between views isn't intuitive.
The mode switcher could get a fourth button (dropdown arrow) on the right for this menu.
Assignee

Comment 45

5 years ago
(In reply to Jim Porter (:squib) from comment #43)
> That part's honestly pretty trivial; just put a <toolbar> in the right spot.
> The only challenge would be collapsing it when it's empty. That might be
> doable with just CSS though, and I think I'd feel ok with something like
> that.
Yes, it seems that currently if you add a new custom toolbar via the palette but do not drop anything to it, it gets removed when you close the palette. But that feature may depend on the toolabr being marked "custom". The one proposed here would be predefined (built-in) so may remain untouched by this feature.

> Axel's mockup might be an even better way to manage this though (but it does
> force you to have the column headings in order to get the mode switcher, and
> I'm not sure if people would like that).
The columns are made toggleable in bug 464973. But yes, it makes the switcher dependent on the headers. However, it would not take additional space. You need the widget anyway, either in the header row, or as a separate widget above the folder pane.
(In reply to :aceman from comment #45)
> (In reply to Jim Porter (:squib) from comment #43)
> > Axel's mockup might be an even better way to manage this though (but it does
> > force you to have the column headings in order to get the mode switcher, and
> > I'm not sure if people would like that).
> The columns are made toggleable in bug 464973. But yes, it makes the
> switcher dependent on the headers. However, it would not take additional
> space. You need the widget anyway, either in the header row, or as a
> separate widget above the folder pane.

Exactly. The advantage of that approach it only wastes one row and is more intuitive IMO as it is part of the folder pane box. Also, it actually looks very nice as it aligns with the column headers of the thread pane - for the "space savers" among the users maybe there is a way to make it collapsible, but it seems overkill to me. I think the choice is a simple "more control vs more space". 

And no, I did not write a patch, this was purely a photoshop exercise. In an addon I would (simply?) cloned the menuitems from view/folders into the column picker dropdown. But not sure if it is really that simple... as I had trouble finding the column picker dropdown in DOM; otherwise I would have mocked it up in DOMi.
(In reply to Richard Marti (:Paenglab) from comment #44)
> Using the treecol picker as a normal menu to switch between views isn't
> intuitive.

I disagree, semantically - actually I believe you are mixing up "intuitive" with "expected". 

Expected: a widget does only the job that it always did
Intuitive: a UI control which is used to configure a nearby UI is extended to have more control.

Also, the menu dropdown is not excessively long (and note that I put the more often used view items to the top, as column configuration is not really changed frequently). the top right of the box is a nice "dead" spot for configuration. If you wanted an extra button without unbalancing column width, you would have to place it _underneath_ that spot (and move down the top arrow of the elevator). I think combining is a nice compromise.

> The mode switcher could get a fourth button (dropdown arrow) on the right
> for this menu.

From my experience this won't fly as well - I have often experimented with different views showing
folder size
folder size + unread
folder size + count + unread

and always returned to just Folder, Size; 3 items seemed to waste too much horizontal space. So would an extra button in the columns, and it would be confusing as it might impeded on column width alignment.
Axel, okay some quibbling ;).
But your screenshot is mixing Extra Folder Columns with the folder View toggler which isn't the focus of this bug. So a extra dropmarker would be needed here.
We don't have to make it a full <toolbar>. It could be something similar to the top of the "today pane" (F11) in lightning: a dropdown and a closer, but inside the folder pane. Then make it toggleable in View | Toolbars. That should not be a lot of code. 

I also think it's good to have the folder mode showing all the time so people can get back / understand what's going on if the switch without noticing.

If it's easily closeable (= removable by one click) it could also be in there by default.
Assignee

Comment 50

5 years ago
(In reply to Richard Marti (:Paenglab) from comment #48)
> Axel, okay some quibbling ;).
> But your screenshot is mixing Extra Folder Columns with the folder View
> toggler which isn't the focus of this bug. So a extra dropmarker would be
> needed here.

But the final UI will be a mix of Extra Folder Columns (bug 464973) with the folder View
toggler (this bug) so we can design them properly at once.
Richard,

Could you make a screenshot? I cannot really imagine where you put that dropmarker (and how it would look with a scroll bar underneath it)
Posted image FolderToggle with dropdown arrow (obsolete) —
(In reply to Axel Grude [:realRaven] from comment #51)
> Richard,
> 
> Could you make a screenshot? I cannot really imagine where you put that
> dropmarker (and how it would look with a scroll bar underneath it)

This is only a quick mockup with a dropmarker.
Assignee

Comment 53

5 years ago
Comment on attachment 8543270 [details]
FolderToggle with dropdown arrow

There are no column headers in this picture. Where would they appear? Below this widget? And what does the "down" arrow contain in this proposal?
(In reply to :aceman from comment #53)
> Comment on attachment 8543270 [details]
> FolderToggle with dropdown arrow
> 
> There are no column headers in this picture. Where would they appear? Below
> this widget? And what does the "down" arrow contain in this proposal?

There is it written in this bug the column headers will be a part of this bug? In the dropdown there would be the different views. The two other arrow buttons can also be removed (I would prefer this).
Assignee

Comment 55

5 years ago
Then I somehow do not understand what is the difference to the design from comment 16.
It was only a answer to Axel's mockup and it would be looking a bit lighter (with the two arrow buttons removed) than the menulist-button from comment 16.
(In reply to Richard Marti (:Paenglab) from comment #56)
> It was only a answer to Axel's mockup and it would be looking a bit lighter
> (with the two arrow buttons removed) than the menulist-button from comment
> 16.

I think the existence of columns may be liked or disliked by some users (although would probably be thankful for the integrated view switcher). I have to agree with Kent's view that the arrows look not nice (and they are not very *intuitive* either). Given a choice I would probably prefer the drop down with clear label of current state, but as a folder column user I prefer my own solution (combined drop down).
(In reply to Richard Marti (:Paenglab) from comment #54)
> (In reply to :aceman from comment #53)
> > Comment on attachment 8543270 [details]
> > FolderToggle with dropdown arrow

> The two other arrow buttons can also be removed (I would prefer this).

++

I've used the arrows for years, and I still can't remember the order. Using the arrows to switch panes involves randomly pressing an arrow until you cycle to the page that you want, which makes no sense, as there is no natural order to these different folder views. The dropdown does this better.

Comment 59

4 years ago
So... just found this after creating bug 1164818...

Should that be considered a dupe of this now? I'm not sure of the status of this particular bug, since the Expanded Folder Columns have already been added back in, but not the arrows.

Also - I believe this should be *optional* - ie, a way to enable or disable them (via a menu entry toggle under View > Folders)...
Assignee

Comment 60

4 years ago
Yes, it looks like a dupe.
The status of this one is that there were some proposals how to do it and make it optional to also accommodate the people who want a clean UI. I hope to get to it after TB38 is released successfully.
Component: General → Folder and Message Lists
OS: Linux → All
Hardware: x86 → All

Updated

4 years ago
Duplicate of this bug: 1164818

Comment 62

4 years ago
Thanks aceman, glad to hear it...

So... any feel if there is a chance this change would be accepted for 38? Or will it have to wait for the next ESR?
I've been using my own modified version of the folder view switcher addon which has, instead of arrows, a dropdown menu with the names of the types of views available, such as "Favorite Folders", "Favorite Folders - Compact View", etc.

I used to use the arrows, and always hated them. I think they are a terrible UI. The dropdown works great.

So I think we should expose folder view selection (I use it constantly because it is convenient and useful) but would oppose doing that through arrows.

Comment 64

4 years ago
Ok with me, the dropdown does seem to make more sense.

Thanks Kent...

Comment 65

4 years ago
Oh... care to share the modified Addon? ;)
(In reply to Kent James (:rkent) from comment #63)
> I've been using my own modified version of the folder view switcher addon
> which has, instead of arrows, a dropdown menu with the names of the types of
> views available, such as "Favorite Folders", "Favorite Folders - Compact
> View", etc.
> 
> I used to use the arrows, and always hated them. I think they are a terrible
> UI. The dropdown works great.
> 
> So I think we should expose folder view selection (I use it constantly
> because it is convenient and useful) but would oppose doing that through
> arrows.

I would second that. Any way to combine this with columns for showing the folder size? Then both the folder tree and the thread pane would start on the same height.
Sorry, I seem to be repeating myself. I see that we had this whole conversation 6 months ago, see Comment 16 ff including the extension that I use. To me this feature is more important than the folder columns which we successfully argued to resurrect for Thunderbird 38. But that feature had an extension with 200,000 users which argued its importance, this one does not, so my case is weaker.

Comment 68

4 years ago
Thanks Kent... yes, definitely like the drop-down *much* better...

Did you try to get with the official Addon author to get him to incorporate the change?

Also - did you take a peek at how hard it might be to provide a way to limit the views that are presented in the drop-down? I will never use most of them...

Anyway, thanks for sharing!
Sorry, I have not had time to get the dropdown adopted in an official addon. My changes were bare minimal kludges to get it to work, it would take some hours to do it cleanly even in the addon.

Is anyone else willing to take that up?
Assignee

Comment 70

4 years ago
Sure, I am still assigned to this bug. But if anybody wants to fix it immediately, he can take it from me.
Assignee

Comment 71

4 years ago
Posted patch WIP patch v2 (obsolete) — Splinter Review
This is a reworked version. It contains the menulist and also the arrows. The whole widget is inside a toolbar that is collapsed, but can be enabled via the normal toolbar toggles, e.g. View->Toolbars->Folder Pane toolbar. Maybe it could contain some more stuff in the future. Or extensions can put more stuff in there.
So for now it does not need to use a <toolbarpalette>.

Is this an acceptable solution?
Attachment #8540975 - Attachment is obsolete: true
Attachment #8606635 - Flags: feedback?(squibblyflabbetydoo)
Attachment #8606635 - Flags: feedback?(rkent)
Attachment #8606635 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 8606635 [details] [diff] [review]
WIP patch v2

Review of attachment 8606635 [details] [diff] [review]:
-----------------------------------------------------------------

Looks pretty good, but the "Compact" options should be somehow like in the menus (with a checkbox). Otherwise you also force people to go through modes they never want.
Attachment #8606635 - Flags: feedback?(mkmelin+mozilla)
Assignee

Comment 73

4 years ago
On the other hand it could be interesting to provide this UI that behaves differently so that everybody chooses what he likes.
Comment on attachment 8606635 [details] [diff] [review]
WIP patch v2

I don't think this is right. Wouldn't we want the widget to be in the main toolbar's palette and then have this new "folder pane toolbar" point to that palette? Then you could put anything in the folder pane toolbar.

Also, I'm not a fan of anything that exposes those awful folder pane arrows again. As mentioned earlier in this bug (e.g. comment 63), a dropdown would be much nicer. If we're trying to promote usage of this again, we really need a better UI. While I'm still not convinced this is worth our time, if we do it, we should do it right.
Attachment #8606635 - Flags: feedback?(squibblyflabbetydoo) → feedback-
Comment on attachment 8606635 [details] [diff] [review]
WIP patch v2

Obviously I like the idea :)

I agree with squib that we should not expose the arrows at all.

We've already had this discussion about the location, main toolbar versus above the folder pane. I'm not sure we can ever resolve this. I don't find comment 38 persuasive:

"My argument for putting this in the mail toolbar is that it lets us use the existing toolbar customization code instead of writing new code to configure a single widget that only a small percentage of users will want."

It seems to me that the code is already written, is not that extensive, and we should put the toolbar in the optimal location for the best user experience, which is above the folder pane.

But while we are talking "toolbar", from the user perspective this is not a toolbar, it is just a single user interface element. So I would not include its options in the toolbars menu, but in the Layouts menu just like Folder Pane Columns.

As for the "Compact Views", I was surprised when I first tried this, as I did not know these existed. Now I find that I appreciate both views and like being able to choose. There are only seven items in the dropdown, it is not hard to choose.
Attachment #8606635 - Flags: feedback?(rkent) → feedback+

Updated

4 years ago
Attachment #8541301 - Flags: feedback?(acelists)
One more point: It would be good to see an implementation where the dropdown was in the main toolbar so that I could evaluate that option directly.
Assignee

Comment 77

4 years ago
(In reply to Kent James (:rkent) from comment #75)
> It seems to me that the code is already written, is not that extensive, and
> we should put the toolbar in the optimal location for the best user
> experience, which is above the folder pane.
> 
> But while we are talking "toolbar", from the user perspective this is not a
> toolbar, it is just a single user interface element. So I would not include
> its options in the toolbars menu, but in the Layouts menu just like Folder
> Pane Columns.
As I said, maybe it is one element today, but it could contain more in the future.
If I do not make it a toolbar, it would require the extensive code to maintain the state of the element. See the previous patch of 14KB.

> As for the "Compact Views", I was surprised when I first tried this, as I
> did not know these existed. Now I find that I appreciate both views and like
> being able to choose. There are only seven items in the dropdown, it is not
> hard to choose.
They are "hidden" behind the "compact view" checkbox in the view Menu. The combination of that checkbox and the view name produces the particular variant of a view. Currently in the new menulist you have a flat list of all view available.
"If I do not make it a toolbar, it would require the extensive code to maintain the state of the element."

Fine, make it a toolbar, that is an implementation detail that has nothing to do with where the option to turn it on or off should exist. I was addressing where the option is exposed in the UI. It should be exposed next to the Folder Pane Columns option.
(In reply to Kent James (:rkent) from comment #78)
> Fine, make it a toolbar, that is an implementation detail that has nothing
> to do with where the option to turn it on or off should exist. I was
> addressing where the option is exposed in the UI. It should be exposed next
> to the Folder Pane Columns option.

I don't agree with that at all. Regardless of the implementation, this is fundamentally a toolbar (i.e. a box that holds some widgets to provide faster access to some commonly-used functions). I would certainly expect this to be listed alongside the other toolbars.

It might make sense to provide the ability to show/hide this by right-clicking on an empty row of the folder pane, though. That would be similar to how you can enable/disable the main toolbar by right-clicking on it or the tab bar.
Assignee

Comment 80

4 years ago
(In reply to Kent James (:rkent) from comment #78)
> "If I do not make it a toolbar, it would require the extensive code to
> maintain the state of the element."
> 
> Fine, make it a toolbar, that is an implementation detail that has nothing
> to do with where the option to turn it on or off should exist. I was
> addressing where the option is exposed in the UI. It should be exposed next
> to the Folder Pane Columns option.

It has everything to do with where the turning on is. If it is a toolbar and uses existing infrastructure it can only be toggled in view->toolbars. So it depends on how much code we are ready to add to have the toggle elsewhere. Unless squib comes up with something clever.
Yes, we sacrificed that much code for the folder columns, because it couldn't be a toolbar. But here we have more options.
Assignee

Comment 81

4 years ago
Posted patch WIP patch v3 (obsolete) — Splinter Review
Quick hack to offer the widget also for main toolbar.
Attachment #8606692 - Flags: feedback?(rkent)

Comment 82

4 years ago
Thanks aceman!!

Any chance you could address this question of mine from comment 68:

> Also - did you take a peek at how hard it might be to provide a way to limit
> the views that are presented in the drop-down? I will never use most of
> them...

If this is hard to do I totally understand, but it sure would be something nice to have if it isn't too difficult, since you're currently in the mood to hack on this a little...

:)

Thanks again!
Assignee

Comment 83

4 years ago
(In reply to Charles from comment #82)
> > Also - did you take a peek at how hard it might be to provide a way to limit
> > the views that are presented in the drop-down? I will never use most of
> > them...
> 
> If this is hard to do I totally understand, but it sure would be something
> nice to have if it isn't too difficult

Theoretically it would be easy. There is an internal array of mode names that are available. Filtering the array before building the menulist would be easy. The hard part is how to allow the user to edit the list without much code and visual clutter:) All of this must be seamless and ideally invisible to users in the default state (otherwise the UI guys don't like it). That is why we argue in several comments about the code size of this feature and "appearance complexity".
I think it way already said that with the current ~7 modes "it is not that much". If there would be 20 we should start thinking about that user filter. Are there any extensions adding new modes?

Comment 84

4 years ago
Hi aceman,

Thanks for peeking at this!

(In reply to :aceman from comment #83)
> Theoretically it would be easy. There is an internal array of mode names
> that are available. Filtering the array before building the menulist would
> be easy. The hard part is how to allow the user to edit the list without
> much code and visual clutter:)

Understood - but I would be TOTALLY fine with something that I'd have to do in user.js (or maybe userChrome.css? or somewhere else?) - and that the changes would require a restart...

> I think it way already said that with the current ~7 modes "it is not that
> much". If there would be 20 we should start thinking about that user filter.
> Are there any extensions adding new modes?

Not that I know of, and since we now have a drop-down, it isn't nearly as big of an issue (much easier to ignore the unwanted entries in a drop-down than it is to have to cycle through them constantly with the arrows)...

But, *if* I could limit the views to just the ones I want to use, I'd prefer the arrows... ;)

Also, I do have some bugs opened to add features to the Unified Folders - one providing the ability to permanently pin the 'Favorites' view to the top of the folder pane above your mail accounts, another to allow pinning multiple views (ie, Favorites and Unread), another to allow creation of *new* Views (although, after adding that enhancement request, I realized I could just create a Saved Search and add it to my Favorites, essentially accomplishing the same thing) - as well as a final one to rename 'Unified' folders back to 'Smart' folders (I still don't understand the rationale of changing that - it doesn't make any sense to call them 'Unified folders', and then also have a 'Unified' view. 'Smart' folders makes much more sense to me.

Comment 85

4 years ago
Sorry for asking very late in the discussion:
Why is there more to it than this:
  #folderPaneHeader, #abDirTreeHeader {
    display: -moz-box !important;
  }
This is what I've had in userChrome.css for a long time.
This un-hides what was hidden in bug 667245.

I guess what it proposed here is more elaborate, so that's why it has never landed ;-(
Assignee

Comment 86

4 years ago
The problem is your solution unconditionally shows the widget. But we want to have it toggleable and hidden by default. That is why all the discussion about how to implement that.

But it does not mean it will not land. There are patches available and I am working on it.

Comment 87

4 years ago
Comment on attachment 8606692 [details] [diff] [review]
WIP patch v3

No one asked me, but I'll give my opinion anyway ;-)
I like it! The pull-down is  better than the arrows where you had to cycle through the different folder views. I hope it lands soon.
Attachment #8606692 - Flags: feedback+

Comment 89

4 years ago
Hi Jorg,

Have you had a chance to look at adding some user prefs for editing the list of displayed Smart Folders?

Can't wait to try this out... thanks again!

Comment 90

4 years ago
(In reply to Charles from comment #89)
> Have you had a chance to look at adding some user prefs for editing the list
> of displayed Smart Folders?

This is not "my" bug, it's Aceman's, so I'm the wrong person to talk to. I've just recently come across the bug and took the liberty to post a screenshot to create some movement ;-)

I don't really understand the question: "edit the list of displayed smart folders". I thought the list is fixed (as shown in the picture) and you select the view you want.

Comment 91

4 years ago
Sorry for the mixup Jorg...

Read comment 82 and 83... basically I want to be able to limit the list of available/choices presented in the list of 'Unified Folders'... I will never use most of them, and I don't like unnecessary clutter... ;)
Assignee

Comment 92

4 years ago
I don't know what the "list of Unified folders" is, but we discussed hiding some of the folder modes in those 2 comments. I think we should not add more features to this bug now or it will never pass review :) Please open a new bug for your feature proposal. You can also copy my comment 83 to that new bug :)
Assignee

Updated

4 years ago
Attachment #8606692 - Flags: feedback?(squibblyflabbetydoo)
Attachment #8606692 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 8606692 [details] [diff] [review]
WIP patch v3

Review of attachment 8606692 [details] [diff] [review]:
-----------------------------------------------------------------

This seems ok, but see my comments below.

::: mail/base/content/folderPane.js
@@ +147,5 @@
>        // This is ok.  If we've already migrated we'll end up here
>      }
>  
> +    for (let i = 1; i <=2; i++) {
> +    let modeSelector = document.getElementById("folderview-mode-selector"+((i==2)?i:""));

I think it'd make more sense to set a class for each element and use document.getElementsByClassName here.

@@ +424,5 @@
>      this._updateCompactState(this._mode);
>  
>      // Accept the mode and set up labels.
> +    document.getElementById("folderview-mode-selector").value = this._mode;
> +    document.getElementById("folderview-mode-selector2").value = this._mode;

Likewise here.

::: mail/base/content/mailWindowOverlay.xul
@@ +3272,5 @@
>      <toolbarbutton id="button-appmenu"
>                     class="toolbarbutton-1 button-appmenu"
>                     label="&appmenuButton.label;"
>                     tooltiptext="&appmenuButton1.tooltip;"/>
> +                <toolbaritem id="folderpane-mode-selector2"

This could use a better name, e.g. "toolbar-folderpane-mode-selector"? Also the indentation seems messed up.
Attachment #8606692 - Flags: feedback?(squibblyflabbetydoo) → feedback+
Assignee

Comment 94

4 years ago
Posted patch patch v3.1 (obsolete) — Splinter Review
Thanks, converted to class.
Attachment #8606635 - Attachment is obsolete: true
Attachment #8606692 - Attachment is obsolete: true
Attachment #8606692 - Flags: feedback?(rkent)
Attachment #8606692 - Flags: feedback?(mkmelin+mozilla)
Attachment #8672737 - Flags: review?(squibblyflabbetydoo)
Attachment #8672737 - Flags: feedback?(rkent)
Comment on attachment 8672737 [details] [diff] [review]
patch v3.1

Review of attachment 8672737 [details] [diff] [review]:
-----------------------------------------------------------------

I still think the compact versions should be separated like in the menu. Very few people likely want to use more than one compact/full modes, and this is forcing them in the face of everyone.

Comment 96

4 years ago
Magnus, can you please post a screenshot to explain what you mean.
What I mean is that I don't like how the compact views are in there with the rest. 
Haven't thought how widgets support that in this scenario, but compare to the View | Folders | ... menu. You get to choose view, and compact is just an option.
Comment on attachment 8672737 [details] [diff] [review]
patch v3.1

Looks great, thanks!

On the Compact version issue of comment 95:

Recently I have stopped using compact views, always preferring the normal view. I keep changing my mind about their value. However, if I were using compact views, it is important that you can switch quickly between views. The proposed dropdown allows you to switch between one non-compact view and a different but compact view in a single operation (Navigate to dropdown arrow, click, select new mode, click) which is important.

In the main menu, it requires two passes at the menu to switch from, for example, Recent Folders (Compact) to Favorite Folders (non-compact). To make matters worse, every time that you switch to the All Folders menu (which is an essential view), the compact mode is lost. Re-enabling it requires two iterations on the menu. The practical effect of that is that the compact mode is effectively unusable, so nobody would use it.

But I find the current dropdown cluttered with both kinds of views listed, which I think it what Magnus is objecting to. I can live with the current clutter and prefer that to either the current situation, or say dropping Compact completely. It might help though to present the folders in a different order, with all of the non-compact first, perhaps followed by a separator line, then the Compact version, like this:

All Folders
Unread Folders
Favorite Folders
Unified Folders
-------------------
Unread Folders - Compact View
Favorite Folders - Compact View
Recent Folders - Compact View

I don't feel strongly about this though. Given the doubts of some people about how much value this has in the first place, I'm not sure additional effort optimizing this is worth it.
Attachment #8672737 - Flags: feedback?(rkent) → feedback+
Assignee

Comment 99

4 years ago
(In reply to Kent James (:rkent) from comment #98)
> I don't feel strongly about this though. Given the doubts of some people
> about how much value this has in the first place, I'm not sure additional
> effort optimizing this is worth it.

Exactly. I do not like the checkbox to switch the compact mode. I would not like to implement it in this new menulist. I think this new widget may actually gain value by behaving differently than the main menu so that everybody can choose which UI suits them.

To the sorting problem, I think there could be some value having "mode" and "mode - compact" sorted together so that user actually sees, there are 2 versions. But I have no problem if we can decide on some other order, e.g. what you propose. As long as it can be sorted automatically by some algorithm.

Comment 100

4 years ago
(In reply to :aceman from comment #99)
> I do not like the checkbox to switch the compact mode. 
Me either.

"View > Folders" looks nice, but it's a pain to use since you need to visit the menu twice to get what you want. User-un-friendly!! (IMHO we should fix that as well while we're here.)

Comment 101

4 years ago
(In reply to Charles from comment #84)
> Also, I do have some bugs opened to add features to the Unified Folders -

Providing bug numbers since I failed to do so before, and in hopes that someone might take an interest in one or more...

> one providing the ability to permanently pin the 'Favorites' view to the top
> of the folder pane above your mail accounts,

Bug 1163562 - Pin Favorites to the top of the Folder Pane

> another to allow pinning multiple views (ie, Favorites and Unread),

Bug 1163555 - Allow 'Pinning' (and re-ordering) one or more 'Unified Folders' views to the top of the Folder Pane

> another to allow creation of *new* Views (although, after adding that
> enhancement request, I realized I could just create a Saved Search and
> add it to my Favorites, essentially accomplishing the same thing)

Duped the original bug 1159716 to this one:
Bug 1159713 - Allow customization of choices in View > Folders (Unified Folders)

> - as well as a final one to rename 'Unified' folders back to 'Smart'
> folders (I still don't understand the rationale of changing that -
> it doesn't make any sense to call them 'Unified folders', and then
> also have a 'Unified' view. 'Smart' folders makes much more sense
> to me.

Bug 1163567 - Change 'Unified Folders' name back to 'Smart Folders'

Hope someone else who may be able to do something about it finds one or more of these useful...
(In reply to Jorg K (GMT+2) from comment #100)
> "View > Folders" looks nice, but it's a pain to use since you need to visit
> the menu twice to get what you want. User-un-friendly!!

That "compact view" isn't remembered when switching to Unified is of course a bug (but not this bug).
Comment on attachment 8672737 [details] [diff] [review]
patch v3.1

Review of attachment 8672737 [details] [diff] [review]:
-----------------------------------------------------------------

Looking at this more closely, I'm a little confused as to why there are two instances of the folder view picker. I also agree with Magnus that the current layout of views could use some work. Either use a checkbox like we do elsewhere (I think I'd prefer this), or at least put all the compact views together, like Kent suggests.

::: mail/base/content/mailWindowOverlay.xul
@@ +3319,5 @@
>      <toolbarbutton id="button-appmenu"
>                     class="toolbarbutton-1 button-appmenu"
>                     label="&appmenuButton.label;"
>                     tooltiptext="&appmenuButton1.tooltip;"/>
> +                <toolbaritem id="toolbar-folderpane-mode-selector"

The indentation on this is messed up...

::: mail/base/content/messenger.xul
@@ +326,5 @@
> +                       customizable="true"
> +                       align="start"
> +                       mode="full"
> +                       collapsed="true">
> +                <toolbaritem id="folderpane-mode-selector"

Why do you need this here when you have the same thing in the <toolbarpalette>? I thought the idea was that this toolbar would use all the same buttons at the main toolbar. That way, you could add the folder views menu, or say, the folder location menu instead.
Attachment #8672737 - Flags: review?(squibblyflabbetydoo) → review-
Comment on attachment 8672737 [details] [diff] [review]
patch v3.1

Review of attachment 8672737 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +164,5 @@
>  <!ENTITY recentFolders.accesskey "R">
>  <!ENTITY compactVersion.label "Compact View">
>  <!ENTITY compactVersion.accesskey "C">
> +<!ENTITY folderPaneBar.label "Folder Pane Toolbar">
> +<!ENTITY folderModeSwitcher.label "Folder Mode Switcher">

I think it would also make sense to drop the "Switcher" in this name. Either call it "Folder Modes" or "Folder Views". We don't label our reply button as "Reply Button". :)

The latter has the benefit of being closest to what the feature is "called" now, since you get to it from View -> Folders, and matches with the "Mail Views" toolbar button.

Comment 105

3 years ago
This bug has gone very quiet again. Will we ever get this feature *back* (since we once had it!!).
Assignee

Comment 106

3 years ago
I think I have all the mentioned problems solved (double occurrence of the list, labels, sort order of the modes). Now I need to find a way how to access the menulist and populate the items. It seems when it is in the palette and not put on a toolbar, it is not findable via document.getElementById(). On the other hand, populating it at onpopupopen doesn't seem very efficient to me. But I know we do that often.
Assignee

Comment 107

3 years ago
Posted patch patch v4 (obsolete) — Splinter Review
This should work now. The only ugly part is that I had to put a toolbarspring into the new toolbar so that when it is empty, it appears when going into Customize palette. It is not high enough, but better than invisible. Is there a better way to do it?
Attachment #8672737 - Attachment is obsolete: true
Attachment #8729860 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8729860 [details] [diff] [review]
patch v4

Review of attachment 8729860 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good overall, but I think you could simplify the logic for initFolderModeSelector.

::: mail/base/content/folderPane.js
@@ +442,5 @@
>  
>      return this.baseMode(aMode) + (aCompact ? "_compact" : "");
>    },
>  
> +  initFolderModeSelector: function() {

This should probably have an underscore at the beginning to indicate it's a private method.

@@ +454,5 @@
> +                     let bValue = allModes.indexOf(b);
> +                     if (b.endsWith("_compact"))
> +                       bValue += allModes.length;
> +                     return aValue - bValue;
> +                   });

This could be simplified (both in code clarity and asymptotic complexity):

    let modeItems = [], compactModes = [];
    for (let mode of this._modeNames) {
      let array = mode.endsWith("_compact") ? compactModes : modeItems;
      array.push(mode);
    }
    modeItems.push(...compactModes);

In fact, you could drop the last line and just have two separate arrays: one for full, and one for compact. That would make it a lot easier to determine where to put the <menuseparator> below.

@@ +461,5 @@
> +    // Can't use modeSelector.removeAllItems() here as it would remove the menupopup too, with its attributes.
> +    while (modeSelector.menupopup.hasChildNodes())
> +      modeSelector.menupopup.lastChild.remove();
> +
> +    let firstSepar = true;

I'd prefer "firstSep" to "firstSepar"; I read this as "firstSpear" initially and was very confused. "sep" is a common abbreviation for "separator" though.

@@ +481,5 @@
> +      if (mode == currentMode)
> +        item.setAttribute("checked", "true");
> +      else
> +        item.setAttribute("checked", "false");
> +    }

Continuing from my previous comment, you could pull the body of this loop out into a helper function and then do this:

    for (let mode of fullModes)
      appendMode();

    if (fullModes.length && compactModes.length) {
      modeSelector.menupopup.appendChild(
        document.createElement("menuseparator")
      );
    }

    for (let mode of compactModes)
      appendMode();

@@ +484,5 @@
> +        item.setAttribute("checked", "false");
> +    }
> +  },
> +
> +  selectModeInSelector: function(aMode) {

This should also have an underscore at the beginning to indicate it's a private method.
Attachment #8729860 - Flags: review?(squibblyflabbetydoo) → review-
(In reply to :aceman from comment #107)
> Created attachment 8729860 [details] [diff] [review]
> patch v4
> 
> This should work now. The only ugly part is that I had to put a
> toolbarspring into the new toolbar so that when it is empty, it appears when
> going into Customize palette. It is not high enough, but better than
> invisible. Is there a better way to do it?

This is because Linux has a min-height: 0 here: https://dxr.mozilla.org/comm-central/source/mail/themes/linux/mail/messageHeader.css#46 which overrides the min-height of toolbar.css. OS X and Windows don't have this. You could add:

#folderPane-toolbar (
  min-height: 24px;
}

for example in mailWindow1.css. Ten the toolbarspring isn't needed and the menulist uses the whole width.
Assignee

Comment 110

3 years ago
Posted patch patch v4.1 (obsolete) — Splinter Review
Thanks for the comments. I incorporated the suggestions. I also removed a ton of css that was for the arrow buttons that are removed in this patch.

The new toolbar now does not show up automatically, no even when going into customize.
It is collapsed by default. You need to enable it (in the toolbar context menu).
Then it shows up (hopefully on all platforms). Then you can drag any items into it, including the new "mode selector". The selector will show the current folder mode label (just not the first time you drag it out from the palette).
Attachment #8729860 - Attachment is obsolete: true
Attachment #8730387 - Flags: ui-review?(richard.marti)
Attachment #8730387 - Flags: review?(squibblyflabbetydoo)
Attachment #8730387 - Flags: feedback?(rkent)
Comment on attachment 8730387 [details] [diff] [review]
patch v4.1

Review of attachment 8730387 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good! Note: I haven't run TB with this patch, so I can't comment whether everything behaves correctly.
Attachment #8730387 - Flags: review?(squibblyflabbetydoo) → review+
Comment on attachment 8730387 [details] [diff] [review]
patch v4.1

Review of attachment 8730387 [details] [diff] [review]:
-----------------------------------------------------------------

I did not review the code, only the functionality.

Looks good except for one issue. The casual user will try this, enable the folder pane toolbar, and not understand what it is about because it starts out empty. If you know enough to try to customize it, then you get the customize menu, but it is not apparent which items are intended for the folder pane toolbar. You really have to know what you are doing to actually get this configured correctly.

I really think that you should have the default condition of the folder pane tool bar to contain the folder view dropdown. If the user knows enough to customize toolbars, she can remove that. If not, the the toolbar just works when you enable it.
Attachment #8730387 - Flags: feedback?(rkent) → feedback+
The downside of setting the default like that is that the "Folder Views" toolbar item will be mysteriously absent from the palette unless you turn on the Folder Pane toolbar and then move the Folder Views item where you want.
Assignee

Comment 114

3 years ago
I think it is fine that the user can drag ANY item to the folderpane toolbar. The view picker may be the most useful one to put there, but why not the others if he wishes so. I don't think we need to somehow mark which 'items are intended for the folderpane toolbar'. It is just another toolbar with a difference, that it is not the width of the full window. So use it as you see fit.
Yeah, if it were up to me, I'd use the same palette for *every* toolbar in the 3pane, but that gets a bit hairy with the message header toolbar (and the attachment toolbar).

Comment 116

3 years ago
(In reply to Kent James (:rkent) from comment #112)
> Looks good except for one issue. The casual user will try this, enable the
> folder pane toolbar, and not understand what it is about because it starts
> out empty. If you know enough to try to customize it, then you get the
> customize menu, but it is not apparent which items are intended for the
> folder pane toolbar. You really have to know what you are doing to actually
> get this configured correctly.
+1

I enabled the Toolbars > Folder Pane Toolbars and got an empty grey area. It didn't even say: "Put something here through configuring", no tooltip, nothing, you can't even right-click on it. You have to right-click elsewhere to be able to configure this new toolbar. Because I knew of this bug, I was able to configure it correctly, "normal" users won't be able to find it.
 
> I really think that you should have the default condition of the folder pane
> tool bar to contain the folder view dropdown. If the user knows enough to
> customize toolbars, she can remove that. If not, the the toolbar just works
> when you enable it.
+1

I also find it quite amusing that you can drag any toolbar item there. I understand that the bug is there to return the original (now removed) functionality, switching between the views quickly, perhaps in a more useful form. So why add more features and variations to it?
Assignee

Comment 117

3 years ago
(In reply to Jorg K (GMT+1) from comment #116)
> (In reply to Kent James (:rkent) from comment #112)
> > Looks good except for one issue. The casual user will try this, enable the
> > folder pane toolbar, and not understand what it is about because it starts
> > out empty. If you know enough to try to customize it, then you get the
> > customize menu, but it is not apparent which items are intended for the
> > folder pane toolbar. You really have to know what you are doing to actually
> > get this configured correctly.
> +1
> 
> I enabled the Toolbars > Folder Pane Toolbars and got an empty grey area. It
> didn't even say: "Put something here through configuring", no tooltip,
> nothing, you can't even right-click on it. You have to right-click elsewhere
> to be able to configure this new toolbar. Because I knew of this bug, I was
> able to configure it correctly, "normal" users won't be able to find it.
>  
Considering the feature (similar to the folder pane columns) was once removed, putting it back is tried with the least exposure (and maximum invisibility of it in the default state). So it is not a feature we want to put right in the face of all "normal" users. Making it available if you know to look for it is the first step. If the UI people allow us to do more, that will be a bonus :)

> > I really think that you should have the default condition of the folder pane
> > tool bar to contain the folder view dropdown. If the user knows enough to
> > customize toolbars, she can remove that. If not, the the toolbar just works
> > when you enable it.
> +1

I'd be fine with the toolbar having the single item predefined and it could be moved to other place.
On the other hand, if the item is there, you pay the price to always update it (yes, which may be a single occurence per session).

> I also find it quite amusing that you can drag any toolbar item there. I
> understand that the bug is there to return the original (now removed)
> functionality, switching between the views quickly, perhaps in a more useful
> form. So why add more features and variations to it?

Why not, if it is for free? If we wanted to hardcode only the old functionality, there would be the "WIP patch" (v1) accepted.

(In reply to Jim Porter (:squib) from comment #113)
> The downside of setting the default like that is that the "Folder Views"
> toolbar item will be mysteriously absent from the palette unless you turn on
> the Folder Pane toolbar and then move the Folder Views item where you want.

I think I would be fine with that.

Comment 118

3 years ago
(In reply to :aceman from comment #117)
> Why not, if it is for free? If we wanted to hardcode only the old
> functionality, there would be the "WIP patch" (v1) accepted.
Let's not start this discussion. Personally, I would have never removed the old functionality and I would have been happy with one of the WIP patches, see comment #87. As I said in that comment: A menu is better than the arrows, since it gives me faster access to what I want.

What about:
> I also find it quite amusing that you can drag any toolbar item there.
Is the intention really to have another toolbar area which can house anything? Why does the area not react to right-click? Most semi-advanced users know the concept of a context menu, so can that be made to work there? And even if it's only a "Customise ..." item popping up.
Posted image flexing.png
With your patch I get this:
- on main toolbar beside the "Folder location" menulist it shrinks too much
- on customize window the menulist is too tall

For both issues I have a patch.

I too think it's weird with the empty Folder pane toolbar. The folderpane-mode-selector is also new (re-)introduced and only users which are going into customize will recognize the the new menulist.

We should put the menulist initially on the new toolbar.
Posted patch 700976-flex-fix.patch (obsolete) — Splinter Review
This patch fixes the two issues I noted in previous comment.

Aceman, if you want to add this patch in your next patch, don't hesitate to do it.
Attachment #8730725 - Flags: review?(squibblyflabbetydoo)
Attachment #8730725 - Flags: feedback?(acelists)
Comment on attachment 8730387 [details] [diff] [review]
patch v4.1

I'm setting ui-r- because of the empty toolbar and thus no hint for what it can be used.

With adding the folderpane-mode-selector the toolbar has from beginning a usable function.
Attachment #8730387 - Flags: ui-review?(richard.marti) → ui-review-
Comment on attachment 8730725 [details] [diff] [review]
700976-flex-fix.patch

Review of attachment 8730725 [details] [diff] [review]:
-----------------------------------------------------------------

rs=me
Attachment #8730725 - Flags: review?(squibblyflabbetydoo) → review+
I'd say at minimum, you should be able to right-click the Folder Pane Toolbar and select "customize". Every other toolbar does this. As a bonus, I'd add something like a little tooltip/bubble that pops up and says, "Hey, you can put stuff here! Just right-click and start customizing!" or something to that effect.
Assignee

Comment 124

3 years ago
Comment on attachment 8730725 [details] [diff] [review]
700976-flex-fix.patch

Review of attachment 8730725 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, I like this.
Please remove the hunk from mailWindowOverlay.xul and the rest can stay as a separate patch.
Thanks.

::: mail/base/content/mailWindowOverlay.xul
@@ +3330,5 @@
>                     label="&appmenuButton.label;"
>                     tooltiptext="&appmenuButton1.tooltip;"/>
>      <toolbaritem id="folderpane-mode-selector"
> +                 align="center"
> +                 title="&folderModeSelector.label;">

Please remove this change, I'll incorporate it in my patch as it is removing a line that I add in my patch :)
Attachment #8730725 - Flags: feedback?(acelists) → feedback+
Assignee

Comment 125

3 years ago
Posted patch patch v4.2 (obsolete) — Splinter Review
This should fix the problems. There is now the standard context menu on the new toolbar. When first enabling it, it should contain the mode selector as the single item. It can be dragged out to other place.

You may need to try with a new profile so that the defaultset attribute on the toolbar takes effect.
Attachment #8730387 - Attachment is obsolete: true
Attachment #8731153 - Flags: review?(squibblyflabbetydoo)
Posted patch 700976-flex-fix.patch (obsolete) — Splinter Review
Removed the mail/base/content/mailWindowOverlay.xul part.

Setting r+ from previous patch because the other parts are unchanged.
Attachment #8730725 - Attachment is obsolete: true
Attachment #8731162 - Flags: review+

Comment 127

3 years ago
Guys, please forgive the intrusion. Would you be very offended to combine the two patches. I know that Richard doesn't mind to have a few lines of his work integrated into a larger patch.

This makes uplifting easier and also, as far as I can see, these are not really independent (but I could be wrong on this one).

I tried it out and all seems to work nicely with some nits:

When configuring the folder pane toolbar, the view switcher shows up small and right justified.

Also, when placing to items onto the new toolbar, the space isn't equally distributed, picture to follow.
Attachment #8731153 - Attachment is obsolete: true
Attachment #8731162 - Attachment is obsolete: true
Attachment #8731153 - Flags: review?(squibblyflabbetydoo)
Attachment #8731182 - Flags: review?(squibblyflabbetydoo)
Attachment #8731182 - Flags: feedback+

Comment 128

3 years ago
Attachment #573147 - Attachment is obsolete: true
Attachment #573148 - Attachment is obsolete: true
Attachment #8541301 - Attachment is obsolete: true
Attachment #8543238 - Attachment is obsolete: true
Attachment #8543270 - Attachment is obsolete: true
Attachment #8632470 - Attachment is obsolete: true
(In reply to Jorg K (GMT+1) from comment #128)
> Created attachment 8731184 [details]
> Pciture showing problematic space distribution if more than one item is
> placed onto the new toolbar.

This is because I set #folderPane-toolbar > #folderpane-mode-selector { -moz-box-flex: 1; } in primaryToolbar.css to make it fill the whole folder pane toolbar. With other elements (especially this beast of #locationFolders ;) ) it will then shrink as you see. This code could be removed when the #folderpane-mode-selector isn't placed here as default. But without this code placed on it as the only element it wouldn't fill the whole toolbar.

Comment 130

3 years ago
Thanks for looking into it, but the question is: Can it be fixed? I know, it's all CSS, but even there you have selectors to qualify on first/last child? Sorry, I'm not an expert, perhaps that doesn't help.
It should be fixable with adding #folderPane-toolbar > #folderpane-mode-selector:only-child { -moz-box-flex: 1; } but I need to wait to check until my build finished.

Comment 132

3 years ago
That makes the view switcher wider, but since the other beast (#locationFolders) doesn't shrink, it now overruns the given space. Well, I would have been happy with a simple solution, but now that this area was promoted into a full toolbar, we have more complication.
Assignee

Comment 133

3 years ago
Posted patch patch v4.3 (obsolete) — Splinter Review
Incorporating css fix to solve the problem when both folder selector and mode selector are on the new toolbar.
Attachment #8731182 - Attachment is obsolete: true
Attachment #8731182 - Flags: review?(squibblyflabbetydoo)
Attachment #8734960 - Flags: review?(squibblyflabbetydoo)
Attachment #8734960 - Flags: feedback?(mozilla)

Comment 134

3 years ago
Comment on attachment 8734960 [details] [diff] [review]
patch v4.3

Yes, that works better and addresses my comment #132.

However, I don't like the look, screenshot to follow.
Attachment #8734960 - Flags: feedback?(mozilla) → feedback+

Comment 135

3 years ago
OK, the German pedant reckons that the new drop-down is quite awkwardly placed. I has space on the left and looks really cobbled together on the right.

It looks a little better when the "Folder Pane Columns" control is added.

In the screenshot you can see the old arrow implementation from the userChrome.css trick (comment #85) in the TB instance at the top. That fills the space nicely.
Attachment #8731184 - Attachment is obsolete: true
The only issue I see is that the background around the dropdown is a slightly different color than the folder pane's background. A border at the bottom to divide the two visually would be another acceptable alternative.

I don't think I'd r+ a patch that adds a bunch of custom styling to a toolbar that's off by default. Especially not when this feature is already right on the line of "how much work should we do for a feature most users won't even see".
Comment on attachment 8734960 [details] [diff] [review]
patch v4.3

Review of attachment 8734960 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. (Note that I haven't applied this patch to my local build; if you'd like me to, just let me know.)
Attachment #8734960 - Flags: review?(squibblyflabbetydoo) → review+

Comment 138

3 years ago
(In reply to Jim Porter (:squib) from comment #136)
> Especially not when this feature is already
> right on the line of "how much work should we do for a feature most users
> won't even see".
I lot of work and discussion was invested in bug 667245 to remove a useful feature that users were using and some were relying on for their daily work. So bringing something back to undo the damage is worth some work IMHO.

The user won't mind how the missing feature is resurrected, they most likely won't care either that it's now a toolbar that can house various things. What they will see however is that it looks erraticly placed.
(In reply to Jorg K (GMT+1) from comment #138)
> (In reply to Jim Porter (:squib) from comment #136)
> > Especially not when this feature is already
> > right on the line of "how much work should we do for a feature most users
> > won't even see".
> I lot of work and discussion was invested in bug 667245 to remove a useful
> feature that users were using and some were relying on for their daily work.
> So bringing something back to undo the damage is worth some work IMHO.

In software development, discussion is cheap; cheap enough that you might as well round it down to "free". I'm a lot more concerned with long-term maintenance costs. You can easily get someone to add a few lines of code during review, but it's a lot harder to guarantee long-term upkeep of that code. As a corollary, I'd estimate most code removals as negative work in total, since they reduce the maintenance burden.

(Of course, in reality, code removals just shift the work onto add-on developers, but that's the whole point: the core application should be the bits that most users actually use. Sadly, we don't have a lot of actual numbers on what bits people use because no one ever bothered to *use* Test Pilot to do user studies, despite having me port the add-on to Thunderbird. No, I'm not bitter.)

> The user won't mind how the missing feature is resurrected, they most likely
> won't care either that it's now a toolbar that can house various things.
> What they will see however is that it looks erraticly placed.

The old folder mode switcher was sinfully ugly (OS X was a bit better). Almost *anything* would be a visual improvement. In fact, the current patch is pretty close to Asa's original proposal, and the only thing we'd need to change is the background color: https://web.archive.org/web/20160325233802/http://farm7.static.flickr.com/6043/5896620344_e41a727b6b_o.png
(In reply to Jim Porter (:squib) from comment #139)
> and the only thing we'd need to change is the background color.

Change the toolbar background color to the tree background color? If we'd have only the menulist, okay. But now it's a normal toolbar which can have all elements and should look like a toolbar. I'm more for a border between toolbar and tree.
Either way is fine with me. But I imagine changing the background color would actually look good in a variety of cases. Adding a border is probably the simplest way, though. We could always tweak the theme (in small ways, please!) in a followup if we're unhappy later.
Assignee

Comment 142

3 years ago
I'll fix the padding and add the bottom border. The toolbar background seems fine to me. It is the same as others, at least on linux. I see in the screenshots it is not the same as the main toolbars on Windows, but still fine to me.

But I hope that will be enough.
Assignee

Comment 143

3 years ago
Posted patch patch v4.4 (obsolete) — Splinter Review
Thanks to Paenglab for the css for the toolbar border and background. I removed the padding/margin of the 2 elements when they are in the folderpane toolbar. Hopefully it is fine now.
Attachment #8734960 - Attachment is obsolete: true
Attachment #8735186 - Flags: ui-review?(richard.marti)
Attachment #8735186 - Flags: feedback?(mozilla)

Comment 144

3 years ago
Comment on attachment 8735186 [details] [diff] [review]
patch v4.4

Better, but not perfect.
Attachment #8735186 - Flags: feedback?(mozilla) → feedback+

Comment 145

3 years ago
Can you remove the top/botton padding/margin. There is an awkward double border with one pixel background in between.

Look, in bug 368915 we were still fighting over the solution in cmt 170 and settled on the solution in cmt 225, here we're not even at cmt 150 ;-)

Comment 146

3 years ago
I tried margin: 0; instead of only left/right. That works, but only until you place another item there, for example "Back". These items seem to be higher, so then you get some space below the view selector. 

Can't all the items on this toolbar get margin: 0?

#folderPane-toolbar * {
  margin: 0;
}

does it for me.
Comment on attachment 8735186 [details] [diff] [review]
patch v4.4

I'm not so a fan of of the no margin at left/right because the menulist border touches the other borders and makes it look as a fat 2px border. But I think we should leave this as it is now. maybe in a followup bug we can decide what we expect what the user will do with this toolbar. If he will never change this we could remove the border/use the tree background color. If he will add other elements, then we have to pay attention with spacing between the elements. Jörg's proposal with 0px margin looks too compressed when you hover the button beside the menulist.

I found one issue: when you change the main toolbar mode to full, also the #folderPane-toolbar changes to this mode. But also with reverting by using "Restore default Set" it stays in full mode. This needs to be changed to force always mode="icons". ui-r+ with fixing this.
Attachment #8735186 - Flags: ui-review?(richard.marti) → ui-review+
Assignee

Comment 149

3 years ago
(In reply to Jorg K (GMT+1) from comment #146)
> Can't all the items on this toolbar get margin: 0?
> 
> #folderPane-toolbar * {
>   margin: 0;
> }
> 
> does it for me.

That would kill also the internal margins inside the toolbar elements, e.g. between icon and a dropdown arrow, or the "View" label and its associated menulist.

This would work for me:
#folderPane-toolbar menulist:only-child {
  margin: 0;
}

I.e. if the whole item consists of only a menulist then remove the margins.
Assignee

Comment 150

3 years ago
(In reply to Richard Marti (:Paenglab) from comment #147)
> I found one issue: when you change the main toolbar mode to full, also the
> #folderPane-toolbar changes to this mode. But also with reverting by using
> "Restore default Set" it stays in full mode. This needs to be changed to
> force always mode="icons". ui-r+ with fixing this.

Yes, for some reason this new toolbar does not obey the "Icons beside text" mode, while other toolbars do. The other modes seem to work. Even though in "Icons and text" and "Icons beside text" the mode is still "full" in both cases. The property must be stored somewhere else.

Yes, forcing always "icons" mode would be nice here, if that is possible.

Comment 151

3 years ago
That works nicely with the view switcher being the only item, or view switcher and #locationFolders combined. But add "Back" as a third item and you'll see what I meant in comment #146.

How about:
#folderPane-toolbar #locationFolders,
#folderPane-toolbar > #folderpane-mode-selector > menulist {
  margin-left: 0;
  margin-right: 0;
}
#folderPane-toolbar * {
  margin-top: 0;
  margin-bottom: 0;
}

(In reply to :aceman from comment #149)
> That would kill also the internal margins inside the toolbar elements, e.g.
> between icon and a dropdown arrow, or the "View" label and its associated
> menulist.
I can't see that.

(In reply to Richard Marti (:Paenglab) from comment #147)
> I'm not so a fan of of the no margin at left/right because the menulist
> border touches the other borders and makes it look as a fat 2px border.
Yes, but with the one-pixel margin it's even worse, you have a 3px border, dark, light, dark.
(In reply to :aceman from comment #150)

> Yes, for some reason this new toolbar does not obey the "Icons beside text"
> mode, while other toolbars do. The other modes seem to work. Even though in
> "Icons and text" and "Icons beside text" the mode is still "full" in both
> cases. The property must be stored somewhere else.

It's stored in the toolbox as labelalign="end". We should never show the button text because the folder pane is normally too small.
Assignee

Comment 153

3 years ago
(In reply to Jorg K (GMT+1) from comment #151)
> (In reply to :aceman from comment #149)
> > That would kill also the internal margins inside the toolbar elements, e.g.
> > between icon and a dropdown arrow, or the "View" label and its associated
> > menulist.
> I can't see that.

Try putting "Mail Views" on the main toolbar and on the folderpane-toolbar. The spacing between the label "View" and the menulist will be different.
Assignee

Comment 154

3 years ago
Posted patch patch v4.5 (obsolete) — Splinter Review
Looks like there are some undocumented attributes on the toolbar to lock the mode and iconsize.

If you still put folder modes and some buttons on the new toolbar, there will be some 1-2px space below the menulist of folder modes. Seems the icons are still higher than the menulist (that is also on the main toolbar, but it is not that visible there). But I would not try to fix everything in this bug. Seems the styling of toolbarbuttons and items is quite convoluted and defined in multiple css files. That could be reworked in some other bug. Or it can't be. I'm sure there are reasons for this due to the varions themes/OSes we have to support.
Attachment #8735186 - Attachment is obsolete: true
Attachment #8735262 - Flags: ui-review?(richard.marti)
Attachment #8735262 - Flags: feedback?(mozilla)

Comment 155

3 years ago
Comment on attachment 8735262 [details] [diff] [review]
patch v4.5

Review of attachment 8735262 [details] [diff] [review]:
-----------------------------------------------------------------

This works well enough now ;-)

::: mail/base/content/messenger.xul
@@ +318,5 @@
>  
>            <box id="messengerBox" orient="horizontal" flex="1" minheight="100" height="100" persist="height">
>              <vbox id="folderPaneBox" minwidth="125" width="200" persist="width">
> +              <sidebarheader id="folderPaneHeader" hidden="true" align="center"/>
> +              <toolbox id="folderPane-toolbox">

This wasn't in the previous patch, why do we need it? folderPane-toolbox is not referenced anywhere in the patch.

@@ +321,5 @@
> +              <sidebarheader id="folderPaneHeader" hidden="true" align="center"/>
> +              <toolbox id="folderPane-toolbox">
> +                <toolbar id="folderPane-toolbar"
> +                         class="inline-toolbar"
> +                         toolboxid="mail-toolbox"

Which ID should be used here?
Attachment #8735262 - Flags: feedback?(mozilla) → feedback+
Posted patch Patch v4.5.1 (obsolete) — Splinter Review
The issue with the buttons is your rule #folderPane-toolbar menulist:only-child. The menulist is always the only-child in the toolbaritem, except in mailviews with the label. I fixed this in this patch and also the toolbar background color on Windows because the added toolbox changed the appearance.
Comment on attachment 8735262 [details] [diff] [review]
patch v4.5

ui-r+ also when I don't really like the fat borders when only one element is in the toolbar.
Attachment #8735262 - Flags: ui-review?(richard.marti) → ui-review+
Assignee

Comment 158

3 years ago
(In reply to Richard Marti (:Paenglab) from comment #156)
> The issue with the buttons is your rule #folderPane-toolbar
> menulist:only-child. The menulist is always the only-child in the
> toolbaritem, except in mailviews with the label.

But that is the point. I want that margin 0 to apply to all toolbaritems which consist of only a menulist. Your patch does not do that. If you put Folder modes and Folder location on the toolbar, I think you get the margins again that Jorg and me do not want.

> I fixed this in this patch
> and also the toolbar background color on Windows because the added toolbox
> changed the appearance.

The tooolbox should not be there, it was a remnant of an experiment. The toolbar references a different toolbox via toolboxid. I'll remove it.
(In reply to :aceman from comment #158)
> (In reply to Richard Marti (:Paenglab) from comment #156)
> > The issue with the buttons is your rule #folderPane-toolbar
> > menulist:only-child. The menulist is always the only-child in the
> > toolbaritem, except in mailviews with the label.
> 
> But that is the point. I want that margin 0 to apply to all toolbaritems
> which consist of only a menulist. Your patch does not do that. If you put
> Folder modes and Folder location on the toolbar, I think you get the margins
> again that Jorg and me do not want.

But then you get the issue you described in comment 154 and you need additional rules for the buttons.
Assignee

Comment 160

3 years ago
(In reply to Richard Marti (:Paenglab) from comment #159)
> But then you get the issue you described in comment 154 and you need
> additional rules for the buttons.

I could live with the 1px margin bottom without the additional rules :)

Comment 161

3 years ago
(In reply to :aceman from comment #160)
> I could live with the 1px margin bottom without the additional rules :)
How does that look if the view switcher is the only item? Like a 3px border? Border, margin, other border?
(In reply to :aceman from comment #160)
> I could live with the 1px margin bottom without the additional rules :)

I not.
Assignee

Comment 163

3 years ago
(In reply to Jorg K (GMT+1) from comment #161)
> (In reply to :aceman from comment #160)
> > I could live with the 1px margin bottom without the additional rules :)
> How does that look if the view switcher is the only item? Like a 3px border?
> Border, margin, other border?

border of the menulist, 1px margin, border of the toolbar. And the 3px margin on the right.
But we can't fix all individual items in this bug. I think that would need some global solution.
We should focus on the items that are most likely to be put on the folderpane toolbar. So the mode selector. Anything else is bonus.

Comment 164

3 years ago
Well, with patch v4.5 (haven't tried 4.5.1) I see a 2px border. No margin. I like that much better.
Assignee

Comment 165

3 years ago
May depend on OS. I also only tried 4.5, but with the toolbox removed.

Comment 166

3 years ago
I've tried 4.5.1 now, but with the erroneous toolbox removed. When placing the the view switcher and #locationFolders together, I get a lot of margin to the left and right and in between. I prefer 4.5.

Comment 167

3 years ago
Sorry, the margin-left and margin-right set to 0 was in 4.4, that's already gone in 4.5. :-(

So what's the difference between 4.5 and 4.5.1?
4.5  : #folderPane-toolbar menulist:only-child {
4.5.1: #folderPane-toolbar > toolbaritem:only-child > menulist {
Assignee

Comment 168

3 years ago
(In reply to Jorg K (GMT+1) from comment #167)
> Sorry, the margin-left and margin-right set to 0 was in 4.4, that's already
> gone in 4.5. :-(

Replaced with margin:0, so no margin on all sides.

> So what's the difference between 4.5 and 4.5.1?
> 4.5  : #folderPane-toolbar menulist:only-child {
> 4.5.1: #folderPane-toolbar > toolbaritem:only-child > menulist {

Explained in comment 158. The 4.5.1 means margin:0 if there is only one item in the toolbar.

Comment 169

3 years ago
So sorry about all this. I went back to 4.5 and this is the one I like. I'd remove the erroneous toolbox and be done with it. Sorry again.
With this code the menulists and the buttons have 0px margin but when multiple elements are placed they have a spacing of 2px between them.

#folderPane-toolbar > .toolbarbutton-1,
#folderPane-toolbar > toolbaritem > menulist {
  margin: 0;
}

#folderPane-toolbar > :-moz-any(*) + :-moz-any(*) {
  margin-inline-start: 2px;
}
Assignee

Comment 171

3 years ago
Will that not break "Mail views" again (comment 153) ?
Not break, but be more condensed like all the other elements on this toolbar, and be different from the normal toolbars.
Assignee

Comment 173

3 years ago
Posted patch patch v4.6Splinter Review
Ok, works for me.
Attachment #8735262 - Attachment is obsolete: true
Attachment #8735285 - Attachment is obsolete: true
Attachment #8735423 - Flags: feedback?(mozilla)

Comment 174

3 years ago
Comment on attachment 8735423 [details] [diff] [review]
patch v4.6

Review of attachment 8735423 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Richard Marti (:Paenglab) from comment #170)
> With this code the menulists and the buttons have 0px margin but when
> multiple elements are placed they have a spacing of 2px between them.
And why do we need the space in between? This toolbar is small, so I could live without it.
But I can live with it, too ;-) (I liked 4.5 better.)

::: mail/themes/osx/mail/primaryToolbar.css
@@ +450,5 @@
> +#folderPane-toolbar > toolbaritem > menulist {
> +  margin: 0;
> +}
> +
> +#folderPane-toolbar > :-moz-any(*) + :-moz-any(*) {

Just out of interest, what does that do?
Attachment #8735423 - Flags: feedback?(mozilla) → feedback+
(In reply to Jorg K (GMT+1) from comment #174)
> > +#folderPane-toolbar > :-moz-any(*) + :-moz-any(*) {
> 
> Just out of interest, what does that do?

It adds the 2px spacing between the elements.

Comment 176

3 years ago
(In reply to Richard Marti (:Paenglab) from comment #175)
> It adds the 2px spacing between the elements.
Sure, you said so in comment #170 and I replied to it in comment #174. I'd like to understand the somewhat unusual CSS.
Assignee

Comment 177

3 years ago
I'd think the syntax means that if there are any 2 direct children (>) of the toolbar, add the margin at the start of the second of them. So adds margin between items, but only if there are at least 2 in the toolbar.
Correct, and with :-moz-any(*) I don't need to write all possible combinations with toolbaritem and toolbarbutton-1.
Assignee

Comment 179

3 years ago
So hopefully we are done here.
Status: REOPENED → ASSIGNED
Keywords: checkin-needed

Comment 180

3 years ago
Let's land it - unless you want to keep discussing up to cmt #250 ;-)

Comment 181

3 years ago
https://hg.mozilla.org/comm-central/rev/709e8de02a15 - Thanks!
Status: ASSIGNED → RESOLVED
Closed: 8 years ago3 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 48.0

Comment 182

3 years ago
If it didn't have that one string change, I'd love to uplift that to Aurora :-(

Comment 183

3 years ago
I've switched to today's Daily to use the goodness implemented here ;-)

One question: The horizontal line is a little short on the left side, is this intentional?
Intentional for menus with place for icons before the text. ;) But not really for this menu. Can you file a bug?
Depends on: 1260744

Updated

3 years ago
Blocks: 1318552

Updated

2 years ago
Duplicate of this bug: 1340918
You need to log in before you can comment on or make changes to this bug.