Bug 42023 - PWM-Like tabbing support for windows
Summary: PWM-Like tabbing support for windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.0
Platform: Debian testing Other
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 45183 92659 183114 184283 184327 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-05-02 15:18 UTC by kdebugs
Modified: 2009-11-15 04:24 UTC (History)
23 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Two windows form a tab bar using the BII deco (87.25 KB, image/png)
2007-06-02 12:11 UTC, Eike Hein
Details
A screenshot of two kittens windows running, tabbing a bunch of stuff together (383.18 KB, image/png)
2009-05-03 06:36 UTC, James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kdebugs 2002-05-02 15:04:19 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kwin
Version:           KDE 2.2.2 
Severity:          wishlist
Installed from:    Debian testing/unstable Packages
Compiler:          Not Specified
OS:                Not Specified
OS/Compiler notes: Not Specified

It would be nice to have PWM-like window tabs when using kwin.

This would eliminate the need to implement tabs in e.g. Konqueror and Konsole or any other application which might have multiple instances (like a instant messenger).

It would be fine to see this PWM/Fluxbox like tabs and a way to make applications group by default.

(Submitted via bugs.kde.org)
Comment 1 Cristian Tibirna 2002-05-02 21:10:31 UTC
On Thursday 02 May 2002 11:04 kdebugs@berteun.dds.nl wrote:
>
> It would be fine to see this PWM/Fluxbox like tabs and a way to make
> applications group by default.
>

Why not use PWM/fluxbox directly?

-- 
Cristian Tibirna .. tibirna@sympatico.ca
PhD student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna
KDE developer .. tibirna@kde.org .. www.kde.org
Comment 2 Berteun Damman 2002-05-02 23:18:24 UTC
Op donderdag 2 mei 2002 23:10 schreef u:
> Why not use PWM/fluxbox directly?

Because the interaction between PWM / FluxBox and the KDE Environment 
is not (nearly) perfect. It is indeed possible but when using another 
window manager I lose style options and both window managers interact 
badly with the KDE desktop application so it's not really good.

On the other hand the feature isn't of utmost importance to me I'd 
like the idea of having tabbing support in the window manager and not 
in every application (Konsole Konqueror). If this is possible while 
retaining a good integration into the KDE environment this would be 
great (I think).

But hey It's a wishlist feature :)

Berteun
Comment 3 Lubos Lunak 2002-10-03 18:54:29 UTC
*** Bug 45183 has been marked as a duplicate of this bug. ***
Comment 4 Jesper Juhl 2002-11-22 22:49:57 UTC
The (IMHO) very nice thing about having FluxBox like tabs in KWin is that it would enable 
tabbing for *all* applications, not just stuff like Konsole and Konqueror can be tabbed, and not 
all applications need to implement tab support. 
If KWin implemented FluxBox like tabbing and also made it easily available to apps like Konsole 
and Konq to implement their tabbing as WM tabs instead of their own "build-in" tabs it would 
save a lot of work for others wanting to add tabs to their apps. 
And besides, the FluxBox tabs are extremely cool in the way they allow you to group windows 
from different applications. 
 
Comment 5 Julien Ponge 2002-11-24 14:00:53 UTC
I totally agree with that : FluxBox-like grouping is just a *great* feature. 
When I code with an editor like NEdit, I find myself with tons of windows 
under KDE and it just reminds me the old days when I used to work on Windows. 
It becomes a real mess. With FluxBox I just group the windows and it becomes 
really handful ! 
 
So I would really like to see that in KDE. 
Comment 6 Nathaniel Gray 2003-03-07 19:19:35 UTC
I think this would be a really great thing.  I've got tabs in Konsole, tabs in 
Konqueror, tabs in Mozilla, and even tabs in NEdit (Julien, check 
sourceforge.net/projects/nedit for a patch) but they *all* have different 
shortcuts, different capabilities, and different appearances.  There's really 
no need for this, since tabbing can be handled consistently at the WM 
level.  It would take a little thought to work out a flexible API that would 
allow application writers some advanced control (for example, to display 
their tabs inside their client area) but still work with legacy apps, but it 
could be done. 
 
Comment 7 Tim Middleton 2003-06-18 13:59:54 UTC
Somehow I don't think this is going to happen anytime soon, but I also would
like to see it. For a while not long ago I had to abandon KDE because the system
I was working on just didn't have the RAM... i missed tabbed Konsole most. Then
i found Fluxbox and it's nifty tab feature and put tabs on and grouped all my
RXVT windows... it was wonderful. Now i'm back to KDE, so i don't need this
feature so much, but it still would be good for other apps.
Comment 8 Eduardo Robles Elvira 2004-06-11 22:43:16 UTC
Does someone still remembers this wish? It still has _662_ votes! 20 are mine. It's a very useful feature; I think it as useful as virtual desktops.

BTW, I don't think that this feature could replace konsole, kdevelop, konqueror.. tabs; inestead, I feel that it would be complementary. You could have a real hierarchy of opened web pages. When I used fluxbox, I often had 3 or more web browser windows tabbed, and each window had some tabs opened =). Moreover, it would add choice: you could feel more comfortable using konsole tabs, but maybe others preffer konsole windows tabbed. And of course, it could be a cool way of tabbing for apps that doesn't support tabbing (such as kedit).

One more thing: It would be cool if it were configurable, "featureful". For example, fluxbox let you group one (or more) apps when they're opened automatically. Or you can just also want that all the windows of the same app tabbed in a sole title border.  Don't forget the tab reordering feature, with center (or wheel) mouse button via drag&drop :-).

PD: I suggest to mark this bug report as a wish, because I feel that it's more a feature request than a real bug :-P.

Apologies for my bad english.
Comment 9 Andrius Kazimieras Kasparavičius 2004-10-14 23:05:44 UTC
silence :) it's impossible to work in good mood with scrooling horizontal tabs with konsole or especially konversation-multiple servers. Nothing found in 3.4 roadmap. Any predictions? :)
Comment 10 Stephan Binner 2004-11-04 10:41:18 UTC
*** Bug 92659 has been marked as a duplicate of this bug. ***
Comment 11 David 2004-11-04 23:12:45 UTC
I just thought I would add that it would be nice if it could be either the tab style or the newer style that fluxbox implements (my favorite).

The newer style simply breaks up the title bar for each application (leaving the buttons at either end). The advantage of this is that you do not need any extra space, and you do not need extra components in the theme because there is virtualy nothing extra to draw on screen.
Comment 12 Luke-Jr 2005-02-01 07:52:15 UTC
http://utopios.org/dev/projects/kde/mockup-images/

