To verbalize this, where would you suggest the split occur?  At first (and looking at GNOME Tweak), I thought you meant the folder list and the conversation list, but I could see this split occurring between the conversation list and viewer too.  Or should we have three headerbars?  That seems excessive.  But from your later comments, I think you mean between the conversation list and viewer.

But if it was between the folder and conversation lists, that might give us a place to put a "hide folder list" button.

I guess I'm a little cooler than you are on the idea.  The biggest advantage it seems to offer is to give the inline composer a place to put its buttons.  That's not insignificant.  If the idea is that they replace the Archive/Trash and Search box, I'd have to ponder that.  Currently we display the account, folder, and unread count in the center of the headerbar; where would that information go in this split model?

Ultimately I think I need to see some mock-ups of how this all ties together, what buttons go where and how it looks with the inline and inline-new composers.  I'm a little worried that we're trying to solve a problem we don't have at the moment.

Created attachment 296253 [details]
mockup of main configuration

I was thinking of putting the divider between the conversation list and the conversation viewer.  It'd always be there, regardless of what happens to the folder list.    I think having three sections would be too busy.  But maybe two is too many too.

After thinking about it some more, I realized that the folder list and the conversation list are all about finding messages.  The conversation viewer is about reading, reacting to, and manipulating messages.  Of the toolbar widgets, only the search box is about finding messages; all the others are for replying or manipulating messages.  So in this mockup, I've put the search box over on the left hand side and almost all of the other buttons over on the right hand side.  I've left the new message button all the way on the left, because I do like that primacy for it.  Arguably, it belongs on the right-hand side, since it isn't for finding messages.

I put the current title on the right-hand side, although the information in presents is really relevant for the left.  Although there is extra room on the left right now, it'd get pretty tight if we hid the folder list.  We might consider using a search button that expands to a search box when clicked.  This wouldn't actually make it any harder to use - you still have to click on it today to get keyboard focus.

Did we put the account name, folder name, and unread count into the header because it's vitally important to see them, or because there wasn't anything else we were more interested in sticking up there.  I'd be tempted to leave them out completely and set the title on the right-hand side from the current conversation.

Created attachment 296255 [details]
mockup of new message configuration

Here's a rough idea of how the new message mode would look.  Of all the buttons hidden in this mode, only the "Empty Spam or Trash Folders" button would be active.  The close button would close the composer, restoring the previous view.  This means it'd take two clicks to close Geary from this state, but I'm okay with that.  The detach button would work as usual.

I think that this is where the big win is.  In the main view, we get a slightly more logical layout at the cost of a bit more complexity.  But here we get to hide a lot of useless buttons and avoid the double headerbar look.

> Did we put the account name, folder name, and unread count into the header
> because it's vitally important to see them, or because there wasn't anything
> else we were more interested in sticking up there.

They're not *vital*; the other obvious use for the middle section would be the application name itself.  The current information does seem more relevant if/when we add hiding the folder list.

I definitely agree that the new message mockup is a win.  Not only is it more efficient with screen real estate, it also just looks cleaner and makes the application appear more fluid, changing its configuration to match whatever task is at hand.

