KDE's Human Interface Guidelines
Sat, Apr 4
As a side-note, I just wanted to mention that the Contribute section in the HIG doesn't actually explain how to submit the changes you make locally. I followed the instructions from this Community page. I'm not sure if this is correct and it actually took a bit of searching to find. So it might be useful to include up-to-date instructions on the Contribute page in the HIG, even if it's just a link to that same page (assuming that's the correct workflow to use).
Mar 4 2020
Well, sort of. We did some porting, but there's still substantial inconsistency between old-fashioned QWidgets lists and more modern QML lists. So I guess it depends on whether you think that's within the scope of this task.
Mar 3 2020
My opinion: For consistency with all other dialog windows, there should always be a QDialogButtonBox, even if it has only one button.
Mar 2 2020
Is this done?
Feb 21 2020
Feb 19 2020
Windows 10 does that, showing taskbar thumbnails for windows on a per-tab basis, not a per-window basis. It feels nice for windows that have 3 or fewer tabs. For windows with like 30 tabs (i.e. web browsers), it turns into a list, which is nice. I wouldn't mind having that in Plasma.
Have we ever considered thinking outside the (application) box and telling the UI shell which views are being managed by each window, so the shell can help the user switch view (app/view/file/uri, even Activity) consistently? I realise this is bigger than consistent tab style across apps, so please point me to it if this is in the wrong place.
I just came here because this is an issue that intensely irritates me, and I'd like to help: https://blogs.kde.org/2020/02/19/it-time-war-tabs
Feb 16 2020
Feb 6 2020
Yes, you can always close a dialog with Alt+F4.
What @trmdi says is true, but is there a way to close the dialog with a keyboard shortcut? If we care about providing a way to close apps with no titlebar via the GUI, should we add additional ways to close apps like Discover?
To me this seems a bit redundant since the window itself already has a close button in its titlebar
Feb 3 2020
One idea I've seen since this original discussion was to make the switch control have a little light on it that comes on when the switch is in the "On" state. That would be a universal visual signal so we wouldn't need to worry about localizing the shortest possible versions of the strings "on" and "off".
Jan 9 2020
Please, push a commit to fix the headers. See https://binary-factory.kde.org/job/Website_hig-kde-org/157/console
Jan 7 2020
I've landed this for you in https://cgit.kde.org/websites/hig-kde-org.git/commit/?id=ad3d052e47f0d24f0548bd14cff2749345ea5968
Apparently I am not that important :(
Shipit! Do you have commit access for the HIG repo?
Jan 6 2020
Done, I'll leave it to the VDG/consistency goal to be sure things match.
Ok, will update.
Having played with it a bit, I agree with @sefaeyeoglu here. Reversing them from what's currently proposed feels nicer to me. Things enter faster, which is ultimately what you want for things that animate from invisible to visible.
Jan 4 2020
Jan 3 2020
As mentioned in D18000 I think the following two things should be adjusted. I think it is more natural that way.
Jan 2 2020
@esokrates, I think that's a good idea. It does make sense to me to be able to collapse it even further. This would make a "Hide Sidebar"-button in a toolbar even less necessary. So consider it added to my proposal.
Could you please add hiding the sidebar altogether to the proposal? If you go that expansion path, further collapsing from the vertical could lead to the sidebar being hidden altogether with only a slight visual hint that there is something that can be expanded (like the libreoffice sidepane).
Nov 22 2019
Is it not possible to query the device the box has to be rendered on whether it uses touch or pointer input? If it is possible, the SpinBox could render in two different ways, one of which is the current design and the other being a touch optimized render.
Mobile users are very much used to in input field with a Minus control button on the left and a Plus control button on the right to modify the value of the input by a pre-set step. However this design is not very logical for pointer input devices such as regular desktop PCs, or laptops.
Nov 17 2019
Personally, I would suggest to use that easing curve.
Change the page title and filename from "Animations" to "Animation"
Nov 16 2019
I agree that animations should be consistent and specified in the HIG. I will see if there's anything I can do to help you with this page.
Nov 14 2019
Oct 29 2019
Note-worthy: Maui often uses concept 1b for its applications. In this case, you have icons for all possible views and only the label of the active view is used. I think it's a quite elegant approach.
Oct 27 2019
Oct 13 2019
Oct 10 2019
Tooltips don't need to immediately pop up, of course, like most tooltips nowadays. They would not hide your stuff unless you kept hovering over an item for long enough.