I just switched to Plasma 5 and I can not find the "Attach as tab to..." option to group windows. Is this very useful feature gonna be implemented? Reproducible: Always Actual Results: No such option. Expected Results: Right-click on the window title should show the option "Attach as tab to..." and middle-mouse click should allow to group windows.
api is still there, matter of decorations to use it.
(In reply to Thomas Lübking from comment #1) > api is still there, matter of decorations to use it. I see. Then please could you add this feature into the Breeze decoration?
(In reply to Thomas Lübking from comment #1) > api is still there, matter of decorations to use it. actually no: it's not yet exposed in kdecoration2
This is not possible to introduce in a small release right? I hope this feature returns soon, other than that, the new stuff is an awesome job, kudos!
(In reply to kdeuser56 from comment #4) > This is not possible to introduce in a small release right? no, sorry that cannot be done for multiple reasons (the feature freeze could be bended given that it's a regression, but language freeze, Oxygen not ported, etc. make it to much for a minor release) > I hope this > feature returns soon, other than that, the new stuff is an awesome job, > kudos! thanks.
*** Bug 347616 has been marked as a duplicate of this bug. ***
Hello Martin, Before I begin, many thanks for the hard work. Any timeframe / roadmap to re-adding this feature. At least in my case, I had huge amount of kwin rules that auto-tabbed windows that I cannot move from kwin4. - Gilboa
Duplicate of https://bugs.kde.org/show_bug.cgi?id=340137?
Yesno. Tabbing isn't enabled in the core (the code is cut short), (afair) not implemented in libkdecoration2 and finally not used in Breeze.
Idiotic question: Are there any existing kwin that still use the old kdecoration that are compatible with Plasma 2 and capable of window tabbing?
> Are there any existing kwin that still use the old kdecoration that are compatible with Plasma 2 and capable of window tabbing? well any kwin (+oxygen) before the change to kdecoration2. Whether that's compatible with current Plasma is unlikely though. Plasma, kwin, kdecoration and breeze are released together and expected to be used together. Nobody tries other combinations so it might or might not work.
Thanks for the (prompt) answer. Guess I'll have to grow some patience. :)
Is there a target release for this feature? I had used it before in KDE4 and I'm now missing it with KDE5 on Fedora 23. No need to squeeze it in past any release freezes, just wondering what future release will have it so it'll then make its way down into distro packages.
> Is there a target release for this feature? Sorry no, there is no target release for this feature yet. With every release cycle I hope to find some time for it, but well...
Thanks for the update Martin. I expect features such as Wayland support take priority (and rightly so). Your hard work is appreciated and I can wait for window tabbing to make its return someday.
Perhaps it is then best to remove the window tabbing settings under "Window Behavior" --> "Advanced" until it becomes available.
I'm really missing this!!! It helps a lot to keep work organized!!!
Seems like it's about time to get serious or get honest. Either restore the "missing feature" or take it off the list. Three years and 11 minor versions with no progress is too many! At least for me, it is not simply eye candy. Not being able to tab windows directly impacts my daily efficiency and is a continual frustration. Same goes for a particular broken package (https://bugs.kde.org/show_bug.cgi?id=370964). If only I could go back to KDE4 that had issues like these resolved in lots less than 3 years!
I have to say this affects me and my work too!!! (if only i could code well enough...)
(In reply to john from comment #19) > I have to say this affects me and my work too!!! (if only i could code well > enough...) Ditto. I would fix it if I could. Meanwhile, window tabbing has been added to MacOS and is coming soon to Win10 thanks to 20,000 votes for it. It's a huge productivity enhancer.
(In reply to therapon from comment #20) > (In reply to john from comment #19) > > I have to say this affects me and my work too!!! (if only i could code well > > enough...) > > Ditto. I would fix it if I could. Meanwhile, window tabbing has been added > to MacOS and is coming soon to Win10 thanks to 20,000 votes for it. It's a > huge productivity enhancer. I think i'll grab some popcorns and see who (from Apple or Windows) will be the first to claim they came up with that idea (as already happened with the "convergence" concept which, actually, born from KDE)!!! Anyway 20,000 votes are a lot of people that "take up the work" to vote for the feature. It should indicate something...
*** Bug 340137 has been marked as a duplicate of this bug. ***
*** Bug 401535 has been marked as a duplicate of this bug. ***
I would love to see this feature. Is anyone planning to work on it?
I have to admit that the reason I am stuck to kde4 is because of this feature.I thought that it would not take long until this feature was implemented. Unfortunately I have no idea about harcore programming such as this, which leaves me to only wish that this will be implemented soon. I strongly endorse this implementation.
+1, would love to see this feature implemented!
Since it worked in KDE 4 apparently, can this be seen as a regression? Also marking as confirmed based on the comments here.
I was just thinking the same thing. If it was in Plasma 4, it'd be a regression as this feature won't be dropped soon AFAIK
Hello, For a while this feature was highlighted as missing in in the errata of new plasma release but now (for a long while in fact) it's not being shown at all. This makes me think it is now abandoned...am I right to think that there now no plans from the core plasma dev to bring it back? If so, is there any clues at to what makes it hard to port/implement from Plasma 4 to Plasma 5 so maybe someone else can have a go at the task (as this was such a brilliant feature)? Many thanks
*** Bug 466986 has been marked as a duplicate of this bug. ***
I'd like to advocate that this feature could pair very well with the new Kwin tiling. There could be a default, or optional setting, where if you shift drag a window over another window, they automatically tab together. Similarly, a shift drag from the tab would pull the window out of the tab group, and allow it to be made an independent window or allow it to be dragged into another tab group.
Would be cool to revive this feature, somehow modernized, like allowing to show those apps tiled and adjusted how it is displayed in the Window Panel and create new short cuts for those windows
We are not reviving this feature. The prevalence of CSDs makes this impossible to do well.
*** Bug 474739 has been marked as a duplicate of this bug. ***
(In reply to David Edmundson from comment #33) > We are not reviving this feature. The prevalence of CSDs makes this > impossible to do well. I don't think CSDs make it impossible to do well. Why do you say that?
Concept for tabbing mixed SSD and CSD windows: You initiate window merging via shortcut or taskbar option, then select a second (and third…) window. Plasma windows without CSD get regularly tabbed, CSD windows get an extra title bar to be tabbed. The title bar disappears after dissolving the window tabbing.
(In reply to Maximilian Böhm from comment #36) > Concept for tabbing mixed SSD and CSD windows: You initiate window merging > via shortcut or taskbar option, then select a second (and third…) window. > Plasma windows without CSD get regularly tabbed, CSD windows get an extra > title bar to be tabbed. The title bar disappears after dissolving the window > tabbing. I agree, I don't see why this would be undesirable at all... In fact I think this is exactly how tiling window managers go about resolving this issue.
I just want to thank everyone who is still paying attention to this "bug". I am still waiting in agony for this feature. It is sad for me that I don't have the programming skills to contribute. I am still in kde4 (Kubuntu 14.04) !!!!! (for other reasons as well) I will have to update this year, which means that the feature won't be available. Speaking for myself, I still think that window tabbing is INCREDIBLY useful and productive. There will be a lot of users who will appreciate this feature.
I have to say I agree. This feature was SO good! ...and greatly missed since Plasma 5
I'm curious about this possibility as well. I came here after seeing on MacOS you can do tabbed windows and searching for other options. Also out of curiosity checked if there's a windows solution. I found some random program called TidyTabs, which makes me think a similar solution could be possible with a KWin script or plugin. A script to stack all windows of the same class on top of each other would be easy. Just needs a visual tabbed indicator and some constraint on extra padding for maximized area on top. The tabs could be a simple Qt app that the kwin script keeps glued to the top of the stack perhaps... But aside from a hack like that, it would be cool for built in support.
(In reply to David Edmundson from comment #33) > We are not reviving this feature. The prevalence of CSDs makes this > impossible to do well. Kwin currently allows overriding these with standard titlebars and such. Wouldn't it be a matter of just forcing this on windows that are tabbed?
Does https://bugs.kde.org/show_bug.cgi?id=42023 have any relevance to this? Worth putting it in the https://bugs.kde.org/page.cgi?id=fields.html#see_also?
(In reply to Maximilian Böhm from comment #36) > Concept for tabbing mixed SSD and CSD windows: You initiate window merging > via shortcut or taskbar option, then select a second (and third…) window. > Plasma windows without CSD get regularly tabbed, CSD windows get an extra > title bar to be tabbed. The title bar disappears after dissolving the window > tabbing. Totally agree with this. A piece of Windows software called Groupy by Stardock does exactly this. Native Windows title bars are modified with tabs directly inside, and software with their own title bars have a tab bar put above.
The new cosmic desktop from System76 is doing it, so maybe there is a way on how to do it properly : https://system76.com/cosmic
(In reply to Kevin Messer from comment #44) > The new cosmic desktop from System76 is doing it, so maybe there is a way on how to do it properly : https://system76.com/cosmic Ctrl+F-ing "tab" doesn't return anything. Can you quote or link whichever part of that discusses WM-level tabs?
(In reply to Roke Julian Lockhart Beedell from comment #45) > (In reply to Kevin Messer from comment #44) > > > The new cosmic desktop from System76 is doing it, so maybe there is a way on how to do it properly : https://system76.com/cosmic > > Ctrl+F-ing "tab" doesn't return anything. Can you quote or link whichever > part of that discusses WM-level tabs? "Stack windows from different apps like tabs in a web browser" quote from the first paragraph under Adaptable Windows
(In reply to Gauthier from comment #46) > (In reply to Roke Julian Lockhart Beedell from comment #45) > > (In reply to Kevin Messer from comment #44) > > > > > The new cosmic desktop from System76 is doing it, so maybe there is a way on how to do it properly : https://system76.com/cosmic > > > > Ctrl+F-ing "tab" doesn't return anything. Can you quote or link whichever > > part of that discusses WM-level tabs? > > "Stack windows from different apps like tabs in a web browser" quote from > the first paragraph under Adaptable Windows And is demonstrate in the screenshot below the paragraph (on the right hand side of the image)
(In reply to Roke Julian Lockhart Beedell from comment #45) > (In reply to Kevin Messer from comment #44) > > > The new cosmic desktop from System76 is doing it, so maybe there is a way on how to do it properly : https://system76.com/cosmic > > Ctrl+F-ing "tab" doesn't return anything. Can you quote or link whichever > part of that discusses WM-level tabs? Yes, here is a Github discussion : https://github.com/pop-os/cosmic-comp/issues/262 And I also guess you guys can discuss with them how they did it technically.
(In reply to Kevin Messer from comment #48) Thank you.
I would like this feature (as many others seem to,) so I'm reopening it. I migrated to KDE during the Plasma 6 release, so I've never had this feature, but I greatly see the usefulness of it.
Don't re-open closed bug reports please.
What can we do to bring it back ? I mean, I tested the alpha 5 of the cosmic desktop and there it works as intended, just like the KDE4 times, so there must be a way also for KDE to have it. I am pretty sure that people would even pay money to have it implemented.
It's more like a feature request than a bug at this point...though to be fair that's what it's been ever since plasma 5. Not sure where the best is for feature requests...I thought here was, no? In which it may be correct that it is in fact not resolved and that the INTENTIONAL flag doesn't make sense for feature request (unless there is an argument from core KDE devs to actively not wanting such a feature to ever be implemented). As for the question (In reply to Kevin Messer from comment #52) > What can we do to bring it back ? One thing is to post it as a feature request, another would be to learn the code and start working on implementing it yourself. Something that personally I don't have the knowledge nor the time to learn and do...so the only option is to respect and trust the choices of other devs as to what they want to implement. I say that even though I heavily used window tabbing in KDE 4, has been missing it ever since Plasma 5 and I think it is a shame that it gets implement in another desktop and is seen as a very cool feature while KDE had it ages ago. But unless someone puts the work we must learn to live with it...or without it I should say ;).
(In reply to Gauthier from comment #53) It's already an FR – the importance is "NOR wishlist". "Wishlist" in this Bugzilla instance means that it's an FR. (In reply to andy from comment #40) Has anyone attempted to create a KWin script that implements this?
(In reply to Roke Julian Lockhart Beedell from comment #54) > (In reply to Gauthier from comment #53) > It's already an FR – the importance is "NOR wishlist". "Wishlist" in this > Bugzilla instance means that it's an FR. Ah yes, that was it, thanks. But then in that case the status flag RESOLVE INTENTIONAL doesn't make sense here. This should normally be for things that are reported as bugs where in fact it is the intended behaviour, no?
(In reply to Gauthier from comment #55) Yeah, it's a bit of a quirk in how they're triaged here. I asked Nate about that some ago, and it basically equates to a rejected FR. Ultimately, whether something is an FR or bug is mostly based upon the underlying implementation. What matters is that the triage assignee considers this to be undesirable. I'd estimate that the sole route to changing this is by developing a patch/fork that implements this and proposing at Invent (with a promise of continued maintainership) or developing a script that provides this in lieu of it being present in the main codebase.
(In reply to Roke Julian Lockhart Beedell from comment #54) > (In reply to andy from comment #40) > Has anyone attempted to create a KWin script that implements this? After a little searching, I found Aziroshin's kwin-window-tabbing kwin script on GitHub (https://github.com/Aziroshin/kwin-window-tabbing), however, "Currently in its initial stage of development and not yet usable." It's promising that someone's working on it, though.
I've discovered using Karousel that it has an approximation of tabbed windows, but it comes with its whole tiling setup as well. It has what it calls "stacked columns," wherein all windows in a tiled column but one are shaded, and as you change focus from one window to another, which window is unshaded changes accordingly. This does not work in Wayland, as Plasma's Wayland session breaks window shading. Not a solution for those who don't want to deal with that tiling script, or those who don't want to use X11, but it might suit some folks who find these comments. I'll attach a demo video of stacking and unstacking three windows.
Created attachment 177797 [details] Karousel Stacked Column screenshot I had trouble getting a video under the attachment size limit. Here's a screenshot of a Karousel stacked column (one window focused, two shaded).
maybe this is not the best place for this discussions, but here's an easy set up (workaround) i use myself: (You need: Global Menu widget + Application Title Bar widget) 1. Move the default bottom panel to the top 2. Place Global menu and Application Title Bar widget wherever you like them the most 3. set Application Title Bar to "Borderless maximised windows" to hide border and titlebars of maximised windows a) The task manager works as a "tabbed window" b) If you want more windows or groups you can use Virtual desktops or Activities (i never actually use this myself) this leaves more space for your windows and for you to focus on what you're doing without loosing functionalities.
(In reply to David Edmundson from comment #33) > We are not reviving this feature. The prevalence of CSDs makes this > impossible to do well. It could still work with SSD windows, just like some other features like customizable title bar buttons. AFAIUI KDE sticks to SSD for reasons including that it allows for customization and features beyond the lowest common denominator features supported generally by CSD windows. KDE applications use SSD, and most applications that use CSD by default (including Firefox, Chromium/Chrome, VS Codium/Code) can be configured to use CSD. GNOME apps are the only apps I've seen that can't be configured to use SSD. (In reply to Maximilian Böhm from comment #36) > Concept for tabbing mixed SSD and CSD windows: You initiate window merging > via shortcut or taskbar option, then select a second (and third…) window. > Plasma windows without CSD get regularly tabbed, CSD windows get an extra > title bar to be tabbed. The title bar disappears after dissolving the window > tabbing. (In reply to David from comment #41) > Kwin currently allows overriding these with standard titlebars and such. > Wouldn't it be a matter of just forcing this on windows that are tabbed? Unfortunately forcing a titlebar and frame on CSD windows is often ugly: CSD windows draw their own shadows, which KWin sees as part of the window, so there's a glitchy, semi-transparent frame between the KWin frame and the actual window. I just tried, this happens with Gnome Calculator, Nautilus/GNOME Files and Chromium, but not with GEdit and Firefox. (With the latter two, the titlebar can be re-enabled from the window menu, with the former ones that option is disabled, and it can only be forced via special window settings.) Though even with the former ones, KWin knows where the actual content is for the purposes of snapping, so in theory it could cut off/ignore the shadow when a titlebar and frame is forced on the window. But again, most apps can be configured inside the app to use SSD anyway, which works well, except for GNOME apps which there's rarely a reason to use under KDE anyway.
(In reply to Grósz Dániel from comment #61) > CSD windows draw their own shadows, which KWin sees as part of the window, so there's a glitchy, semi-transparent frame between the KWin frame and the actual window. I just tried, this happens with Gnome Calculator, Nautilus/GNOME Files and Chromium, but not with GEdit and Firefox. (With the latter two, the titlebar can be re-enabled from the window menu, with the former ones that option is disabled, and it can only be forced via special window settings.) Though even with the former ones, KWin knows where the actual content is for the purposes of snapping, so in theory it could cut off/ignore the shadow when a titlebar and frame is forced on the window. That wasn't *always* an issue. Per https://bugs.kde.org/show_bug.cgi?id=479372#c1, I recall it being a noticeable regression in KWin's XOrg 11 backend late in the Plasma 5.x development cycle - one reboot, there was a gap between the window decorations that was not there before.