Plasma Sets
OpenPublic

Tags
None
Tokens
"Love" token, awarded by oussemabouaneni."Love" token, awarded by niccolove."100" token, awarded by januz.
Authored By
alex-l, Jun 13 2018

Mock History

Current Revision

Mock Description

Just an idea about extending the old tabs by KWin with some features by Windows 10 Sets and more

rk added a subscriber: rk.Jul 7 2018, 7:50 AM
januz awarded a token.Jul 15 2018, 2:19 AM
januz added a subscriber: januz.
jessep added a subscriber: jessep.Aug 17 2018, 8:46 PM
kezik added a subscriber: kezik.Nov 14 2018, 11:17 AM
maverick74 added a subscriber: maverick74.EditedDec 19 2018, 7:50 PM

Related to https://bugs.kde.org/show_bug.cgi?id=343690 ?
Oxygen had something like this. Breeze does not (yet)...

scherek added a subscriber: scherek.Jan 8 2019, 2:52 PM

Think about top bar beeing a panel, so tabs can be set icon-only, other widgets can be added (clock, global menu, else).

How would it work with web browsers? Tabs within tabs? Also, I think it would be a great idea to make the default keyboard shortcuts for switching between tabs Super + tab and Super + shift + tab and leave Alt + Tab and Alt + Shift + Tab for switching between windows.

@oussemabouaneni it's writter in the very first image: the browser (and other apps with tabs) should hide their tab bar. Managing shortcuts in a meaningful way shouldn't be a problem. The challenge would be integrating existing browsers like Firefox and not only the KDE one, Falkon.

@scherek except for the icon-only tabs (that I don't think would work), do you mean something like this?

@alex-l I think he means like pinning tabs in web browsers.

This comment was removed by oussemabouaneni.
alex-l added a comment.EditedJun 18 2019, 11:46 AM

Hey @ngraham, you said tabs in the title bar prejudice usability in dragging the window like in Firefox and I think you are right, so I did the following mockup with a responsive layout for the title bar, can you let me know if it would be good for you? Thanks!

The green indicate the area you can use to drag the window. "h" height is preserved and "w" is a minimum width: when a window shrinks the layout change to guarantee that minimum. "w" could be configurable by the user, something like "drag area: tiny/medium/large":

Edit: I think that maximized windows there is no need to change the layout, but just preserve the drag area

Ah, nice. Always adding drag space above the tabs seems to me to be a better solution than always keeping some drag area to the right. The problem with that approach is that with a lot of tabs, the amount of remaining drag area is tiny and borderline useless, just like Firefox with CSD currently has. Also, people who habitually maximize every window and expert users who alt-RMB drag to move windows will complain that there's "wasted space" in the titlebar because of the preservation of drag area

Then again by adding drag area above the tabs, people will complain that the titlebar is taking up too much space and doesn't respect Fitts' law for dragging tabs. You can't win! :(

The problem with that approach is that with a lot of tabs, the amount of remaining drag area is tiny and borderline useless, just like Firefox with CSD currently has

Maybe the mockup it's not clear enough but this is exactly what I tried to solve! :) if there are many tabs the layout change with that additional drag area above tabs.

BTW the same approach could be used with DWD too: