KDE's Human Interface Guidelines
Sun, Jun 16
They are, but I think breeze icons (especially directories) are not too bright and don't hurt eyes at night, like bright Deepin ones. If the purpose is to have everything darker, it could be better to just lower monitor brightness.
Or... did I misunderstand and you would like to just make backlight and directory icon color the same?
^ Indeed. Here is how a tweaked Breeze Dark looks like with deepin-dark icons:
I don't think it's a particularly good thing to have the folder colors the same color as the highlight color. Also, if we are going to make the folder color match the highlight color, it would make sense to make the folder color change with the colorscheme. People have requested that and I tried that already, but it just doesn't work well. Folders end up looking way too dark on colorschemes with dark highlights and dark background colors.
Sat, Jun 15
Wed, Jun 12
My general take on colors is that we need some more contrast. Rough suggestions for revamping the colors would then be:
Mon, Jun 10
Fri, May 31
Tue, May 21
Mon, May 20
May 8 2019
Apr 30 2019
Ooh, I like the arrow version. That does seem like it could be a sensible compromise.
I have made two mockups of SpinBoxes: the first one - with plus & minus signs and the second one with arrows instead of signs. Maybe it will be a compromise with mouse scroll mnemonics mentioned above. And the bonus point: you actually can control value inside a SpinBox with the up and down arrows on a keyboard, so, in my opinion, arrows on the buttons will be a better match with that behavior.
Apr 25 2019
Apr 24 2019
Apr 23 2019
Apr 19 2019
Apr 17 2019
BTW, we should also unify the styles for the lists itself. The list headers and items currently don't all look consistent.
Apr 3 2019
I agree that on touch input, the current spinboxes are unusable.
I am also that person who actually clicks up and down arrows with a mouse; I find it more precise than scrolling.
When using a touchpad, I prefer having big clickable - and + buttons (regardless of their location).
I disagree that touchpad users "don't really need" working with this control: it's not only in settings, I regularly change screenshot timeouts in Spectacle, etc.
Mar 28 2019
Some text editors do show in tabs icons for different filetypes (like IntelliJ or older versions of Atom), but I can't think of anything else.
Mar 7 2019
This is a pretty good proposal. But I think there are some gestures we can't differentiate like the flick from the drag and also the edge swipe for 3 or 4 fingers seems to complex to determine and to be using it's good to have so many gestures so that the user can select them according to their will.
Feb 26 2019
Feb 19 2019
Feb 16 2019
I propose that we consider Breeze Light as a replacement for the default color scheme.
Feb 13 2019
Feb 12 2019
Feb 7 2019
One idea for new tab behavior from https://bugs.kde.org/show_bug.cgi?id=403690
- When a new blank/empty/default tab is opened, put it on the far right
- When a new tab is opened from some context (e.g. "Open this folder in a new tab") open it immediately to the right of the current tab
Feb 6 2019
Feb 5 2019
Jan 22 2019
Yeah I agree that contextual, item-specific actions should continue to be inline the way they currently are for Kirigami ListViews. This probably includes the remove button, where applicable. If the remove button is inline, there's probably enough space to show Add and GHNS buttons and distinguish them with text, perhaps by replacing the word "Get" with "Download" to ensure that people know what the button actually does.
(Kirigami) Tabs seam to have kind of a strange height of 28.
Just for info, there are some pretty old HIG drafts about lists, that contain some stuff about add & remove buttons. Most of it is probably from KDE 4 times.
This is definitely an area that needs fixing ++