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

List:       koffice-devel
Subject:    Re: Notes on koffice unit tests
From:       Jan Hambrecht <jaham () gmx ! net>
Date:       2007-02-12 11:48:17
Message-ID: 45D05401.105 () gmx ! net
[Download RAW message or body]

Thomas Zander wrote:
> On Monday 12 February 2007 12:11, Jan Hambrecht wrote:
>> I looked up the z-index definition in the odf spec as well as the
>> svg-spec. It seems that the z-index attribute is not well defined. Odf
>> just points to use the svg:z-index. But in svg the rendering order is
>> only defined by the order of the elements inside the document.
>> See http://www.w3.org/TR/SVG/render.html#RenderingOrder or
>> http://wiki.svg.org/Rendering_Order.
> 
> z-index is a very old concept that all apps know. I'm sure I don't have to 
> explain it.
> The drawing order in current svn is something I choose to make the effect be 
> what you expact from the z-index concepts.
> Which means the lowest z-index is drawn first so another can be drawn on top 
> of that.

I am aware of that and i am fine with what you have done in flake.

Actually this mail was not meant to trash the z-index, rather to point 
out that there is still some flux on how that will finally be defined in 
the svg as well as the odf spec.

> 
> If you look at KoShape you will notice a hasTransparency() method. If that 
> returns false then you can avoid drawing any object that is completely hidden 
> below it.
> There is no code for that just yet, as its an optimisation that I postponed 
> until I have less to do.  But its important to keep in mind when creating 
> this.
> Its also why in my other email I stated that the hierarchical painting for 
> hierarchical shapes is a good thing.

Yes i prefer that too, but again that would break the z-order painting. 
And what is with the shape containers z-index?
As long as the the z-index works document wide and can be abitrary set, 
there are cases with unclear rendering order.
Or do i miss something?

> 
> Notice that the KoShapeGroup is just a convenience class where the difference 
> lies in selection.  Other than that the shapes are just like non-nested 
> children of a KoShapeContainer.
>
Ack.


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