[RFC] New (QML) Desktop Containment

[Aaron J. Seigo]

On Thursday, November 22, 2012 17:11:56 Sebastian Kügler wrote:
> So for many workflows, we rely quite heavily on the desktop being unlocked.

indeed. locking the desktop introduces a separation between functions. 
axiomatically, it removes functionality. that's the point of it. and when 
removing functionality two things happen:

* you can do less
* you are confronted with fewer controls (access to actions)

one possibility is to provide a toggle switch that exposes more functionality. 
this is the same underlying concept behind "simple" and "advanced" user modes.

and i think that's the root of the problem. some actions are seen as "too 
much" (visually, interaction skill, etc.) and so "lock desktop" has become a 
simple/advanced modality switch for some people.

btw, the lock function is actually the kiosk mode exposed. it was never 
developed for its use as a feature separate from that. i regret exposing it at 
this point because it has become a simple/advanced mode switch and has caused 
some to decide that instead of solving the actual issues with the full UI to 
try and split it into modes. this creates new problems, several of which 
you've enumerated.

my suggestion is that instead of creating a new solution that works around the 
actual problems (by hiding them under the rug) and just creates new 
inneficiencies and problems of its own .. we should identify what would be good 
to improve and require of ourselves that we come up with solutions that do not 
involve modes.

it's going to be just as much work to get a modal system into a highly 
functional state as it will be to improve the current non-modal (by default, 
anyways) implementation. putting that effort into modal will result in an 
inferior by design result.

so please, back away from the crack pipe of "just lock things by default!" and 
consider the actual issues that need resolving and let's work on them one by 
one.

if at the end of the exercise we find that there is no way to produce a 
satisfactorily working system without modes, then we can consider that. but 
nobody has gone down that road yet.

> Viewing it from this angle, would probably also mean to streamline which
> actions are offered in which mode.

or just don't have modes. all the problems you enumerate come from trying to 
solve the problems of movement and "applet handles are not pretty" with modes.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121123/d822b0ef/attachment.sig>