Re: Re: prep'ing the QML screenlocker for a merge into master
On Saturday 21 January 2012 15:32:10 Aaron J. Seigo wrote: > > 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 :-( > > yes, i know. however, there are some things used in the QML that are > probably not needed / should be replaced with the components work. right, I didn't like to have the keyboard switcher embedded as a QWidget for example. > > > > * 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 > > ah, yes, i would like to do it with turning off the screen (rather than just > painting black) good > > > > * 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. > > nah, it's pretty easy for multiscreen. still, i do prefer the idea of a > lock- screen specific thing (perhaps something that is coordinated with the > QML log in screen too?) I would like to have it coordinated with the log in screen. I think this would give a very pleasant experience especially if we go for not stopping at KDM but logging in the user directly (as done on PA). Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: prep'ing the QML screenlocker for a merge into master
On Friday, January 20, 2012 15:31:52 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= wrote: > On Friday 20 January 2012 15:02:39 Aaron J. Seigo wrote: > > * 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. ok :) > > * 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"? i was on branch screenlocker, but hadn't rebuilt plasma-overlay. even then, there were some minor issues that i found i was able to trigger, though i really need to test with a clean build of everything to be sure. > > * 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 :-( yes, i know. however, there are some things used in the QML that are probably not needed / should be replaced with the components work. > > * 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 ah, yes, i would like to do it with turning off the screen (rather than just painting black) > > * 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. nah, it's pretty easy for multiscreen. still, i do prefer the idea of a lock- screen specific thing (perhaps something that is coordinated with the QML log in screen too?) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: prep'ing the QML screenlocker for a merge into master
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 lef
