CEGUI (Crazy Eddie's GUI) Forums

It sounds pretty simple and as I see it, CEGUI computes the corners height based on the edges which is probably not a bad thing, but I hate seeing the background image overlapping the corner images. This widget is based of the Falagard/FrameWindow and is basically a TaharezLook/FrameWindow with different images.

I supplied 2 screens, one with a solid background and one with a transparen one so you can see what kind of corners I need to set up.

Hi, and welcome

I have moved this to the skinning forum, since it's a question about skinning

Getting the imagery arranged the way you want is fairly easy - you just need to specify the background and the frame as separate named ImagerySections, specifying them in the StateImagery definitions within layers that have the appropriate priorities (you can usually get away with listing them in the correct sequence, but this is not guaranteed to work - whereas using priorities is).

Now, this will be suitable for the 'basic' cases, however if you wanted the ornamental corner pieces to also overlay child windows (buttons and other content), you need another solution. What you will want to do in these cases is create an additional WidgetLook definition which you can apply to a DefaultWindow (this just has basic Enabled / Disabled states), you then would add an instance of this new window type to the FrameWindow WidgetLook as a Child element - this must be specified as always on top, and either permanently disabled, or have mouse pass-through enabled. The end result is that the FrameWindow content is then sandwiched between the actual FrameWindow and the additional window that overlays the ornamental frame parts over everything else.

If you get stuck, let us know which of the alternatives described is more like what you need and I'll try and give you more tips on how to get it working (this would be some time tomorrow).

Hope this gives some clues.

CE

Thanks, I separated the background layer and now it works fine. What I was curious is how do you set the priority for the layers because making a single layer does the job, but does the tag Layer have any other properties I should know about ?

For the corner ornaments. Well, I have to check that with the designers but for now I'm just going to stay out of showing windows in those areas. And for tiling the the left/right/top/bottom edges I read about it in a post but it's a really messy operation, having to chop each piece apart and set the edges lengths according to the neighbor edges. Isn't there a faster way by now ?

EDIT : By the way, can't I make 2 Font objects with a single font file ? Like say a font name with size 12 and another one with size 14 without making 2 different files (clutter & all).

Regarding dynamic font sizes, check this wiki page: http://www.cegui.org.uk/wiki/index.php/DynamicFont, specifically the setFont() function. I haven't implemented this myself, but I plan on implementing something similar down the road. No one really wants to make/deal with multiple xml-font files. I'm really not sure why the FontManager doesn't already have a function similar to this (hint hint).

The Layer tag has a 'priority' attribute, this takes a number - the higher the number the higher the priority of the layer content (here, higher priority means appearing in front of lower priority layers). See the docs for more info: http://www.cegui.org.uk/FalDocs/node36.html

To get control over the formatting of frame edges, you still have to split them out into separate ImageryComponent definitions. I will get around to adding the ability to specify formatting for the FrameComponent parts (and hey, it's not been that long since it first came up, has it?! ).

The situation with fonts is a bit sucky. At the moment, loading via XML means one font per XML file The things I'm (supposed to be) working on at the moment might result in a totally new approach to fonts and their rendering at the lower levels - it depends on what performance I get once I start doing some tests of the various options. In addition to this we (almost certainly scriptkid, actually) will be implementing advanced text formatting support, which again could well influence the font implementation. In addition to this there are other known issues with the current font implementation (especially with regards to asian fonts) so there's likely to be mods to fix these issues too. So yeah, the fonts will basically be redone - and we'll make some ease of use enhancements at the XML end

CE.

Thanks for the input. By the way, is there any way to color differently every line of a MultiLineEditbox ? Or every character for that matter.

I'm actually quite surprised that the founder is answering my inquires and I'm still puzzled if he has a full-time job and does this in his free time, or if CEGUI is his full-time job .

EDIT : Is there any way to derive a widget from a template widget ? Like say I have a button with 3 images as states and I want a second widget that just has those 3 images changed but I don't want to state the image property for every widget instance I make. Is there a way to do that from the looknfeel ?

EDIT2 : I looked all over but I can't seem to find out what are the base properties for the Falagard base widgets, like "SizingEnabled" for example. To that end, I need to disable the Horizontal ScrollBar of a MultiLineEditbox, is that possible ?

EDIT3 : Why does
<ImageDim imageset="MySet" image="RandomImage" dimension="Width" />
differ from
<AbsoluteDim value="15" />

When the width of the image is 15 pixels ? Is the image scaled ? If so, how is it scaled and how can I turn off the scaling ?

Ok - answers...

Multi-coloured text strings (and therefore, different coloured lines in the multi-line editbox) are not readily available at the moment, although this is the main part, or at least the motivating part, of the extended text formatting that we will be working on for the 0.7.0 release.

CrazyEddie works on CEGUI and offers CEGUI support as a part-time 'hobby' project.

"inheritance" of looknfeels is not supported at the moment. This has been mentioned before (quite a while back), and I appreciate the advantages this would bring. The looknfeel system, while one of the best parts of the library, has remained largely unchanged since it was first written about three years ago. In the time that has passed various points have come up either via direct request, or by my monitoring of 'issues' and usage, and I probably have enough items now to warrant an overhaul of the skinning system - this would likely include things like inheriting from widgetlooks, the improvements to FrameComponent already touched on.

Properties on a window can come from three places:
1) The core CEGUI::Widget, these properties are put into a namespace and can be browsed via the API docs namespaces section.
2) The WindowRenderer assigned to a Window. These are more uncommon, and unfortunately do not get included in the doxygen output (though will for future versions, due to our dir structure change)
3) In the looknfeel itself via PropertyDefinition and PropertyLinkDefinition.