Some various mockup ideas, some requiring fairly complex modifications to kwin and tab classes.
Comment 13 Rene Horn 2005-04-05 07:25:53 UTC
I, too, would like this feature very much.  It's been almost three years, but no word on this feature as of yet.
Comment 14 Andrius Kazimieras Kasparavičius 2005-08-02 02:56:39 UTC
agree with #12, any plans for implementation? :)
Comment 15 Lubos Lunak 2005-11-01 16:36:22 UTC
*** Bug 56157 has been marked as a duplicate of this bug. ***
Comment 16 Arne Schmitz 2006-06-23 14:58:12 UTC
Is there happening anything on this problem?
Comment 17 Jonathan C. Dietrich 2006-09-28 02:30:39 UTC
I just added my votes, we are up to 1206. I just recently tried fluxbox, and find the tabbed environment very nice, and it is almost enough to pull me away from kwin, but the integration is not quite tight enough. Please consider this for KDE4. (PS. I like how fluxbox allows the "tabs" to be part of the title bar, hence taking up no more room.)
Comment 18 Stefan Monov 2006-10-12 21:26:38 UTC
See also: http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml
Comment 19 Adrian Friedli 2006-10-15 02:38:50 UTC
Eduardo Robles Elvira wrote in #8:
> BTW, I don't think that this feature could replace konsole, kdevelop,
> konqueror.. tabs; inestead, I feel that it would be complementary. You could
> have a real hierarchy of opened web pages. When I used fluxbox, I often had 3
> or more web browser windows tabbed, and each window had some tabs opened =).
> Moreover, it would add choice: you could feel more comfortable using konsole
> tabs, but maybe others preffer konsole windows tabbed. And of course, it
> could be a cool way of tabbing for apps that doesn't support tabbing (such as
> kedit).

Why not just allow an infinite number of tab-levels and implement the tab-hierarchy in kwin? Personally I would not prefer different tab-implementations if everything could be done in one.
Comment 20 Stephan Sokolow 2006-10-15 05:09:49 UTC
Interesting idea, but I'd rather not have a new process for each tab, thanks. Fluxbox-style single-level tabs combined with application-level tabbing will do just fine.
Comment 21 Technologov 2007-06-02 11:55:36 UTC
Yes, indeed, this would be VERY important feature to add.

Screenshot of very primitive implementation:
http://en.wikipedia.org/wiki/Image:Pwm-screenshot.png

Of course from 2000 to 2007, the KDE technology has advanced
tremendously, so we could implement similar technology at much more
customizable levels.

That is: instead of making tabs above the window, we could make it
below the menu, above the menu, or near the bottom, but inside the
window decoration... anywhere.

(I know that in KDE3, applications menu's are plug-able, which I can
prove because KDE3 can be made to feel like Mac with menu's on top,
instead of being in the main window)

So having this revolutionary technology implemented and customizeble
will win a LOT of users from other platforms (both from Windows, and
GNOME) to KDE4, as those platforms have nothing to offer in that space
AFAIK.

Especially now, considering the fact that KDE4 apps are going to be ported
to Win/Mac, and no longer stay Linux-unique, I believe that the Linux
community should use this technology as a "rabbit-in-wizard's-hat"
advantage :) to continue moving people from proprietary platforms.

From technological standpoint, it will be similar to taskbar (kicker)
application grouping, except that this will be much more useful and
more convenient, and more customizable.

Please do it in KDE4, and don't delay it for another 5 years to 2012.

-Alexey "Technologov"
Comment 22 Eike Hein 2007-06-02 12:10:47 UTC
Most people don't appear to know (alright, how could they), but KDE actually has had this feature for many years. The BII window decoration shipped with KDE uses BeOS-like tab title bars, and if multiple windows with the same size are placed at the same location, the decoration will move the title tabs to provide a tab bar. Screenshot follows.
Comment 23 Eike Hein 2007-06-02 12:11:50 UTC
Created attachment 20758 [details]
Two windows form a tab bar using the BII deco
Comment 24 Lubos Lunak 2007-06-02 12:25:23 UTC
This wish is still valid, the BII decoration is far from being a real tabs implementation.
Comment 25 Eike Hein 2007-06-02 17:57:01 UTC
True, but I felt it was worth pointing out -- perhaps it'll float someone's boat.
Comment 26 pankkake 2007-06-02 18:29:52 UTC
I'm already using this feature; while still great, it's not that easy to use, and sometimes it doesn't work, or doesn't react well when the length of window title changes (which can be often with applications like Firefox).
Another solution can be to use a tabbed Window Manager in conjunction with the KDE system by setting the KDEWM environment variable.
Comment 27 Luciano Montanaro 2007-06-04 11:24:18 UTC
Well, I'm not familiar with PWM; from what I gather it offers a way to group together more window frames. A better feature request would describe the feature requested with a few more details...

What I'd like to try to do is:
add a new "clip" button, that could be shown on application-type windows (I'd exclude dialogs, non-resizable windows, and generally transient windows is that ok?).
The user would be able to drag the clip from the titlebar of a window onto the titlebar of another window; dropping it there would create a new group.

What should be done with the titlebar buttons, however? Should they be "global", and apply to the active tab, or should they be replicated for each grouped window? The minimize, maximize and pin buttons could be shared... the close, menu and help buttons may be replicated for each tab.

Would something like this work? Would it satisfy you? Is there something missing?
Comment 28 Eduardo Robles Elvira 2007-06-04 12:02:48 UTC
I don't know if you guys have seen the Beryl Group Tab plugin, but I think that it is exactly how I'd like it to be in KWin! You can watch how it works in http://www.youtube.com/watch?v=eotwBwXquqw
Comment 29 Stephan Sokolow 2007-06-04 16:27:44 UTC
Just as a suggestion, here's a little example of why application-level tabbing is still important.

Right now, I'm posting this comment in a Konqueror window with 21 tabs, and that's LOW by my standards. I often work with 30 or 40 tabs to a window and two or three Konqueror windows.

I can't afford to by a quad-core system with another gig or two of RAM just to to keep doing what I'm doing now.

Now, on the other hand, there is one thing which separate Konqueror processes would help... but the proper solution to that one is to move each tab into it's own thread so that KHTML and KJS can't freeze up the entire viewer (Konqueror is far more than just a web browser and file manager to me) when rendering complex pages or running AJAX-heavy web apps.
Comment 30 Luke-Jr 2007-06-04 16:51:03 UTC
Indeed, but that's a problem with application designs, not the tabbing model.
Konqueror, IIRC, does already have an option to share a single process already. That could possibly be extended to share between the same logical window.
Comment 31 Stephan Sokolow 2007-06-04 17:21:48 UTC
Or... we could keep the application level tabbing to avoid punishing free-minded people who want to use Konqueror tabbing with a non-kwin window manager.

Personally, I think that doing it the way you suggest is just asking for trouble... unfortunately, Xfce is the only desktop even close to KDE in quality and it's got a long way to go, so I can't just afford to say "Do what you want, let the 'crash and burn' show how wrong you are."
Comment 32 quazgar 2007-08-31 13:56:17 UTC
Keeping tabs inside applications which have an internal use for tabs makes sense, at least because one would not like to start several instances of Konqueror or Firefox all with their separate memory usage.

But:

Tabbing or grouping by the window manager still has several advantages:

* For applications that don't support tabs natively.

* For grouping windows of different applications:  One might want to have a console window, some editor windows and maybe a graphical svn/cvs uiser interface grouped together.  (Ok, why not use emacs instead? ;-) )  Or different chat/IM clients together, because not every client supports all protocols equally well.  This is the main reason for why I really long for his feature to be included. 
Comment 33 Stephan Sokolow 2007-08-31 20:51:17 UTC
Agreed.
Comment 34 Richard Hartmann 2007-12-18 18:51:25 UTC
In light of the impeding KDE4 release, I am going through all bug reports I am involved in. To the best of my knowledge, this issue is still open.

From what I know about KDE4, this should finally be doable with little to no effort, no?
Comment 35 Richard Hartmann 2007-12-18 18:53:47 UTC
PS: Vote count is 1311, now
Comment 36 Mike 2007-12-18 18:58:11 UTC
+1 (well 5 ;))

