*** Bug 724934 has been marked as a duplicate of this bug. ***

*** Bug 725979 has been marked as a duplicate of this bug. ***

The one stumbling block I see is, what happens to the status bar?  Right now, it's at the bottom of the folder list, but I don't think we want to hide it with the folder list.  Some ideas:

1) We could move it to the bottom of the conversation list when the folder list is closed.  I don't know if this would seem natural or not, but it'd probably be difficult to do with a nice animations.

2) Make the status bar extend over the bottom of both the folder and conversation lists.  When one is hidden, it the status bar stays in the same place.

3) Make the status bar into an overlay that only appears when necessary.  It could stay in the bottom left, or we could move it elsewhere.

4) Move the contents of the status bar into the header.  Not sure where, though.

One nice thing about keeping the status bar in position is that we could put the toggle button there.  All the header bar buttons act on mail, in some form, so it's sort of odd to me to have a UI control up there.

Thinking further afield, some other possibilities:

5) We could have a single pane on the left which could be toggled between folder list and conversation list.

6) We could stack the folder list and conversation list vertically in the left pane.  This would give the user a bit more control in allotting space (since both components enforce minimal widths).  We could also notice when the pane has been dragged to hide the folder list, and replace it with an expansion button.

Either of these could coexist with the current layout as options, as well.

One thing that most of these would require is a change to the large-scale structure of the main window.  Currently, it looks like this:

|---------------------- GtkPaned -----------------------|
|                                                       |
|-- Folder --|---------------- GtkPaned ----------------|
|    List    |                                          |
|            |-- Conversation --|-- Conversation View --|
|            |       List       |                       |
|            |                  |                       |
|-- Status --|------------------|-----------------------|

For 2, 5, and 6, we'd want a layout more like

|---------------------- GtkPaned -----------------------|
|                                                       |
|----------- GtkPaned ----------|-- Conversation View --|
|            |                  |                       |
|-- Folder --|-- Conversation --|                       |
|    List    |       List       |                       |
|            |                  |                       |
|------------|------------------|-----------------------|

Is there any reason the former layout was chosen over the latter?  This would change how resizing works -- currently moving the left divider resizes the folder list and conversation view, leaving the conversation list fixed.  After the change, the conversation view would remain fixed.  Is that a problem?

These are all great points.  My feelings are:

* I like the idea of making the status bar an overlay rather than extending it or somehow moving it between the two columns.  My only question about the overlay is making sure it's the same width as the column it's overlaying -- I know you encountered some wackiness with overlays and sizing when working on the inline composer.

* Moving the status bar into the header is an intriguing idea I'd not considered.  I thought a little bit about how that could look, but I'm not sure it's the way to go.  We'd need to add a spinner control and a text label for error messages.  That plus the account nickname/email address and the current folder and its unread count, and suddenly it sounds pretty busy up there, especially since the error line and spinner are transitory widgets that we'd need to leave space for.

If you have other suggestions about this, please let me know.  I got briefly excited about this idea before backing off.

* I particularly like the overlay idea for the reason you gave later: we now have an inconspicuous place to put the toggle button.  Yes, that's a better place for it.  One of the things I struggled with on this was putting the toggle in the toolbar -- it felt out-of-place, almost interfering with the feng shui of our current toolbar.  I thought about having it float someplace, but I was thinking of at the top of the folder list, and that never made sense.  Putting it on the status bar is Zen.  <Sound of one hand clapping.>

* Stacking/rotating between the folder list and conversation list is something we've discussed heavily in the past.  I personally would be fine with rotating between the two and making Geary a two-pane app only.  However, we've had strong opinions from people who want to be able to see their folder list at all times (especially from people who do heavy filtering and need to see when new mail arrives in non-Inbox folders).

In short, if we went this route I think we'd need to offer it as a user preference, which is something I'm reluctant to do.  Plus, even if we do offer it, do we still need to allow a way for the three-pane user to hide the folder list?  Sounds overkill, but I actually think there's some merit to it.  In any event, it's probably too late in the cycle to be doing this.  There might be a clever way to do this, however.  (A tri-state toggle?)

Be curious about your thoughts on this subject (two- vs. three-pane UI).

