Jump to content
  • Advertisement
Sign in to follow this  
Republic of Zak

Gui Container Compression

This topic is 1793 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys, first time joining these forums so pleasure to meet you.


I've got an Math based issue which related to GUI's. In the UnrealEd 4 (based on the video, thought other GUI's do it) in the main container window you can rescale all the docked elements (boxes), but their neighbouring elements are either compressed or expanding to fill the space you've rescaled or a docked new element in the container forcing everything to rescale, also noting that some of the elements I imagine would either have fixed width/heights or have a minimum width/height and this would change how everything around them is rescaled. My problem is how is this done mathematically.


I've noticed a massive issue with programming and that's the names of things, without prior knowledge of what a techniques is there's no way I'd be able to guess what you call this. Took me 2 hours to find out this is some type of packing technique and even that might not be the right thing.


So can anyone enlighten me to what this rescaling or re skinning (if that's correct) technique is called or how it may be achieve?


Thank you in advance

Share this post

Link to post
Share on other sites
There are at least two layers of completely different concerns:

- You have a tree of rectangles (container -> child widget relationships), with the constraint that children must be entirely contained in their parents and not overlap their siblings, and you need to choose the size of each rectangle for a given root rectangle height and width.

- You need to draw a widget with a given position and size, scaling and stretching graphical elements, drawing child widgets in the right order, etc.

Generally, the first problem is approached with constraint systems, usually organized in a very strict hierarchical way (widgets are constrained only by available space in their container and by their siblings, regardless of what they are and what they contain).

For example, in the Swing framework for Java every widget (JComponent) is a Container that owns an arbitrary number of children (with generic infrastructure to dispatch events, add and remove children etc.) and has a LayoutManager that decides the position and size of all children. JComponent instances can plead for a minimum, preferred and maximum size, but they aren't mandatory. All interesting behaviour is contained in the LayoutManager implementations: for example there are GridLayout, which divides available space evenly, and BorderLayout, which handles up to 5 children (but usually 2): the "center" one is stretched in both directions and the top, bottom, left and right children only along the corresponding border.

Drawing scaled widgets depends on graphical style: do you want line thickness to change? Font size? Rounded corner radius? Icon size, usually in discrete steps? Every widget is supposed to know what it should draw and how to draw it, possibly with the help of a theming engine to improve coherence of graphical rules.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!