--===============1982499998634263423==
Content-Type: multipart/signed; boundary="nextPart1523237.RoPacPhy8b"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: quoted-printable


--nextPart1523237.RoPacPhy8b
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Thursday, November 22, 2012 17:11:56 Sebastian K=FCgler wrote:
> So for many workflows, we rely quite heavily on the desktop being unl=
ocked.

indeed. locking the desktop introduces a separation between functions.=20=

axiomatically, it removes functionality. that's the point of it. and wh=
en=20
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 functio=
nality.=20
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 "t=
oo=20
much" (visually, interaction skill, etc.) and so "lock desktop" has bec=
ome a=20
simple/advanced modality switch for some people.

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

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

it's going to be just as much work to get a modal system into a highly=20=

functional state as it will be to improve the current non-modal (by def=
ault,=20
anyways) implementation. putting that effort into modal will result in =
an=20
inferior by design result.

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

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

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

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

--=20
Aaron J. Seigo
--nextPart1523237.RoPacPhy8b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEABECAAYFAlCvThEACgkQ1rcusafx20NeKQCfR5n5xP6JXXCxStpXMM7bBTST
yWAAnjNiLczmiz7fN5Zz2xV+TN7+o0io
=jQCC
-----END PGP SIGNATURE-----

--nextPart1523237.RoPacPhy8b--


--===============1982499998634263423==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

--===============1982499998634263423==--