I do not think this is a reason to drop tabs in applications. It actually works better when application itself can use tabs. For example: I 'merge' Kopete's contact list and chat message window. Tabs on top allows me to switch 'modes' so to speak (contact list / message window) while inner tabs will manage separate contacts I'm talking to.

f.d.o standard is a good thing though.

this is no official statement, just my 2¢

a) there should be no reason for a fdo spec on this (the handling is WM internal and requries no additoinal hints from the clients)

b) making is a requirement for netwm compliant WMs would break other window manager concepts (tiling ones, fullscreen only WMs) that otherwise do respect NETWM

c) and in general:
moving tabs from the client to the WM makes little to no sense in most cases.
toolkits like Qt or gtk need to provide tabbing support for other OS/NETWM uncompliant WMs anyway, so one could never save that code.

if the application is so unreliable that it needs to be segmented, the application needs to be fixed or avoided.

a valid exception is the browser (chrome), as it (lately) acts as VM for various untrusted clients (js powered webpages) with the unpredictable and pot. malicious behaviour (even it they can not break out of the sandbox, they can eat all cpu time granted to the browser -and esp. its UI thread- by the OS, so the browser needed it's own task scheduler/manager -> there's no reason to dupe the more reliable and better tested OS schedulers)

Non-mandatory 'description' standard maybe then? On the other hand if it does not make any sense bug should be closed.

> I do not think this is a reason to drop tabs in applications. It actually
> works better when application itself can use tabs. For example: I 'merge'
> Kopete's contact list and chat message window. Tabs on top allows me to
> switch 'modes' so to speak (contact list / message window) while inner tabs
> will manage separate contacts I'm talking to.

If we had (once we have?) nested windows, this wouldn't be an issue.

> there should be no reason for a fdo spec on this (the handling is WM
> internal and requries no additoinal hints from the clients)

I'm not sure I agree with that; clients should be able to say "I should be in the same group as <window_id>" or "I should be in a group above the group of <window_id>"... maybe others. Basically so that apps can implement 'new window' and 'new tab' as per traditional semantics, but such that the tabs are done by WM tabbing rather than within the app.

It certainly can (and probably should) be optional, but I still think there is huge value in making it standardized.

Back when Maciej and I were debating NWI, the goal was to make application-side MDI obsolete. But I don't think this is possible unless the application can communicate to the WM how it wants its windows to be grouped on creation.

> moving tabs from the client to the WM makes little to no sense in most cases.
> toolkits like Qt or gtk need to provide tabbing support for other OS/NETWM
> uncompliant WMs anyway, so one could never save that code.

Catering to deficient OS's is not the way to encourage progress. If we have to do that, we will be following, not leading. But at least we could let the WM do MDI on fully-featured WM's and have in-application MDI as a fallback.

> if the application is so unreliable that it needs to be segmented, the
> application needs to be fixed or avoided.

While admirable, that's both unrealistic and irrelevant. Irrelevant because you lose the ability to insert other application's windows in the group when you manage MDI in the application and not the WM. It's more flexible (and also more standardized) to move all MDI to the WM. a) MDI behaves the same system-wide, and b) because the WM controls the MDI, the user can do things the application developers didn't envision.

In the current state there is nothing we could commit to freedesktop.org. KWin tabbing is completely internal and does not interact with windows. I want to add a kind of API for 4.6 so that windows can request that a new window should be opened as a window tab. But even then I'm not sure about standardizing it. The use case for application controlled window tabbing is quite limited - I can only think of browsers as valid use cases. For most other things the current approach is more suited.

But of course if we want Firefox to make use of it we have to bring it to freedesktop.org.

Well, I have to respectfully disagree. Why shouldn't e.g. Dolphin us it? And I really, REALLY, **REALLY** want Konsole to use it. For Konsole, mostly because it's crashed on me one too many times, and because Konsole crashes can be very nearly as bad as X crashes in terms of interrupted (or worse, lost) work.

With *just* tabbing I can agree there isn't as much justification (though, as you say, FF is a biggie), but if/when NWI gets here, it becomes interesting for e.g. Kate, KDevelop, Krita, GIMP, Inkscape... anything with MDI or docking toolwindows, really...

That reminds me, any spec should also include a command-line argument to request a window attach itself to a specified group, so that e.g. when I open a PDF in Okular from <web browser of choice>, Okular can start up as a tab in the browser group. (Of course, given that use case, I can argue that even if only browsers are making direct use of tabbing, all sorts of things wind up using it /indirectly/ anyway.)

Now... as you say, it's not ready :-), so maybe we can table this for a while.

> Well, I have to respectfully disagree. Why
> shouldn't e.g. Dolphin us it? And I really, REALLY, **REALLY** want
> Konsole to use it. For Konsole, mostly because it's crashed on me one too
> many times, and because Konsole crashes can be very nearly as bad as X
> crashes in terms of interrupted (or worse, lost) work.
Your Konsole crashes won't be solved by window tabbing. All Konsole windows 
belong to the same process, so a crash in one "tab" will still close all tabs. 
Same true for Konqueror or Rekonq. Window Tabs don't bring us the stupid 
Chromium approach of having one Tab per window (yes it is stupid).
> 
> With *just* tabbing I can agree there isn't as much justification (though,
> as you say, FF is a biggie), but if/when NWI gets here, it becomes
> interesting for e.g. Kate, KDevelop, Krita, GIMP, Inkscape... anything
> with MDI or docking toolwindows, really...
The problem with NWI is that it is a hughe project which I don't expect any 
developer to address soon. It's even way to complex for a GSOC project
> 
> That reminds me, any spec should also include a command-line argument to
> request a window attach itself to a specified group, so that e.g. when I
> open a PDF in Okular from <web browser of choice>, Okular can start up as
> a tab in the browser group. (Of course, given that use case, I can argue
> that even if only browsers are making direct use of tabbing, all sorts of
> things wind up using it /indirectly/ anyway.)
might be complicated but sounds like a reasonable idea.
> 
> Now... as you say, it's not ready :-), so maybe we can table this for a
> while.

