[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: kounavail reborn
From:       Thomas Zander <zander () kde ! org>
Date:       2010-03-21 21:53:26
Message-ID: 201003212253.27799.zander () kde ! org
[Download RAW message or body]

On Thursday 18. March 2010 14.08.08 Inge Wallin wrote:
> So we have two possibilities:
>  1. Create a normal shape, but test for it in the loop above and don't use
> it. 2. (suggestion from boud): Make the unavailshape part of the flake
> library

What is an important detail is that the order of the frames in the ODF is 
relevant. For the general audience I'll just repeat that part as its relevant 
to what comes next :)
So if there is more than one datatype (for example musicML and then SVG) the 
one without loss is the first one, the others are fallback types and having a 
proper implementation for the first type mean the rest can be ignored without 
dataloss. (as the plugin can regenerate them)

So, I want to change the problem description from there being nothing to 
handle the content to instead we not having a handler for the first datatype 
(musicML in my example). Not having a primary handler leads to dataloss.

My suggestion would then to change the loop you pasted to not being a loop 
anymore but instead a single pass.
* for "draw:object" call createShapeInternal()
* if there is no plugin create the un-avail shape and call load on it with the 
draw:frame XML element. Passing this xml element means it can know about all 
the draw:object elements.

The un-avail shape then can store the content of the first type and it in turn 
can iterate all the alternative types to see if there is a usable fall back. 
If all fails, it should draw something, much like you suggested.

If the un-avail shape is created as a shapeContainer it can then just create a 
child SVG or PNG, etc shape to show the alternative content. Potentially 
making it non-editable. (would make sense to me to lock it at least)

I agree this belongs inside of Flake, my selling reason is that this shape 
should never be seen in the flake shape registry. Something that is mandatory 
for a plugin. Not having it in the registry avoids recursiveness and IMO it 
would confuse the user to see this in a shape selector.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]