Layers, layergroups, dockwindow, preview and dynamic layersize

[Casper Boemann]

On Wednesday 30 June 2004 21:55, Boudewijn Rempt wrote:
> > > Maybe it would be nice to keep the width() and height() methods
> > > in kis_paint_device and have them return
> > >  x() + extentLeft()
> > >  y() + extentUp()
> >
> > That would give the topleft corner of the layer in image coords.??
>
> Well, it is what you used to replace width() and height() with in the diff.

I hope not,  I have replace made some special replacements sometimes 

> I think it is important to hide things like this behind a simple API.
> Extending the layers should be automatic, the paint code shouldn't need to
> concern itself with details like that

Yes and no. The fact that you can paint on negative coords cannot be hidden.
The use of extentXXX() should be reserved for those places where we filter or 
do other things to the entire paint device. Ideally we should use iterators 
for this.

> . Ideally, I want to hide all the 
> image data behind the simplest interface possible, so image operations,
> whether paint ops, filter ops or composite ops do little more than request
> a pixel or a rect of pixels (by location or through an iterator), do their
> thing and write the rect of pixels back.

There you see - we agree.

> All the tile cobbling, the undo storing, the deferred loading and all that
> kind of complexity should remain hidden.

ideed

> By the way, I couldn't find out for sure whether images still have a fixed
> size with your code. Oh, and it might be a good idea to adapt the
> tilemanager to not allocate tiles if there's nothing but background colour
> pixels. That way we really have minimal memory usage.

Images still have fixed sizes and this should remain so. The projection and 
bacground paintdevices are special cases and this I'll look into, more than I 
already have, but I am aware of them and know how to handle them when I come 
to part 2 and 3 of my plan to introduce dynamic layersizes.

> Yeah, right :-). One thing at a time. I guess the selection type that you
> broke is the floating selection thingy -- with the Gimp that is clearly a
> fixed size layer. I think we should keep to behaviour, which means that we
> need a way to make layers of a fixed size. And that's on your plate :-). I
> will handle selection masks, but floating selections are a type of layer I
> wasn't intending to touch very much.

I'll fix that as well then. But what is currently implemented is actually a 
kind of dynamic layersize (it moves the contents and resizes the 
paintdevice). all that is needed to fix floating selection is making the 
layers dynamic, and some small codechanges to delete the old behaviour. Voila

> What do other people think of these changes?
probably not a lot since they don't have the patch and files. Perhabs you 
could post them (or commit) when you have merged with cyrille's changes?

best regards
Casper Boemann