The search bar I'm having some trouble with.  I've just never seen an application or web site with the search bar in the middle like that (unless it's dead-center, i.e. a page dedicated to searching).  The trend in GNOME is to hide the search bar and replace it with a search toggle button that reveals the search text box when pressed, like you suggested.  This mockup might be a case for something like that.

When we were developing the search folder early on, we discussed having an always-visible search folder in the sidebar that, when selected, would display the search text box at the top of the conversation list.  That would be the account-wide search.  The thinking was that there would be a search text box at the top of all folders' conversation lists that would allow for folder-wide searching, but those would be hidden by default and revealed by a button or accelerator.  Let's not worry about all that at the moment, but some food for thought.

What strikes me in your mockups is that the only thing I hesitate over is the search text box.  One other idea -- not even a nit, but a suggestion -- instead of the account/folder/unseen in the middle of the right headerbar, we could put the conversation subject; viola, now we don't need to list the subject in the conversation viewer.

Otherwise I now see what you're driving at.  This is starting to look pretty interesting.

(In reply to Jim Nelson from comment #4)
> The search bar I'm having some trouble with.  I've just never seen an
> application or web site with the search bar in the middle like that (unless
> it's dead-center, i.e. a page dedicated to searching).  The trend in GNOME
> is to hide the search bar and replace it with a search toggle button that
> reveals the search text box when pressed, like you suggested.  This mockup
> might be a case for something like that.

My original thought was to leave it on the right, just because it feels unnatural any place else.  But I think getting things placed more logically overrules this, so we should find some way to make search work on the left of the layout.

FWIW, the tweak tool puts a search button on the way on the left-hand side.
> 
> When we were developing the search folder early on, we discussed having an
> always-visible search folder in the sidebar that, when selected, would
> display the search text box at the top of the conversation list.  That would
> be the account-wide search.  The thinking was that there would be a search
> text box at the top of all folders' conversation lists that would allow for
> folder-wide searching, but those would be hidden by default and revealed by
> a button or accelerator.  Let's not worry about all that at the moment, but
> some food for thought.

Just this afternoon, I was looking at the search "folder" and wondered, why does it say "Search" instead of actually giving my search query.  And if the label is the query, why can't I have multiple queries.  And if I have multiple queries, why shouldn't I be able to edit them in the folder list?  This is quickly wandering far from the aegis of this bug, so I'll just say that I agree that the toolbar-level search box maybe should be re-thought.
> 
> What strikes me in your mockups is that the only thing I hesitate over is
> the search text box.  One other idea -- not even a nit, but a suggestion --
> instead of the account/folder/unseen in the middle of the right headerbar,
> we could put the conversation subject; viola, now we don't need to list the
> subject in the conversation viewer.

I considered suggesting this, but I was afraid of introducing too many ideas at once.  I'm glad it seems like a natural extension.  If we get rid of the search box in the header, we could easily put the current info as a title for the left-hand half of the headerbar.

One thing we should keep in mind is that new versions of GTK apparently don't like ellipsizing titles in headerbars.  Since subjects can be arbitrarily long, we should make sure that they ellipsize correctly.

I think the first step will be to rearrange the nesting of the paneds.  Since that seemed necessary for the vertical layout, as well, I'll get started there.

I pushed some work in progress to wip/743960-split-header.  The basic functionality is there, but it'll trip over itself in a lot of corner cases, I'm sure.  Areas that I know need improvement:

1) The first time you run this branch, the left two columns will be much skinnier than they had been.  This is because the setting that used to set the width of the conversation list is now being used to set the combined width of the folder and conversation lists.  I haven't thought up a clever way to migrate the settings over, but we could just introduce a new setting with a sensible default and start using that.  People will lose their old setting, but they won't see something squashed.

2) If you have the close button set to show on the left, it'll show on the left side of the right-hand half of the headerbar.  My gut reaction is that this is wrong, but the tweak tool behaves the same way.  We probably want to test for such things and move it all the way over to the left.

2.5) But the composer will still show its close button on the left of the right-hand side, which is the right thing to do, I think.  Although it does mean that there will be two close buttons on the full headerbar.

3) If there is a gear menu, it will be all the way on the right.  This means that it'll be hidden when the full-pane composer is up, which is probably not a good thing.  My first instinct is to move it to the left-hand pane, so it'll always be visible.  But that may mess with people's expectation to always find this on the right side.   We may be able to add this to the composer's headerbar when we need it.

4) I haven't tested this with server-side decorations (a la Unity).  I expect breakage.

5) I think I've adjust the CSS so that there's a thin line between the paned's handle and the top of the paned composer under Adwaita.  But it looks a bit odd that there's no border on the left-hand side of the headerbar and headers.  You don't want the border all the way down the composer widget's right-hand side, though, because that gives you a double border along the editor.  Under Ambiance, there are no borders at all, but the different color for the headerbar gives you a better visual separation.

6) I've left the existing header in place on the conversation view side.  But I think we should consider moving that to the folder list side and/or putting the subject on the conversation view side.

7) The separator in the headerbar is aligned with the left side of the paned handle.  This isn't great, but I haven't thought of a better solution.  It looks worse in Ambiance than in Adwaita.

I actually only see one close button on the far right side (I'm running 14.10 Adwaita), but when the new inline composer is in place, there is still only one close button -- which is the composer's, it turns out, although it looks like I'm closing the application.  That's something we'll need to attack (although technically Trusty support is not required for the next release; I haven't tried this yet under Utopic or Vivid).

One thought: instead of a close button for the inline new composer, dedicated Save/Discard buttons (as we now have space for them).  This would obviate the need for a popup confirmation.  Another thought, not set in stone.  (I do worry about pressing Discard by accident and poof, gone.)

I think what I'm seeing as the next step would be replacing the search box with a search toggle button that, when toggled, reveals the search box (sitting at the top of the conversation list?)  Put the yorba/inbox (n) as the header on the left and the subject line on the right (we'll worry about ellipsizes/tooltips later).

