Unified Coordinate Enhacement - Smart System

[Van]

I have an idea that I think would enhance the usablity of CEGUI and the layout files.

The problem
The problem with any GUI window system is the resolution of the window system. What looks good at 800x600 is not so great at 1024 x 768 and is horrible at 1600 x 1200. Trying to come up with a schema that works for everyone is difficult. Granted, most people work at 1024 x 768 but as the Wide/Theater screens become cheaper they will begin to dominate the monitor market. I have a 27" wide theater view flat monitor. I run at very high resolutions ( 1600 x 1200 for games). The windows never look right from other applications. it's really annoying. Anyone who has disgned screens can relate that if you design a window at 800 x 600 and then view it in 1024 x 768 (or larger) that the widgets move further and further apart leaving alot of dead space. This idea is to help eliminate that dead space.

The idea
Add an overload Unified coordiante function that can be use data from other window elements - a smart unified system..

Here is a typical unified entry in a layout file:

Code: Select all


<Property Name="UnifiedAreaRect" Value="{ { 0.00, 15.00 } , { 0.00, 35.00 }, { 1.00, -15.00 } , { 1.00, -70.00 } }" />



Now, lineing up a window below it would be difficult. What if you could do this:

Code: Select all


<Property Name="UnifiedAreaRect" Value="{ { 0.00, 15.00 } , { 'WindowName:Y:Bottom', 35.00 }, { 1.00, -15.00 } , { 'AnotherWindowName:Y:Top', -70.00 } }" />



Notice that I have added WindowName and AnotherWindowName.

When the Unified Smart System enounters a STRING (vs a number), it will attempt to locate the Window by that name and use the current value for which the 'label' (i.e. WindowName and AnotherWindowName ) occupy. In this case, WindowName would cause the unified smart system to obtain the lower-left corner and use it as the required data; AnotherWindowName would cause the unified smart system to return the top-left corner data.

Why do this?
Well, it would make designing screens for almost any resolution work better (IMHO). It would make it easier for window layout people and wouldn't require the programmer to "adjust the windows" for different resolutions. It may help the stacking widgets on the screen so that you can maximize the amount of space being made available. Recall that if you design a window at 800 x 600 and then view it in 1024 x 768 (or larger) that the widgets move further and further apart leaving alot of dead space. This idea is to help eliminate that dead space.

Now, not being really familiar with internals of CEGUI, is this idea feasible and would others find this useful?

[PeterNewman]

I like this idea, although I don't know how implementable it would be.

The only immediate downside I see is windows linking up (where window1 is attached to the top of window2, and window2 is attached to the bottom of window1), where positioning would be pretty much up to the order they got called in the re-layout.

[Pompei2]

Yeah, sounds really good !

[gcarlton]

This touches on a whole new aspect for GUI systems, that of laying out the elements dynamically. There are two options: Arrange on load, or Arrange on the fly during update.

Arrange on load is really just a helper that "distills" down to a standard coordinate once finished. It makes it a bit easier to specify, but in terms of the implementation once the window is created it needs no new behaviour.

Dynamic arrangement is a fair more interesting problem. Hard coding a small amount of logic into the coordinate system has some limitations that would become apparent as soon as more complex things were attempted. Consider cases where you want a button streteched between two other ones, or a grid arrangement, or a circular context menu? Even a simple vertical stack of buttons may wish to grow/shrink depending on how many there are.

Instead of a slightly "smart" coordinate system, it would be better to keep the coordinate system as is and have the smarts in another place. This other entity would arrange its subelements according to whatever scheme is necessary. It may be something aggregated with an arbitrary window (e.g. controlling layout of its children), or a special Property that is used in by some other Arrangement Manager. Or perhaps even a virtual "ArrangeChildren" that subwindows could do with as they see fit.