Tabbed applications are a symptom of broken window managers :)
Comment 37 Stefan Monov 2007-12-19 20:53:51 UTC
@comment 34
> From what I know about KDE4, this should finally be doable with little to no effort, no?

Nope, that's wrong. It's not easier to do in KWin 4 than in KWin 3. KWin 4's major advances are compositing and Qt4, none of which is relevant.
Comment 38 Jonathan C. Dietrich 2008-01-14 20:14:34 UTC
I hope that KDE4 will continue work as well as KDE3 does with ion3 as my window manager. I would very much rather have native support for this type of interface.
Comment 39 Daniel Gonzalez Schiller 2008-04-04 03:22:11 UTC
I want this feature also!
its very praktical.
That is great on fluxbox
Comment 40 Richard Hartmann 2008-11-27 15:33:53 UTC
There is now a bounty on this: http://www.undefinedfire.com/kde/500-kwin-bounty/

If/when someone pokes this, looking at http://bugs.kde.org/show_bug.cgi?id=120595 as well might be a good idea. It is somewhat related.
Comment 41 Martin Flöser 2009-02-14 10:42:38 UTC
*** Bug 184283 has been marked as a duplicate of this bug. ***
Comment 42 lucas 2009-02-15 08:20:18 UTC
*** Bug 184327 has been marked as a duplicate of this bug. ***
Comment 43 Martin Flöser 2009-02-18 20:34:18 UTC
*** Bug 183114 has been marked as a duplicate of this bug. ***
Comment 44 James 2009-04-29 19:36:25 UTC
I'll complete this if nobody is working on it.

I've done some work on kde for Kopete and event notification so I have a subversion account, although obviously I'll submit my patches to the kde dashboard before committing.

I don't wish to receive bounty for open source work, but if you'd like to give the money to a charity of your own choice once I complete this, then that would be a very nice thing for you to do.
Comment 45 James 2009-04-29 19:59:42 UTC
Out of interest, my idea for this is to allow one to create a "container" which other windows can be dragged into.

This container could then be switched between tabbed/tiled modes.. a key would switch between windows inside this container.

It would be very useful for me.. to have a maximised container with kopete tiled to the right of konsole.. this would mimic my kind of work flow. In other situations (e.g.) kedit then a tabbed view of windows inside a container would be better.

The default kind of view would be tabbed.. so that people don't have to worry about more advanced containment schemes if all they are interested in is tabbing windows together.
Comment 46 Martin Flöser 2009-04-29 20:03:32 UTC
James thanks for the offer to work on this feature.

But I must say we have an GSoC student for this feature. So to all: it's finally happening and if everything goes well, we will have window tabbing in KDE 4.4.

See: http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044
Comment 47 James 2009-05-03 06:32:50 UTC
Hi,

Oh I didn't see that message, but I wrote an application that multiplexes windows together into tabs over the last few days.

git clone git://afterclap.com/kittens && cd kittens && make

It seems to work quite well so far.

meta+r opens a run application dialogue (no arguments supported yet)
meta+, and meta+. (below < and >) switch between tabbed windows.

Those are all re-mappable in the usual way.

If the GSoC student could add further support into KWin for this feature that would make it look much cooler. It would also be possible to work around the key bindings for changing the window/starting an application being global which is required without kwin support.

James
Comment 48 James 2009-05-03 06:36:57 UTC
Created attachment 33309 [details]
A screenshot of two kittens windows running, tabbing a bunch of stuff together

This is a screenshot of the Kde4 application container described in the above post.
Comment 49 Richard Hartmann 2009-05-03 11:19:31 UTC
As there is actual activity on this bug now, let me summarize some cross-references here. When the code is touched, it might be worth keeping those other requests in mind as they might spin off from the coding at hand.

https://bugs.kde.org/show_bug.cgi?id=120595 -- Enable grouping of windows by welding the edges together.
  For examples, see
  http://www.kde-look.org/content/show.php?content=34104
  http://www.kde-look.org/content/preview.php?preview=2&id=34104&file1=34104-1.png&file2=34104-2.png&file3=&name=Idea:+Welding+Window+Edges

https://bugs.kde.org/show_bug.cgi?id=59338 -- Window tiling (Ion-like window layout and control)
  which refers to
  https://bugs.kde.org/show_bug.cgi?id=165933 -- Tile windows vertically / horizontally
Comment 50 Mike 2009-05-03 16:14:29 UTC
If this feature is implemented would it be wise to remove all tabbing support from applications themselves?

I think it might cause a lot of confusion if there is 2 levels of tabbing.  IMHO the window manager should take care of the tabbing so that there is consistency across the entire desktop.  It should also make the application code easier more stable.  Not to mention the fact that we can group unrelated applications if the WM takes care of it.
Comment 51 pankkake 2009-05-03 16:24:02 UTC
Tabs inside applications usually have more features and would probably consume less memory.
More importantly, everyone isn't using KWin as their window manager when using KDE apps.
Comment 52 Stephan Sokolow 2009-05-03 16:32:55 UTC
Agreed. Even when I was using Fluxbox and playing around with Compiz, WM-level tabbing was only for situations where app-level tabbing didn't meet requirements.

Besides, as I remember, the kwin/compatibility Bugzilla subproduct is speicifically intended for reporting co-dependencies between KWin and KDE apps as bugs.
Comment 53 Martin Flöser 2009-05-03 16:38:51 UTC
and not KDE applications like e.g. Firefox would still use tabbing. Window tabbing is for windows. Tabs are for one application. Think of Kate: when using tabs each tab shares the same amount of settings. Without tabs but with window tabs each Kate tab would be an independent Kate session with possible different settings. It would be rather complicated to keep the different sessions in sync.
Comment 54 Mike 2009-05-03 17:02:23 UTC
None of those problems are impossible to work around with a bit of thought.  Personally I think of trying to explain to a new user the difference between window tabs and application tabs.  It would not be easy to explain the benefits and use cases of each.

D-Bus is probably your friend if you want to synchronize application settings and Firefox and non-KDE applications could still have tabs inside window tabs.  I would switch to Konqueror if it integrated better with the system.  There are many other benefits to keeping a 1-window-to-1-document-to-1-process metaphor.

Anyhow, it is obvious that the decision has been made somewhere.  I think it is a shame that KDE is artificially restricted.
Comment 55 James 2009-05-03 17:53:18 UTC
(In reply to comment #54)
> None of those problems are impossible to work around with a bit of thought. 
> Personally I think of trying to explain to a new user the difference between
> window tabs and application tabs.  It would not be easy to explain the benefits
> and use cases of each.
> 
> D-Bus is probably your friend if you want to synchronize application settings
> and Firefox and non-KDE applications could still have tabs inside window tabs. 
> I would switch to Konqueror if it integrated better with the system.  There are
> many other benefits to keeping a 1-window-to-1-document-to-1-process metaphor.
> 
> Anyhow, it is obvious that the decision has been made somewhere.  I think it is
> a shame that KDE is artificially restricted.

Both application tabs and window tabs are useful for different situations. I don't understand, how is kde artificially restricted?
Comment 56 pankkake 2009-05-03 18:02:41 UTC
One good example of such "restrictions" would be #59789
Comment 57 Mike 2009-05-03 18:49:15 UTC
(In reply to comment #55)
> Both application tabs and window tabs are useful for different situations. I
> don't understand, how is kde artificially restricted?

It depends on if you think that KDE not having consistent tabbing support is restricting it.  I could list all the benefits of having a well integrated KWin, but I do not think that is the objective.

One interesting thing to note is that this bug is from 2002, well before most applications used tabs.  I think that application tabs are a workaround for the fact that the window manager never fixed this bug.

If there were cooperation between the applications and the window manager (via EWMH) then no application developer would need to worry about tabbing support and they could add extra functionality via a standard API.

Imagine if I have a Konqueror window open with 2 tabs, then I add a Konsole window, then add another Konqueror window to my group.  Now I have a very strange system where I have 2 levels of tabbing where I really only meant to have one.  I would have to somehow promote each Konqueror tab to a window and then regroup it.  Similarly if I now create a new tab from inside Konsole I have a different interface and 2 different shortcuts for very similar metaphores.  If everything was controlled at the window level then I could have the same application shortcut for a new tab in every KDE application.
Comment 58 James 2009-05-03 19:17:29 UTC
(In reply to comment #50)
> If this feature is implemented would it be wise to remove all tabbing support
> from applications themselves?
> 
> I think it might cause a lot of confusion if there is 2 levels of tabbing. 
> IMHO the window manager should take care of the tabbing so that there is
> consistency across the entire desktop.  It should also make the application
> code easier more stable.  Not to mention the fact that we can group unrelated
> applications if the WM takes care of it.

I disagree I don't think it would be wise to remove application-level tabbing.
It is necessary for things like vim to allow you to copy text between buffers with the keys.. forcing all applications to use dbus just to pass data between tabs would be asking a lot, and many would disagree with the idea anyway.

For me I like two layers of control, I'm probably just going to tile all of my applications inside this kittens application, and then use kde keys just for tabbing between instances on each desktop, and I want the benefits and drawbacks of both application-level and window-manager level tabs when I do this.
Comment 59 Sergei Andreev 2009-05-03 19:24:46 UTC
And 12 copies of Krusader is not good too. All is in good measure.
Comment 60 Thomas Lübking 2009-05-03 19:34:55 UTC
i think it's important to clarify few things.

(1. and 2. refer to the "1-window-to-1-document-to-1-process" stuff)

1. (i think) you're (only) talking about "document type tabs" (seriously, making every config dialog that uses some tabs some processes would be idiotic at best, why? get a book about multithreaded programming and then try to extrapolate this to several processes...)

   example:
user checks checkmark, -> dbus call: is this mutex'd? -> yes: pend and recall, no: set mutex, change setting, async dbus call all related processes to update (not blocking the app itself), wait for update confirmations (policy on timing,
confirmation lack), unset mutex and update the UI visual)
   worst case:
the user clicks a checkmark and (because one of the related
process is currently a littly busy, hangs, just crashed) it lasts 5 seconds
until the mark is actually checked....

2. multiprocess tabbing can be /very/ resource (RAM) expensive - depending on the application in quest (think of IDEs, every process has to provide the whole functionality, including symbol database etc. and i won't start discussing the demanded tabbed playlists for amarok...) i.e. for many apps it would be much more then "ok, let's extend EWMH" but require a complete relayout to a multiprocess application (including designing a - secured ? - former in-process now inter-process communication, encapsulating UI sections (to avoid the example from 1.), ...

3. browser tabbing has (mostly) grown on windows "ok, maybe MDI /is/ crap" movement and (in this regard) dates back to ~2000
http://en.wikipedia.org/wiki/Tabbed_document_interface
so app side tabs are a workaround for "we lost MDI :-(" ;-P

4. WM tabbing is (from my experience) no way DAU safe. (either you play around with the 3rd MB or enter the "i just wanted to move the window and now ripped all tabs out" "how can i click-focus a window w/o changing the tab" situations)

5. however: nobody (nobody) prevents you from running e.g. an extra instanced konqueror window for each site (konsole instancing will get a little trickier, but not using single window instead tabs), you just have to do that. if then you're WM supports tabbing (or you use a collector like the mentioned kittens - that i've not tested so far) you'll have a consistent WM side tabbing NOW without taking the app side tabbing feature at all (for a certain kind of tabbed apps, and imho the only kind where it makes some sense)
Comment 61 Mike 2009-05-03 19:57:07 UTC
1. I only mean top level windows and yes I do mean a 1-1 mapping of document, (top-level) window and process.  There are lots of benefits if we can get that mapping.

As far as DBus goes, I would see it happening like this.

a) user checks checkbox.
b) settings/ui is updated as per normal.
c) dbus signal is sent out telling all listening apps (not necessarily of the same type) that their settings have changed.
d) original app does not care what other instances do with that data.  Some settings would be stored alongside the document, some global to the application.  eg. If I display a folder of pictures I want it to show me a slideshow and remember that setting only for that document (folder).

2. Maybe an IDE is an exception to the rule but I think that Amarok should be able to create separate processes if it was designed that way (obviously it isn't).  I do not know enough about the internals of Amarok to comment but Chrome seems to manage 1 process per window (tab) without much problem.  It might even increase performance if unused tabs can be swapped out in memory, only keeping the one that is being worked on.

3. MDI should have been replaced by window tabbing in 2000, I agree.  Window tabbing offers many benefits over MDI or application tabbing.

4. Google could not tell me what DAU means so the rest of the comment did not make much sense.

5. I am fairly sure that KDE applications are hardcoded to spawn a new thread if you try to launch a new process.  I know that Dolphin works like that but there is no consistency.  Having 1 process per document per window is going to require some top-down design if it is going to ever work in a coherent way.  Windows 7 sees IE tabs as individual windows when it comes to displaying the taskbar thumbnails so it is easy to select a tab within a window if the window manager has control.
Comment 62 Martin Flöser 2009-05-03 20:23:33 UTC
Google Chrome is a bad example as it's afaik the only application going for this approach. And they only do it due to security reasons.

A "DAU" btw. is the most uneducated user you can imagine. It's a common phrase in German software IT. I don't know if there is a common English phrase for it.

Btw I really think we should stick to tabs per application. It's the way joe user expects and window tabs are a power user feature for very special use cases - nothing for joe user.
Comment 63 Thomas Lübking 2009-05-03 21:40:06 UTC
(In reply to comment #61)
> 1. I only mean top level windows and yes I do mean a 1-1 mapping of document,
> (top-level) window and process.  There are lots of benefits if we can get that
> mapping.
name one that is not related to browser specifics (aka the chrome argument list)

> As far as DBus goes, I would see it happening like this.
> [stuff]
this way you'll end up with arbitrarily saved settings (best case) or a race condition (worst case)

> 2. Maybe an IDE is an exception to the rule but I think that Amarok should be
a) amaroks ram-eater are the svg's, plasma and (of course...) the database
b) chrome stacks one complete application into one tab, that's different from splitting an application into many.
c) the point about chrome is /NOT/ swapping away memory (what is a lame argument by google, btw. if i work in a browser and close a tab i likely want the next tab to show up fast, and not be reloaded from HD swap...) but to create a BowserOS (that's neither surprising nor wrong, it's just googles business) 

> 4. Google could not tell me what DAU means so the rest of the comment did not
> make much sense.
sorry, was understood by a bunch of americans (so i though "dumbest assumable user" would be an english pendent to the german phrase)
the comment however /makes/ sense and says:
titlebars are used for certain actions by Joe User and placing tabs there takes away this usage model from them -> Joe gets confused ;-)
(i mostly mentioned it because you introduced "new users" to who we shall explain things...)

