KDE's Human Interface Guidelines
Wed, Apr 17
BTW, we should also unify the styles for the lists itself. The list headers and items currently don't all look consistent.
Wed, Apr 3
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.
Thu, Mar 28
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 ++
Jan 21 2019
Jan 9 2019
Merge request for Refactored tab content and added recommendation about size .
Jan 3 2019
Right, but why would the tabs resize when other tabs are closed? Only Kate's tab bar does this as far as I can tell and that's the nonstandard one. The closable tabs in Konsole and Dolphin for example have a fixed size determined by the title text, and do not change their size when others are closed.
- Fixed wrong direction for PageUp / Down in tab navigation
Dec 29 2018
- Added recommendation for Ctrl + PgUp/PgDown for tab navigation
Dec 28 2018
Let's also recommend setting Ctrl + PgUp/PgDn as secondary shortcuts if these do not conflict with other shortcuts in the app.
Dec 27 2018
Also, food for thought regarding close buttons: if we put each close button on the left side of its tab, then it's easy to close multiple tabs, since clicking on it will bring the next tab's close button into the exact same position; you can just repeatedly click on the same space to close multiple tabs.
Shortcuts: I'm okay with using ctrl+tab as the default shortcut as long as we preserve ctrl+pgup/pdgn as a secondary shortcut for compatibility.
Visually the style Kate is using, with a minor change to only have the close red on hover, and the tab shaded selection color on hover of background tabs.