Toolbox Brainstorming

[Aaron J. Seigo]

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?)

> 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.

> * 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()

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.

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.

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.

> 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.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080105/a5254193/attachment.pgp