PropertyLinkDefinition: map or multimap?

[HorizonDefeated]

Hello,

NOTE I hope this issue hasn't come up before- I did a brief troll first.

I recently developed a custom CEGUI control that was a collection of child controls (similar to Combobox). As I understand the existing PropertyLinkDefinition allows a parent property to be map/linked to a child property. For example the color property of a the parent could be mapped to a child's color property.

In my case what I am interested in doing is mapping several parent color properties to multiple children controls. IE the color of the parent would get mapped/linked to multiple children.

The existing implementation of PropertySet uses a map which only allows one-to-one mapping. As soon as you try to add another property of the same name it throws an error. For my own purposes I have modified this to be a multi-map which allows one-to-many mapping (for PropertyLinkDefinitions only). I would like to see either my changes (need to be cleaned up a little and maybe a couple of behavioral questions answered) pushed back in to the code base or someone else implement something similar.

Thoughts?

PS My result looks something like the following in my looknfeel file:

Code: Select all

<WidgetLook name="ProcerusLook/SplitButton">
      <PropertyLinkDefinition name="ButtonColor" widget="__auto_primary_button__" targetProperty="ButtonColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="ButtonColor" widget="__auto_dd_button__" targetProperty="ButtonColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="NormalHighlightColor" widget="__auto_primary_button__" targetProperty="NormalHighlightColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="NormalHighlightColor" widget="__auto_dd_button__" targetProperty="NormalHighlightColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="PushedHighlightColor" widget="__auto_primary_button__" targetProperty="PushedHighlightColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="PushedHighlightColor" widget="__auto_dd_button__" targetProperty="PushedHighlightColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="HoverHighlightColor" widget="__auto_primary_button__" targetProperty="HoverHighlightColor" initialValue="ff1e3cba" />
      <PropertyLinkDefinition name="HoverHighlightColor" widget="__auto_dd_button__" targetProperty="HoverHighlightColor" initialValue="ff1e3cba" />
...
</WidgetLook>


[CrazyEddie]

Hmmmm. Interesting issue / scenario

To be honest, I'm not overly enthusiastic as regards to changing the PropertySet from map to multimap (unless I totally missed the kind of implementation you have in mind) - though this does not need to be the last word on the matter; it has been known - very occasionally - for CE to change his mind

That said, the scenario you describe is a situation that I could see coming up again and again (and am surprised it's not come up before). My first thought's on an implementation would be something like this, instead:

Code: Select all

<PropertyLinkDefinition name="ButtonColor" initialValue="ff1e3cba" >
    <PropertyLinkTarget widget="__auto_primary_button"  property="ButtonColor" />
    <PropertyLinkTarget widget="__auto_dd_button"  property="ButtonColor" />
</PropertyLinkDefinition>

So you basically have one PropertyLinkDefinition which may then contain multiple PropertyLinkTarget elements. The implementation of that would leave PropertySet as a map, with each PropertyLinkDefinition object maintaining the collection of targets, and calling 'set' would cause the PropertyLinkDefinition object to iterate over it's targets.

One interesting issue does arise with the 'get' function though, because it's actually feasible that the targets could somehow have different values, so which one should you return? My own solution would be for the PropertyLinkDefinition to maintain a local copy of the last 'set' value and return that - we could include a note to the developer indicating that this is what happens and they should avoid setting those target properties individually for reasons of consistency.

CE.

[HorizonDefeated]

CE,

Sounds like an even better solution. I would assume that the efficiency would be quite a bit greater than moving to a multimap in PropertySet.

I think I considered this approach but went with the multimap propertyset. However as I can't think of any reason to support that decision now it must have been incorrect. If I do remember I'll chime in.

Anyway, allowing PropertyLinkDefintion to have multiple targets as you described would solve my particular use case scenario.

The get question was exactly the sort of behavioral question that I was referring to. Since I didn't care for my project I made it so that get just returns the first entry it finds. If all the children properties are the same this is fine. If not than all bets are off. Caching the value in the link itself as you mentioned is interesting also: In an extreme case none of the targets may actually have the value you are getting.

PS PropertyLinkDefinitions are awesome for making composite controls with a collection of children controls. Much better to specify these in the XML than implementing it all in code alone Thanks for the mechanism.

[CrazyEddie]

I've thought some more about the 'get' situation and it's not clear cut at all. While my locally held value idea could be used, this precludes us being able to retrieve a property that might update itself for some other reason (such as user interaction). Another possibility, then, is to make the first target specified the master 'get' target - so calling 'get' will fetch the value from that target property.

PS PropertyLinkDefinitions are awesome for making composite controls with a collection of children controls. Much better to specify these in the XML than implementing it all in code alone Thanks for the mechanism.

Thanks, I'm happy like like it One thing I have my eye on adding at some stage in the future - as part of a batch of looknfeel updates that will likely be for 0.8.x - is the concept of an EventLinkDefinition; this would work the same way as the property one, allowing events of sub-widgets to be exposed at the top-level. Such an arrangement should allow us to dump a lot of facade-like code.

CE.

[HorizonDefeated]

CE- I really like the EventLinkDefinition idea! That would really make parent/child controls come together very quickly (development wise).

What are your thoughts for how/when we might see the expanded PropertyLinkDefinition??

Thanks

[CrazyEddie]

What are your thoughts for how/when we might see the expanded PropertyLinkDefinition??

This is a fairly simple thing to add, I think. It can also be done in a non-breaking way, so can go into the v0-7 stable branch. I intend spending (at least some of) the weekend working on the CEGUI core (as opposed to the up and coming skin editor, which is my main focus otherwise), so I can pencil it in to be done over the same period (barring, of course, any major issues) - so it could be available within a few days, at least via SVN.

As for an actual 0.7.2 release (i.e. a v0-7 branch snapshot with prebuilt binary SDKs), this is a little way off yet due to me not being focussed on the core lib at the moment (maybe April?).

CE.

[HorizonDefeated]

Sounds perfect.

I'll watch for your post and test it out when it's in SVN.

Thanks
HD

[CrazyEddie]

Well, it's been a quite productive day, and this support has been added in branches/v0-7 @ rev 2435.

Usage is as proposed above. A couple of interesting things:

• The first defined target is the master target and will be used for 'get' operations.
• It's still possible (but not mandatory) to use the PropertyLinkDefinition attributes to specify a target - if specified this is always used as the first / master target.
• For writing XML, if a single target is specified, the PropertyLinkDefinition attributes are used to specify this. If multiple targets exist, PropertyLinkTarget sub elements are used to specify the targets and no target is specified via the PropertyLinkDefinition attributes.

I tested it a little bit, seems to work fine. I have still to test on non-linux platforms though

CE.