[SOLVED] CloseZilla has Been Defeated!!!

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

[SOLVED] CloseZilla has Been Defeated!!!

Postby daves » Fri Jul 11, 2008 23:11

I have yet to figure out a formula that works for me at all resolutions. I do most of my design at either 1920 x 1200 or even 1280 x 1024.
Recently we deployed our application to a system with a monitor that is about 2600 x 2200 (sweet resolution).

I see a variety of visual anomalies that I want to address in a fashion that will work at all resolutions. I will post images on monday, but for now I'll describe the kinds of behaviours that I want to resolve in terms of two components: a scroll bar (with a thumb slider), and a checkbox.

My dialogs may look just fine at the lower resolution that I design at, and for a particular slider the thumb may look reasonable. Let me use some fake numbers, for illustration. The thumb may take up about 10 percent of the width of the entire slider at one resolution and at the higher resolution it make take closer to 30 percent of the width of the slider (effectively dwarfing the slider). Hence the problem is that elements such as the thumb (or the check in the checkbox) do not scale in proportion to the rest of the window.

Is this something that is easy to solve? Can I tweak the looknfeel to impact this? Currently the looknfeel that I use is a descendant of the windowslook looknfeel. For things like the slider it is essentially windowslook.

I'll also see this problem for things like the close button in a framewindow, which will begin to dwarf the titlebar that it is resident in (at higher resolutions).

Any thoughts/ideas would be appreciated.
Last edited by daves on Thu Jul 17, 2008 12:55, edited 2 times in total.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Sat Jul 12, 2008 06:20

I think the issues may be caused by imagery auto-scaling sizes conflicting with sizes of UI elements (and possibly also text autoscaling, where that is used to control the size of UI parts).

For example, if a slider is given an absolute pixel size of some kind, the physical size of the element on screen will vary according to the resolution (smaller physically at higher resolutions) - if imagery autoscaling is enabled, the images physical sizes will be constant across all resolutions - giving potential issues, such as what you're seeing.

Hope this sheds a little light ;)

CE.

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Postby daves » Mon Jul 14, 2008 13:49

Thank you. This certainly makes sense. Is auto-scaling something that I can turn on/off on a per-instantiated window basis?

More generally what are your recommendations when it comes to deciding whether to use fixed or relative specifications for GUI elements (for example within an application dialog) when indeed there is a need to have the GUI look reasonable at multiple resolutions. Do you have a preference yourself in terms of creating the designs for dialogs and other such GUI elements?

I've struggled, to date, sometimes using relative, sometimes using absolute, sometimes using a combination.

I'd like to figure out a plan forward, and have learned just about enough to know what not to do (which is pretty much everything that I've done so far )!! I dont yet know the "right way"! :)

Take a particular widget (the FrameWindow), that I will use for the creation of many of my application dialogs. I believe the border (titlbar, resizing border) is defined in absolute pixels (though perhaps optionally this can also size relative to the screen resolution - to the points that you made). In the past when I would try to populate such a menu, I would get the best results (at least at the resolution that I was working at) by using a combination of absolute/relative. For example I might start the top placement (of my topmost widgets within the frame) at an absolute offset (in order to get me past the titlebar), then I might use relative positioning in order to get the various contents to position themselves reasonably well relative to each other.

The short of it is I have taken an ad-hoc approach, and would be interested in any/all thoughts that would help me to formalize the design process.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Tue Jul 15, 2008 08:39

I think generally the approach to take will depend upon what your app is and the target audience.

In a game for example, you may not want somebody with a huge screen / high resolution to gain an unfair advantage over somebody running at a much lower resolution - so you'd likely have everything relatively scaled, and imagery auto-scaled, so that the same amount of screen real-estate is taken up by the UI components regardless of resolution.

In an app geared more towards productivity, having a higher screen resolution is desirable because it allows you to see more of what you're working on. In this instance it's likely that it would be preferable to have the UI components not scale since you're just using up valuable space - so in this instance I might use absolute pixel values more, and also disable auto-scaling (at least on imagery, perhaps not on fonts).

I don't believe there is an 'ultimate solution' here, the above is just my 2c on the subject ;)

CE.

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Postby daves » Thu Jul 17, 2008 12:34

That, of course, was the right answer. That is, the answer should have nothing to do with the engineering that is needed to achieve the operational solution, rather it is all about the user and what they expect from the application.