> Your Konsole crashes won't be solved by window tabbing.

Bah. I deleted what I'd written about *and switch to a multi-process model* as being too verbose. I guess it wasn't.

> Window Tabs don't bring us the stupid Chromium approach of having one Tab per
> window (yes it is stupid).

Quite the opposite, if the WM can do MDI (tabbing, in this case), applications SHOULD let the WM do MDI for them. But I think you meant process-per-tab, which is also not stupid; it prevents one broken/rogue website from taking out your browser as a whole (or a crash from taking out *all* documents/sessions/etc as opposed to just one).

> The problem with NWI is that it is a huge project [...]

True, never said it wasn't. But we seem to be taking baby steps in that direction, as tabbing (and the tiling research) indicates.

I'm not asking for NWI tomorrow :-). Mostly I'm using that goal as evidence why I think we *eventually* want an FD.o spec for applications talking to the WM.

<offtopic>Process-per-tab is IMHO a stupid idea, because it introduces a hughe overhead on memory footprint for a very little benefit. It's true that one broken website cannot crash the browser anymore, but a broken website should not be able to crash the browser. In my opinion the browsers should fix their crashes, put websites into sandboxes and not blame them for letting their browser crash. Just imagine KWin would crash if a client would do something bad. It would be unacceptable</offtopic>

This looks like what I was looking for. Tabs in the title bar save vertical space and can be handy where switching between tabs basically changes the entire window contents to be related to something else, such as a browser window, containing a website with address, history controls etc., a Chat window with one conversation and all the controls related to that contact or a File manager with sidebar, history controls and menu bar related to a specific folder. Logically, tabs in applications like these should be on top anyway. Whether or not this is handy in terms of mouse movements is another issue.

We basically need a protocol (or extension to the existing protocol, please standardized, so that it works with all WMs implementing it), that defines the interaction between the WM and the app. The app detects if the WM supports the protocol and tells the WM when it wants to control the tabbing and if other applications should be allowed to the tabs. The tabs are removed from the application itself and placed in the titlebar. The application will still be handled as one, not as several windows. An addition to KTabWidget (boolean AllowWMTabbing or so) could make it easy to implement.

I would really love this feature, I think it's very useful. Also, it would make Linux the first platform actually supporting it on the desktop side, not the application side. Unfortunately, I don't (yet) know how to do it, but I believe it is not a lot of work. In about a year I will have time to look into it, if no one has done it so far, I will try it.

sorry, i couldn't stant [sic!] it anymore ;-P

Hey, what do you guys think about allowing the applications to put all kinds of things in the titlebar? Like Menus, Buttons etc.? I thought about this because I think, FF4 looks great on Windows with Tabs on top and the FF button and integrates well in the rest of the Desktop while saving quite a bit of vertical space on netbooks. On Linux it looks ugly as...
I don't know if the code for this is just in FF or for a part in Windows, but who cares, if someone had a good idea, why not just copy it? On Linux this would need to be standardized in order to look good with all WMs, otherwise apps would look as ugly as chromium (which I use, by the way, it's fast and the only browser with proper html5 support).
Maybe there are some good reasons for or against it. I'd love to read them.

> Hey, what do you guys think about allowing the applications
> to put all kinds of things in the titlebar? Like Menus, Buttons etc.?
There is a feature request to support qtdbusmeu in the window decoration. I like the idea and are happy to accept patches.

Custom buttons is a no-go from a consistancy point of view. Please compare Mark Shuttleworth completely failed idea of "windicators".

I like my menus in the top bar, but menus in the titlebar could be nice for some people. I was actually talking about custom menus, like the firefox button. Whole menus will be too big for a lot of applications (they often are already in the application window, that's why moving them to the top is a good idea, just imagine if you wanted to squeeze them next to the window buttons).
> Custom buttons is a no-go from a consistancy point of view.
Why? Toolbars look different in all applications. Yet no one is complaining about it. Why should Titlebars be any different?
IMHO, allowing custom buttons in the decorations is not a bad idea, it's just a bad idea to use them excessively. I think most people agree, this is a better approach than client side decorations which completely eliminate consistency.

> I like my menus in the top bar, but menus in the titlebar could be nice for
> some people. I was actually talking about custom menus, like the firefox
> button. Whole menus will be too big for a lot of applications (they often are
> already in the application window, that's why moving them to the top is a good
> idea, just imagine if you wanted to squeeze them next to the window buttons).
Sure that's why my idea was to drop the menu into one button. Have a look at the Plasma 
netbook in Kubuntu as reference
> > Custom buttons is a no-go from a consistancy point of view.
> Why? Toolbars look different in all applications. Yet no one is complaining
> about it. Why should Titlebars be any different?
> IMHO, allowing custom buttons in the decorations is not a bad idea, it's just a
> bad idea to use them excessively. I think most people agree, this is a better
> approach than client side decorations which completely eliminate consistency.
Have a look at Oxygen window decoration. It is a piece of art. All buttons follow a certain 
scheme - if we allow the application to add buttons, it will end up inconsistent.

This request unfortunately turned into a discussion about everything and the kitchen sync which makes it rather difficult to actually understand what the request was about.

I try to go back to the initial report and I fully agree with the analysis of comment #2. I don't think the functionality provided here is suited for EWMH. Please note that in general we forward our internal adjustments to EWMH if we consider them as useful. The window tabbing feature does not have any adjustments to EWMH at the moment. So overall there is nothing to standardize.