(*** 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)
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
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
*** Bug 45183 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.
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? :)
*** Bug 92659 has been marked as a duplicate of this bug. ***
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.
http://utopios.org/dev/projects/kde/mockup-images/ Some various mockup ideas, some requiring fairly complex modifications to kwin and tab classes.
I, too, would like this feature very much. It's been almost three years, but no word on this feature as of yet.
agree with #12, any plans for implementation? :)
*** Bug 56157 has been marked as a duplicate of this bug. ***
Is there happening anything on this problem?
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.)
See also: http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml
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.
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.
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"
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.
Created attachment 20758 [details] Two windows form a tab bar using the BII deco
This wish is still valid, the BII decoration is far from being a real tabs implementation.
True, but I felt it was worth pointing out -- perhaps it'll float someone's boat.
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.
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?
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
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.
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.
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."
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.
Agreed.
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?
PS: Vote count is 1311, now
+1 (well 5 ;)) Tabbed applications are a symptom of broken window managers :)
@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.
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.
I want this feature also! its very praktical. That is great on fluxbox
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.
*** Bug 184283 has been marked as a duplicate of this bug. ***
*** Bug 184327 has been marked as a duplicate of this bug. ***
*** Bug 183114 has been marked as a duplicate of this bug. ***
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.
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.
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
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
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.
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
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.
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.
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.
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.
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.
(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?
One good example of such "restrictions" would be #59789
(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.
(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.
And 12 copies of Krusader is not good too. All is in good measure.
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)
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.
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.
(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...)
(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.
(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.
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.
(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.
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.
> 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.
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.
_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.
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).
(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.
> 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.
(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
(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.
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 :)
Erm, I hope the mangled sentence does not stop people from getting what I mean ;)
(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?
(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)
(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.
(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?
(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.
:-) 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
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?)
> 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!
(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.
(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
> (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.
Doesn't Compiz have this? This would be a great feature.
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.
Some days ago I've seen a screenshot (maybe on planet.kde.org ???) with tabs on kwin. Not bad :-)
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