some updates on screen locking related things

[Aaron J. Seigo]

On Wednesday, January 23, 2013 11:00:18 Marco Martin wrote:
> On Wednesday 23 January 2013, Aaron J. Seigo wrote:
> * if the root item of the lock screen doesn't have some property to say that
> supports locking (or even its metadata.desktop) load another qml file
> instead that is purely used as fallback

that's a reasonable idea and one that had occured to me, but i actually kind 
of like the idea of the lock screen being able to provide or deny this 
feature. this would be convenient for, e.g. plasma active.

> * fit the user switching ui in the ksmserver logout dialog instead of
> lockscreen (that is qml anyways) the switch user ui in the lockscreen would
> use the same file as default, so the dialogs would look exactly the same

that's a good idea in terms of being able to componentize this bit. it needs 
to be shareable between lock screens by PW2 anyways.

> loading the ui with the logout window would solve this "hard to cancel"

tbh, i really dislike the current logout window. but that's another topic :)

> problem (mostly an issue just on passwordless login systems where one would
> like to never be confronted with a password)

passwordless systems are an interesting use-case. at the very least, i expect 
the lock screen may need to be able to handle "switch user, but don't lock on 
switch user cancel"

> on the other hand simplifies the process a lot, since when the session is
> switched it has to lock the screen eventually as well, to me is the thing
> that may make this approach "win" ;)

exactly; if the lock process is already in effect, then this becomes faster and 
more reliable.

i will think more about how to make it work with passwordless systems better, 
and perhaps even how to reconcile the logout UI with this as well.

eventually i'd like to have as *few* different QML packages as possible. i 
don't particularly like the idea of having separate packages for:

* splash
* lock
* switch user
* logout

having one big package for all of this would mean trading consistency and 
simplicity for customizability. personally, i would accept that tradeoff. 

does anyone have objections to that idea?

(and if we could eventually roll in DM theming, that'd be even more amazing)

-- 
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/20130123/4aff4f05/attachment.sig>