From kde-panel-devel Sat Jan 21 14:32:10 2012 From: "Aaron J. Seigo" Date: Sat, 21 Jan 2012 14:32:10 +0000 To: kde-panel-devel Subject: Re: prep'ing the QML screenlocker for a merge into master Message-Id: <5108820.LTZOk0ljDO () freedom> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=132715652302387 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7270404928523480164==" --===============7270404928523480164== Content-Type: multipart/signed; boundary="nextPart28875154.eszsNFpMgh"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: 7Bit --nextPart28875154.eszsNFpMgh Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="ISO-8859-1" 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 --nextPart28875154.eszsNFpMgh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk8azGoACgkQ1rcusafx20OeLgCfSOEtYGHKr0VfqJjJFhPn4utw Y2AAnjMEHbyPs6ygl6yfnamnUnvMK8Ar =IRZh -----END PGP SIGNATURE----- --nextPart28875154.eszsNFpMgh-- --===============7270404928523480164== 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 --===============7270404928523480164==--