Improvement of the styles handling in Calligra

[Thorsten Zachmann]

Hello,

On Sunday, April 15, 2012 22:36:13 Inge Wallin wrote:
> I wrote some documentation during the weekend at
> http://community.kde.org/Calligra/Code/Styles. It is mostly documentation
> of how styles are handled in Calligra today but at the end there is a
> suggestion for an improved system.
> 
> I got the thumbs up from boemann for this proposal but before I start
> coding I'd like other people to take a look and give feedback.  So please
> take a look and say what you think of the idea. It would be good if we
> could clean up this very vital part of the engine.

thanks for taking a look into this. It is true that named graphic styles are 
not kept. That does not mean we loose anything on loading and viewing.

However I think to use a system like we do for text properties also for 
graphic properties is not a good idea as we already have hightly specialized 
classes that handle the graphic properties. Those classes use much less memory 
then what would be needed if we go the way we do for paragraph styles. The 
classes we have at the moment are also very effective and good to use during 
runtime.

After some thinging I got the following idea to use some hybrid of both 
methods. Let me explain a bit

For graphic proerties we have e.g. background (color/gradiert ...), forground 
(color/gradient ...), linestyle, shadow ...
We should keep the classes that store this data and handles it.

However all those different properties of the graphic style can be added to a 
map as used in the kotext style classes. something like

QHash<int, QVariant> m_stylesProperities // int is a enum of the type QVariant 
a pointer to e.g. KoShapeBackground, KoShapeBorder ....

To have inheritance each level of a style would have that. and define a parent.

If a inherited style overwrites one property of a style e.g. the color a new 
KoShapeBackground would be set in the inherited style.
To make handling with styles easier I think each shape should have its one 
inheritance level even if if does not overwrite any properties in it. This 
will make modifiying the properties of the shape much easier.

I think separating the storage form handling the data makes no sense as that 
would mean the runtime would be much worse and also the memory footprint would 
increase quite a lot which will make it harder to use on embedded devices. 
This is done in kotext as we use qtextdocument and not our own classes to 
render the stuff and we had to integrate with this system. However that is not 
a good reason to do that also for the other styles.

What do you think.

Thorsten