Toolbox Brainstorming

[Riccardo Iaconelli]

On Saturday 05 January 2008 20:18:25 Aaron J. Seigo wrote:
> On Saturday 05 January 2008, Riccardo Iaconelli wrote:
> > * Make the animations faster, they're way too slow now, and make the
>
> you could also patch the default animator to make moves 200ms (or even
> 150?)

Yeah, but I don't think this is the right solution. While animators should 
control the visual effects and the fps, they should not control the duration 
of the animation, that should be decided by the user (user as in developer).

After all, not all moves/effects are the same, some may need a 500ms, while 
for some others a value of 50ms is much more appropriate.

> > buttons fully disappear behind the edge of the screen, instead of
> > randomly "just disappearing" in the middle of the animation. (patch 0002)
>
> +    int x = 100; // TODO: this is an arbitrary value, try to calculate
> basing on the tool width
>
> that should be fairly easy. just iterate through the tools and ask for
> their size, pick the largest or smallest (depending on the desired effect)
> and use that.

I'll do that later, not said that's impossible, that's why I added a todo. ;-)

> > * Minimize the toolbox if it has no tools to show. Looks broken else.
> > (patch 0004)
>
> patch 0003 =) it looks more complex than it needs to be; why not just hide
> it completely when the number of children is 0 and show it when the number
> is > 0? this can be checked for where tools are added, removed and enabled.
> no need for an m_minimized member (just check if it's shown or not, right?
> =) and probably don't even need calls to setMinimized as it becomes one
> liners to Phase. you'd still need to catch when the disappear is done, of
> course, to call hide()

Personally, I think that throwing away such widgets isn't good, it leads more 
to the so-much-hated surprise, and, after all, for later releases the toolbox 
will remain un-minimized almost all the time (we'll have zoom actions).

What we get by minimizing instead is also a stronger association of that 
corner with the toolbox, that will consequently get into the user habitudes.

And apart from that, I think that visually it makes more sense, and it's 
indeed nicer, if it still stays there, littler. =)

Oh, btw, random idea... what about a blob of plasma as background instead of 
the current gradient? :-)

For what regards the moveItem part, I haven't thought of zoomout, and so, 
yeah, something better than move can be done (like using clipping), but I 
really think that minimizing is the way to go.

Oh, and... because we've raised the toolbox-zooming issue... are we sure the 
toolbox must resize too? Why can't it remain fixed? It's a control interface 
after all, not a plasmoid. Don't have a strong opinion about this zooming 
problem anyway.

> also, code like this:
>
> +        int enabledChildren = 0;
> +
> +        foreach (QGraphicsItem *child, QGraphicsItem::children()) {
> +            enabledChildren += child->isEnabled();
> +        }
> +
> +        if (enabledChildren == 0) {
> +            setMinimized(true);
> +        }
>
> can be written like this (excuse my indentation, email clients make crappy
> code editor ;):
>
> +        bool childrenEnabled = false;
> +
> +        foreach (QGraphicsItem *child, QGraphicsItem::children()) {
> +            if (child->isEnabled()) {
> 	childrenEnabled = true;
> 	break;
> 	}
> +        }
> +
> +        if (childrenEnabled) {
> +            setMinimized(true);
> +        }
>
> saves you going through the whole list.

Yeah, allright, much better like this. =)
Didn't think of it.

> in any case, the toolbox should be hide()'d  so that it's not visible even
> when zoomed out. personally i'd prefer to use the appear/disappear Phase
> events as they are semantically closer to what its doing here.
>
> > the other two are not really about the toolbox, and are almost
> > one-liners,
>
> patch 0002: obviously, this was done to mimic the Qt tooltips. but i agree
> they should be faster. 300ms might be a bit fast; in kicker it was 500ms
> and that seemed to work nicely.

It could be the animation, but I can assure you, that having kicker and 
plasma's panel one on each other, the perceived delay is identical (at least 
when the animation starts). =)
If you try it out you can see it's the right delay.

> patch 0004: yes, that's correct. will need to be careful we don't introduce
> any widget related stuff (beyond the already existent icon stuff) in that
> dialog though.

Sure, committing.

> > P.S. something that doesn't make me happy is it not having an antialiased
> > border when in "normal" state. Anyone has clues on how to sanely do it?
> > setClipping is obviously not anthialiased.
>
> well, one option is to clip a couple pixels larger than needed and draw an
> antialiased border just within that.

I've thought of that, but then the actual painting code will still need to be 
changed... but yeah, I guess it's the only option.

Committing 0001, 0004 and 0002 for now, waiting to resolve the minimize vs. go 
away discussion reguarding the toolbox to commit 0003.

Bye,
-Riccardo
-- 
GPG key:
3D0F6376
When encrypting, please encrypt also for this subkey:
9EBD7FE1
-----
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080105/9f89223b/attachment-0001.pgp