> 5. I am fairly sure that KDE applications are hardcoded to spawn a new thread
> if you try to launch a new process.
some (i know of dolphin and konsole, dolphin is afaics no problem as the relevant kio jobs run in extra processes)

>  I know that Dolphin works like that but
> there is no consistency.  Having 1 process per document per window is going to
> require some top-down design if it is going to ever work in a coherent way.
 
> Windows 7 sees IE tabs as individual windows when it comes to displaying the
err... afaik this is a "fake", i.e. there's some special protocol between the taskbar and IE8, but they're not individual processes


> taskbar thumbnails so it is easy to select a tab within a window if the window
> manager has control.
and if you place a konsole, dolphin and 2 konqueror tabs into one stack, which icon (to stay with Vista 1.1) will represent that window for easy selection from the taskbar (a "broken by design" concept anyway...)
Comment 64 Mike 2009-05-04 01:16:14 UTC
(In reply to comment #62)
> Google Chrome is a bad example as it's afaik the only application going for
> this approach. And they only do it due to security reasons.

Well, IE8 uses it as well, there are many pros and cons to per process or threaded.  I think they feel that performance cons are not so bad these days, dbus makes the communication problem easier.  I thought the main reason was that if one window crashes the rest do not go down.  I cannot count the times that Firefox or Dolphin have crashed and took down all of their windows.  I expect Konqueror is the same.

> 
> Btw I really think we should stick to tabs per application. It's the way joe
> user expects and window tabs are a power user feature for very special use
> cases - nothing for joe user.

There is no consistency at all, that is my main problem.  For example, some applications give you a right-click menu to close a tab, some don't.  If this window tabbing gave me a right click menu to close the tab then I would have different but semantically the same behaviour.  Instead I could have all that functionality in window tabs and not need application tabs.

Different applications have tabs in different places.  Kate has a kind-of-tab which is a document list.  I think that the Kate use of 'tabs' is fitting with 1 window to 1 document because you can abstract document to be a project file which may contain lots of files and resources.

I think that this sort of feature could be very useful to Joe User because it allows him to group documents and tools without thinking about it.  If the UI was right.
Comment 65 Mike 2009-05-04 01:37:56 UTC
(In reply to comment #63)
> (In reply to comment #61)
> > 1. I only mean top level windows and yes I do mean a 1-1 mapping of document,
> > (top-level) window and process.  There are lots of benefits if we can get that
> > mapping.
> name one that is not related to browser specifics (aka the chrome argument
> list)
Kate maintains a 1 window to 1 document metaphor.  They use threads for that but allow multiple processes.
> 
> > As far as DBus goes, I would see it happening like this.
> > [stuff]
> this way you'll end up with arbitrarily saved settings (best case) or a race
> condition (worst case)
An application would only save settings when it has to so I am not sure why the settings would be arbitrarily saved, there would only be a race condition if 2 processes try to modify the same setting at the same time but I thought the settings system should already cope with that, Kate can already run in different processes so it needs the mutex anyway.
> 
> > 2. Maybe an IDE is an exception to the rule but I think that Amarok should be
> a) amaroks ram-eater are the svg's, plasma and (of course...) the database
> b) chrome stacks one complete application into one tab, that's different from
> splitting an application into many.
> c) the point about chrome is /NOT/ swapping away memory (what is a lame
> argument by google, btw. if i work in a browser and close a tab i likely want
> the next tab to show up fast, and not be reloaded from HD swap...) but to
> create a BowserOS (that's neither surprising nor wrong, it's just googles
> business) 
If Chrome were written for Linux today they could save a lot of code and effort if window tabs were already supported well.  They only use (and break) the Windows title bar because Windows does not support window tabbing.

> 
> > 4. Google could not tell me what DAU means so the rest of the comment did not
> > make much sense.
> sorry, was understood by a bunch of americans (so i though "dumbest assumable
> user" would be an english pendent to the german phrase)
> the comment however /makes/ sense and says:
> titlebars are used for certain actions by Joe User and placing tabs there takes
> away this usage model from them -> Joe gets confused ;-)
> (i mostly mentioned it because you introduced "new users" to who we shall
> explain things...)
Nobody mentioned touching the titlebars at all.  Window tabbing can take place inside the frame.
> 
> > 5. I am fairly sure that KDE applications are hardcoded to spawn a new thread
> > if you try to launch a new process.
> some (i know of dolphin and konsole, dolphin is afaics no problem as the
> relevant kio jobs run in extra processes)
> 
> >  I know that Dolphin works like that but
> > there is no consistency.  Having 1 process per document per window is going to
> > require some top-down design if it is going to ever work in a coherent way.
> 
> > Windows 7 sees IE tabs as individual windows when it comes to displaying the
> err... afaik this is a "fake", i.e. there's some special protocol between the
> taskbar and IE8, but they're not individual processes
The taskbar is of course faked, but it would be nice if we could implement it for real.  IE8 does use 1 process per tab, but it stops at 3 and then starts using threads.

> 
> 
> > taskbar thumbnails so it is easy to select a tab within a window if the window
> > manager has control.
> and if you place a konsole, dolphin and 2 konqueror tabs into one stack, which
> icon (to stay with Vista 1.1) will represent that window for easy selection
> from the taskbar (a "broken by design" concept anyway...)
I suppose whichever window is active in the group.  You are going to have that problem either way though.

If each tab had it's own window and taskbar thumbnail then you could select a tab without selecting the window first.
Comment 66 Stephan Sokolow 2009-05-04 03:45:02 UTC
Keep in mind that some people (myself included), prefer to have one taskbar entry per window and only one taskbar entry for each internally-tabbed window.

