Data driving with Falagard

[gcarlton]

One concern I've had was how to make a data-driven widget outside the normal Falagard domain - for example the analog clock widget that was proposed a while back. It doesn't fit the Falagard mould, but it does need some data driving.

I think the properties in LookNFeel are exactly what is needed here. One example I've been considering is a button made up of "bubble" particles that float around the perimeter of the button.

These classes can be created to use properties (added from the LookNFeel), such as:

Code: Select all

PropertyHelper::stringToUint(getProperty("BubbleCount"));

Ok so far. The button can then display this number of bubble particles that float around in whatever way. The speed of the bubbles and their lifetime could even be specified, allowing "angry" bubble buttons and more sedate variations.

However, for the image of the "bubble" to use, I'm not sure the best way of grabbing the information from the LookNFeel. I guess you could do it with 2 more properties (you'd need an imageset name property, and an image name property). You could also use the existing state imagery, and grab the image from that while ignoring the coordinate data.

An advanced alternative would be to allow users to create their own LayerSpecification classes that have a virtual render method. This would actually allow more customisation. You could have a Falagard static image background layer, the "bubble layer" using particles, and on the top, a Falagard text layer with the title. That would require a bit more of a rework though.

[CrazyEddie]

Well for any new widget, or for additional widget functionality that's too "custom" to be accomodated by any of the generic widgets provided, you still have the general pattern we've always had; a base class and a rendering class (in this case for falagard).

The definable properties ability is pretty good. For an Image you should use the established pattern of "set:<imageset_name> image:<image_name>" Then you can use the PropertyHelper::stringToImage function to get the actual image object.

It may be too soon start sub-classing the falagard classes; really, for the moment at least, these are more of an internal thing (or in other words, anything within the falagard sub-dirs may change completely, though we will always maintain compatability with XML files). You may notice that the interfaces to some of those classes are prettly light, in some cases undocumented, and in others, 'obviously' incomplete

Your 'bubble button' sounds pretty interesting though

[gcarlton]

Ok, so those properties look pretty good for any data driving of custom widgets. Good stuff!

As for subclassing Falagard, obviously the system is itself still under development, but I thought I'd throw the idea out there.