CEGUI (Crazy Eddie's GUI) Forums

This might be more of a feature request, cause I've read the documentation several times and I really haven't found a smart way to make a WidgetLook where the titlebar changes appearance when the FrameWindow is rolled up.

FrameWindow has a property "RollUpState", but you can't obviously access it from the children. Also, it's not possible to use <Section> with controlProperty="RollUpState", cause nothing is rendered in rolled-up mode. There is one workaround but it requires making the client area cover the whole window, and I don't like doing that.

Any ideas?

(I could code my own window renderer, but I kinda wanted to make a skin that I could also share with others here.. we'll see.)

This is an interesting point. I've thought about the situation briefly and agree that there is no real provision within the system at present to enable such behaviour - so the rest of the post will deal with the 'feature request' aspect.

While it would be easy to add some state to Titlebar to enable this to happen, I'm against adding such functionality in there for a couple of reasons. First, is because the FrameWindow has the rolled up state, and the titlebar does not, and does not need to, know about that. The second reason is for avoiding 'special case' settings and such. I'm happier when I can implement a more generic solution...

So, having given this literally two minutes thought, I can see two possible feature implementations that would enable you to do what you need.

1) Modify PropertyLinkDefinition in order that the widget attribute can be specified as a special value of '__parent__' which would result in the link being made from child to parent as opposed to the current parent to child. For this specific case, it would enable a property to be defined in the titlebar WidgetLook that links back to the owning frame window "RollUpState" property and can then be used to control rendering of imagery.

2) Add a widget attribute to the <Section> element that allows specification of the widget where the control property is defined. This would also need to have a '__parent__' value to identify the parent window.

These solutions raise another interesting issue, and that is one of what to do in the opposite case. So I think there would need to be a mechanism to negate the property test. This way it would be possible to specify two sections; one used when the property is true, and the other when the property is false. Whether this should be the pretty much ubiquitous '!' preceding the property name, or some other mechanism, I'm not sure. The uncertainty arises since it's not impossible that someone might have named there properties beginning with that symbols (although unlikely), and the same applies to the '__parent__' special case too, I guess.

Discussion, as always, is welcome

CE.

Well, I like the idea of using __parent__ to access the parent widget. It's quite simple and intuitive.

That "!" thingie not so much, but I can't figure out a more elegant way without changing too many things.

Cool. I'll implement the '__parent__' idea over the weekend. And will think about the negation issue some more in the mean time

CE.

Ok. I have added the following features (branches/v0-7 r2456).

<PropertyLinkDefinition>
Now supports the '__parent__' value in the widget attribute to specify a 'back link' to the parent window.

<Section>
Added two new optional attributes: controlValue and controlWidget:

• controlValue: Specifies a value to be compared against the value accessed via the controlProperty. If they match, the section is drawn, if they do not match, the section is not drawn. This enables testing of the 'negative' case (as well as other arbitrary values) - so can be set to "False" to draw the section only if the property value returns "False". If this attribute is omitted or set to the empty string, the previous behaviour (i.e a straight boolean test) is used.
• controlWidget: Specifies either a child widget suffix or the special value '__parent__' to indicate that the controlProperty should be fetched for some window other than the one being drawn. Again if this is omitted or set to the empty string, the existing behaviour is used (i.e. the property is accessed on the window being drawn).

There is still a fly in the ointment as far as certain aspects of what you're actually trying to do, and that is because currently when the roll-up is toggled, the child content is not updated (so no visual change occurs until after something else causes a redraw of the Titlebar). I'll evaluate this some more tomorrow, and probably make it so that all children are updated when the roll up occurs.

CE.