In my application we move towards higher resolutions in order to provide more real-estate for more information/tools (the second of the two cases that you describe). In general, perhaps, I'm closer than I thought then. At higher resolutions our application will largely scale in a fashion that allows more information, and more functions to be exposed.

Let me ask a very specific question then. We have based our GUI scheme and looknfeel off of WindowsLook. Though we have added a few controls, most of the original controls are there as is, with the looknfeel largely unchanged. The close button on the FrameWindow looks reasonable at lower resolutions. It is absolutely HUGE (relative to the framewindow and the titlebar - in fact it is so big that it is no longer contained within the titlebar) at higher resolutions.

Is there something wrong with the way the CloseButton is defined in the WindowsLook looknfeel? Extracting the definition from our looknfeel I see this (within the FrameWindow WidgetLook):

Code: Select all

       <Child type="SVTLook/SystemButton" nameSuffix="__auto_closebutton__">
            <Area>
                <Dim type="LeftEdge">
                    <UnifiedDim scale="1" type="LeftEdge">
                        <DimOperator op="Subtract">
                            <AbsoluteDim value="0.5">
                                <DimOperator op="Multiply">
                                    <ImageDim imageset="SVTLook" image="CloseButtonNormal" dimension="Width">
                                        <DimOperator op="Add">
                                            <WidgetDim widget="__auto_titlebar__" dimension="Height" />
                                        </DimOperator>
                                    </ImageDim>
                                </DimOperator>
                            </AbsoluteDim>
                        </DimOperator>
                    </UnifiedDim>
                </Dim>
                <Dim type="TopEdge">
                    <WidgetDim widget="__auto_titlebar__" dimension="Height">
                        <DimOperator op="Subtract">
                            <AbsoluteDim value="0.5">
                                <DimOperator op="Multiply">
                                    <WidgetDim widget="__auto_titlebar__" dimension="Height">
                                        <DimOperator op="Add">
                                            <ImageDim imageset="SVTLook" image="CloseButtonNormal" dimension="Height" />
                                        </DimOperator>
                                    </WidgetDim>
                                </DimOperator>
                            </AbsoluteDim>
                        </DimOperator>
                    </WidgetDim>
                </Dim>
                <Dim type="Width">
                    <ImageDim imageset="SVTLook" image="CloseButtonNormal" dimension="Width" />
                </Dim>
                <Dim type="Height">
                    <ImageDim imageset="SVTLook" image="CloseButtonNormal" dimension="Height" />
                </Dim>
            </Area>
            <Property name="AlwaysOnTop" value="True" />
            <Property name="NormalImage" value="set:SVTLook image:CloseButtonNormal" />
            <Property name="HoverImage" value="set:SVTLook image:CloseButtonHover" />
            <Property name="PushedImage" value="set:SVTLook image:CloseButtonPushed" />
        </Child>


The imageset definition looks like this:

Code: Select all

<Imageset Name="SVTLook" Imagefile="SVTLook.tga" NativeHorzRes="800" NativeVertRes="600" AutoScaled="true">


This suggests that all images will be autoscaled (to one of your earlier points). The SVTLook.tga file referenced here is no different than WindowsLook.tga.

Is there something easy I can do to "reign that close button back in"? Its acting like the Godzilla of widgets (Closezilla).

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Postby daves » Thu Jul 17, 2008 12:57

CrazyEddie wrote:I think the issues may be caused by imagery auto-scaling sizes conflicting with sizes of UI elements ..

CE.


Yep Yep Yep!!! I simply turned off autoscaling in the imageset definition and ALL of the visual anomalies that were so evident at higher resolutions dissappeared. The application looks lean and mean now at high resolutions.

CloseZilla is dead.

Thank you yet again.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Thu Jul 17, 2008 18:09

daves wrote:Its acting like the Godzilla of widgets (Closezilla).

daves wrote:CloseZilla is dead.

:lol: I found this highly amusing - I'm also glad he is dead :P

Another solution might have been to adjust the area of the close button child specification (currently it is sized according to the image information, this could have been changed to use something else - half the height of the titlebar or whatever), although if you'd done that you would possibly have other 'zilla images rearing up elsewhere :)

CE.


Return to “Help”

Who is online

Users browsing this forum: Google [Bot] and 24 guests