> On Oct. 8, 2012, 5:31 p.m., Martin Gräßlin wrote: > > just an idea: what about hiding the whole X screen saver stuff behind > > another configure dialog. Looking at the screenshot I find the design puts > > emphasis on the wrong part: what we want to remove takes more than 50 % of > > the available screen estate. > > Marco Martin wrote: > another idea would be just show the screen saver part only when the > screensaver radio is selected (i kept it a bit that way before merging btw, > seemed a bit flashy..) > > Aleix Pol Gonzalez wrote: > I agree. On the other hand, showing new dialogs it's considered bad > practice. :/ > Maybe we can show the xscreensaver part when it's enabled? > > **Aleix turns the agateau-sign on** (see bat-signal for further reference) > > Aurélien Gâteau wrote: > Played a bit with the .ui file and came up with this: > http://simplest-image-hosting.net/png-0-plasma-windowedk16149 . Not sure it > is possible, depends on how "previewable" the "simple locker" and "desktop > widgets" lockers are. I can provide the .ui file if you want but I butchered > it, I doubt it would compile. > > Aleix Pol Gonzalez wrote: > It kind of makes sense to share the preview, but it seems it's not that > easy to preview the plasma-overlay. > Anybody knows how hard would be to invoke it in hte preview thingie? > > Thomas Pfeiffer wrote: > I really like Aurélien's attempt! Here is some detailed feedback: > - Putting the screensaver selection in a combo box makes sense to make it > less prominent. Question here: Is it possible to update the preview while the > user navigates through the combo box item list with the keyboard (without > closing it)? Usually when people select a screensaver, they want to browse > through the available savers before settling on one and that would become > tedious if they had to open the box again for each saver. > - I'd rename "Setup..." to "Configure..." as this is the word we normally > use for this. Setup sounds more like "First-time configuration routine" to > me, like something really complex. > - The spin boxes for the timings seem to narrow to hold unit indicators > to me, but I suppose this would change in the final implementation > > Aaron J. Seigo wrote: > We can do a lot better than this. > > Note the complete lack of visual alignment, the mix of widget placement > strategies (left, right; vertical, horizontal) .. meh. > > So .. let's step back and reconsider our assumptions. > > Is this something a person configures *often*? No. So does it need to be > hyper optimized for speed usage? No. > > How much granularity do we need to offer in the UI for things like how > long to wait until a password is required? Not much. > > This should lead us to conclusions such as: > > A spinner is not needed for "Require password after:". A drop down with a > few sensible entries should be enough: Never, Immediately, After 1 minute, > After 2 Minutes, After 5 minutes ... is anything more really necessary? This > also lets us get rid of the checkbox and shorten the text to "Require a > password:" > > Note that "require a password" is an anachronism in our newfound QML > world -> the Plasma Active locker does not require a password at all. In that > light, perhaps this should not even be exposed in the UI at all. If the user > intentionally locks the desktop -> it locks hard instantly. If it is an > automatic trigger, only require a password after 30s or some sensible > timeout. Voila, one more option evaporates and we no longer have a conflict > with the QML themes. > > the spinner after "Start automatically" should have units in it (minutes) > and 0 should be "Never"; drop the checkbox. > > "Locker type" => what does that even mean? It's jargon. "Lock style:" > might be more descriptive and understandable? > > "Simple locker" is meaningless. What is "Simple"? Compared to what? > Perhaps "Password entry" or some other phrase that speaks to the > user-perceptible function. > > The radio buttons also fail in a significant way: we can now have lockers > in QML .. which means we can (and will) have multiple options here. > > So a drop down next to the label "Lock style:" listing the various > installed options. > > I'm not sure why "Desktop widgets" is orthogonal here either. They are > also somewhat broken in the current QML locker; personally, I think how they > are managed needs some rethink. Is fully customized placement of widgets the > easiest / most sensible thing? Or would some auto-alignment with simplified > access to configuration of the widgets in question be more sensible? > > Finally, get rid of both the group boxes in the design; they are visual > noise and increase the number of alignments in the dialog. > > Would be fantastic if we could get rid of "Test" and "Setup" somehow as > well... > > > Bjoern Balazs wrote: > I think we running in the typical problem of different assumptions and > underdefined requirements. I do like the approach of Aurélien and I can the > criticism of Aaron. I could add some more: Why not use a wizard, if the task > is done is infrequent? How do the screensaver settings fit into activities? > But for all of these valid solutions (or questions) we have a totally > different user (and probably scopes of this patch) in mind. I really do not > how we can solve these kind of discussions, without first agreeing on our > target users, their tasks etc. > > My personal feeling is to go with the Thomas commented ideas from > Aurélien, as they seem to be close to what we have and they are somewhat > aligned with the rest of the desktop KCM in terms of detail. After agreeing > (however we can do that) on personas, sezenarios, goal etc. we should revise > this and other KCM moduls. My feeling is that the ideas of Aaron will be > picked up then... > > just my 2 cent :) > > Aurélien Gâteau wrote: > Here is another mockup, taking into account feedback from Thomas, Aaron > and Marco. http://agateau.com/tmp/locker-kcm/locker-kcm2.png
I thing using a huge listview for three entries (locker, plasma thingie, screensaver) is a bit of a waste? On the other hand, also adding all the screensavers there might add too much clutter (although I just have Blank Screensaver and Random as I do not have any installed) let alone there is no easy grouping/indenting then. - Kai Uwe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106768/#review20087 ----------------------------------------------------------- On Oct. 8, 2012, 3:43 p.m., Aleix Pol Gonzalez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106768/ > ----------------------------------------------------------- > > (Updated Oct. 8, 2012, 3:43 p.m.) > > > Review request for Plasma and KDE Usability. > > > Description > ------- > > After complaining about this KCM last week, I wanted to give it a try to > improve it a little. I think that the biggest stopper here is wanting to keep > the screensaver here, because we've ended up with a 3-head monster: > * simple locker > * plasma-based locker > * xscreensavers > > Since it seems it's something we may want for the moment. IMHO, we should end > up with the Plasma-based option alone. I just tried to re-organize it in a > way I like a little better. > > What I did > - I aligned the locking labels to the left, like the Form Layout suggests. It > creates a small puzzle, I'm unsure if that's a problem. > - I added toolTips and whatsThis in the locking type option buttons, so that > we can at least figure out what will happen when we lock. > > > Diffs > ----- > > kcontrol/screensaver/screensaver.ui 6524e27 > kcontrol/screensaver/scrnsave.cpp 0125620 > > Diff: http://git.reviewboard.kde.org/r/106768/diff/ > > > Testing > ------- > > just messed with it for a while. > > > Screenshots > ----------- > > result > http://git.reviewboard.kde.org/r/106768/s/758/ > > > Thanks, > > Aleix Pol Gonzalez > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