I'm still on a weird fence about all this.  On one hand, I see a lot of things being taken care of by this -- in particular, the better new inline composer and more appropriate grouping of functions with views.  I still find the split headerbar kind of unnerving; I remember the first I saw it with tweak tool and thought it was an experiment and nothing more.  Could I get used to this?  I think so, but I'm concerned that Geary will look like no other application on the desktop (other than Tweak).  We might take this to the mailing list or blog when we feel more comfortable exhibiting it to the world and ask for input.  But I definitely think this is worth moving forward on.  It seems like you're making progress in leaps and bounds.  Don't worry about the fine nits quite yet, those we can attack later.  Right now I'm more interested in the overall vision and where it leads to.

(In reply to Jim Nelson from comment #7)
> I actually only see one close button on the far right side (I'm running
> 14.10 Adwaita), but when the new inline composer is in place, there is still
> only one close button -- which is the composer's, it turns out, although it
> looks like I'm closing the application.

This was intentional.  I didn't want two close buttons hanging around, so I decided "close" should close the current activity.  Maybe this isn't a good idea, though.
> 
> One thought: instead of a close button for the inline new composer,
> dedicated Save/Discard buttons (as we now have space for them).  This would
> obviate the need for a popup confirmation.

This is an interesting idea.  We'll still need the dialog, for other things that close the composer, so I'm worried about multiplying code paths.  But it would streamline things.

> I think what I'm seeing as the next step would be replacing the search box
> with a search toggle button that, when toggled, reveals the search box
> (sitting at the top of the conversation list?)  Put the yorba/inbox (n) as
> the header on the left and the subject line on the right (we'll worry about
> ellipsizes/tooltips later).

I feel like the search box should go at the top of the folder list, since search acts like a folder.  (This will also help the switch to a vertical layout.)  I wonder how much work it would take to make an editable row in the folder list view for search.  Also, would it be possible to have multiple search folders?

As for the general idea, I feel like I've seen a number of mockups using split headers, but gnome tweak is the only place I've seen it implemented.  I don't know if this is because the others haven't been implemented, the others were tried and found not to work, or if the general design has shifted.  Perhaps there's some Gnome designer who can provide some insight here.

It occurs to me that we could have a split header without drawing as much attention to it.  If we packed everything to the left in the left half and to the right in the right half and didn't put in the separator, you wouldn't notice it was split until opening the new composer changed the right half.  But this would rather restrict our design options.

Just a quick comment, Polari (https://wiki.gnome.org/Apps/Polari) is also using split headers.

That's good to know.

Do you happen to know offhand
1) Does Polari let you drag the separator between the channel list and the chat window?
2) What happens in Polari when the close button is on the left?

I've clone the repository, but I don't have the GTK version necessary to run master.

I used the split headerbar at home last night and am warming up to it.  I also see how this folds in with the hide/show folder list patch, and I'm beginning to feel more comfortable about landing this for 0.10.  (It's nice to see Polari's using this too.)

> This was intentional.  I didn't want two close buttons hanging around, so I
> decided "close" should close the current activity.  Maybe this isn't a good
> idea, though.

I think we need to find something else for this situation.  For me, the outermost close button means close window, always.  (This confusion is perhaps one downside to GtkHeaderBar.)

> I feel like the search box should go at the top of the folder list, since
> search acts like a folder.

That would be fine too.  Even if the search bar expanded across both, the big point is to reduce the clutter in the toolbar.

> I wonder how much work it would take to make an editable row in
> the folder list view for search.\

I don't think an editable row in the folder list is a good idea -- that will look like you're renaming a folder.  I suppose if there was a faded-out "Search..." you typed to replace that would help ... but I'm still leaning toward a more traditional search bar that creates a search folder.

>  Also, would it be possible to have multiple search folders?

Yep, although since we've never done it, there might be a bump here or there.  I would really like to have saved searches, but as mentioned before, that's a separate problem.

> It occurs to me that we could have a split header without drawing as much
> attention to it.

Naw, let's stick with this approach.  I'm feeling more confident about it now that I've tried it for a while.

One other thing that's simply a note for future reference: We should probably move the Empty Spam/Trash button to the left-side headerbar.  It's a folder operation, so it makes more sense there.

> 1) Does Polari let you drag the separator between the channel list and the
> chat window?

The latest version available in fedora (3.14.1) doesn't allow that. The size of the sidebar is fixed.

> 2) What happens in Polari when the close button is on the left?