The properties available (via all three groups) are also listed on the Wiki for TaharezLook and WindowsLook. These are slightly out of date, but not obsolete or anything.

IIRC there is not a property to disable the use of the horizontal scrollbar. You could enable word-wrapping which would ensure the horizontal scrollbar is not used, but thats probably not what you wanted to do. The solution I think I've suggested before is basically to modify the looknfeel in such a way that the horizontal scrollbar has a zero size.

The Imageset system employs an 'auto-scaling' mechanism to provide imagery that maintains it's physical size regardless of display resolution. This autoscaling can be disabled in the imageset XML by setting the AutoScaled attribute to "False". The 'native resolution" specified in the imageset is only used with auto-scaling, and it basically specifies the resolution for which a 1:1 mapping should be used - resolutions higher than this will cause the imagery to be scaled up, and resolutions lower than the native will cause the imagery to be scaled down.

HTH

CE.

cippyboy wrote:I'm actually quite surprised that the founder is answering my inquires and I'm still puzzled if he has a full-time job and does this in his free time, or if CEGUI is his full-time job .

The founder is an awesome, patient, very personable, resource on this forum. He has a lot of energy for this gui system. I've actually tried to get him to consult for us, but he values his free time (as you can imagine).

it strikes me that he does this out of:
1] his passion for graphics systems,
2] the goodness of his heart,
3] his belief that shared-knowledge is good for all.

I've grown to really enjoy working with CEGUI, and a good bit of that I contribute to the founders continued dedication.

Since he's so kind & all, can he please remove the philosophy of "if encountering an exception, let's just trash everything we loaded so far" ? I admit a warning should be necessary, but just because I wrote in an XML "NAme" instead of "Name" the whole system crashed and at the time I remained puzzled as to what's the reason.

cippyboy wrote:Since he's so kind & all, can he please remove the philosophy of "if encountering an exception, let's just trash everything we loaded so far" ? I admit a warning should be necessary, but just because I wrote in an XML "NAme" instead of "Name" the whole system crashed and at the time I remained puzzled as to what's the reason.

In general, I'm of the frame of mind that most formatting errors are "fundamental issues", that need to be fixed before you can move on. I can't think of a better way than to force the issue by throwing an exception and forcing the higher level application to resolve the issue.

Far more difficult to resolve issues often arise from "simply ignoring the formatting issue and moving on". It should be the responsibility of the higher level application to catch the exception, cleanup (perhaps prompting the user to fix the formatting problem) and then reload.

Another way to think about it is to think of a C++ compiler. If/when it comes across a syntax error, it does not "simply move on". It forces you to fix the problem. It cant possibly guess what you had intended. Its no different when a system like CEGUI parses a scheme or layout file.