[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Traverso-devel] Theming: fonts, colors, etc
From: |
Remon |
Subject: |
Re: [Traverso-devel] Theming: fonts, colors, etc |
Date: |
Wed, 31 Jan 2007 18:40:37 +0100 |
User-agent: |
KMail/1.9.6 |
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