* If there's a hard reason for the GtkPaned layout, I can't recall it.  It may simply be the way it was coded; put the first two in a Paned, then them all in the Paned, i.e. like reading left to right.  Personally I would prefer if it moving one slider only affected the size of the two panes touching it and not the third.  If your change achieves that, all the better.

When I mentioned the overlay, I was thinking something transient that would disappear when it wasn't needed.  I don't think we want to put a button on such an element.  We could have the overlay always visible, but then you also have to make sure that the element it's overlaying doesn't have any content behind that.  At this point, you might as well use the standard box model.

Let's both ponder the possibilities over the weekend.

"However, we've had strong opinions from people who want to be able to see their folder list at all times (especially from people who do heavy filtering and need to see when new mail arrives in non-Inbox folders)."

as someone who's on this bug for the 'portrait orientation' case, count me strongly among those folks. I filter heavily for mailing lists and flip between folders constantly, I don't think I could use an app where the message list and folder list were toggled.

(In reply to comment #6)
> as someone who's on this bug for the 'portrait orientation' case, count me
> strongly among those folks. I filter heavily for mailing lists and flip between
> folders constantly, I don't think I could use an app where the message list and
> folder list were toggled.

Right.  Making Geary two-column-only is off the table.

Robert, I didn't come up with any other bright ideas about this.  (I've had my hands full the past week.)  I still think the original proposal is the way to go: a button that can hide and restore the folder list.

Regarding the transient overlay, you're correct, of course.  One way forward would be to reparent the status bar (w/ button) between the two columns.  Reparenting in GTK+ has its perils, though.  Another technique would be to have two status bars (gulp), their visibility dependent on the column configuration.  One advantage of this route is that a single status bar class can be written that does all the right things and subscribes to the right signals, and the client merely instantiates two of them, packs them in the GtkContainers, and binds their visibility property to a GSetting.

I've been rolling this around my head for a bit, and here's my proposal:

1) Flip the Paned structure to be as in my second diagram.

2) Make the status bar extend across both the folder and conversation lists.  (Though we can revisit this when it's done.)

3) Add a button to the status bar to flip the orientation of the left-hand Paned.

4) When it's in the vertical orientation, track the position of the Paned's handle.  When it's nearly to the top, replace the folder list with a button containing the current folder name.  Clicking the button would move the handle down, exposing the folder list.

5) Remember the handle positions separately for the two orientations.  This would let a user hide the folder list in the vertical orientation and expose it by switching to the horizontal orientation.

I think that this would provide all the various layouts that have been requested with a fairly organic feel.  I'm a bit worried about only having a drag to close the folder view in the vertical orientation, but perhaps we could hook a hot key up to do this as well.  But I'll wait to hear what everyone things before getting started.

I think this sounds great.  It sounds like you've thought through the entire workflow.  A hotkey for closing the folder view sounds fine, we can document it in the online help.

Any other thoughts are welcome, of course, but I would say jump in if you're ready!

I'd like to know what's happening with bug #736165, since that's touching the same elements that this will rearrange.  If we're not going to take that patch, I'll start on this.  But if you think that one's worthwhile, I'll wait for it to land.

Let me prioritize looking at it.

Don't know if this has been discussed, but I would like a quick way of turning off/on the message view pane (right most). I very frequently want to list all the messages in a folder so I can select many and move/delete/etc them. 

For instance, I receive a lot of system alert emails. In the morning, I scan the subject lines, read some of them, and then delete most. This is similar to how I read news in an RSS reader; I read the headlines and only read the full article if I am interested.

While I can grab the slider to make the message pane bigger, I then have to grab it again and adjust it to my preferred width; much slower and more annoying than toggling it with a button or keypress.  Note that Thunderbird has the F8 key which toggles the Preview pane on and off, and I use it frequently.

*** Bug 739905 has been marked as a duplicate of this bug. ***

*** Bug 740665 has been marked as a duplicate of this bug. ***

A sidebar like corebird :http://www.omgubuntu.co.uk/2014/11/linux-twitter-app-corebird-new-release would be amazing. Very little horizontal space used without need to hide. A top-left button is used to switch between account

The problem is that Geary's sidebar is not merely a task switcher within the app.  We have heard numerous users state that they need to be able to see their folders to know when new mail comes in (i.e. mail that is filtered directly to folders and skips Inbox).

There are other Geary tickets about re-laying out and re-styling the sidebar which apply here.

