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.
[SOLVED] CloseZilla has Been Defeated!!!
Moderators: CEGUI MVP, CEGUI Team
[SOLVED] CloseZilla has Been Defeated!!!
Last edited by daves on Thu Jul 17, 2008 12:55, edited 2 times in total.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
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.
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.
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.
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.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
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.
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.
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):
The imageset definition looks like this:
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).
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).
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.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
daves wrote:Its acting like the Godzilla of widgets (Closezilla).
daves wrote:CloseZilla is dead.
I found this highly amusing - I'm also glad he is dead
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.
Who is online
Users browsing this forum: Google [Bot] and 24 guests