(eg. I generally have one to three dozen tabs active in each browser window and one or two browser windows... plus 6 to 12 Kate or gVim tabs and I'd find the taskbar next to useless if it got cluttered up by offering non-optional direct access to tabs as well as windows)

Feel free to offer whatever you want, but don't take away what I like in the process and don't deprive me of the future potential for a Chrome-style non-taskbar-cluttering, resilient, internally-tabbed, crash-resistant browser.
Comment 67 James 2009-05-04 04:59:02 UTC
(In reply to comment #66)
> Keep in mind that some people (myself included), prefer to have one taskbar
> entry per window and only one taskbar entry for each internally-tabbed window.
> 
> (eg. I generally have one to three dozen tabs active in each browser window and
> one or two browser windows... plus 6 to 12 Kate or gVim tabs and I'd find the
> taskbar next to useless if it got cluttered up by offering non-optional direct
> access to tabs as well as windows)
> 
> Feel free to offer whatever you want, but don't take away what I like in the
> process and don't deprive me of the future potential for a Chrome-style
> non-taskbar-cluttering, resilient, internally-tabbed, crash-resistant browser.

Using kittens under KDE only displays a task bar entry for kittens, and kittens shows entries itself for the underlying applications.
Comment 68 Stephan Sokolow 2009-05-04 06:45:50 UTC
Kittens is interesting, but you shouldn't be so eager to advertise it... especially to me. I'm VERY sensitive to UI design rough edges.

For example, despite enjoying the concepts, I can't stand neither kittens nor things like awesome/xmonad. Kittens doesn't let me keep my usual work flow but add tabbing (eg. launching via icons on the panel, merging windows that already exist) and things like awesome and XMonad are little more than GNU screen for X11. (Minimal support for floating windows, ugly appearance, and configuration is only one step removed from hacking raw C code) Hence, they're all more trouble than they're worth.

As I've mentioned to various people, if I weren't near-fanatical about using as little closed-source software as possible, I'd probably be using a mac.
Comment 69 James 2009-05-04 07:10:27 UTC
> things like awesome and XMonad are little more than GNU screen for
> X11. (Minimal support for floating windows, ugly appearance, and 
> configuration is only one step removed from hacking raw C code) 
> Hence, they're all more trouble than they're worth

I already realise that many people feel like that, but there are a large number of users of window managers like awesome and xmonad, so obviously many others including me appreciate this kind of window layout model. I don't think you should be so eager to dismiss them.

> Kittens is interesting, but you shouldn't be so eager to advertise it...
> especially to me. I'm VERY sensitive to UI design rough edges.

I don't know what you mean by "rough edges". It implements features that a lot of people want, and it works well. Users don't care about whatever you might mean by rough edges, and they don't care about software ideologies, they just want applications that works well.

I'm mentioning it in some bugs it applies to as it implements features that were marked as missing in those bugs, even if it is in application form and not at the kwin layer, for most users it will implement the requested features.
Comment 70 Stephan Sokolow 2009-05-04 10:25:51 UTC
Mentioning it once was fine. Mentioning it again came across as "eager".

As for awesome/xmonad and kittens, I never said I didn't want the features... I just said that I'm extremely picky. For example, there's nothing I'd like more than having the ability to tile windows and weld their edges together... I just don't want to give up all the Kwin features I use to get that ability and I can't stand the thought of having to build a config by editing raw Lua or Haskell code.
Comment 71 Richard Hartmann 2009-05-04 12:38:02 UTC
_Strong_ vote against taking away in-application tabs for most of the reasons mentioned above.

And yes, I can see myself using a window-manager-tabbed Konsole with several application-level-tabs each. Matter of fact, that would align very well with how I work.
Comment 72 Helge Hielscher 2009-05-04 14:09:50 UTC
IMHO it should be the other way round. There should be a tabbing framework integrated with the window-manager that applications can make use of, but do not have to (e.g. non KDE applications).
Comment 73 Mike 2009-05-04 15:37:03 UTC
(In reply to comment #69)
> I don't know what you mean by "rough edges". It implements features that a lot
> of people want, and it works well. Users don't care about whatever you might
> mean by rough edges, and they don't care about software ideologies, they just
> want applications that works well.

Rough edges are where an application makes you think just to use it.  A rough edge is where there is a jarring change in your flow.  A rough edge is where you look at the user interface and your brain physically reacts to it's fugliness.  The opposite would be where you see a UI and know instinctively what to do and the look makes you feel good about using that software.  The iPhone is a good example of how a good UI can make or break software.  They do not have half of the features of the competitors but the UI is so easy to use that people prefer it.

Personally I am VERY interested in polishing and removing rough edges.  To me tabs within tabs and multiple ways to have the same functionality are rough edges.

Is anyone in charge of the UI or is it just a free-for-all for the developers?  I really think that this feature needs to be well planned before just implementing anything which happens to match a one line feature request.
Comment 74 James 2009-05-04 16:15:52 UTC
> Rough edges are where an application makes you think just to use it.  A rough
> edge is where there is a jarring change in your flow.  A rough edge is where
> you look at the user interface and your brain physically reacts to it's
> fugliness.  The opposite would be where you see a UI and know instinctively
> what to do and the look makes you feel good about using that software.  The
> iPhone is a good example of how a good UI can make or break software.  They do
> not have half of the features of the competitors but the UI is so easy to use
> that people prefer it.

I like the alliteration it makes it look like you're writing a poem. What you call rough-edges, power-users call must have features. Personally I don't care that most people would find vim a nightmare to use, for us vim-users no widgets and a million short-cuts is a good thing. I don't identify with the opinions of those who want to keep everything so simple as it excludes power-users... this is why I stopped using Gnome many years ago.

> Is anyone in charge of the UI or is it just a free-for-all for the developers? 
> I really think that this feature needs to be well planned before just
> implementing anything which happens to match a one line feature request.

What features are you talking about that aren't being well planned? I'm not really sure what you're referring to with this, much of KDE grows quite organically based on feature requests, the hope is just that us KDE developers will write the code well enough that it will be easy to add new features or change things as the community responds to new features.
Comment 75 Jorge Mata 2009-05-04 16:26:20 UTC
(In reply to comment #73)
> Is anyone in charge of the UI or is it just a free-for-all for the developers? 
> I really think that this feature needs to be well planned before just
> implementing anything which happens to match a one line feature request.

Hi
I'll implement this feature as part of the GSoC, see:

http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044
Comment 76 Mike 2009-05-04 17:53:51 UTC
(In reply to comment #75)
> (In reply to comment #73)
> > Is anyone in charge of the UI or is it just a free-for-all for the developers? 
> > I really think that this feature needs to be well planned before just
> > implementing anything which happens to match a one line feature request.
> 
> Hi
> I'll implement this feature as part of the GSoC, see:
> 
> http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044

Hi Jorge, thank you for implementing this feature.  Please do not take this the wrong way but I do not think enough design has gone into this feature.

The SOC page does not clearly identify how the UI will work, it just gives a few vague possibilities of how it could work (I really hope that they will not all be included with an option).  Should the window tabs be a split taskbar, a tab on top or a tab just inside?  Personally I think tab inside the frame is best.  Chrome/Safari went with a split taskbar which I think is a horrible UI, dragging a window with lots of tabs will be next to impossible.  Tabs on top would mean that closing the entire group would need an extra frame or some other method to close them all.

The part of the SOC proposal which says "This feature would eliminate the need to implement this feature for single applications which will save a lot of work others that want to add tabs to their applications" seems to go against what most of the users here think.  They seem to assume that window tabs and application tabs will live alongside each other and that app developers will still have to worry about tabbing.

There are many gotchas that you will experience which can make or break this feature.  For example, off the top of my head, if you have 3-4 windows tabbed together with unsaved documents and you close the whole group, every application will pop up it's confirmation dialog at the same time.  The user will be left chasing modal popups.  The UI for creating and managing window groups will be crucial to it's usability.
Comment 77 Richard Hartmann 2009-05-04 18:10:28 UTC
It eliminates the need for, but it does not force people to stop from, using internal tabs.

Personally, I would prefer outside tabs as it gives a clear distinction and i alt-click to resize/reposition, anway. Maybe this _should_ be an option :)
Comment 78 Richard Hartmann 2009-05-04 18:11:37 UTC
Erm, I hope the mangled sentence does not stop people from getting what I mean ;)
Comment 79 Mike 2009-05-04 18:25:32 UTC
(In reply to comment #77)
> It eliminates the need for, but it does not force people to stop from, using
> internal tabs.
No, you are right.  I think that KDE-apps should have some sort of defined user interface guidelines which should discourage application tabs.  Document lists like in Kate are fine because they do not use the same user interface element.

Having 1 window per document allows taskbars to see inside tabs which they cannot do with the current way.  Having window and application tabs will make this feature very arbitrary.

This is exactly what I meant by developer free-for-all.  There does not seem to be an overall UI design or goal.
> 
> Personally, I would prefer outside tabs as it gives a clear distinction and i
> alt-click to resize/reposition, anway. Maybe this _should_ be an option :)

As I said, that prevents you from closing the entire group (without an esoteric key shortcut).  Also tablets do not have an alt-mouse combination so you can only move with the taskbar.  On these devices a move would lead to inadvertent window closing, maximisation etc.  Therefore this could not be a default and adding an option for everything just leads to code bloat and option overload, we did that with KDE3, can't we try something else?
Comment 80 Thomas Lübking 2009-05-04 18:29:42 UTC
(In reply to comment #65)
> An application would only save settings when it has to so I am not sure why the
> settings would be arbitrarily saved, 
if (as you suggested) processes can (due to communication errors/latencies) ignore each other w/o respond you can not ensure which process will save what data when - that's arbitrary

> there would only be a race condition if 2 processes try to modify the same setting at the same time but I thought the settings system should already cope with that
this is /not/ only about settings, ok? race conditions could occur everywhere where processes try to act on the same data. the point is:
you want an application to run in multiple threads or even processes? you'll need a mutex system and therefore a safe comm layer. period.

> If Chrome were written for Linux today they could save a lot of code and effort
> if window tabs were already supported well.
To place the tabbar into the window title? Sorry but the UI part of this is no job on a usable toolkit (given you've control on window + titlebar like it's on the explorer shell - and mfc cannot be /that/ bad, well.. maybe a little ;-)

> Nobody mentioned touching the titlebars at all.  Window tabbing can take place
> inside the frame.
*box, chrome, safari... but yes, i assume the tabs can be placed below the titlebar as well (maybe looking different from the rest of the window content - of course...)

> I suppose whichever window is active in the group.  You are going to have that
> problem either way though.
the point is: window tabbing has no (no!) advance on taskbars (no problem either - i don't like taskbars ;-)
 
> If each tab had it's own window and taskbar thumbnail then you could select a
> tab without selecting the window first.
yeah, after mangling through the taskbar stack (if any) as you'll have more open tabs then...


(In reply to comment #64)
as you mentioned kate:
it /does/ keep many (single) documents in one process - as long as you don't abstract to the "project/session" documents - that can be easily broken by opening additional files...
so do you mean: if konqueror (which provides profiles as well) would use a listview instead tabs, you'd be happy? (being confused)

and you /can/ run konqueror in multiple instances (it's just that the appmenu entry calls kfmclient which will by default not create a new instance - just calling "konqueror" however will)
Comment 81 Richard Hartmann 2009-05-04 18:47:22 UTC
(In reply to comment #79)
>No, you are right.  I think that KDE-apps should have some sort of defined user
>interface guidelines which should discourage application tabs.  Document lists
>like in Kate are fine because they do not use the same user interface element.

_Discouraging_ application-level tabs is OK. _Forbidding_ them is not. For example, Konqui & Konsole _need_ them.


> Having 1 window per document allows taskbars to see inside tabs which they
> cannot do with the current way.  Having window and application tabs will make
> this feature very arbitrary.

That would be the user's choice. They open the internal tabs, after all.
And it would be possible to define a clean way to access this information.


> This is exactly what I meant by developer free-for-all.  There does not seem to
> be an overall UI design or goal.

I see this within the scope of the SoC project. Getting feedback from the dev list on the design is a must, anyway.

> As I said, that prevents you from closing the entire group (without an esoteric
> key shortcut).  Also tablets do not have an alt-mouse combination so you can
> only move with the taskbar.  On these devices a move would lead to inadvertent
> window closing, maximisation etc.  Therefore this could not be a default and
> adding an option for everything just leads to code bloat and option overload,
> we did that with KDE3, can't we try something else?

shift-ctrl-q sounds fine to me :)
I agree that it should default to tabs within the decoration, but I do not see how offering the decoration to do this leads to much bloat.
Comment 82 Mike 2009-05-04 18:57:36 UTC
(In reply to comment #81)
> Getting feedback from the dev
> list on the design is a must, anyway.

That explains the problem in one sentence.  Why would developers be good at UI design?
Comment 83 Jorge Mata 2009-05-04 20:12:02 UTC
(In reply to comment #76)
> 
> The SOC page does not clearly identify how the UI will work, it just gives a
> few vague possibilities of how it could work (I really hope that they will not
> all be included with an option).  Should the window tabs be a split taskbar, a
> tab on top or a tab just inside?  Personally I think tab inside the frame is
> best.  Chrome/Safari went with a split taskbar which I think is a horrible UI,
> dragging a window with lots of tabs will be next to impossible.  Tabs on top
> would mean that closing the entire group would need an extra frame or some
> other method to close them all.
> 

I have more info about my proposal at http://www.jmata.co.cc/index.php?kdeapp=1 the way I was thinking is that the decoration will display the tabbed windows, so it will depend on the the decoration if it is inside or outside the frame.

> The part of the SOC proposal which says "This feature would eliminate the need
> to implement this feature for single applications which will save a lot of work
> others that want to add tabs to their applications" seems to go against what
> most of the users here think.  They seem to assume that window tabs and
> application tabs will live alongside each other and that app developers will
> still have to worry about tabbing.
> 

the applications can still have their internal windows, it will depend on the applications want kind of tabs they want or both.

> There are many gotchas that you will experience which can make or break this
> feature.  For example, off the top of my head, if you have 3-4 windows tabbed
> together with unsaved documents and you close the whole group, every
> application will pop up it's confirmation dialog at the same time.  The user
> will be left chasing modal popups.  The UI for creating and managing window
> groups will be crucial to it's usability.

I still need to think more on what kind of problems this feature will bring.
Comment 84 Maciej Pilichowski 2009-05-04 21:56:30 UTC
:-) Funny when it appears there are several groups thinking/discussing things not knowing about each other. Nested Windows Interface concept:
http://techbase.kde.org/Projects/Usability/NWI
Comment 85 Stephan Sokolow 2009-05-04 22:56:44 UTC
Keep in mind that not everyone defines rough edges as strictly as Mike. I'm in favor of keeping application-level tabbing.

Also, if an application is going to prefer Kwin's tabbing, it'll have to at least be optional. As I mentioned before, KDE apps are often used with other WMs and there's a specific bug category for reporting co-dependency between kwin and KDE apps.

I'd recommend having WM-level vs. application-level a user-selectable preference, but it's been my experience that doing so will lead to an irritating number of bugs in the application-level mode because non-default settings tend to get less testing than they should. (Perhaps a LDTP test suite?)
Comment 86 James 2009-05-05 01:20:51 UTC
> I have more info about my proposal at http://www.jmata.co.cc/index.php?kdeapp=1
> the way I was thinking is that the decoration will display the tabbed windows,
> so it will depend on the the decoration if it is inside or outside the frame.

What's missing from the proposal for me is the ability to display 2+ windows from the "tab group" inside the same window at the same time e.g. tab splitting idea from screen/vim.

For me it would be great to tab man windows together into one window manager window.. but to be able to views these tabbed applications in more than just a tabbed view is essential.

> the applications can still have their internal windows, it will depend on the
> applications want kind of tabs they want or both.

This is good!
Comment 87 Richard Hartmann 2009-05-05 10:21:44 UTC
(In reply to comment #82)

> That explains the problem in one sentence.  Why would developers be good at UI
> design?

Why would they need to be? There are several UI-savvy people within or around KDE and those can be asked, as well. In this case, I was speaking about code design, not UI design, though.
Comment 88 Richard Hartmann 2009-05-05 10:28:09 UTC
(In reply to comment #86)

> What's missing from the proposal for me is the ability to display 2+ windows
> from the "tab group" inside the same window at the same time e.g. tab splitting
> idea from screen/vim.

Hmm, good point. It would be awesome to have one merged window of Konsole with Vim & Okular for editing LaTeX/PDF. And yes, I know that I could do the same with virtual desktops, but I don't like them :p
Comment 89 James 2009-05-05 14:53:14 UTC
> (In reply to comment #86)
> Hmm, good point. It would be awesome to have one merged window of Konsole with
> Vim & Okular for editing LaTeX/PDF. And yes, I know that I could do the same
> with virtual desktops, but I don't like them :p

Plus with a virtual desktop if I have Konsole to the left of Okular, if I resize the middle edge konsole will overlap okular or vice-versa, when in a contained layout the resize handle would resize both applications.
Comment 90 Brand 2009-06-17 08:37:20 UTC
Doesn't Compiz have this? This would be a great feature.
Comment 91 deltas4 2009-07-17 17:02:24 UTC
Adobe is also implementing the file menu and other application-specific buttons on the title bar in CS4 applications. Since space is very important and more and more apps are making some use of the title bar space I believe it would be a really nice feature to improve KDE.

I'm not a developer but to create an application like this I guess you would have to create a specific "window manager" for the application in question. If the toolkit used to create the app had its own way of adding buttons/bars it would really be a step forward.

This would facilitate both new developers and KDE developers, applications like Konqueror and Konsole wouldn't need to have their own tab system and we would save a lot of space.
Comment 92 FiNeX 2009-08-16 15:22:57 UTC
Some days ago I've seen a screenshot (maybe on planet.kde.org ???) with tabs on kwin. Not bad :-)
Comment 93 lucas 2009-11-15 04:24:08 UTC
SVN commit 1049334 by lmurray:

Merged r970865:1049322 from /branches/work/kwin-tabbing
Adds window tabbing support to KWin.
FEATURE: 42023


 M  +1 -0      CMakeLists.txt  
 M  +7 -0      activation.cpp  
 M  +60 -0     bridge.cpp  
 M  +14 -0     bridge.h  
 M  +63 -3     client.cpp  
 M  +32 -1     client.h  
 A             clientgroup.cpp   [License: GPL (v2+)]
 A             clientgroup.h   [License: GPL (v2+)]
 M  +1 -0      clients/CMakeLists.txt  
 M  +1 -0      clients/oxygen/CMakeLists.txt  
 M  +2 -0      clients/oxygen/config/config.cpp  
 M  +1 -0      clients/oxygen/config/oxygenconfigurationui.cpp  
 M  +8 -1      clients/oxygen/config/oxygenconfigurationui.ui  
 M  +5 -6      clients/oxygen/oxygen.cpp  
 M  +1 -11     clients/oxygen/oxygen.h  
 M  +10 -4     clients/oxygen/oxygenbutton.cpp  
 M  +3 -4      clients/oxygen/oxygenbutton.h  
 M  +722 -55   clients/oxygen/oxygenclient.cpp  
 M  +96 -11    clients/oxygen/oxygenclient.h  
 A             clients/oxygen/oxygenclientgroupitemdata.cpp   [License: BSD X11 (BSD like)]
 A             clients/oxygen/oxygenclientgroupitemdata.h   [License: BSD X11 (BSD like)]
 M  +10 -0     clients/oxygen/oxygenconfiguration.cpp  
 M  +12 -0     clients/oxygen/oxygenconfiguration.h  
 M  +1 -3      clients/oxygen/oxygenshadowcache.cpp  
 M  +0 -5      clients/oxygen/oxygensizegrip.cpp  
 A             clients/tabstrip (directory)  
 A             clients/tabstrip/CMakeLists.txt  
 A             clients/tabstrip/config (directory)  
 A             clients/tabstrip/config/CMakeLists.txt  
 A             clients/tabstrip/config/tabstripconfig.cpp   [License: GPL (v2+)]
 A             clients/tabstrip/config/tabstripconfig.h   [License: GPL (v2+)]
 A             clients/tabstrip/config/tabstripconfig.ui  
 A             clients/tabstrip/tabstrip.desktop  
 A             clients/tabstrip/tabstripbutton.cpp   [License: GPL (v2+)]
 A             clients/tabstrip/tabstripbutton.h   [License: GPL (v2+)]
 A             clients/tabstrip/tabstripdecoration.cpp   [License: GPL (v2+)]
 A             clients/tabstrip/tabstripdecoration.h   [License: GPL (v2+)]
 A             clients/tabstrip/tabstripfactory.cpp   [License: GPL (v2+)]
 A             clients/tabstrip/tabstripfactory.h   [License: GPL (v2+)]
 M  +25 -0     effects.cpp  
 M  +5 -0      effects.h  
 A             effects/_test/slidetabs (directory)  
 A             effects/_test/slidetabs/CMakeLists.txt  
 A             effects/_test/slidetabs/slidetabs.cpp   [License: GPL (v2+)]
 A             effects/_test/slidetabs/slidetabs.desktop  
 A             effects/_test/slidetabs/slidetabs.h   [License: GPL (v2+)]
 A             effects/_test/slidetabs/slidetabs_config.cpp   [License: GPL (v2+)]
 A             effects/_test/slidetabs/slidetabs_config.desktop  
 A             effects/_test/slidetabs/slidetabs_config.h   [License: GPL (v2+)]
 A             effects/_test/slidetabs/slidetabs_config.ui  
 A             effects/_test/swiveltabs (directory)  
 A             effects/_test/swiveltabs/CMakeLists.txt  
 A             effects/_test/swiveltabs/swiveltabs.cpp   [License: GPL (v2+)]
 A             effects/_test/swiveltabs/swiveltabs.desktop  
 A             effects/_test/swiveltabs/swiveltabs.h   [License: GPL (v2+)]
 A             effects/_test/swiveltabs/swiveltabs_config.cpp   [License: GPL (v2+)]
 A             effects/_test/swiveltabs/swiveltabs_config.desktop  
 A             effects/_test/swiveltabs/swiveltabs_config.h   [License: GPL (v2+)]
 A             effects/_test/swiveltabs/swiveltabs_config.ui  
 M  +2 -0      effects/presentwindows/presentwindows.cpp  
 M  +20 -1     effects/slideback/slideback.cpp  
 M  +3 -0      effects/slideback/slideback.h  
 M  +2 -0      events.cpp  
 M  +21 -5     geometry.cpp  
 M  +52 -0     kcmkwin/kwindecoration/preview.cpp  
 M  +14 -0     kcmkwin/kwindecoration/preview.h  
 M  +3 -0      kwinbindings.cpp  
 M  +8 -0      layers.cpp  
 M  +62 -0     lib/kcommondecoration.cpp  
 M  +18 -1     lib/kcommondecoration.h  
 M  +86 -23    lib/kdecoration.cpp  
 M  +96 -1     lib/kdecoration.h  
 M  +13 -0     lib/kdecorationbridge.h  
 M  +12 -0     lib/kwineffects.cpp  
 M  +6 -1      lib/kwineffects.h  
 M  +20 -0     manage.cpp  
 M  +13 -0     sm.cpp  
 M  +5 -0      sm.h  
 M  +9 -0      tabbox.cpp  
 M  +222 -0    useractions.cpp  
 M  +22 -0     workspace.cpp  
 M  +44 -0     workspace.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1049334