Autolayers & datamanager

Boudewijn Rempt boud at valdyas.org
Sat Dec 18 17:00:03 CET 2004


On Saturday 18 December 2004 16:43, Casper Boemann wrote:
> On Saturday 18 December 2004 16:35, Boudewijn Rempt wrote:
> > For everyone's information: Casper has started work on autolayers and a
> > revised, faster datamanager around a better tile system. For now he's
> > doing this on a branch, autolayers_branch, because it is quite disruptive
> > and I don't want to spoil the chance we have for inclusion in KOffice
> > 1.4.
>
> Yes and I have some questions about the ramifications.
>
> Now that layers are about to automatically resize themselves it poses some
> questions about the functionallity
>
> But first a little background: Until now the layers had fixed sizes, and
> the user had to resize them. With the new system the layers or indeed any
> paint_device have size 0x0 to start with and then whenever painting is done
> the paint_device automatically grows.

Unlimitedly, or to the size of the image? And what happens when a layer is 
moved? 

>
> Coupled with this autoresizing I've also encapsulated the tiles in a
> datamanger, so from now on only the datamanger knows about tiles. For
> everyone else (even the paint_device) it's just a "canvas"

I've just looked at that (I have a lot less free time this weekend than I 
thought), and I think that part is what we need. It might be an idea to 
rename the 'paste' method to 'copy', because that's what it's called in the 
comments.

> what is the beginning and end for an iterator not explicitly initialized.
> My suggestion is that we should require start/end to be explicitly given
> thus avoiding any problems. 

I think so, too.

> Alternatively I have an iterator that only 
> visit pixels that have been "activated" (ie someone has written them to the
> canvas.) Also I can provide the current extent of the canvas, but I think
> that unless absolutey needed we should avoid that.

That sounds like a sound principle.

>
> what is the normal working area for tools like gradient and fill (in
> photoshop fill works on the part of the layer inside the image dimensions)

If there are no selections, then I think that that's the right option. With 
these tools we don't want to suprise users by making them subtly different 
from what they're used to. And of course, it's nice to have a floodfill on by 
default.

> what about rotate,scale and such. My suggestion is that these kind of
> operations should work on selections.

Also on selections, but we need to be able to rotate, scale, shear the 
complete image or a complete layer. If that means that the layer extends 
beyond the image dimensions, we should show that in the user interface but 
not autocrop the layer data nor just not show that it's still there. Paint it 
on the background, or something like that.



-- 
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041218/ab28b023/attachment.pgp


More information about the kimageshop mailing list