Allow recipe list to stretch to use all vertical space available#362
Allow recipe list to stretch to use all vertical space available#362jBugman wants to merge 1 commit into
Conversation
augenfrosch
left a comment
There was a problem hiding this comment.
Thanks for the PR!
I definitely agree that the current UI could be improved to use the available window size better. The approach implemented in your PR does come with some (minor) caveats, see my comments. I personally also feel like keeping the food and potion select panels the same relatively small size is a bit awkward.
#305 is related to this (it currently lacks a description, but is based on a request from the Discord server), which, depending on how it is implemented, could maybe achieve something similar (especially if the implementation allows for sizes depending on the available space).
So maybe a different, more involved approach that calculates all of the panel sizes and allows for customisation/resizing would be better (but definitely more difficult to implement).
| .ctx() | ||
| .data(|data| data.get_temp::<f32>(reserved_id)) | ||
| .unwrap_or(f32::INFINITY); | ||
| (budget - reserved).max(recipe_table_min_height(ui)) |
There was a problem hiding this comment.
The argument egui::Ui passed to recipe_table_min_height here has different item spacing than what the panel uses, since it is modified inside the panel in recipe_select.rs (first line after the group is created at the start of the egui::Widget::ui() implementation), so the calculated minimum size differs.
| ui.ctx() | ||
| .data_mut(|data| data.insert_temp(reserved_id, reserved)); |
There was a problem hiding this comment.
Having the size be "incrementally" be updated causes the sizes to change over a few frames:
screen_recording.mov
(probably need to step through the video frame-by-frame to clearly see it)
I personally feel like this should be avoided, probably by directly calculating the final sizes of the panels.
|
Thanks for the feedback. If there is already work underway to allow real customization, I don't really see the point in my changes then, since those would be conflicting anyway, it's OK to close. Speaking of food and potion, I intentionally left them small because I see usage pattern for them pretty different. You set up it basically once per level/gear set and forget and search is a better tool for that IMO. But on the other hand there is a collapse option, so maybe having all 3 sections be equal by default is fine. After thinking about it since it feels like an on/off toggle in addition to delete button would be useful. At least in how I used it, consumables are for harder stuff and for easier missions or some legacy crafts there is no point, but next consumable would probably be the same again. So instead of deleting and re-adding it would be easier to toggle if you have it on currently in game. |
As far as I know, there isn't anyone actively working on it. I have some vague ideas about how I would implement it, but I don't have any concrete plans. But I do think a more generally resizeable/customisable UI would be better (or at least less likely to come with unwanted changes / downsides for some users). So I guess it is up to you if you want to keep your PR open or close it.
For food and potions, you generally only need the current expansion's level-cap ones, so you generally don't need more than 6 rows (3 if you only care about HQ) to show the most commonly selected options. My comment was mostly just about it looking off to me, with a giant recipe search list and the small consumable select panels below that, so I think having them scale somewhat would look better.
Related to that, I've been thinking about a potential redesign of the recipe & consumable search panels, where an option is selected by clicking on the row, instead of the current select button. That could allow for the consumables to be deselected by clicking on the selected row again, which, combined with my previous point, would probably achieve a similar effect in most situations. Or, I guess, the select button could turn into a deselect button, but the current localised text is already "problematic" (especially the German translation, where the select text is already not the best translation to save space), so not sure if that would work out. But all in all, I think it would probably be better to discuss significant UI changes on the Discord server, which would also make it easier for others to give feedback on the UI/UX design. |
51687b3 to
436eb66
Compare
|
@augenfrosch Did a pass fixing issues you've mentioned, at least I can't reproduce size-blinking. It also scales panels a bit more evenly. |



Hi, here is a somewhat opinionated change based on the idea that we should use more space when the screen resolution and font size allow it.
Nothing changes for smaller layouts, but when possible, we use the full vertical space, with the recipe list being the only element that stretches. The containers on the right stretch too; in my opinion, it looked a bit odd to leave them at a fixed height.
I see that since I started working on this, recipe filtering by job has been implemented by someone else, which should alleviate the current UX hurdles significantly. This change was my second issue. Feel free to reject it if it goes against the general direction, since I did not communicate it in advance.
Large size target

"Default" smaller screen layout, where we even have scrolling still.

Vertical "mobile" layout without changes as well