I've pushed some work in progress to wip/714793-orientation.  It's based on the split headerbar branch, but only because that implements step (1) of my plan in comment 8.  It should be easy to rebase it if we want to land this before the headerbar stuff.  FWIW, I think (2) nicely works with the split headerbar, since it helps reinforce the two-halves thing we have going.

I implemented (3) and (5) about as written above.  The button in the statusbar is just a placeholder.  I think we'll need to try to find an icon (or two) that demonstrate what the button does.  I suspect we can also shrink it down some, so it doesn't make the statusbar taller.

In place of the button suggested by (4), I put in a combo box to select the current folder.  This is really preliminary, just to see if this is worth pursuing.  I was thinking that it be nice if that button let you switch folders, instead of just revealing the folder list.  When I realized that a combo box can take a tree model, I thought I'd give it a go.

This big problem is that the first level is only the accounts, of which there are probably only one or two.  So to do anything, you have to pop open a sub-menu and select a folder.  I don't know if this is fixable without changing the structure of the model.

If this were the only way to change folder, we'd need to do much better.  But I'd see this mainly being used by people who generally live in one inbox and rarely change folders (like me).  A bit of awkwardness is okay, and you can always switch to the folder list to make the change.  (In fact, you can use the statusbar button to switch to the three pane view and back, although there's occasionally a re-paint problem right now.)

As I said, there's a bunch of problems with how this last commit is implemented, so for now, I'm just looking for feedback on the design.  Comments on the implementation of the previous commits are welcome, though.

This is intriguing, Robert, but I'm confused about the combo box.  Did you intend for it to be a drop-down combo box, where the current folder is displayed and the others are listed below if the control is clicked on?  For me, it merely looks like the standard tree view is relocating from the left side to above the conversation list when I select the button.

I agree -- this two-column layout is best suited for people who sit in one folder (really, their Inbox) most of the time and only have a couple of accounts hooked up.  That said, I suspect a lot of people will get some mileage out of this layout.  (I know I will.)

What I'm seeing right now as issues are nits.  I think this is certainly the right direction.  I suspect I'll want to land this before the split headerbar patch, so it's worth thinking about rebasing this against master.

The combo box only appears when you're in the vertical layout and you drag the handle all the way to the top.  The usual treeview gets replaced by a combo box.  (Although I just tested this in Adwaita, and it didn't seem to work.  In folder-list-tree.vala, increase the number in line 94.  This is something we'd have to fix if we like this idea.)

Ok, now I see it.  Pretty cool!  Not sure why this is theme-specific, but I'm sure there's a way to get a reasonable value at runtime.

It looks like the widgets in a paned have a minimal size below which they cannot go.  I suspect for a scrolled window, it's set by the scrollbar.  Since different themes have different scrollbars, they have different minimal sizes.

A paned does have a min_position property, which I gather is supposed to tell you what this is.  But in my testing, it's always been 0, which is a lie.  Perhaps if we set a minimum height on the folder list, we can get this to work.  Of course, in that case, we already know the number in question.

What I really want is to make the transition happen right at the height of the combo box, but it looks like that won't work.

The two options I can think of are (a) using an off-screen window and testing programmatically at startup to find the magic value, or (b) finding a number that works with most or all popular themes and using that, even if it means not pixel-perfect behavior.

I wouldn't want this to hamper the entire effort, so I'm inclined to go with (b), barring another not-terribly convoluted solution being discovered.

I think we need some futzing to get the combo box right.  But we needn't wait for that to be ready to land the rest.  So, some questions:

1) Any idea for the switcher button?  I'm think about trying to make some icons that looks the the layout (something like :| and |||), but maybe you have a better idea.  We could also use a toggle button, but I don't know what that icon would be.

2) When people first run this code, they're going to get poorly-sized columns, since we've changed the nesting of the paneds?  Should we try to correct this?  Should we stop using the existing setting and create a new one that starts with a sensible default?  Should we just say this is pre-1.0 software and these things happen?

3) Any thoughts about the code architecture in implementing the combo box?  What I did was a quick hack job.  I think we should really make a FolderList.Widget that contains a FolderList.Tree and the ComboBox.  I'm not entirely sure how the code should be split up, though.  I also had to make some things in Sidebar.Tree public, so the combo box could get access to them.  Is there a better approach here?

