feat(ui): Move Gallery to the Bottom#8950
feat(ui): Move Gallery to the Bottom#8950joshistoast wants to merge 17 commits intoinvoke-ai:mainfrom
Conversation
joshistoast
changed the title
|
Aww shucks, merge conflicts |
|
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. |
|
@DustyShoe Thanks for the feedback, allow me to further clarify the rationale here.
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.
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.
Layouts that work better on more aspect ratios are more desirable, no?
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. |
|
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.
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. |
|
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:
A future PR can address the current dockview setup |
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. |
- uses existing boards list components instead of creating new ones - make minimized search button work - UI improvements
when panel is collapsed, remove the ugly bottom border
joshistoast
force-pushed
the
feat/gallery-redux
branch
from
7b4492d to
1b70888
Compare
- Centralize panel state - Create panel state helpers - Replace `GALLERY_PANEL_ID` with `BOTTOM_GALLERY_PANEL_ID`
joshistoast
requested review from
Pfannkuchensack,
blessedcoolant,
dunkeroni and
lstein
as code owners
|
As a user rather than a programmer, I believe the optimal solution is full customisability, enabling users to arrange windows and buttons according to their preferences. A high-tech program should follow the most advanced solution. Corel Draw realised this two decades ago. :) |
|
@zaum Agreed, but since invoke doesn't yet have a finished dockview implementation we're currently left with trying to create good static layouts. Until then, this is an overall better use of space for the gallery. In a future PR, we can try fixing the dockview setup, and when that happens the current gallery will need to get redesigned into something like this regardless. I also agree that community feedback is good, so if you have anything to contribute or say about this PR I'd love to hear it. |
I feel with this new layout that we're sacrificing vertical space on the left that's used by linear and linear Workflows. I already have to scroll to find things there, and now it's going to get much worse. I understand that these panels can collapse, but I really like having my gallery open to work on existing images or recall parameters, etc. and collapsing panels hasn't yet been something I've done. |
|
OK, I get the gist of the PR. Move the Boards and Gallery panels down to a new collapsible panel at the bottom of the window that spans the entire width. Also, incorporate the staging into the gallery. But where are you suggesting the layers panel go? If they stay in the same place, you gain no space for the canvas. If the move to the left panel, then that gets even more cramped than it is now, since it loses some vertical space due to the new spanning board/gallery combo panel. If it is incorporated into the new board/gallery panel, then you don't have much vertical area for many layers. I am not yet convinced that this would offer any additional space for the canvas. Some actual screenshots of it in action might help convince me and others, as the existing boxed-out design approach can only show so much. Moving the existing layout around like this might make some people happy, but would also disrupt many others. How useful you find it will depend on many factors. The kind of aspect ratios you are generating, the resolution and aspect ratio of the monitor you use, and even the UI scaling factor on your monitor. You are not going to make everyone happy with a single fixed layout. Instead of moving the existing layout around, I would prefer a flexible Docker solution (I know it's out of scope for this PR). I would be happier if this PR were reduced in scope to just moving the staging area into the gallery. This could be done without moving any panels around. If you still think the layout change is useful, then create a separate PR and have it selectable by the user. But again, a properly docked layout would be far superior. Moving the staging controls into the gallery could gain some usable canvas space. At times, I found it can get in the way. But I reserve judgment on this and worry that some oddities could pop up when using it, For starters, you would lose sight of the staging area if you change the gallery you are showing by changing the board, unless it appears at the top of every gallery board. It is unclear how this would work. More fundamentally, you are changing the paradigm of the staging area. Currently, the images in the staging area are not actually saved in a board. They are saved into a board when the save icon is clicked; it then saves the currently selected image into the auto-add assigned board. This change would alter how that looks to the user. What happens if you change the auto-add board, then generate more into staging? Maybe I am not picturing how this would work correctly. How are you proposing to incorporate the existing staging controls and functionality into the gallery? For example. What happens when you click the accept button, do all the staged images in the gallery disappear? The issue of the staging area taking up valuable canvas could be overcome by a less drastic change, like making the staging area collapsible. |
In the Generate tab, it serves primarily as an image viewer, focused on displaying the current image, so no work is done there other than viewing.
This is not an issue for the vast majority of users, as the overwhelming majority of screens in use today have a 16:9 or even wider aspect ratio (such as 21:9 WQHD). If there are significant cases where less forgiving aspect ratios create real problems, it would be helpful to provide specific examples.
This issue is only half-valid for very wide landscape images. When viewing portrait images and even some landscape ratios at minimum side panel widths, vertical space is the limiting factor. In these cases, moving the gallery to the bottom doesn’t solve the problem. It swaps reduced width for reduced height which is more valuable.
These are occasional settings and don't need to be visible at all times; keeping them tucked away avoids unnecessary distraction and clutter. I would have liked it if you had pointed out the exact ones that need to be exposed.
A full-width bar that can't be collapsed any further is less space-efficient than a small floating toggle, which doesn't shrink the viewer image. Long prompts and scroll:
This is beneficial only for the Stage idea. For your Stage concept:Showing in-progress and queued images directly in the gallery is only a nuisance. The main thing it does is showing the number of images queued, but this is already covered by the queue counter. And queueing a large number of generations will shift the gallery content, which will quickly become annoying. This should really be optional for your Stage concept. Canvas: I believe this concept could be useful when re-conceptualized as a seperate tab/view after we get customizable layouts. |
|
I think it's great to explore ways to potentially better utilize screen space, but with apologies to the work that was put into this, I have to agree with the majority in that this proposed layout does not appeal to me from a user's perspective. Although I can see the benefit for the use case of browsing through wider images, I personally tend to work with portrait orientation more often than landscape, so I find the vertical real-estate more valuable for the image area, particularly on your typical 16:9 or 16:10 monitors that have more room to spare horizontally. Regarding the notion of moving the staging area into the gallery, I'm afraid I don't see what that's trying to solve. Is it just to avoid having the staging area in the canvas itself? I suppose this has never been a bother to me, as the canvas can still be panned and zoomed while previewing the options, and it serves as a prominent reminder that a selection must be made before continuing with other canvas operations. Putting the staged temporary images into the otherwise permanent gallery grid, I think, overloads its functionality in a confusing way. Having a separate temporary panel appear in the right-hand bar for staging would be tenable, perhaps, if there's a great desire to get it out of the canvas area, but I'm personally ambivalent to that. |
|
If Invoke were a desktop app I would propose creating separate floating windows for the image generation parameters, the galleries, and the preview area. The main window would be the image viewer in text generation mode, and the canvas in canvas mode. The user could hide and unhide the floating windows, pin their positions, and anchor them to the sides of the main window, and have a preset feature that allows them to snapshot and retore the geometry. However, in a web browser app, this type of application doesn't seem to work all that well due to limitations on multiple screens and inter-window communication. In addition, somewhat selfishly, I love using Invoke on tablets, and multiple windows would be unworkable on this platform. In fact, I'm not sure how well the proposed gallery-at-the-bottom layout would work on a typical platform's aspect ratio. |
8 participants
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.
Why the current right-sidebar gallery is limiting
The current gallery layout gives an entire sidebar to parameters on the left and another for the gallery on the right, which reduces the width available to the central working area. This becomes more noticeable on narrower windows, split-screen setups, and aspect ratios that are less forgiving than 16:9.
That constraint also affects the gallery itself. Because a large amount of gallery functionality has to fit into a narrow sidebar, several actions and views are hidden behind toggles, dropdowns, or expandable controls rather than being visible at a glance.
On canvas, the issue is more pronounced because the right sidebar must accommodate both gallery and layers. As those surfaces compete for the same space, the primary working area is compressed further and requires more UI switching to access related functionality.
This PR explores a layout that reduces pressure on the right sidebar, gives gallery features more room, and makes queued or in-progress work visible directly in the board grid.
What changed
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:
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
What's Newcopy (if doing a release after this PR)