-
Notifications
You must be signed in to change notification settings - Fork 12
Resizable UI #649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: beta
Are you sure you want to change the base?
Resizable UI #649
Conversation
fix an issue where the top level children would not grow in the direction of the layout orientation
…sted focuse navigation
…n and automatically wraps for the given width
fix childGaps not being subtracted when calculating remaining width to distribute
fix annotations for ui/init.lua
…if the window is squeezed too small instead of the preferred width
…mechanism and new GameMode related enums
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is your plan for brining back the black letter boxing border on desktop?
Maybe we add the navigation stack to a sub view that is centered and have the black background on the root view? Then eventually all these calls to canvas width can instead get the size of the appropriate parent element or use the new fill alignment layout stuff.
About half way done looking through code, still need to test.
end | ||
|
||
function Game:handleResize(newWidth, newHeight) | ||
local activeScene = GAME.navigationStack:getActiveScene() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should probably be a root element that all scenes are parented from, that way we can draw overlays on it etc and it is always the root spot to update scale / height / width on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep!
This is still WIP and I did this quick and dirty to get a layout resize for window resizes so I could test the layout at all. I intend to come back to this.
… by default in debug mode
Letterboxing specifically exists to fill remaining space when the window size doesn't match the desired aspect ratio but with the new layout strategy it could technically just adapt to that size as we no longer have a specific desired aspect ratio. |
…ich relevant UI elements always know whether they are being hovered by a keyboard/controller cursor cursors can now also traverse focus within a scene in a non-linear (aka a button can pass it to an entirely different UiElement) and reversible way
…ng the actual on-screen position
…used children to get repositioned twice, causing failure for wrappables inside of scrollContainers
…an look bad as default)
client/src/ui/ImageContainer.lua
Outdated
self.scale = math.min(self.width / self.imageWidth, self.height / self.imageHeight) | ||
self.width = self.imageWidth * self.scale | ||
self.height = self.imageHeight * self.scale | ||
-- self.width = self.imageWidth * self.scale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete?
local go = ui.MenuItem.createButtonMenuItem("go_", nil, nil, function() self:goToCharacterSelect(garbagePatternStepper.value, widthSlider.value, heightSlider.value) end) | ||
local back = ui.MenuItem.createButtonMenuItem("back", nil, nil, exitMenu) | ||
|
||
self.menu = ui.VerticalMenu({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we should have a constructor here that does "the right thing" for main menu menus so we can adjust in one spot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess, to be fair this is really placeholderish.
Looking at my current idea I want to support in-room game mode adjustments so this particular one will most likely be embedded later but I get what you mean in general.
I'll keep that in mind for when I try to establish the general outline for the "split screen" idea.
apply some of Jam's feedback in comments / var renames 4-slice the image cursor and draw it with maintained aspect ratio
…and move the translate in UIElement:draw
explicitly use cursors for Options/SoundTest
start on stage selection
Work-in-Progress branch for overhauling our UI (again)
Goal
Move away from the 16:9 static global canvas and make it so that scenes and UI can be designed in a way that looks okay on mobile without compromising much on design for desktop.
Changes
Font handling
Font sizes used to be handled in numeric sizes and the way the size was set was inconsistent across the repository.
The new font handling has a range of string keys that refer to specific base sizes so that different text can be sized relatively to each other using those keys but without requiring explicit numbers.
Instead the GraphicsUtil font functions now access an extra parameter
fontSizeDelta
that is added to the standard font size for each key before fetching the font.This has the advantage that
FlexBox Layout
This is mostly described within the PR in the updated
Understanding the Codebase.md
doc so read there instead.New Battle Room UI
This is under construction.
The idea is to move to a vertical layout that makes use of scrollable and wrappable elements to provide much more screen real estate to implement more sophisticated UI options going forward, in many cases UI options that cannot be properly fit into the current battle room UI.
TODO