Scene list toolbar

[WithoutPants]

Adds a sticky top toolbar to the scenes query page. The sticky toolbar includes buttons to edit the filter, toggle the sidebar,

The results summary has been moved to be left-justified on the same row as the sort, page and display mode selectors. This row is not stickied.

A play button is included, and the new Scene button is moved from the navbar to the toolbar.

The toggle sidebar button has been moved to the right side of the toolbar, and removed from the sidebar.

On mobile viewports, the sidebar includes a button to close the sidebar at the bottom:

When an item is selected, the toolbar changes to show the number selected, with buttons to select all or none:

Related discussion here: https://discourse.stashapp.cc/t/query-page-redesign/2064/27

[cj12312021]

Keeping the pills in the same location as they've been creates a pretty big hole in your design. The consolidation of the filters and all its properties into a neat location was the more appealing part of your original proposal, which solved the balance issues introduced when you uncentered the toolbar weeks ago. These issues have returned, and the extraction of the filter button outside the sidebar into an isolated location on the left no longer makes as much sense. I wasn't the biggest fan of making this area stick, but this change makes that decision less appealing. You've introduced so much unused space that will be taking up unnecessary real estate.

The plan B you proposed in the Discourse topic would have been preferable. It wasn't perfect, but it fit into the proposed design and would have been pretty flexible for users to patch to their liking.

On mobile, my thinking was that you would simply move that tag pill area down as you currently have it in your screenshot (preferably with the same design style you land on). That or move the other button down to keep the pills and the filter button on the same row. Reverting to the old design on mobile is more tolerable here. I even think the number on the tag button might be a sufficient indicator to let users know that filters have been applied, and simply show the active filters in the tag window when activated.

[cj12312021]

In practice, the experience of clicking the expand sidebar button on the far right, then mousing over to the far left to use the sidebar is not great. Keeping @echo6ix's suggestion for the sidebar button, which fixes the button to the top left, would work better here.

[WithoutPants]

Keeping the pills in the same location as they've been creates a pretty big hole in your design. The consolidation of the filters and all its properties into a neat location was the more appealing part of your original proposal, which solved the balance issues introduced when you uncentered the toolbar weeks ago.

I mentioned in this post that I'd be separating the filter tags changes into a separate PR to limit the scope of the code changes for this PR, but I neglected to mention it in the description for this PR:

In any case, I’m going to push the filter tag stuff into a PR separate from the rest of the toolbar stuff, since whichever way we go, it’s a chunk of changes on its own. For the time being, I’ll leave the filter tags at the top of the page.

In the interests of keeping design discussion in one place, I'm going to suggest discussing this in the Discourse design post.

[cj12312021]

Ah, okay, I only had a quick read through the first paragraph of your Discourse message via email before heading to bed and woke up to this PR. I may have been able to squeeze in a few more minutes of sleep had I caught that this PR did not complete that work. That news is certainly a relief.

It sounds like the last feedback about the expand sidebar button's usability is the only bit here that is relevant. I can move that over shortly.

[SyZeeGee]

@WithoutPants Maybe missed it myself, but to "select all" (on page) requires a single item to be selected, whereas before iirc, it was just always there? This requires to go to the List view I think to select an item (ex: if on wall view)

Seems like the intention may have been to instantiate the selection widget / component next to here, even if no selections?

With an item selected

Seems like a new design here - before a dropdown with select all, select none iirc.
Also notice how the side pane toggle disappears (which is fine)

[SyZeeGee]

Also minor, zindex issue (I think this PR is associated) - with selections, the dropdown has more entries that can get clipped - even without there is minor overlap.