D22102: Implement apply-on-double-click for all grid view KCM delegates

Pino Toscano noreply at phabricator.kde.org
Sun Jun 30 16:29:31 BST 2019


pino added a comment.


  In D22102#487806 <https://phabricator.kde.org/D22102#487806>, @ngraham wrote:
  
  > Right now, I find it *extremely* annoying, slow, and frustrating to test new themes, colors, icons, wallpapers, etc. The workflow is to click on the delegate, and then click on the Apply button in the corner of the window, or use its hidden Alt accelerator. If I want to see 5 items, I do this five times. If I want to look through 20 items, I do this 20 times. Every time I do this, I get frustrated and feel like it should be doable in a faster way.
  
  
  While I can understand that clicking can be "annoying", OTOH I consider all the KCMs you mentioned as "mostly once" configuration items: you generally configure the color/wallpaper/icons/etc when you start using Plasma, and then you almost never go back to change these configurations again. Maybe my perspective is limited, however I do not see e.g. an icon KCM used more than once per month (even stretching things a bit), so using them often is not a "common case".
  Sure, I agree that 20 clicks for trying a wallpaper might be "slow", although most probably you have configured it within 10 minutes...
  
  > This proposal is one way to resolve the issue. I don't personally see a problem with the hidden double-click accelerator (obviously, or else I wouldn't have submitted the patch :) ),
  
  As I wrote already, this is problematic on its own:
  
  - the general paradigm is OK/Apply/Cancel, so having "pieces" of the instant-apply one mixed in (with not even the possibility to disable it) IMHO adds more confusion than anything else; I can imagine an user thinking "here I can double click to apply instantly" "hmm but here not"
  - corollary of the above: IMHO choosing *one* paradigm and following it is the coherent way of doing things; switching to instant-apply (which I don't agree with) would require a massive amount of work
  - mis-clicking, even mis-double-clicking happens, and if the user does that, they cannot go back to the previous setting, as the action was the equivalent of pressing the Apply button
  
  Also, the original proposal mentioned that this would not need explicit documentation. This is very bad, as the user faces some hidden behaviour on their configuration modules, and they have no way to know that this is actually wanted unless they "google it". I do not think our users need to be left in the dark about features.
  
  > but if people don't like this approach, I hope we can have a conversation about alternative approaches to resolve the underlying issue of the test-multiple-items-in-a-grid-view-KCM workflow being quite slow.
  
  Surely I do not want to undermine your own PoV, however how is this a issue even? Do we have user reports that point out that this complicates the workflow so much?
  From what I can see, the original D18571: Add "apply on double-click" feature to most other recent ported KCMs <https://phabricator.kde.org/D18571> was done by Nate Graham, based on the RFE #398303 requested by Nate Graham, with only a later #403384 requested by a single user.
  
  > I can think of a few:
  > 
  > - Move to the instant apply paradigm
  
  -1
  
  > - Add Preview buttons to all delegates that "virtually" apply the item to everything visible on screen
  
  What would this Preview button do?
  
  > - Do the above, but on hover or selection, with a visible message that says "this is just a preview", click Apply to apply these settings"
  > - Probably way more
  
  Or probably leave things as they are.

REPOSITORY
  R296 KDeclarative

REVISION DETAIL
  https://phabricator.kde.org/D22102

To: ngraham, #plasma, #vdg, mart, broulik
Cc: pino, davidedmundson, filipf, mglb, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190630/1701d3a2/attachment.html>


More information about the Kde-frameworks-devel mailing list