[enhancement]: Reverse the queue list - Latest entry should be at the top

[ufuksarp]

Is there an existing issue for this?

• I have searched the existing issues

Contact Details

No response

What should this feature add?

In the queue list, latest entry should be at the top for better UX, not at the bottom. You have to scroll to the bottom to see the latest entry in this current implementation.

Alternatives

No response

Additional Content

No response

[psychedelicious]

I'd like to get more feedback on this. The way it's laid out makes sense to me right now, but I don't have a super strong opinion on it.

If somebody wanted to try out sorting with the latest entry at the top, I think this would be pretty straightforward:

• list_queue_items() in invokeai/app/services/session_queue/session_queue_sqlite.py: update the sorting in the SQL query
• queueItemsAdapter in invokeai/frontend/web/src/services/api/endpoints/queue.ts: match the sorting to the SQL query

[RicoRaw]

I think this is a great idea. I think giving users the option for sort order (newest or oldest) would be the best implementation of this. It shouldn't be hard coded in reverse.
Additionally, an "auto-prune" option would be a nice toggle option to add. During my most creative brainstorming sessions, I find it burdensome to have to keep clicking the "prune" button. I know it seems lazy on the surface, but when generating thousands of generations per session, scrolling and pruning gets very monotonous.

[Jonseed]

I just came here because I was also thinking reverse chronological order would make more sense too, otherwise you have to scroll all the way to the bottom to see your last job(s), or prune the jobs to be able to see your last job(s) on screen. A sort button could also work to easily change the sort order.

[psychedelicious]

We recent redesigned the image gallery to use virtualized list that renders all images at once. I think moving the queue to use a similar strategy could be the right move here and also make it much simpler to implement this.

The gallery strategy is now:

• Load a list of all image names (UUIDs).
• Render a virtualized list of the image names, which creates DOM elements only for the images that are visible.
• As the user scrolls, the range of visible images changes and we load the full image objects for the new range.

This is enabled with two different queries:

1. Get all image names for the gallery view, including the selected board, category, sort, search term.
2. Get the full image DTO objects for a list of image names. This is called as the visible range changes. Only objects that we do not already have cached are fetched.

We could follow this same strategy for the queue. User could sort by some of the relevant columns, filter, etc. It's a bit simpler than the gallery implementation which has special handling for starred vs unstarred images. Much of the same frontend logic could just copied over from the gallery.

[csehatt741]

@psychedelicious, as for the visual representation, should a sort button be added next to column names

and/or a Queue Settings button added which would open a modal where sorting and filtering could be configured

[psychedelicious]

@csehatt741 I think a sort icon next to the column names is the best UX, given the data is displayed as a table. Sortable fields might include #, Status and completed_at (this is not currently a column). I doubt the utility of having a column for batch field values, maybe it can go to make room for completed_at.

[ufuksarp]

Will this persist through sessions? I think it should.

[csehatt741]

This is just a draft PR, work is still in-progress