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