Bug 332675

Summary:	Add a <plus> button to create new windows
Product:	[Plasma] kwin	Reporter:	Wout Mertens <Wout.mertens>
Component:	window-tabbing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Wout Mertens 2014-03-27 11:48:04 UTC

Chromium has a "+" button in the tab bar which allows you to create a new tab. It would be nice if kwin could provide the same, telling apps to create a new window and adding it to the client group.
E.g. when I have a Konsole window open and I click on the "+" button, kwin will tell Konsole to open a new window and kwin will add it as a tab to the current window.

Reproducible: Always

Comment 1 Wout Mertens 2014-03-27 11:49:31 UTC

If this gets implemented, perhaps Chromium will implement a KDE mode where the tab bar is hidden and instead windows/browser tabs are managed by kwin.

Comment 2 Thomas Lübking 2014-03-27 11:54:35 UTC

this cannot somehow be implemented in kwin but *needs* an extension to the NETWM protocol (and support by the reg. client) which can then be implemented by kwin.

Comment 3 Martin Flöser 2014-03-27 12:11:48 UTC

how should that behave if there are tabs of different applications? E.g. I 
used to tab Kile and Okular together back in the days when Kile didn't provide 
a built-in preview.

Comment 4 Wout Mertens 2014-03-27 12:17:35 UTC

Thomas, I'm not sure about the technicals, but couldn't kwin detect if a window is a KDE app and use dbus to do the communication? A NETWM extension would be marvelous of course but doesn't seem likely. Non-dbus apps won't get a "+".

Martin, the "+" would create tell the current foreground app to create a new window.

Comment 5 Thomas Lübking 2014-03-27 12:28:45 UTC

client/wm protocol is mandatory and gnome/gtk is moving towards CSD, so they're likely never gonna support such (got reply to the noborder state extension? ... seen the ridiculous late dialog approaches?)

----------

If there's strong interest in this regard (dragging client actions into the titlebar), it would very likely end up being KDE only (with a KDE only window property)

The client would add a property with the supported actions/mimetypes/stuff and the dbus service/object/interface (or there'd be a default "/WM org.kde.WMActions.*) for the features it wants to expose to the WM

That could also get us out of the stupid appmenu approach (as dbus-menu was not designed for a dynamic setup and also having access to a menu while the client itself might be blocked/stopped and thus the ability to send it a random amount of actions while it does not even respond is plain stupid) - the client would just expose the presence of a menubar popup and kwin would add a button for it.

Sorry for the rant.

Comment 6 Wout Mertens 2014-03-28 08:49:47 UTC

Thomas, well that sounds like a great approach and indeed improves the appmenu...

Comment 7 Martin Flöser 2016-08-29 06:45:20 UTC

Unfortunately the rework in decorations in KWin 5 resulted in the window tabbing feature to be lost. We still want to bring this feature back, but after several versions it still hasn't emerged yet. Given that I think it is time to adjust the status of this bug report. The new implementation would be different anyway and it's questionable whether this report would still apply to it.