feat(ui): Move Gallery to the Bottom

[joshistoast]

Summary

Moves the gallery panel to the bottom of the page and renders queued/in-progress images directly in the image grid.

Originally, the plan was to duplicate much of the gallery functionality into a new Generate tab called "Stage". After reconsidering the current gallery layout, the available screen space, and the cost of duplicating similar features, I decided to solve both problems at once: bring the relevant Stage concepts into the gallery and relocate the gallery to a more efficient position.

What changed

• Moved the gallery panel to the bottom of the page
• Added queued and in-progress items to the board image grid
• Reworked the gallery panel's expanded and collapsed states
• Moved board selection into a sidebar inside the gallery panel
• Added a minimized boards sidebar state that still surfaces thumbnails and quick actions

Details

Bottom gallery panel

The gallery now lives in a bottom panel with expanded and collapsed states, similar to the previous implementation. Instead of using a floating button to toggle, it now uses a full-width bar with an expand button that displays the currently selected board.

Board sidebar

Board selection now lives in a resizable sidebar within the gallery panel. Like the previous version, it can be reduced in size, but it is no longer fully collapsed. In its minimized state, it still shows thumbnails and preserves quick actions such as:

• expand
• search
• add board

Queued and in-progress items in the grid

Queued and in-progress items now render directly in their respective board grids, providing more immediate visual feedback about the current state of a batch.

Rationale

This avoids introducing a separate Stage surface with overlapping functionality, makes better use of available space, and improves visibility into active generation work without requiring the user to switch contexts.

Related Issues / Discussions

QA Instructions

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[joshistoast]

Aww shucks, merge conflicts

[DustyShoe]

My main concern with this layout is the loss of screen real estate for the main image.

In the current layout, the central preview gets most of the available space, which makes sense for an image generation tool. Both side panels can be collapsed and the gallery scrolls vertically, allowing a large number of thumbnails to be visible while still keeping the main image large.

Even if the gallery occupies a significant portion of the screen area, there is still plenty of vertical space left for the preview.

In this proposed layout, the gallery competes with the preview for vertical space. If the gallery is expanded, the main image ends up confined to a relatively small area.

Another concern is horizontal scrolling in the gallery. On desktop this tends to feel awkward, especially when vertical scrolling works well and allows many more items to be visible at once.

The prompt and generation controls are also quite space-hungry. In the current layout the side panel provides enough width to comfortably work with longer prompts. In a narrower panel this could quickly become cramped.

Overall, the current layout seems to make better use of desktop screen space by prioritizing the preview area while still keeping the gallery and controls accessible.

The proposed layout feels more fitting for mobile devices in portrait orientation (with some caveats). I’d suggest revisiting it once a dedicated mobile UI is being considered.

Honestly, I’d rather see your "Stage" project come to life than refactor the current gallery view, which is already convenient and very effective.

[joshistoast]

@DustyShoe Thanks for the feedback, allow me to further clarify the rationale here.

In the current layout, the central preview gets most of the available space, which makes sense for an image generation tool. Both side panels can be collapsed and the gallery scrolls vertically, allowing a large number of thumbnails to be visible while still keeping the main image large.

Even if the gallery occupies a significant portion of the screen area, there is still plenty of vertical space left for the preview.

In this proposed layout, the gallery competes with the preview for vertical space. If the gallery is expanded, the main image ends up confined to a relatively small area.

Overall, the current layout seems to make better use of desktop screen space by prioritizing the preview area while still keeping the gallery and controls accessible.

When the gallery is expanded and anything short of 16x9 aspect ratio, the left and right sidebars pinch the preview image into the middle and squash it. In terms of smarter use of screen real estate, this keeps the preview space more available for various aspect ratios. At the same time the left panel pushes left, this pushes up.

As for canvas, more room is now available for managing layers, and less UI gymnastics is required to view and manage the gallery while layers are open.

Another concern is horizontal scrolling in the gallery. On desktop this tends to feel awkward, especially when vertical scrolling works well and allows many more items to be visible at once.

It definitely is, and can be made less awkward by dragging it to your preferred height and setting your preferred columns. On the scale of awkwardness however, it's definitely lower than the current implementation when canvas layers also come into play, and when the browser window is square and pinching the preview area.

The proposed layout feels more fitting for mobile devices in portrait orientation (with some caveats). I’d suggest revisiting it once a dedicated mobile UI is being considered.

Layouts that work better on more aspect ratios are more desirable, no?

Honestly, I’d rather see your "Stage" project come to life than refactor the current gallery view, which is already convenient and very effective.

The only difference between the gallery and the stage grid view, would've been screen real estate and showing in progress and queued items. So to avoid unnecessary code and feature duplication, and fixing the existing gallery UI shortcomings (everything tucked away to conserve space) this would hit 2 birds with 1 stone and is the smarter approach.

The list view for the stage feature is still planned, and I've even been having some fun ideas for how we might show the changing params like a git tree.

Overall the right panel is doing too much in too little space, and doesn't work well for aspect ratios short of 16x9. This better preserves the preview area space, gives gallery features room to exist, and is a smarter use of my proposed grid stage view.

[DustyShoe]

A drastic change to the main working areas of the app like this should probably be discussed more broadly before moving forward.

It would make sense to gather feedback from more users. Our individual opinions alone (yours or mine) are not enough to justify such a significant layout change.

In terms of smarter use of screen real estate, this keeps the preview space more available for various aspect ratios. At the same time the left panel pushes left, this pushes up.

I'm not sure how this actually increases available space. The bottom gallery layout consumes a significant amount of vertical space, which directly reduces the height available for the preview.

Also, most desktop displays today are 16:9 or wider. Because of that, vertical sidebars tend to work better on desktop layouts since they use horizontal space while preserving vertical room for the preview.

[DustyShoe]

I have a few suggestions.

Blender as an example: give users the ability to create their own panels and assign them specific roles.

Krita as another example: make panels behave like dockers, allowing users to move them around, resize them, and add or remove elements.

[joshistoast]

I have a few suggestions.

Blender as an example: give users the ability to create their own panels and assign them specific roles.

Krita as another example: make panels behave like dockers, allowing users to move them around, resize them, and add or remove elements.

This is about improving the gallery implementation and combining it with my stage features, customizable panels is far out of scope for this. It would be nice to have in the future though, but first the current dockview implementation needs to be stronger. In the words of psychedelicious:

We got partway into implementing that before needing to back out and do a static layout. So the current code is working around dockviews intended use case somewhat

A future PR can address the current dockview setup

[DustyShoe]

This is about improving the gallery implementation

I'm sorry, but the layout proposed in the mockup does not look like an improvement. You're removing the ability to use the viewer as a simple image browser where a large part of the screen can be dedicated to the image preview.

I want to see a good chunk of my gallery and the current image at full size at the same time. I'm pretty sure i'm not alone here.

I think I've already made enough points explaining why I object to the proposed layout, and continuing this discussion here probably won't lead anywhere. Instead it would be better to bring this to the broader community and gather more feedback.