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

List:       koffice-devel
Subject:    Re: koffice/libs/flake/tests
From:       jaham () gmx ! net
Date:       2009-09-25 17:42:54
Message-ID: 200909251942.54305.jaham () gmx ! net
[Download RAW message or body]

On Friday 25 September 2009 06:18:33 Thorsten Zachmann wrote:
> On Thu September 24 2009, Jan Hambrecht wrote:
> > Thomas Zander wrote:
> > So what we would need to do is when painting is to respect the shape
> > hierarchy. So we have to sort the shapes on each level of the hierarchy.
> > First sort all shapes by their z-Index. Start painting in that order.
> > When painting a shape container, sort all of its children by their
> > z-Index and start painting them. When painting a shape container, sort
> > all of its children by their z-Index and start painting them...
> 
> Painting shapes by the hierarchy would make the painting code more
>  complicated as then not only the shapes that are really need repainting
>  but also their parents need to be taken into account. At the moment the
>  painting algorithm is quite simple but it needs each object to have a
>  unique z-index. However the z- index needs to be unique whatever the
>  painting algorithm will use a hierarchy or not as otherwise we will have
>  the same behaviour as we have now that sometimes some shapes are above and
>  sometimes below a shape with the same z- index.
> 
> > That would ensure what you described above and would also make sure,
> > z-Order inside a shape container is handled correctly.
> >
> > > The 'if' has the comment; // we can't be under our parent.
> > > Which illustrates this is the reason for it being there. I don't know
> > > if this is the best solution, but its one that seemed to have worked so
> > > far.
> >
> > Well obviously it does not work, otherwise we would not discuss these
> > matters now, would we?
> >
> > > If someone makes a patch that effectively removes that line I think
> > > we'll have to do a lot of testing to make sure all code still works
> > > according to the above design.
> >
> > As written above, i think this line does not make sure that the above is
> > working correctly.
> 
> The line does only work in one direction but not in the other e.g. not when
> raising objects. Also it does not work when you have a layer as a parent
>  for the group and the shape as then both might return the same z-index.

So to sum it up, it does not work. :-)

> 
> I think there are two possibilities:
> 
> o Use a hierarchy when painting:
> - more complicated paining algorithm
> - 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.

I don't think it is such a good idea to do that. And even if the spec allows 
it (is it explecitly stated, or is it just not specified at all?), it is 
against common behaviour of painting apps.

> - in one hierarchy level the z-index needs to be unique
> 
> o have a unique z-index over the full document.
> - ordering is a bit more complicated for lower/raise
> 
> I think both ways need quite some work to implement.
> 
> Thorsten
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
> 
_______________________________________________
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]