Re: [Traverso-devel] Theming: fonts, colors, etc

[Remon]

Hi,

> We're asking for object->property in the source code, and if the XML parser
> finds a corresponding entry in the XML file, its value is returned. If the
> entry doesn't exist, we should suggest a default value, just as in
> QSettings.

Well, I had something in mind like the current Config class, you probably 
noticed the similarities between my suggestion and the Config class usage.

The Config class loads the _whole_ settings file, by indeed using the 
QSettings class, and stores it in a Hash as a QString, QVariant pair.
Now, getting or setting a config value is _really_ fast, memory overhead is 
very low, enfin, you get the idea.

The same thing would apply more or less to the Themer, it would parse the xml 
file only one time (expensive operation), create the Font, Color and whatever 
it has to create objects, and stores them into maybe a Hash too, or some 
other form of 'library'.

Idea is as follows:

Objects get their font, color and/or gradient in their paint() function _all_ 
the time.
So the get function needs to be fast.
Now, when you change a font or color, the themer emits the fontChanged(), or 
colorChanged() signal.
The objects connected to this signal only have to do an update() call to 
reflect the changes. Since most objects allready inherit from a base object 
(e.g. ViewItem for the View classes), the whole code for this can be done in 
3 or 4 files maybe.


> I have absolutely no experience with XML, so I may be totally wrong, but
> like this you need special functions for each class, e.g. get_color for
> colors, get_font for fonts etc. If there's a new type, the themer must be
> updated. E.g. if in future we need QPixmaps, a get_pixmap function must be
> added.

You have a point here. On the other hand, it's not that hard to add one 
function in the themer, and do most of the parsing there, instead of doing 
the parsing in all the classes that get their theme from the themer .. ?

> OTOH if the themer would have one function get_value(object, property),
> return the value as a string, and leave it to the source code to interpret
> it, we would be much more flexible. The above XML could looke like this for
> example:
>
>         <object name="VUMeter" >
>             <property name="color:background" value="#99aaff" />
>             <property name="gradient:background" value="#ffffff;#cccccc" />
>             <property name="font:cliptitle" value="(whatever
> QFont::toString() returns)" /> </object>
>
> At first this looks much less convenient, especially because decoding the
> value of e.g. a gradient requires some effort. Getting a font value would
> be:
>
>       QString s = themer()->get_value("VUMeter", "font:cliptitle");
>       QFont f;
>       f.fromString(s);
>
> But if we later decide to have more properties, e.g. by adding a background
> pixmap, the changes would be trivial:
>
>         <object name="VUMeter" >
>             <property name="color:background" value="#99aaff" />
>             <property name="gradient:background" value="#ffffff;#cccccc" />
>             <property name="font:cliptitle" value="(whatever
> QFont::toString() returns)" /> <property name="pixmap:bg_tile"
> value="/usr/share/traverso/bg.png" /> </object>
>
> Loading the pixmap would be:
>
>       QString s = themer()->get_value("VUMeter", "pixmap:bg_tile");
>       QPixmap p(s);
>
> No modifications to themer required.

It's indeed something I forgot to add in my example, a property 'type' for 
each object, that can be parsed by the object itself, due it doesn't fit in 
an obvious catagory.

Actually, your idea is a very nice one, though the downside is that the xml 
needs to stay in the themer, and has to be parsed (to some degree) everytime 
an objects wants to know some property, with of course the downside that 
the 'expensive' conversion from a QString -> someothertype has to be done.

This at least means that getting theme data is a no go in the paint() 
function, unless the conversion from QString to other data types isn't as 
expensive as I think it is......

The benefit of leaving most of the parsing to the themer is that for every 
type of data, the parsing will only happen one time, at least on a per object 
basis.
Take for example the CurveNodeView object, even if you cache the result in the 
constructor of CurveNodeView, so you don't get the theme information in the 
paint() function, every CurveNodeView object that is created will do the same 
parsing, which add's to the overhead of loading a project (CurveNodes can 
easily become into the amount of hundreds if not more ???)


> It's a bit like QSettings, which always returns QVariant and uses
> QVariant's casting functions to convert it to a different type.

There are few types that aren't supported by QVariant, but indeed it's a good 
idea to use the 'default value' thing in case a theme is missing some 
parameters....


> I hope that's not utter nonsense... ;-)

I'm not a guru with xml either, and your idea seems absolutely valid, though 
I'm not sure about the overhead of it.

Perhaps a mix of both would be a good solution?
Things like QFont and QColor, as well as QGradient can be get by dedicated 
functions, with extremely low overhead, 'custom' properties are returned as a 
QString, and the parsing is left to the object itself ?

At least for QFont this would be very handy, if one wants to scale the font 
size application global ?

QPixmap 'could' be handy too, since Traverso uses the QPixmapCache. Loading 
pixmaps is rather expensive, and there is a find_pixmap() convenience 
function in Utils.h iirc, to make use of it. On the other hand, that could be 
called from within the object as well .

Regards,

Remon