With https://invent.kde.org/frameworks/kirigami/-/merge_requests/1235, we have a path forward here, at least for QML apps.

This was done in https://invent.kde.org/plasma/breeze/-/merge_requests/108!

To bring new ideas into this, what about the way it is currently done in plasmoids?
A long press on the title bar (in addition to starting dragging) could move the window into a sort of 'edit mode', with big handles on every edge and corner. In my mind that would probably be the most practical and discoverable solution.

It looks quite nicely organized and should be possible using the new WIP port of the hig to develop.kde.org.

No consensus, closing.

In T11579#229002, @ngraham wrote:

In T11579#228998, @Imerion wrote:

After all, horizontal space really isn't an issue with modern computers all using 16:9-screens. A portrait view might be another matter, there I'd prefer the ComboBox.

I wish to politely object. :) Horizontal space is not an issue when a window is maximized on such a display, but it is very much an issue when two windows are tiled size-by-side, which is an arrangement that is otherwise quite natural and comfortable on widescreen displays.

In T11579#228998, @Imerion wrote:

After all, horizontal space really isn't an issue with modern computers all using 16:9-screens. A portrait view might be another matter, there I'd prefer the ComboBox.

Many good ideas here. I just want to add that I still think having labels in one way or another would be really useful, for several reasons. (I listed a few more in issue D29242). After all, horizontal space really isn't an issue with modern computers all using 16:9-screens. A portrait view might be another matter, there I'd prefer the ComboBox.

as long as you can still single click on the arrows to increment/decrement or scroll with the mouse wheel to increment/decrement, adding the ability to click/tap and drag to change the value seems like a good idea.

That's the kind of solution I was hoping for. With this idea I can see all KDE applications be it Dolphin, Marble, KDevelop or Okular use the same component although I know that that might seem like too much to ask for. There might still be some decision making necessary for specific applications to figure out which interface appearance would be best but as long as we would be using one component in the background all the groundwork would be done to facilitate easy switching between complete solutions if the situation calls for it.
I hope this idea will also work nicely on a technical level.

the problem is as usual: easy to do with qml stuff, hacky and pain for qwidgets..
that said, the most user friendly spinbox i ever found was in a super ancient version of Corel Draw (something that still ran on windows 3.1 iirc :p)
the look was stil pretty much the same of the current spinbox, but with something that reminded an handle fused with the arrow buttons.
if one keeped the mouse pressed and dragged up and down, could make the values go up and down in a very fast, efficient and suprisingly super precise way.

Sounds awesome to me! Each discrete dock area/sidebar should also be showable and hideable, as with Dolphin panels. UI-wise, we could standardize on a default UI of icons-only tabs or toolbuttons for tabbed views with the current view's title underneath the tab bar inside the view itself as I did in https://invent.kde.org/kde/okular/-/merge_requests/156, something easily replicable in a Kirigami component for consistency, even if it wouldn't have the ability to re-arrange things--or maybe it could?)

Yeah, show me how to use QDockWidget in a KPart! I tried it, but found no way.

Yes, exploring icons only tabs is the best option IMO.

It could probably be made into one, yeah. I know that @felixernst and @mmustac were interested in exploring a dual-sidebar design, so perhaps the re-usable component could allow tabs to be dragged between instances, and then the app could gain the ability to have multiple sidebars. Then again that feels like it would be re-inventing the QDockWidget! It already has the ability to become tabbed when multiple docks are added to it. Maybe we should see if we can use icons-only tabs and explore that? I can see it being possible to re-implement my Okular patch using QDockWidgets.

Looks good! I wonder if it could be some sort of re-usable component for other applications as well.

In T11579#205966, @niccolove wrote:

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.

In T10233#221413, @dariuszdeoniziak wrote:

In T10233#221412, @wstephenson wrote:

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

It came from terminal apps, noticed it in Konsole and Gnome Terminal. Although Ctrl + Tab works in Konsole too, not sure about other terminals.

You're welcome!

Seems to be because I still had the "Differential Revision" field in the commit message:

Oh interesting, Phab closed it automatically when I landed the GitLab version.

In D28554#646620, @ngraham wrote:

Thank you! You can formally Abandon this now.

Thank you! You can formally Abandon this now.

Created the merge request at https://invent.kde.org/websites/hig-kde-org/-/merge_requests/73

Sorry for responding so late as well. I'll re-submit according to the instructions you provided.

