[RFC] New (QML) Desktop Containment

[Sebastian Kügler]

Hey,

On Thursday, November 22, 2012 13:31:40 Aaron J. Seigo wrote:
> On Thursday, November 22, 2012 13:05:05 Sebastian Kügler wrote:
> > The idea is to make locked mode the default
> 
> so to do anything to the system, one first has to discover that it can be 
> unlocked, then unlock, then to return to the optimized-for default, re-lock 
> it.
> 
> it creates a system that only works as intended when done so in strictly 
> divided modes.
> 
> can we imagine any way to make interacting with the system more baroque,
> less  discoverable and more labor intensive?

This increased modality is a problem I have with my PoC approach as well, but 
haven't solved yet. There are I think two aspects to it, which we may want to 
make as seamless as possible (i.e. reducing the labor to switch between modes, 
increasing the discoverability how you do changes to the widget, resizing, 
moving, configure, etc.).

Right now, we're defaulting to unlocked, and show applet handles on hover 
events, on the left or right close to where the mousepointer entered, when the 
desktop is locked, one always has to go through the toolbox or context menu to 
unlock first. Configuring the containment is possible in both cases (locked 
and unlocked). 

Configuring an applet is possible through the context menu also when locked, 
but only via unlock -> applethandle when locked. Actions such as open in 
$Application are only available via the applet handle, so only unlocked 
(although it has nothing to do with manipulating the applet itself, it's 
directly content related).
So for many workflows, we rely quite heavily on the desktop being unlocked.

Also, when something is dropped onto the containment, it would make sense to 
give feedback (instead of just making it impossible to drag). We do something 
similar in the containment's config dialog, which mentions "you first need to 
unlock, [do that]" at the top.

I think it makes sense to think in two different workflows for the user:

- content aware: the user types something in the notes plasmoid, reads a feed, 
  basically uses the widgets that are there

- workspace management: the user adds a widget to the containment, or removes 
  it, rearranges the widgets

One should not get into the way of the other, it should be intuitive, easy and 
precise to switch between these workflows.

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


One idea I had bouncing around was to unlock the widgets also on certain 
actions. For example when the widget is dragged beyond a certain threshold. 

My biggest question mark for this idea is when to trigger the unlock, or 
rather: How to detect if the user wants to manage the widgtets. 
If widgets can dragged, we need to communicate "this is how you drag" 
(currently our visual indicator for that is the applet handle). 
On touchscreens, tap-hold-drag is quite natural. An equivalent on the desktop 
is drag and drop, so this behaviour would be consistent with what users are 
used, a common metaphore.

Unlocking is I think easier, idea: While the desktop is unlocked, we show a 
small information frame at the top, with a "Lock widgets" button, and maybe a 
timer which locks the widgets after a certain amount of inactivity (i.e. the 
user is using some other program or hasn't moved / resized in the last N 
seconds.

This is a bit of a braindump of the part "what problem are we solving here?", 
not a solution at this point. :)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9