Review Request 122660: Breeze Decoration Redesign
Hugo Pereira Da Costa
hugo.pereira at free.fr
Thu Apr 23 14:19:59 UTC 2015
> On Feb. 21, 2015, 1:44 p.m., Hugo Pereira Da Costa wrote:
> > "Preinstalled colours schemes to ensure consistent colouring"
> > that is a regression with respect to exiting code. Its a no go. Please include.
> >
> > "Updated the behaviour of the resize grip - fixed bug for fullscreen"
> > Can you post a bug report related to the bug ? There was indeed an issue with size grip and fullscreen window, but this was fixed, as far as I know. See https://bugs.kde.org/show_bug.cgi?id=343988 and commit therein
> >
> > "Redesigned buttons and tweaked the titlebar slightly."
> > Can you post screenshots ? Were these changes discussed in the Visual Design Group forum ? (https://forum.kde.org/viewforum.php?f=285)
> >
> > "Font weight will now affect the boldness of icons in buttons"
> > Same question.
> > No other element in the widget style has this behavior (icons, frame sizes, etc.), so I'd like to know the rationale behind it and get this discussed.
> >
> > I have not tested the changes yet, but will do asap
>
> Ken Vermette wrote:
> "that is a regression with respect to exiting code. Its a no go. Please include."
> Sorry, I should have said "tested with preinstalled colour schemes"; I was just checking to ensure colours were sane for themes; make sure the buttons didn't turn neon-pink when using obsidian or anything like that.
>
> "There was indeed an issue with size grip and fullscreen window ..."
> I re-wrote the grip behaviour with the input of Jens (another VDG member); I wasn't specifically aiming to do it with the change to the grip display code, but I was aware that it would be fixed in my build. The new behaviour should hide the grip on maximised windows and inactive windows; on maximised windows the grip is pointless, and on inactive windows the grip is not obvious, but still covers scrollbars or status items...
>
> "Can you post screenshots ?"
> Of course; they're included now.
>
> "Were these changes discussed in the Visual Design Group forum ?"
> Not on the forum, no. I did refer to Jens during the sprint, and other members of the VDG have responded positivly to my screenshot on G+. This is also an initial version, and assuming it flies I'll be updating based on feedback accordingly. The design is also evolutionary anyway.
>
> "No other element in the widget style has this behavior (icons, frame sizes, etc.), so I'd like to know the rationale behind it and get this discussed."
> I was going to add a config option but if I had of done this, but I chose to use the font width to avoid overburdening the settings dialog with tweaker stuff - it's less than a 0.7px difference.
>
> I'd be perfectly fine removing the feature; when first starting I did not know there was a float variant of setWidth - so I could not get the line to a happy medium; now that I have it at a 'good' width it was kept simply because it could 'follow along' with the font easily. The edit is <1 line.
>
> Hugo Pereira Da Costa wrote:
> "Preinstalled colours schemes to ensure consistent colouring"
> Sorry. That was a wrong copy paste (damn review board).
>
> I meant: "Note; Buttons are not animated yet in this variant"
> that is a regression with respect to exiting code. Its a no go. Please include.
> I am ok with incremental commits but not when they remove existing and working functionalities. Re-added animations can be the topic of another review request, but this one will not get a ship it untill the other one exists, sorry.
>
> ""There was indeed an issue with size grip and fullscreen window ..."
> I re-wrote the grip behaviour with the input of Jens (another VDG member); I wasn't specifically aiming to do it with the change to the grip display code, but I was aware that it would be fixed in my build. The new behaviour should hide the grip on maximised windows and inactive windows; on maximised windows the grip is pointless, and on inactive windows the grip is not obvious, but still covers scrollbars or status items..."
> So, this is not a bug fix (since the bug is already fixed), this is a behavorial change. Please take it out of this commit and submit it in a separate review request for further discussion. It is independent of the design change. Note that some people (me for instance) could see the hiding of the resize handle on inactive window as a regression, (because of not being able to resize inactive windows any more).
>
>
> ""Were these changes discussed in the Visual Design Group forum ?" Not on the forum, no. I did refer to Jens during the sprint, and other members of the VDG have responded positivly to my screenshot on G+. This is also an initial version, and assuming it flies I'll be updating based on feedback accordingly. The design is also evolutionary anyway."
>
> I would really appreciate a dedicated thread on the design changes on the forum, if only to get feedback of other forum members, including me.
> I can post some of my personnal comments here (and copy there when the thread exist)
>
> -- I find the colors too distracting. (but that is only personnal, possibly biased, so feel free to ignore unless many more people feel the same, especially other 'design' experts
>
> - I fail to see the rationale behind the button coloring. I understand there is some sort of 'traffic light' metaphor, but then, why would minimize be more "orange" than say "unpin", or "keep below", or "un-maximize". Likewise, why would maximize be more "green" than say "pin", or "keep above".
>
> - with the current code close button appears as "grey" on active window and red on others. While the other buttons are colored on active and grey on inactive. I fail to see why. To me at least, "close" is as dangerous on active windows than on inactive, while making it grey would make it "less" important than other coloured buttons.
>
> - with the current code the "pressed button" click state feedback coloring feel somewhat random: grey on active window, "highlight" on inactive.
>
> - I fail to see the added value of the circles around the buttons, especially when there is already a nice mouse-over effect. It would be like adding a frame around every single toolbutton in a toolbar, around the icon. As a side effect, for a given button size, it also makes the actual glyphs 2 pixels smaller than what they are now, due to the need to the extra spacing with respect to the circle. Which, IMHO goes in the wrong direction.
>
> - on the redesign of the "pin" button, I fail to see what issue the new design address with respect to the old one.
>
> - finally, the same buttons are also used in the widget style, for dock manipulations (see: dolphin -> unlock panels, as well as kdevelop), and MDI windows (see oxygen-demo5, mdi window tab). So any change to the decoration should also come with a matching change to the widget style.
>
> That's all I have for now.
> Again:
> - I'd rather have these things discussed on the forum rather than here
> - I have nothing against incremental commits, but not when the first one break things that working and against which there have been no bugs reported nor formal complains.
> - I would encourage you to commit these changes to a dedicated branch or scratch repository, ask for feedback, fix the issues that show up (especially the one that are not present in the current code), and when ready (e.g. no regression, inconsistencies, and overall consensus here and with VDG members), merge via review-request.
>
> Best,
>
> Hugo
>
> Aleix Pol Gonzalez wrote:
> Should this be discussed then? I didn't see a discussion.
>
> I think it's a shame that these initiatives are just discarded instead of iterated. We shouldn't consider everything as Done.
https://forum.kde.org/viewtopic.php?f=285&t=125388
Ken discarded this review in order to first focus on getting it more polished, possibly as an alternative windeco, before rediscussing later whether it should become default.
- Hugo
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122660/#review76378
-----------------------------------------------------------
On March 16, 2015, 2:44 a.m., Ken Vermette wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122660/
> -----------------------------------------------------------
>
> (Updated March 16, 2015, 2:44 a.m.)
>
>
> Review request for Plasma and Hugo Pereira Da Costa.
>
>
> Repository: breeze
>
>
> Description
> -------
>
> Overhaul of the Breeze Window decoration drawing code;
> - Redesigned buttons and tweaked the titlebar slightly.
> - Updated the behaviour of the resize grip - fixed bug for fullscreen
> - Font weight will now affect the boldness of icons in buttons
>
> Note; Buttons are not animated yet in this variant.
>
>
> Diffs
> -----
>
> kdecoration/breezebutton.cpp 5ac0cfe
> kdecoration/breezedecoration.h 9eb6c65
> kdecoration/breezedecoration.cpp b474a8b
> kdecoration/breezebutton.h c43959a
>
> Diff: https://git.reviewboard.kde.org/r/122660/diff/
>
>
> Testing
> -------
>
> - Tried out preinstalled colours schemes to ensure consistent colouring
> - Viewed various button sizes
>
>
> File Attachments
> ----------------
>
> Updated Decos
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/21/66f8d3d8-5852-4b79-b211-339cbc7bf712__newdecos.png
> Full Windows
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/21/20580b13-3bb1-4020-9ddf-8d1253184a45__snapshot1.png
>
>
> Thanks,
>
> Ken Vermette
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150423/5e94da77/attachment-0001.html>
More information about the Plasma-devel
mailing list