(Updated the documentation with https://invent.kde.org/websites/hig-kde-org/-/commit/9f5f615630745e2bcc07cba31c45fbfe36f93a81)

Sorry for the delayed review, and thanks very much for the patch! Also sorry for the poor documentation. I'll fix that. It needs to mention that patches for the HIG are submitted on GitLab, at https://invent.kde.org/websites/hig-kde-org/-/merge_requests. Would you mind re-submitting this patch over there? Thanks again!

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).

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.

My opinion: For consistency with all other dialog windows, there should always be a QDialogButtonBox, even if it has only one button.

Is this done?

In T10233#221412, @wstephenson wrote:

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

In T10233#221412, @wstephenson wrote:

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

In T10233#221316, @ngraham wrote:

For windows with like 30 tabs (i.e. web browsers), it turns into a list, which is nice

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

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

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".

Please, push a commit to fix the headers. See https://binary-factory.kde.org/job/Website_hig-kde-org/157/console

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?

LGTM. VDG and Goal: Consistency folks, is this good now?

Done, I'll leave it to the VDG/consistency goal to be sure things match.

update

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.

As mentioned in D18000 I think the following two things should be adjusted. I think it is more natural that way.

@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).

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.

Personally, I would suggest to use that easing curve.

In D25343#563703, @ngraham wrote:

Change the page title and filename from "Animations" to "Animation"

In terms of Quad vs Cubic, I think it would make the most sense to use this page to describe the current state of reality (so, Quad). Then, we should define the default easing curves for visible->invisible, invisible->visible, and visible->visible in some central location, and port everything to pull the data from there rather than hardcoding it. Finally, we should discuss what those standardized easing curves should be. I also slightly prefer Cubic to Quad, having used it now, but we should consistently use the same one everywhere.

Does that sound like a sane and doable plan?

Change the page title and filename from "Animations" to "Animation"

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.

https://invent.kde.org/websites/hig-kde-org/merge_requests/49

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.

In T11579#204100, @onvitaik wrote:

Would it be possible to drop the vertical text (both bottom-to-top and top-to-bottom) on the sidebar, and instead just use buttons with tooltips? From a UX standpoint, vertical text can be a big negative to users, as you're possibly making them tilt their heads to read the text better. It can also make the UI feel a bit inconsistent by being the only place(s) where text is not horizontal.

In T10233#171758, @fabianr wrote:

Firefox and Chrome both resize tabs when opening or closing tabs

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.

I think tooltips are very disturbing for such toolview buttons.
You very often hover over them during switching and then you always get your stuff hidden by the tooltip.

Would it be possible to drop the vertical text (both bottom-to-top and top-to-bottom) on the sidebar, and instead just use buttons with tooltips? From a UX standpoint, vertical text can be a big negative to users, as you're possibly making them tilt their heads to read the text better. It can also make the UI feel a bit inconsistent by being the only place(s) where text is not horizontal.

In T8749#202902, @alex-l wrote:

@ngraham wouldn't right click a quick alternative way to open the more options menu?

about the draggable handle: can people actually guess what the button does? Maybe we should us an arrow next to the 3 vertical dots instead of another dot?

@ngraham wouldn't right click a quick alternative way to open the more options menu?

Looks like we eventually standardized on the following:

• Drag handle or checkbox is always on the left (and we never have both at once; in practice, we haven't ever even used checkable items)
• On the desktop, actions are always hidden by default but appear on hover; there is no right-click behavior (it's not needed)
• On mobile, the handle on the right is touched or dragged to reveal the actions

In T11579#201778, @Leon0402 wrote:

@ngraham I hope I understand you correctly. Your problem is that the actual sidebar or the side view, which comes if you click on the sidebar, takes width as well ... and therefore you don't want to waste more width, right?

What do you think of modifying the condition:

horizontal: (windows.width - sidebar.width - sideview.width) >= windows.height
vertical: (windows.width - sidebar.width - sideview.width) < windows.height

This calculation would take into account the width problem and would show the vertical mode faster if there is not enough width.

Here is a first test run, although I just used 300px for "sidebar.width + sideview.width".

Obviously we should start settings min width and heights for the window ... sure you could also start and switch in some size to "icon only" ... but at some point, there should be a stop ... the application doesn't have to run in a 2px x 2px window.

Let's not forget digiKam :)

I was mostly thinking about manual resizing by the user. In a picture:

@ngraham I hope I understand you correctly. Your problem is that the actual sidebar or the side view, which comes if you click on the sidebar, takes width as well ... and therefore you don't want to waste more width, right?