I tried testing this, but moving the close button in gnome did not work. (using this guide http://askubuntu.com/questions/125765/how-do-i-add-minimize-maximize-buttons-to-gnome-shell-windows). I would expect the button to move all the way to the left, and therefore to a different header bar.

I looked into the polari source, and it looks like they're trying to move the close button all the way to the left.  Even if that isn't happening, we should probably go with that.

Assuming we're going to go with this, I think the big sticking point is what to do about the composer close button.  Jim suggested replacing it with a discard button and a save+close button.  I think we could use those in all the inline composer instances easily enough.  My question is, do we also use those in the detached composers?  On the one hand, consistency is nice, but on the other, it'd be a bit odd to have a top-level window without a close button.

Should these buttons always go on the right, or should they follow the close button side?

Moving the empty spam/trash button to the left makes sense.  I actually don't know how that button works -- does it make sense that it is active when you're not in one of those folders?  Should it only be visible when you are?

Should the undo button also move over there?  On the one hand, the actions that it undoes are on the right hand side, but undo might still be active when there's a new composer up.

Should we move the gear menu over to the left hand side?  Or should we make sure it's always next to the close button on the right hand side?

I assume we should move the database search update widget to stay with the search entry box?

There's an updated branch at wip/743960-split-header-2.  This one is based on the orientation switcher branch.  I've gone ahead with the custom close buttons.  Possibly inadvisedly, I use only these buttons even when the composer is detached.  I think it's an interesting idea, but I suspect it's too radical.  We may want to drop both custom close buttons and use the standard one with the dialog in this case.

I've grouped the close, detach, and send buttons together in a pill, since they all do something to windows.  At the moment, they're always at the right side of the window.  We could try to move them to be on the same side as the close button, but I don't know if people would actually appreciate that.  I did get the main window's close button to show up either on the far left or far right, depending on the theme.

The trash icon for the "Close and discard" button works, I think, but the save icon for "Close and save" looks too much like the inbox icon.  Perhaps we should reuse the drafts folder icon?

The search entry has been moved out of the headerbar and into a dedicated search bar.  This stretches all the way across the bottom of the left-hand-side headerbar.  This was easier to do than have it just line up with one of the two panes when they're side by side, and I actually like how it parallels with the status bar at the bottom of the window.

Into its space, I've moved the gear menu, the empty menu, and the account and folder names.  I hadn't realized before that the empty menu button actually had a menu attached to it.  Now that I know that, it's obvious it should always be active.  But if I didn't realize that this button launched a menu, I suspect few users will either.  I don't know what to do about this, offhand.

I've added the conversation subject as the title of the conversation headerbar.  I'm not sure I like it, though.  The subject can easily be long enough to fill the whole available space, which makes the header look very busy.  If there's some extra room, it looks fine, though, so maybe we should enforce some padding around it.  Perhaps we should use the subtitle to display some more information (total number of messages, number of unread messages, number of correspondents, names of correspondents, etc.)?

I think the search database update widget will properly obscure the search entry, but I haven't actually seen it in action.  The user will only see it if they happen to open the search bar while the update is happening, but I think that's okay.

Just a note: I mainly use the move conversations button, when selecting multiple conversations from conversations list (as currently it's not possible to move multiple conversations using drag and drop). This workflow feels wrong with the mark/label/move buttons being over the conversations view. (But I guess the best fix for this is to add drag and drop for multiple conversations?)

I also wanted to note that this clashes a bit with #713723

Beside this, I like the split headerbar :)

Right now, we just display a "n conversations selected" note in the conversation viewer when multiple conversations are selected.  If we displayed a little summary of each of those conversations, would that make it more obvious that the various mark and delete buttons will operate on those conversations?

I guess yes. This would be nicer.

Ok, lots of big (and good!) changes here.  Let me break down what I think here:

* The search button / revealed search box is great stuff.  No problem with it spanning both left columns.

* Regarding the empty button, yes it would help if there was a visual indicator of the drop-down menu.  We went through this with the mark/star button which also has a drop-down.  The standard Gtk widget for a button with a drop arrow presumes that the button has "default" function and the menu is only revealed if the arrow is pressed.  That didn't make sense then or with the empty button; I'd be happy if someone can come up with a standard visual indicator.  But that's probably best left for a separate ticket.

* Regarding Undo, current behavior is fine.  If the user wants to undo, they need to close the composer.  Unlike most applications, Geary's undo is a bit more of a "last resort" kind of operation (versus an app where the user might undo/redo a lot, i.e. a paint app where you want to see before and after).

* Gear menu, for better or worse, should always be next to the close button on the right-hand side.

* Database upgrade widget should remain with search text box; it's used to indicate that search is unavailable due to background indexing.  Bonus points would be to change the Search button icon to reflect that as well, but let's not worry about that for now.

* Yes, padding for the conversation header subject line.  I think adding the participants list beneath it would be fantastic.  Number of messages or unread ... I find that less interesting.  If we need to use a smaller font for the subject to get more text on the screen, I think that's worth exploring.  (<small> tag might be enough?)

* It would be great if either line is ellipsized to make a tooltip available with full text.

* For the composer, I would separate the Send button from the others.  It's kind of the big kahuna of operations you can perform with the composer.

* Regarding the other three, I think they should be in this order:

[Detach | Save | Trash]

I also think they should be to the right of the Send button, i.e. the farthest right-hand side of the headerbar.  They are, in a sense, like minimize/maximize/close.

* I agree that it's odd to have them on the detached composer.  Alas, I have to fall back on convention and ask for a close button.  We *could* have it as well as the trash/save buttons next to it.  I know we have to keep the "Save/Discard/Cancel?" dialog for certain code paths, but anything we can do to avoid displaying it, I'm all for.

* How hard would it be to do what mar-v-in asked in comment 16?  In interests of keeping this patch as contained as possible, that might be something to push off to another ticket.

Lots of stuff going on here.  Keep up the good work.  Very curious to see the next iteration -- I too am growing fond of this refresh and think it's a big step in the right direction.

Two quick reactions:

1) Putting the gear menu always next to the close button is going to be hard.  I initially tried to create a headerbar with three sections: folder, conversation, and close button.  But this ended up with padding and a visible seam between the conversation header and the close button.  So our options are:
a) Put the gear menu on the left, where it'll always be exposed.
b) Have the gear menu on the right, but only visible in the conversation view, not the composer view.
c) Do all sorts of gymnastics to inject the gear menu into the composer headerbar.