I just pushed a commit that provides icons for the switcher button.  They're not great, but they're something.  This creates a new image each time the switch is made.  I don't know if it'd be better to cache the two images and just swap them out, or if that'd be premature optimization.

There's a new branch up at wip/714793-orientation2.  This is rebased onto master, without the split headerbar stuff.  I've also left out the combo box feature for now.  It wasn't always repainting correctly when you toggled the orientation, and I think it needs quite a bit of work, if it's even the right solution.  But I think it'd be perfectly fine to land the rest of this without that.

I've tweaked the switcher button a little bit, and I think it's looking sort of okay now.  I haven't done anything about the initial sizing issues people will run into on upgrading.  We could put in a fake database upgrade and correct the sizes then, but that seems like being too tricky for our own good.

(In reply to Robert Schroll from comment #23)
> I think we need some futzing to get the combo box right.  But we needn't
> wait for that to be ready to land the rest.

That seems reasonable to me.  It looks like a great idea to me, but I can also see how complicated it would become to get it right.

> 1) Any idea for the switcher button?  I'm think about trying to make some
> icons that looks the the layout (something like :| and |||), but maybe you
> have a better idea.

Unfortunately, I don't have a better suggestion than what you're aiming for here.  The only aesthetic comment I have about the icons are to make the interior lines a bit bolder.  Also, if you can reduce the height of the status bar, that would be great.  Otherwise, I think the icons are communicating purpose well.

I wouldn't bother with caching the images -- if they were being loaded and destroyed in a hot loop, sure, but that's not the case here.

> 2) When people first run this code, they're going to get poorly-sized
> columns, since we've changed the nesting of the paneds?  Should we try to
> correct this?  Should we stop using the existing setting and create a new
> one that starts with a sensible default?  Should we just say this is pre-1.0
> software and these things happen?

If we can easily migrate the existing settings, then I'm all for that; if not, or it's more trouble than it's worth, then we should ignore the old ones (perhaps deleting them, although I'm not exactly sure how that works due to how GSettings requires schemas) and start using new ones with reasonable defaults.

> 3) Any thoughts about the code architecture in implementing the combo box? 
> What I did was a quick hack job.  I think we should really make a
> FolderList.Widget that contains a FolderList.Tree and the ComboBox.

Unfortunately, the sidebar code was migrated from Shotwell (which, when populated with photos, has a pretty extensive tree with varied branches) and wasn't designed with this in mind.  A lot of blood was shed to get the TreeModel and TreeView to work the way we needed it to work in Shotwell; breaking Sidebar.Tree apart further makes sense (it's not a strict MVC architecture), but shortcuts were taken years ago due to time constraints and specific requirements.

That said, this Widget you're talking of, do you mean it would contain a Sidebar.Tree and a ComboBox, hiding one when the other is visible?  And they both reference the same TreeModel?  One way of doing that would be to make Tree's internals more visible, another would be to refactor it to split out some of the model code to a separate class.  It would take me a bit of time to review the full code base and go through all the alternatives to figure out the engineered approach.

That said, I'm a little wary of going down this path.  I'm concerned that the scope of this ticket is going far afield.  The goal here is to conserve real estate for machines where it's scarce, and refactoring the sidebar seems like a big task for what started off as a layout refresh.  So I'm pretty hesistant to go that route without strong reasons.

Let me ask you: your approach came about because ComboBox and TreeView both use a TreeModel.  What about leaving the sidebar as it is and simply tieing the signals FolderList monitors to a second Model, one for the ComboBox?  I know it's duplicate work, but I wonder how difficult that would be.  Perhaps there's more to this than I understand.

