Improvement of the styles handling in Calligra

[C. Boemann]

On Tuesday 17 April 2012 09:05:39 Inge Wallin wrote:
> On Tuesday, April 17, 2012 07:09:51 C. Boemann wrote:
> > On Tuesday 17 April 2012 03:27:39 Inge Wallin wrote:
> > > > If a inherited style overwrites one property of a style e.g. the
> > > > color a new KoShapeBackground would be set in the inherited style.
> > > 
> > > That could work, yes. It will be somewhat complex to create the style
> > > again on saving.  Here is a problem:
> > > 
> > > Say that we have two styles, A and B. B inherits A.  We have two
> > > attributes x and y which could be set in A, B or Both.  x and y
> > > together create the complex value Z.  Now suppose both x and y are set
> > > in A, creating a Z value for style A.  And x is changed in style B
> > > meaning that in our binary representaiton we will have another value
> > > for Z in B. Now when we want to save the styles back to a file, there
> > > is no way for us to know if y was set in B to the same value as in A
> > > or if it was left unspecified and just inherited its value from A.
> > > This makes a difference if the value of y in A is ever changed.
> > 
> > But we should never touch A in calligra, which is sort of what I hear
> > zagge saying too. If we always modify the autostyle on top, then saving
> > back while retain the inheritance and the values in A (so that data is
> > not lost for people loading it back into LO/OO)
> 
> First, I don't agree. We might not want to touch it in Words (the jury is
> still out on that one) but I can see some definite value of touching it in,
> say, Flow. Changing whole diagrams by changing a graphic style would be
> much in line with what that applicaiton does.
True it makes sense there. Okay so we should have the infrastructure in place, 
but the use of graphic styles needs to be done very selectively. Ie only where 
presentation of graphics is the primary ting. Just like textstyles where 
presentation of text is the primary thing.

> Second, it is irrelevant for the discussion.  *If* somebody changes A even
> outside Calligra (and OOo and LO has the features to do it) then we should
> not have destroyed the information in B. So we need to be able to keep the
> information even while saving memory. The whole point of the proposal is
> to keep the information that is already in the file, regardless of if we
> allow the user to change it or not.
I believe that is what I just said: "while retain the inheritance and the 
values in A (so that data is not lost for people loading it back into LO/OO)"
Obviously that means not littering B with copies of A's values but only change 
those when the use does.