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

List:       koffice-devel
Subject:    Re: koffice/libs/flake/tests
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2009-09-27 10:07:09
Message-ID: 200909271207.09769.t.zachmann () zagge ! de
[Download RAW message or body]

On Fri September 25 2009, Thomas Zander wrote:
> On Friday 25. September 2009 06.18.33 Thorsten Zachmann wrote:
> > - it will no longer be possible to have something like the following:
> >   layer 1: shape 1, shape 2
> >   layer 2: shape 3, shape 4
> >   and the following order:
> >   shape 1
> >   shape 3
> >   shape 2
> >   shape 4
> >   which is possible right now and also allowed by the odf spec.
> 
> What does that mean, allowed by the odf spec?

It is possible to create a document as described above in oodraw. It is also 
valid odf. There is nothing in odf which prevents something like that. So what 
should a koffice application do when it opens a document with the above order 
and layer combination?

> I think its essential to have shapes keep in their layers and not have a
> shape shown on top of a shape in a layer above. I had the impression that
> this is a universal usage and design concept of layers.
> Do you agree with that?

I don't have a personal preference on that one. I can see uses for both ways, 
e.g. if you like to be able to hide things easily by setting a layers 
visibility then a not hierarchy approach is really handy.

> So, I'd support fixing the painting order to respect the shape hierarchy.

That is not the only think that needs fixing to make it work.

> The algoritm Jan described sounds a bit complex; I have the impression it
> can be fixed by just making the sorting method take the parent into
>  account. If you don't see what I have in mind, I can make a mockup of my
>  idea later.

The idea is clear and this should work. 

Thorsten
_______________________________________________
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]