2) I made all of the composer header buttons into pillbuttons, since the send button needs to be raised.  But maybe the other three can be flat, like the close button (and how the detach button was before).  This would reinforce the parallel to the window management buttons.  Maybe this wouldn't looks so good in the new message state where there's also a close button, though.

Also, perhaps we could use [ Save | Trash | Detach ] for inline composers and change it to [ Save | Trash | Close ] for detached composers, for a bit more consistency.

I'll take a look at the rest and see what I can do.

> a) Put the gear menu on the left, where it'll always be exposed.
> b) Have the gear menu on the right, but only visible in the conversation
> view, not the composer view.
> c) Do all sorts of gymnastics to inject the gear menu into the composer
> headerbar.

Gah.  Unpleasant.  Unless you can point me to some precedent for putting the gear anywhere but on the right-hand side of the toolbar, I think that choice is off the table.

Does it have to be injected?  Could the composer headerbar simply have a gear menu tied to the same actions as the main toolbar, but only displayed when its in the INLINE_NEW state?

> 2) I made all of the composer header buttons into pillbuttons, since the
> send button needs to be raised.  But maybe the other three can be flat, like
> the close button (and how the detach button was before).

Could they all still be pill buttons, by the Send button is simply a solo pill button?  Sort of like the New Message and Undo buttons on Geary today.

> Also, perhaps we could use [ Save | Trash | Detach ] for inline composers
> and change it to [ Save | Trash | Close ] for detached composers, for a bit
> more consistency.

That would be fine.

I've just pushed three commits that should address most of your points.

The first rearranges how the window buttons on the composer work.  Now the Send button is by itself.  To its right, the close-and-save and close-and-discard buttons are together in a pill.  (Although I just noticed they're backwards from your preference.  I can fix that later.)  The detach button is separate, displayed without relief, and put on the side of the window close button.  The idea is that it takes the place of the close button for the attached composer, so the rest of the elements don't jump around at all when the window is detached.  (This also helps us avoid needing two pills, one with the detach button, one without.)

The second puts the gear menu on the right, and duplicates it in the composer headerbar.  This wasn't as nasty as I feared it would be.

The third adds the participants as a subtitle.  It also adds some padding around the title and subtitle and adds tooltips.

Once the folder-list branch lands, I'll rebase on top of that.  I'll also take that opportunity to squash away some redundant commits here.

Two things I noticed on the branch (both w/ the centered header text on the right-side headerbar):

* "No conversations selected." with a period doesn't look right here.  Made more sense when it was floating in the center of the view pane, but not as a header.

* It looks like the participants text field needs to be set to accept markup.  I received an email with a From: like this:

'Joe Smith via Paypal' via paypal

displayed in the headerbar as:

'Joe Smith via paypal' via paypal

I've rebased this onto master and pushed this as wip/743960-split-header-3.  I've removed that period and I think I've solved the markup issue by ensuring that we don't pass markup to the subtitle.  I don't have a test message handy, though.

I checked, the markup issue is fixed.  Thanks.