Bug 332675 - Add a <plus> button to create new windows
Summary: Add a <plus> button to create new windows
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: window-tabbing (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-27 11:48 UTC by Wout Mertens
Modified: 2016-08-29 06:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.