Toolbox Brainstorming

[Chani]

huh. I agree that having the desktop toolbox on a panel would be weird. if the 
desktop toolbox is meant to be strongly associated with the desktop 
containment, then it should be on the desktop, and stay there.
but then I get confused as to whether it should zoom out with the containment: 
if it does, then it's tiny and hard to use. if it doesn't, then it's suddenly 
this separate magic thing and I start expecting it to be associated with the 
corona instead.

I seem to remember there being agreement that it should not be zoomed out. 
this brings up some questions in my mind:

how do we zoom back in if there's more than one containment?
how do we avoid having several toolboxes on top of each other (one per desktop 
containment)?
how do we know which containment it's associated with while zoomed out?

the solution to the second question seems obvious: only show the toolbox if 
you're the active containment. this implies that we have an 'active' one, and 
that the toolbox in the corner is associated with it. maybe have some shiny 
effect to highlight the active one. that solves question 3, and part of 
question 1 since the 'zoom in' button would apply to the active one. now you 
just need to be able to change which one is active (as simple as clicking 
anywhere on one of them?) and maybe have some kind of shortcut to zoom in on 
a specific one without first clicking it and then clicking the zoom-in 
button. heck, just adding the zoom actions to the context menu would do that.

am I on the right track here?
I've been assuming that we want to keep the ability to interact with applets 
on the first zoom-out level; if nothing else it'll be useful to drag them 
around then.

> > in the panel this would also unlock something like applet handles in
> > all panels so it's possible to rearrange applets also in the panels.
>
> that's exactxly the plan for the panel toolbox, yes =)

oh yeah... panel toolbox... yes, someday we'll actually be able to configure 
that beast ;) btw, did you ever see the mockup fonz did? I like that one.

>
> > if the user removed the toolbox plasmoid all the toolbox icons are
> > displayed in each containment like today.
>
> hm.. that would require lots of special casing and communicating between
> containments. that sort of hacking in the code makes me very ... hesitant
> as it quicky leads to a very ugly code base.

special casing is bad. bad, bad, bad!

I notice somehere else in this thread there's mention of hiding the toolbox 
when it has nothing to show. it seems to me that it should *never* have 
nothing to show; I think that the lock/unlock action belongs in there. 
although I do have two questions about that:
does locking applets apply to all containments (desktop and panel), or just 
the current one?
should configuration be allowed when they're locked?

also, if the toolbox stays glued to the corner, I forsee problems when panels 
are movable. what's the point of a toolbox that's buried under a panel? I 
don't know how to deal with that nicely.

oh, and I don't agree with the idea of making the toolbox an applet: that'd 
mean it would have a handle (destroying its prettiness), and could be messed 
with and accidentally removed by a silly user. I say that there should be a 
way to hide it, for the people who really want that (I'm starting to want it 
myself), but it should *not* be something that could be done by accident 
(seeing how much trouble amarok had with people losing the menu bar even 
though they actually had a menu button appear while the menu bar was hidden 
proves that people can be really, really dumb)

-- 
This message brought to you by evyl bananas, and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080106/08a8b67f/attachment.pgp