Hiding vs. locking functionality

[Aaron J. Seigo]

On Wednesday 09 January 2008, Sven Burmeister wrote:
> On Donnerstag, 10. Januar 2008, Aaron J. Seigo wrote:
> > > > this is not new in plasma, btw, but exactly how it was implemented in
> > > > kicker with not complaints recv'd.
> > >
> > > Of course it is. Kicker is one thing to lock, i.e. "lock kicker" locks
> > > kicker. Yet locking widgets in this case means lock desktop + toolbox
> > > and panel, none of which are perceived as widgets by the user, but as
> > > desktop, toolbox and panel. "Lock desktop" would come closer as the
> > > user might assume the toolbox and panel as part of the desktop.
> >
> > i am aware that we are working towards changing how the user interacts
> > with the workspace.
>
> You could use that sentence to justify anything, so it is not really a
> valid reason, is it?
>
> Further, first you say: we did it like that in KDE3 and are now basically
> doing the same, so there is no reason to change it. Then you change 180°
> and argue that things are changing? Either or.

if you follow the conversation accurately, what i said was this:

locking means not adding, just like we did prior. (rational: we know that 
decision works well due to past experience)

locking also means all widgets, not just panel or per containment. that's 
purposeful; but you state that people won't make the connection between the 
panel and desktop, and i'm saying that that is something we are actively 
changing.

there are two sub-threads to this conversation =)

> Either KDE3's behaviour has to be kept, because nobody complained and
> people are used to it,

it's not because people are used to it, it's because we know this solution to 
the problem (which is identical in this way in both kicker and plasma) worked 
well.

> "lock desktop" and not just a "lock widgets". Or plasma is working towards
> a new way to interact, then you cannot justify that "lock widgets" is right
> because it worked for kicker.

in this way, the situations are different. in fact, in kicker, when you locked 
the panels, you locked all of them; in that way it's no different. the 
difference is that we now pull the desktop (among other things) into this as 
well.

to add some more context here: there were requests in kicker to be able 
to "Lock this panel". however, my concern is that to lock all the panels one 
would have to go around do that on each panel _or_ we'd have to provide 
_another_ option to "Lock all panels". neither approach was great and the 
need for the small tweak really felt unecessary: you can only interact with 
one area at a time anyways, so lock/unlock as needed/desired. it is for some 
cases less efficient, but for most of the actual use cases it is better.

-- 
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: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080109/7a0780f9/attachment.pgp