Back to General and Gameplay Programming

GUI elements whose positions depend on one another

Zondartul · 2015-12-14T20:25:18

Hello GameDev.net. I've decided to make a GUI toolkit for fun. What I mean by a "GUI toolkit" is a library for creating windows, forms, and dialog boxes by combining elements such as buttons, labels, scroll-bars and checkboxes. But let's not focus on all that right now, what's important is what happens to the most basic element, a "frame", which is simply a rectangle of a given position and size. I've encountered a design problem. Or maybe it's a math problem. I'm not sure. I want to have several ways to change the position and size of the components: The first is to statically set the size and position of an element. The second is to click-and-drag the body or the edge of an element to change their position/size "by hand". The third to tell the element to "set size to contents", where the element automatically shrinks or expands to exactly circumscribe all child elements. The fourth is to set the size or position of an element as a percentage of parent element's size. Additionally, an element may be moved around by it's parent to fit some additional constraint, for example "elements must be aligned horizontally without overlapping". Each of these behaviors I have already coded and, individually, they work. The problems start when I try to make several of those to happen at the same time. I do not know which order to "invalidate" elements in. By invalidating, I mean "tell the element to resize/reposition itself and reposition it's children in a way that all constraints are satisfied". You probably see the problem by now. With so many dependencies/constraints, everything depends on everything! And since any element is only aware of the constraints that directly relate to it, by attempting to fix those constraints, it would break the constraints imposed on other elements. So I would have an infinite loop of things getting invalidated and then trying to fix themselves (this looks hilarious on the screen btw, you click on something and it just spirals out of control and flies beyond the edges of the screen). Here's a very simple example: Frame A is a parent of Frame B. I initially set the size of both frames to 100. Then I tell A "size = to contents" and I tell B "size = 101% parent size". B would grow bigger, so A would grow bigger, so B would grow bigger, ad infinitum. Everything would freeze because two elements would play catch-up forever. I think I have multiple circular dependencies. Or maybe a better way to look at this is like a system of N variables and M equations, and it's over-constrained. TL;DR: My GUI elements have constraints on their relative positions and sizes and I don't know how to resolve them.

General and Gameplay Programming Programming

Started by Zondartul December 12, 2015 02:04 PM

11 comments, last by Zondartul 8 years, 5 months ago

Amr0

2,230

December 14, 2015 10:52 AM

I worked for a while on a layout library, called HBox. Here is an excerpt from the linked page:

Some GUI libraries come with their own layout facilities. Other libraries require the user to take care of all GUI layout functions: positioning and sizing elements, responding to size change, enforcing minimum/maximum constraints, hit-testing... etc. Whether it's for an existing GUI library, or as a back component of your own library, HBox aims to take care of all your layout needs.

HBox is a small C++ library with a simple API. The API is composed of a single HBox class, which represents a box. Naturally the boxes are hierarchically related. Each box will layout its children when changes are made to its size and other properties. The final layout depends on the "solver" of the parent, as well as the properties of the children.

Each box can have margins and padding, similar to the CSS box model. HBox however does not attempt to recreate the same behavior and rules of CSS, so it is only conceptually similar to the CSS box model, and HBox attributes do not necessarily mean the same as their CSS counterparts. Also, HBox currently has no support for thick borders or other border properties.

HBox aims to be versatile and simple at the same time. Complex layouts can be accomplished by using additional boxes that don't correspond directly to GUI elements. Using such boxes with the right "solver" types allows this versatility to create all sorts of layouts. More about that later.

HBox supports 3 types of property/distance units: absolute (pixels if you'd like), percentage, and flex units. Flex units are like springs, with minimum and maximum constraints. Again, more on that later.

It's not finished yet unfortunately, so it's not very useful to you at this stage. It implements the mentioned two-pass approach to resolving sizes and positions of boxes. I hope this has been helpful somehow. If you'd like the source code, let me know.

Blog | MayaFPS: First Person Controls in Maya | Curver - Fastest Line-art Tool Ever! | RefreshBrowser: Notepad++ plug-in for webdevs

swiftcoder

18,997

December 14, 2015 04:56 PM

Why don't you have a look at the code for QT or WxWidgets?

There are simpler options to read (insert shameless plug for simplui in that respect).

I'm not sure I've ever encountered a GUI framework that *doesn't* do 2-pass measure and layout. It should allow you to solve most non-recursive constraints with relative ease (as long as you avoid pathological edge-cases like Android's RelativeLayout).

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Zondartul

312

Author

December 14, 2015 08:25 PM

Thank you all for your advice! I deliberated between using the method I posted and the two-pass layout as seen in most GUI frameworks.

The method I was planning to do has some issues, so I'll look into how Qt / simplui / WxWidgets do the layout. I'll tell you if I figure anything out.

Turns out, the method in my second post, the one that involves a "constraint solver" that simply constructs a graph and then "fixes" constraints one-by-one in the order of dependency, in the general case suffers from a multiple-writer problem as constraints don't know about each other. It would probably be possible to have all constraints satisfied simultaneously if they were posed as a set of linear equations, and then the whole system could be solved using matrices or some such. Buuut... that's kind of too difficult for me to handle. And it might, possibly, make the constraints too unintuitive for the user. So I'm sticking with the more common method for now.

GUI elements whose positions depend on one another

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

GUI elements whose positions depend on one another

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines