D10170: Added optional transparency/blur to menu frames

[Andres Betts]

abetts added subscribers: andreask, colomar, abetts.
abetts added a comment.


  In https://phabricator.kde.org/D10170#198471, @hpereiradacosta wrote:
  
  > Hello, 
  >  Hi, 
  >  thanks for the patch !
  >
  > Few comments:
  >  1/ the code does not compile under kde4 (cmake -DUSE_KDE4). You would need to use the proper #ifdef to prevent this
  >
  > 2/ I think the "blur" option should go. Blur should be controlled centrally by the desktop effect. In other words: BlurBehind should always be set to true, and then left to kwin to handle. Having an extra option here seems like micro-management. Why would you need blur behind plasma widgets (as handled by the desktop effect) and not behind menus ? (or vice versa). Also, right now, selecting "blur" in the style settings, but unselecting the desktop effect results in no blur behind menu, and hence inconsistency with what the style option says.
  >
  > 3/ the slider should follow the same convention and design as for the translucency effect: "transparent <----slider---> opaque".  0% should be transparent, 100% should be opaque. 
  >  Also, should have the same granularity, so ... percents. (not 10%)
  >
  > 4/ I would really like the VDG opinion on this. IMHO I am not sure if it fits the breeze "guidelines" or design-ideas, in the sense that I do not know why this is needed (what is the use case), aside from "this is pretty".
  >
  > In other words: why would one need to be able to see what is behind the menu you are currently navigating ? 
  >  Navigating a menu is a very focused thing one wants to do: one is looking for a specific action to perform on the current content of the window. To me at least, seeing-through the menu is more a distraction to this task than anything else. (and adding blur to reduce this distraction would in fact go in the direction of not being translucent at all).
  >
  > If the only reason is "this is pretty", then this has to be balanced with the extra option, code complexity, and configurations to be tested on the maintainer side, that this patch adds.
  
  
  Maybe I can add some extra reasons. I am not sure if having the extra menu to control Blur is "necessary." However, I see value in having it in our KCMs or as part of an effect. One thing that this patch accomplishes is to have a blurred effect consistent in more areas of the desktop. While now we are able to make windows transparent and blur them, an option to have menus follow that convention is not present. Imagine that maybe a window style or theme allows transparency but that the menus don't look well with the preset and you would like to change it independently, There is no option for that. My thought is that if is about theme/style consistency, this makes sense to have. I feel, however, that it fits better in a KCM or as part of the transparency effect options. Thoughts anyone else in the VDG? @colomar , @ngraham , @andreask

REPOSITORY
  R31 Breeze

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

To: anemeth, hpereiradacosta, #plasma, #vdg
Cc: abetts, colomar, andreask, zzag, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20180131/22fb1270/attachment.html>