> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