(In reply to Robert Schroll from comment #25)

> I haven't done anything about the initial sizing issues people
> will run into on upgrading.  We could put in a fake database upgrade and
> correct the sizes then, but that seems like being too tricky for our own
> good.

The database upgrade is down in the Engine and I would resist piggybacking on it for client settings upgrades.  One approach in the client would be to use new GSettings keys and migrate the old settings to them (if possible) or simply give them new reasonable defaults.  Or, a new key (something like "layout-version") that indicates the current values are "old" and need to be migrated/assigned new defaults.

Migrating old values is not super critical here; users won't go ballistic if they lose their old values and have to adjust them to their preferred settings again.

I've just pushed some slightly bulkier icons to the orientation2 branch.  They're slightly heavy to my eyes, but not too badly so.

You can make the status bar a bit thinner by setting margin_top and margin_bottom to 0 in status-bar.vala.  But when you do so, it no longer lines up with the find bar in conversation viewer.  Most of the time, that's closed, so this isn't a big issue, but it did look rather sloppy to me to have them miss each other by four pixels.  Try it and let me know what you think.

I'll look at the settings migration.  It'd certainly be possible to detect and update the settings, but this would (1) inject some procedural code into the settings, which happen nice and implicitly right now, and (2) saddle us with one-time-use code in the codebase "forever".

I've pushed a commit that should keep the layout about the same through the upgrade.  (I don't account for the thickness of the paned handle.)

To test: Set your orientation to horizontal (three panes across).  Checkout the current master.  Build, run, and set your panes as you like them.  Close geary, checkout this branch, build, and run.  The panes should be in the same position.

I've just pushed a few more commits.  The first three change the orientation button into a setting in the preferences dialog.  (It takes three, since I'm reverting some of the commits that provided the buttons.  I'll rebase these away later.)  The final one keeps the status bar from spanning both the folder and conversation lists in the horizontal layout.

I ended up going with a reparenting scheme for this.  The alternative was to have two status bars, but I was worried about keeping them synchronized.  The status bar is a public member of the main window, and it seemed unfair to make everyone interfacing with it remember to update things twice.  I started building a class to act as an interface, but got confused as to where the logic should lie.  There's a fair amount in the Gtk.Statusbar, but then our class implements its own logic.  But that's still an option if reparenting worries you.

Also, as I said over email, I'd appreciate it if you can try out the split-pane branch and see if you like the full-width status bar there.  (I think it works better, but I won't be hurt if you disagree.)

It looks like reparenting is working fine, so let's stick with this.  And I didn't realize the status bar was public on the main window, so I fully understand wanting to keep that interface simple.

I've looked at the full-width status bar on wip/743960-split-header-2 and I'm still not vibing on it.  You probably explained it before and I'm not finding it on the tickets -- what advantage do you see?  (Is it because of the way it lines up with the center drag nub?)  It does look good, and if the space was being used more actively I would have less of a problem.  But with the button moved to the Preferences box, the only thing that status bar is for is the ocassional spinner and text, and it's hard to justify for me.

I liked that it lined up with the center nub, the split in the header, and the search bar (when opened).

But, it's not a big thing and I'm going to be using the vertical view myself, so I won't be bothered at all with not stretching all the way.  Let's do it like this for now.

I was unsure what element should get the Gtk.STYLE_CLASS_SIDEBAR.  What does that even do?

Other than that, is there more work to be done, or should I rebase this and commit?

(In reply to Robert Schroll from comment #31)
> I liked that it lined up with the center nub, the split in the header, and
> the search bar (when opened).

I see.  The search bar thing was kind of the missing puzzle piece.

> Let's do it like this for now.

Yeah, let's do that for now.  I will say, we've sometimes talked about using the status bar more fully (i.e. status icons, persistent error items that require the user to dismiss them, etc.)  It might make sense to widen the status bar if that arises.

> I was unsure what element should get the Gtk.STYLE_CLASS_SIDEBAR.  What does
> that even do?

It was added by Jon McCann in commit 79d0ea5a, bug #720785.  It's not explained in the ticket, but I vaguely recall talking about it with him in Montreal.  We should leave it in, if at all possible.

> Other than that, is there more work to be done, or should I rebase this and
> commit?

No, I think that wraps it up.  Please rebase and commit!

I noticed one bug before commiting -- the conversation list grew if you 
opened it in the three-pane view.  I've snuck a fix in for that, should 
you want to review it post facto.

No problem.  Very relieved to see this make it in for 0.10.

Folder list is the left sidebar. There's no way to show/hide it, so I wonder why this is marked as RESOLVED FIXED.

What you can do is switch to two-pane view and then resize the folder list to the minimum. But this is another thing.

Anyway, all new work on sidebar should take bug 730712 in account.

I read here:
https://bugzilla.gnome.org/show_bug.cgi?id=714391#c6

that this bug implemented the switch to 2-pane mode. The subject was misleading...