Split header

[jeremypw]

Fixes #2456

Splits header with sidebar header just containing the close button
Moving or adding other tools to the sidebar header is left for further PRs as required.

[alainm23]

The design change feels much better, just one question. There is a reason why the navigation buttons (back and forward) are aligned to the center and not to the right?

[danirabbit]

I think the navigation buttons should stay in the right side pane with the view since that's the thing that they take action on. All of our prior art has these buttons in the right side pane as well.

The reason the back button is in the sidebar in System Settings is because it does take action on the entire view including the sidebar there. But here, going back or forward doesn't change the sidebar it just changes the view

[jeremypw]

@danirabbit OK. Is there any other widget that can be moved into the sidebar header to save space on the rh pane? For comparison, Gnome Files has the AppMenu there.

[danirabbit]

GNOME Files has 3 menus, 2 of which are in the right side pane

A menu in the sidebar for some app-wide functions

A menu on the pathbar for actions specific to that folder/path:

A menu for view options

So we already have 2 fewer menus than GNOME Files and 1 fewer menus in the right side pane 😅

[jeremypw]

@danirabbit So nothing in the sidebar header except the close button? If that is the case I am inclined to withdraw this PR as it achieves little and squashes up the widgets in the rh toolbar.

[jeremypw]

Appearance after reversion:

[jeremypw]

@teamcons If we are going to enforce the mantra that the sidebar header can only contain things that act on the sidebar then a search button there would be expected to search amongst the bookmarks, not the view. A search button that acts on the view should be in the view header.

[jeremypw]

@danirabbit I don't think you ever made it clear which widgets should appear in the sidebar header? Do you want to follow Gnome?

[danirabbit]

@jeremypw hey sorry for not following up! Basically the long term idea of having the top level panes is to:

1. Facilitate responsive, so you have really simple and obvious break points where you split the app into pages, hide sidebars, etc
2. Make sure that controls are closer to the objects they take action on

So for example if we're thinking of looking at one page at a time in a tiled or mobile layout, having the navigation buttons in the sidebar means they would be hidden most of the time and make them harder to get to. So this would be a good place to put controls that are infrequently accessed like maybe app-wide settings that you don't toggle frequently, but not a great place to put controls that you access all the time.

So #2509 (comment) is probably the right think going off of that, but it does look pretty clunky and has a lot of empty space here at the top. So I'm not sure this totally makes sense for Files yet unless we rethink how more of these controls are laid out. I'm +1 on waiting to do this sort of thing as there's no obvious gain here yet

[jeremypw]

@danirabbit Thanks for the explanation. The "responsiveness" metric does give a rational for what goes where that I wasn't really thinking of. I am not sure whether you are envisaging elementaryos for mobiles or other small screen devices at some point or just want to give the user the option of smaller usable windows. Anyway, its something I'll try to bear in mind.

[jeremypw]

Maybe open a discussion about how Files should respond to limited width constraint?

[jeremypw]

Converting to draft for now to keep the discussion visible.

[teamcons]

regardless of the responsiveness angle,

Everything is smushed to the right, and theres not much candidate for the left pane.
i keep trying to think of a way to use the empty space on left pane - and it isnt a good mindset at all, to look for ways to use the space just for the sake of using it

it just doesnt feel like this works for Pantheon Files. Not for now at least. Maybe for Gnome Files and others, but, here, :/

no idea