-6

This is an idea that I've been brewing for a short while and, though I haven't dedicated a massive amount of thought to it, I'd like to throw it out into the wild for discussion. Since I heard that KWin would be getting window tabbing, I had the idea of removing the traditional tab interface in favour of the window-tabbing interface. A small, none-comprehensive list of advantages and disadvantages:

Advantages:
1. This would make, "each tab a separate process" easier to implement: it's no longer embedding different processes into the same window, but simply creating a new window and e.g. sending KWin a call to create a new tab instead. This can improve stability for several applications, such as Konqueror, KMail or Kopete (an interesting thought: if each chat window spawned a new process that was loosely tied to the contacts window for the sake of receiving status changes, and something caused the contacts window to crash, conversations could theoretically be continued with only the contacts process having to be restarted and re-registered to the chats, e.g. the Yahoo/Facebook plug-in misbehaves. Something similar would happen with KMail, where new messages would open in a new tab as a new process).

2. Detaching, re-attaching and closing tabs would be consistent across all applications and would even be possible between applications (Think: a Kopete contact has been exported to KAddressBook/KContactManager/KWhateverItsCalled and the two contacts are linked via Nepomuk/Akonadi. The user sees an E-mail from them, wants to continue the discussion in Kopete through instant-messaging and switches to Kopete on the same desktop. He clicks on the contact and KWin automatically tabs that E-mail and instant-messaging window together (another idea for another discussion somewhere else: a unified, Akonadi-powered conversation viewer showing conversations between this person and yourself chronologically across different medium, including IMs, E-mails and whatever else)).

3. Application developers don't have to add new tab widgets to their projects any more. Instead, they add a call to announce that they want KWin to tab certain windows together, like Kopete chat windows. They can also add calls to query Akonadi or Nepomuk for features that are similar between the application and other applications and make tabbing interfaces depending on what is received (see 2 above).

4. Configuring this on a global basis would be made easier. Moreover, making this configurable on a per-application basis would also be simple: just tell the application to make certain calls when certain elements return certain values, or no calls at all if some element returns a different value (Konqueror's and Kopete's tabbing configuration wouldn't need to be changed - just the calls they make. It would still be possible to e.g. have links open in a new window instead of a new tab).

Disadvantages:
1. KWin-dependant! This wouldn't work in other window managers and might cause more grief for developers just to get both interfaces up and running depending on what window manager is running (could this be solved via an OpenDesktop spec. for window tabbing? Fluxbox and Compiz already support it as well, for example - it would be kinda cool to have the WMs behave similarly but with their own implementation of tabbing. On the other hand, would the Gnome project consider this beneficial enough to implement?).

2. Resources! Having separate processes per tab or per window in certain applications (Konqueror/Kopete/KMail) might eat up lots of resources, and only making some parts of the application multi-process would defeat the original point of making it simple to implement this for developers.

3. Legacy use! What happens when you open a KCM module with lots of tabs? Does it open all those tabs in the window border? Would each tab be close-able (OK, so this could be solved with, "read-only"-like fixed tabs)? Would this make each KCM tab feel independent, even though they are of the same KCM section? Would this cause grief and despair in navigating System Settings? What about an interface like Choqok's, where there are two legacy tab widgets in use? "Meta-tabs" seems to come across as a complex solution to a currently mundane problem that could be avoided entirely, both use-wise and implementation-wise.

4. Toolbars! Toolbars, dockers and the like can be detached from windows - what happens, then, when a user switches tabs? Presumably the same thing as when a user switches windows - the toolbars/dockers for the previous window become hidden and the current window's toolbars and dockers show. Is this desirable?

5. External applications! Just as KDE applications would likely depend on KWin for this, none-KDE applications (firefox, I'm looking at you) will likely have their own, inconsistent implementation of tabs, as they wouldn't be programmed with KWin's capabilities in mind (would this be solved by the above tabbed-window-manager spec + linux-specific hacks in Firefox and other cross-application hacks?).

6. Inter-process communication! D-Bus is amazing. Really, it is. But, what would having all those processes communicating with each other via D-Bus do to your resources? Would you need God's given horse-and-chariot to power the next version of KDE for this?

Doesn't anybody have anything to add?

I don't think each process for each tab is a good idea. Why KWIN should force programmers to do that? Actually you can group windows from the same application - no each process for each window.

I think, that it's not bad idea, but must be implemented by developers themsevles. One major priority for KWin developers is allowing application to group/ungroup own window. It also should have access to signals, like attaching, detaching, switching, etc.

one processes per tab wouldn't be forced, it would just be easier to do. For example, right now all Kopete windows run under the same process, even though they are separate windows. If one goes, they all go. If there's a bug in e.g. how Kopete receives contact information from Yahoo and that causes it to crash, it doesn't matter if the chat window interface is absolutely flawless - it is forced down as well. Having them run as separate processes would prevent that: the contact window crashes and goes down but you can resume chatting with your contact while the contact window restarts. With window tabbing, it would also be easier to make each chat instance separate in the same fashion: one chat instance doesn't crash the whole thing.

Maybe I should move this to the Discussion board - you know, so that it'll actually be discussed...

This can already be done in KDE4.4.
You just have to set group windows of same app together.
So in Koqueror you can then set to open all links in a new window and hide tabbar when only one tab is open, and you get a process per tab browser.
And it automatically groups every duplicated windows of a app, so it same for Kopete, Dolphin etc...
I'd say it's "done" in a way... (provided it is more primitive than your way, but still..)

Well, yes, I noticed this, but still, it's more like a half-hearted attempt currently: for example, Konqueror doesn't properly differentiate between, "new tab" and, "new window"; creating a new window actually results in a new window tab. My suggestion would make the new tab option create a new window tab, and the new window option would create a new, separate window.
Kopete is the same, currently: a new chat tab is actually created in the kopete contact list window group, whereas my idea would have it behave as it does now and instead use window tabbing to group chat windows together, instead of having a contact window tab and a chat window tab, the chat window tab then having 3 or 4 tabs within it for each chat (depending on how you have it set up).