prep'ing the QML screenlocker for a merge into master

[Martin Gräßlin]

On Friday 20 January 2012 15:02:39 Aaron J. Seigo wrote:
> hi all ...
> 
> i've spent some time today looking at the screenlocker branch in kde-
> workspace. i was hoping it might be a straight-forward merge after adding
> one or two little features and possibly merging the screenlocker daemon
> with ksmserver.
> 
> seems it needs a bit more work than that, so i figured i'd compile a short
> list here of TODOs. if others have input, please provide it now before i
> start working on things. those who would like to help out are more than
> welcome to!
> 
> * screensaver kcm needs to be replaced with a screen locker kcm that lists
> available themes and manage the widgets on locker feature (more on that
> below)
yes, that one is still missing
> 
> * the lock screen qml is currently stored in share/apps/kscreenlocker/ ..
> this seems ripe for file collisions in the case of multiple entries and
> doesn't give us the possibility of making a nice KCM to select themes.
> better would probably be to use Plasma::Package (or if we wish to not link
> against libplasma, use Plasma::Package in the kcm and just directly open
> the files in the appropriate directories beneath kscreenlocker; however the
> QML brings in libplasma so i don't see any benefit to not just using
> Plasma::Package directly)
> 
> * there is, understandably, a lot of X-isms in the code. in particular, some
> calls to XScreenSaver and then much of the code in LockWindow. in
> preperation for a move to Wayland, this should be encapsulated in a file
> that can be built conditionally on the window system target.
For Wayland we need a different architecture. I doubt it makes much sense to 
share anything except the QML files. So I would defer this to when we actually 
have Wayland as the underlying windowing system.
> 
> * widgets on screensaver feature is broken. while the plasma-overlay screen
> does come up, you can not unlock the screen due to its tight integration
> with the previous locker.
What? That worked quite fine when I last touched the branch. Actually I 
removed all the integration bits for the old screenlocker. You are working on 
branch "screenlocker" and not on "farhad_hf/lockscreen"?
> so ... that needs some work too. in particular,
> it should probably be integrated with kscreenlocker itself and the
> plasmoids placed directly on the same QML layer as the screenlocker itself.
> whether this is available or not could be a feature of the theme?
I thought about it, too. But just starting the plasma-overlay takes quite some 
time. On my high end system it often takes so long that the system suspended 
before the screen locker becomes visible.
> 
> * there are a large number of issues in the default locker QML. a rewrite is
> probably in order. (issues include: the frame which contains the greater is
> the wrong size, the keyboard layout selection button is in an odd place,
> uses things like QGraphicsLinearLayouts, the password line edit does not
> get focus on first start, when selecting "start a new session", the text
> and widgets are completely misplaced (not kept within the greeter frame))
it uses QGraphicsLayouts because we need to embed QWidgets. Unfortunately we 
do not get to the underlying system. If we don't want anymore the QWidgets we 
would have to rewrite the complete authentication system :-(
> 
> * related to the above, blanking the screen is now left up to
> powermanagement. fair enough. however, the defaults for powermanagement for
> systems that are plugged in tends to mean it won't happen for quite some
> time on most systems. it feels rather innelegant to have the lock screen
> just always showing. in the default theme, fading out at least the greater
> UI when there is no user interaction and back in when user interaction
> happens (independent of power management) might feel nicer.
I would prefer to get this right and turn off the screen. Blanking the screen 
by painting black feels wrong to me. In fact I always thought that my screen 
turns off till I used the new locker
> 
> * the default wallpaper of the desktop theme is used when locking the
> screen. this doesn't feel right; looking at that default paper, i expect
> the wallpaper shown on my desktop that i've configured.
This would require to pull in the complete Plasma Wallpaper stuff. And this 
becomes really difficult for things like multi screen.
> yet on Plasma
> Active we do show a default hard-coded image and there this feels right. i
> had to ask myself: why? i think because the image used looks sufficiently
> different, has few colours, etc. (it's also imagery used in the start up
> sequence, but that's overly relevant). i'd like to see something similar
> for the default theme for screen locking. the theme paper is just too ...
> wallpapery :)
> 
> * the daemon (though not the locker itself, of course) should be integrated
> into ksmserver, giving us one long-running daemon for all things session
> management related
> 
> so a fair amount of work left to be done here and what i thought would be a
> one-day job turned into an afternoon of exploration and research and the
> realization that i'll be spending much of next week making this happen.
> people willing to pitch in are welcome to do so!
I will recheck why things are not working which I know that they were working 
when I last used the branch.

Cheers
Martin
-------------- 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/20120120/19b0a8e3/attachment.sig>