[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [RFC] New (QML) Desktop Containment
From:       Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date:       2012-11-22 16:11:56
Message-ID: 1585402.700rBpzlzH () miro
[Download RAW message or body]

Hey,

On Thursday, November 22, 2012 13:31:40 Aaron J. Seigo wrote:
> On Thursday, November 22, 2012 13:05:05 Sebastian K=FCgler 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-lo=
ck =

> 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, b=
ut =

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 mod=
es, =

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 t=
o =

give feedback (instead of just making it impossible to drag). We do somethi=
ng =

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 fe=
ed, =

  basically uses the widgets that are there

- workspace management: the user adds a widget to the containment, or remov=
es =

  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 deskt=
op =

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. th=
e =

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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]