Layers, layergroups, dockwindow, preview and dynamic layersize

[Boudewijn Rempt]

On Wednesday 30 June 2004 15:40, Casper Boemann wrote:
> Hi

I've still not managed to get your patch to compile because it clashes with 
Cyrille's recent changes, but I'm working on it.

> I'm posting this to the list, since you replied to the private mail whereby
> I sent you the patch.
>
> > 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 
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. 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. 

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

(Although I would like to have some way to parallelize image ops that can be
parallelized by feeding image chunks to operator threads. Perhaps it's better 
to define an operator interface, create operator classes and feed the ops to 
the image manager.)

> But besides that. Keeping width and height might lure someone to think the
> dimension are fixed and/or relative to 0,0

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.

> btw if you grep for CBR you'll find some code commented out. Things
> primarily related to the layer docker which I'll reinstate, in the very
> near future Until then the menu items still work if you want to manipulate
> layers. But the docker is my next item on my agenda. No need to hinder the
> user for longer than nessesary.

Okay.

>
> I have also commented out the workings of the offset ()(can't remember the
> correct name) function, which eventually would go altogether. It does break
> selection but please rewrite selection to disregard extent of paintdevice.
> ( I know you are working on selections so I thought I would let that up to
> you). You should just paint all over, and not resize it either.

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. 

What do other people think of these changes? 

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi