Bug 332546

Summary:	Two types of tabs work very differently
Product:	[Plasma] kwin	Reporter:	Brock McNuggets <usenet>
Component:	window-tabbing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal
Priority:	NOR
Version:	4.11.6
Target Milestone:	---
Platform:	Mint (Ubuntu based)
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Brock McNuggets 2014-03-25 04:38:53 UTC

There are two types of tabs, one for Dolphin and one for the window in general (allowing you to attach different applications). I will call these "Dolphin tabs" and "Window tabs". 

Dolphin tabs allow you to drag items from one tab to another. 
They do not allow you to detach and then re-attach (combine windows Dolphin windows as tabs)

Window tabs allow you to attach and detach from each other.
They do not allow you to drag from one tab to the other.

Expectation: they should work roughly the same. They should both allow you to drag items (assuming you can drag from one window to another you should be able to drag from one Window tab to another). Both should allow you to attach and detach tabs. Would be good to have the be a simple and consistent UI: perhaps when you drag and hold one window over the other you are given the option to combine into tabs, and when you drag one Dolphin tab over another you are given a similar option (this might require the user to already have multiple tabs in each Dolphin window or to have it when you drag to the main part of the window you get the option for Dolphin tabs and the top Window tabs... or even a menu like the drag and drop items the "Copy Here / Link Here / Cancel" where you get an option that way.

Reproducible: Always

Comment 1 Christoph Feck 2014-03-25 23:18:54 UTC

> They do not allow you to detach and then re-attach (combine windows Dolphin windows as tabs)

That's https://bugreports.qt-project.org/browse/QTBUG-3160

> They do not allow you to drag from one tab to the other.

I doubt that's possible. KWin probably has no idea that an application is currently trying to drag something, so it doesn't know that it should switch tabs during hovering them.

Comment 2 Brock McNuggets 2014-03-25 23:39:59 UTC

Curious: Is that because it only knows there is a drag action once it is outside of the window… and the tabs are in the window? If the answer is long I get that this is not a discussion forum for such things, just curious (and might help with some other bugs I am looking at).

Comment 3 Thomas Lübking 2014-03-26 15:00:31 UTC

> Expectation: they should work roughly the same.
That's impossible*

The decoration could intercept DnD enter/move events and start a timer to auto-activate the tab below, but that's it.
It would eg. be completely impossible* to drop a file on a WM tab and have the dolphin window below perform a copy operation or firefox open the tab or stuff like that.
Turning an internal tab into a window or a window (of the same client process!) into a tab would be subject to the client - detaching a tab (ie. turning it into a window) is possible in dolphin.

*to be more precise, this would require a common protocol between WM and clients, it can not be provided by one side only.
-> you may file a draft extension to the NETWM spec - which then not only needs to be supported by kwin, but also all clients.

Comment 4 Martin Flöser 2014-03-26 19:48:37 UTC

> *to be more precise, this would require a common protocol between WM and
> clients, it can not be provided by one side only.

Just for the record: with Wayland that might become possible thanks to KWin 
being in better control. But it won't have any priority in implementation.

Comment 5 Thomas Lübking 2014-03-26 20:12:44 UTC

We cannot just forward the DnD clientmessage to "some" position into the client, since we don't know how the client will react for the particular spot.
(Otherwise it should also be more or less possible w/ X11)

The client would have to provide a list of supported mimetypes to the decoration (so we can hint the correct action/acceptance) and we then send it the drop message (inc. mimedata) which it needs to handle correctly according to the "not in my geometry" (ie. titlebar/tab) spot.