layerlist widget source
illissius at gmail.com
Thu Dec 8 21:32:08 CET 2005
On 12/8/05, Boudewijn Rempt <boud at valdyas.org> wrote:
> 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
> > 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.
> > Work is punishment for failing to procrastinate effectively.
> Ah, you've read Diana Wynne Jones "The Complete Skiver"?
No, actually. I just saw it somewhere and decided it might be a nice
bit of reverse psychology (I have this *ahem* little problem with
Also, I'm not sure whether you were still in the channel at the time,
but I posted some screenshots:
Suggestions on the UI are especially appreciated -- one good one I've
gotten already is to have the previews to the left of the other
> kimageshop mailing list
> kimageshop at kde.org
Work is punishment for failing to procrastinate effectively.
More information about the kimageshop