Breeze Windeco defaults • KDE Community Forums

This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Board index

Breeze Windeco defaults

Page 2 of 2 (24 posts)

Previous • 1, 2

Tags:

pepedopolous Registered Member Posts 40 Karma 0 OS	Re: Breeze Windeco defaults Fri Jan 16, 2015 5:25 pm Thanks Hugo and the VDG team! It's gonna be a sweet release! P
hugo.pereira@free.fr Registered Member Posts 133 Karma 0	Re: Breeze Windeco defaults Mon Jan 19, 2015 7:41 pm hugo.pereira@free.fr wrote:Hi Text vertical centering can be easily fixed. Button vertical centering is more problematic. The idea with removing the top few pixels is Fitt's law: you move your mouse against a corner, and a button must be hit, not an inactive border. So unlike unmaximized windows there must be no (software) margin between button and maximized deco border. So either: - remove the botton margin too, but that would likely make the decoration too skeezed - add a 'fake' virtual margin inside the button, to extend the hit area without breaking vertical centering. I'll work on the second, but it requires a bit of testing Not sure what to be done with horizontal positionning (putting a fake margin here will be even more complex because this would affect all buttons, and then, you'd need to squeeze the 'spacing' between buttons accordingly) Hugo Just a heads up: it has all been fixed in 'master' now Titlebar size and button position should not move anymore when you maximize a window, be it with or without the "draw border on maximized window" option being checked. As a side note, the rationale behind this option being set to false is "Fitts law". Basically: remove all borders. If you want to hit a button just throw your mouse in a corner. Idem for some applications' scrollbar. Best, Hugo
colomar Registered Member Posts 947 Karma 2 OS	Re: Breeze Windeco defaults Tue Jan 20, 2015 2:34 pm Thanks, Hugo! And yes, the rationale behind disabling borders on maximized windows by default makes perfect sense. Actually, I don't see a reason for anyone actually wanting borders around maximized windows. What purpose would they serve anyway?
veqz Registered Member Posts 111 Karma 0	Re: Breeze Windeco defaults Wed Jan 28, 2015 6:49 pm Testing 5.2 now, and the red colour for the on-hovered close button seems off to me: That red colour is #FF98A2 as far as I can tell, and not any of the colours from the guidelines: https://techbase.kde.org/Projects/Usability/HIG/Color. Is this an overlay issue with the colour (mixing red with white) and thus a bug, or is it a design choice? Or is this only occurring for me?
hugo.pereira@free.fr Registered Member Posts 133 Karma 0	Re: Breeze Windeco defaults Fri Jan 30, 2015 4:26 pm veqz wrote:Testing 5.2 now, and the red colour for the on-hovered close button seems off to me: That red colour is #FF98A2 as far as I can tell, and not any of the colours from the guidelines: https://techbase.kde.org/Projects/Usability/HIG/Color. Is this an overlay issue with the colour (mixing red with white) and thus a bug, or is it a design choice? Or is this only occurring for me? Color is from standard palette "NegativeForeground" (use of a palette color is the only choice here since we want to accomodate possible palette changes on the user) But then, since I found it too "aggressive", I 'lightened' it (QColor::lighter()) Admittingly, It would be more robust if I'd use the true one (not lightened). It would look like this: http://wstaw.org/m/2015/01/30/plasma-desktopIx3128.png http://wstaw.org/m/2015/01/30/plasma-desktopBz3128.png What do you think ? (and from the above, if it is still not in the guidelines, then the color palette must be changed, not the kdecoration code)
alake Registered Member Posts 591 Karma 3 OS	Re: Breeze Windeco defaults Sat Jan 31, 2015 9:52 pm The challenge is that we need a visual distinction between hover and click so that there is sufficient visual feedback on click. So I'm totally cool with using the true palette color (I think it looks better as well), as long as we ensure there is sufficient feedback on click (mouse down).
veqz Registered Member Posts 111 Karma 0	Re: Breeze Windeco defaults Sun Feb 01, 2015 2:33 pm How about just simply switching it up? So hover gets the colour of mouse down, and mouse down gets the colour of hover?
colomar Registered Member Posts 947 Karma 2 OS	Re: Breeze Windeco defaults Mon Feb 02, 2015 9:36 pm veqz wrote:How about just simply switching it up? So hover gets the color of mouse down, and mouse down gets the color of hover? Using color roles for other things isn't a good idea, because we don't know what colors other schemes may assign to these roles, so it may look really bad in other schemes.
kilianl Registered Member Posts 6 Karma 0	Re: Breeze Windeco defaults Fri Dec 18, 2015 9:39 pm Whats the state of breeze light in plasma 5.5? I think its still not shipped by default, do you still plan on doing so?

Page 2 of 2 (24 posts)

Previous • 1, 2

Bookmarks

Who is online

Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan