layerlist widget source

[Boudewijn Rempt]

On Wed, 7 Dec 2005, [ISO-8859-1] Gábor Lehel wrote:

> So, a few people were asking what I have so far with the new layers
> widget, so here it is. It's not yet in krita, because krita needs some
> refactoring to use it the way I'd intend, and I haven't done that yet.

No problem, Krita is like plasticine... We can fix everything that needs
fixing.

>
> random notes:
>

I think the name would be better as LayerListView or LayersView -- classes
ending in List tend to be abstract data classes, not widgets.

> - LayerList has such an ungodly amount of slots forwarding things to
> LayerItem because it's a QObject and LayerItem isn't -- I'm not sure
> whether these are useful to have, or whether they're just clutter
> (opinions?)

Are they used at the moment? Do we need them when refactoring Krita to make
it possible to use your layerview? If not, then they are clutter. We're
not yet trying to create a binary compatible set-in-a-slab-of-stone API.
The simplest thing that works, the smallest class that does everything we
need, that's the thing to strive for. I've been pruning classes like
KisView and KisImage of unused methods for ages :-).

> - I have similar concerns with regards to being able to use IDs for
> layers instead of just LayerItem*s (adds clutter), but most likely
> this is genuinely useful and I'll keep it

ID's are good, because that will hide the LayerItem implementation
from the rest of Krita (and Kivio, Karbon and possibly other apps).
That would make the layerbox a facade design pattern, but that's
fine with me.

> - I'll probably get rid of LayerFolder (or leave it purely for
> convenience), and have a bool d->isFolder in LayerItem instead, so you
> can inherit from it without things becoming a mess when you want to
> use folders too

Fine with me.

> - I'm not sure how to handle preview images -- use setPreview(QImage*)
> to set it, and then previewChanged() to notify whenever it changes (as
> now); or have setPreview(const QImage&) and use that to set it /and/
> every time it changes; or support both ways; or something else
> entirely?

Depends a bit. I was working on the preview thumbnail mechanism for the
birds' eyeview widget and I hadn't decided what the best strategy would
be. May be something to refactor when integration time comes.

> - this is, of course, a work in progress: some things (like tool tips)
> just plain aren't implemented at all yet, others may not work
> properly, for lack of testing -- I'm planning on stumbling upon and
> fixing most of these when I integrate it with krita

That's the nice thing about software -- it can (almost always) be
fixed :-)

> Comments, advice, opinions, et al welcomed.

Thanks!

> Work is punishment for failing to procrastinate effectively.

Ah, you've read Diana Wynne Jones "The Complete Skiver"?