Thanks for the suggestion. While I agree that saving screen space is good, implementing this would be an enormous amount of work. If there was a general solution for Qt/KDE apps, we could consider using it, but a custom 'tabs in title bar' implementation in Dolphin is definitely not going to happen.

I believed that most of the work was already done. .. With the ability to add multiple windows together (moving the title bar with the middle mouse button). Oops, it only works with Oxygen.  :S (maybe need an interpreter to other themes that be operational).
.. I thought it was a feature of the system.
In any case, "you just" copy or take inspiration from the browser!
I can hardly believe that there is any university student or group available to add to your thesis a worthwhile project for the whole community! ?

(In reply to comment #2)
> I believed that most of the work was already done. .. With the ability to
> add multiple windows together (moving the title bar with the middle mouse
> button). Oops, it only works with Oxygen.  :S (maybe need an interpreter to
> other themes that be operational).

You might have noticed that this feature works with any group of windows and does not interact at all with the different applications. Making it cooperate somehow with Dolphin's internal representation of tabs is far from trivial.

> In any case, "you just" copy or take inspiration from the browser!

You might know one of the browsers you quoted is not free software, and the other one does not use Qt, so it's basically impossible to "just copy" anything from them.

The program mentioned non-free makes the tabs too small as some taskbar buttons that transform into strips unusable (many windows / programs open). Even in that case has already been copied to the preview function. Or the opposite has occurred?
Instead, I believe it is just laziness or lack of imagination.
For example, it is a life that I look forward to the rapid drag & drop from the open windows to the application buttons reduced to icons in the taskbar.
This concept is substantially analogous.
Are not very different from the Dolphin cards (they only need a communications port that already exists in the white space of the window, is not it?).
Only the location is different: in the title bar instead of the taskbar.

Maybe you could help Martin Gräßlin to extend our window tabbing that KWin provides a hook for applications to add custom buttons such as "New Tab" and context menu entries, so we could finally use that window tabbing as replacement for tabs in applications like Dolphin or Rekonq. And this suggestion isn't less utopian than yours,

1. of all: dolphin could never rely on the WM providing this, there's no tabbing standard. The extension oxygen uses is atm tagged "unstable" what will not change before 4.11 - thus implementing it in a 3rd party deco will cause ABI breaks (thus the ABI versiin export)

2nd: you can cause any kind of new window to be autotabbed with others of it's kind (where "kind" refers to either app type or user set id)

3rd: i'm not aware about internal tabbing features of dolphin, but whatever specifics there are, will require a new client message protocol (meaning extension to kdelibs, not gonna happen in 4.x cycle, or X11 code in dolphin) - and by that ideally an update of the NETWM extension

4th: at least opera 12 has "tabs in titlebar" by using its own "titlebar" what kills _all_ WM titlebar features (look, button pos, click behavior, some FX)

since you seem to believe that this is trivial, about lazyness and a students task, we make a deal:
i guide you through that (but no GSoC!) including specifying a client protocol, implementation for KWindowSystem and inside kwin etc. so it'll be available for the next major KDE version ("notfive")
but by guide i mean "pointing you to the proper X11 headers" (there's hardly an API doc to read) and review your code (pointing mistakes) and spec attempts.
When done, you shall honestly reconsider your assumptions.
Deal?

@Thomas: I hadn't meant to be rude but was talking to the reporter of this bug that if something like that should happen, he needs to make KWin support that :)

@Kai, Thomas: thanks for your comments! @Kai: there was at most one person being rude here, and this person was certainly not you.

(In reply to comment #4)
@Francesco: please note that KDE has something called 'Code of Conduct':

http://www.kde.org/code-of-conduct/

Some of the statements are "Be considerate", "Be respectful" and "Be pragmatic". I tried to follow those when responding to your recent feature requests. Even though I had trouble to understand what you mean sometimes, and I do see problems with some of your ideas, I spent quite a bit of time reading your reports and comments and spent even more time explaining why the idea you posted here is not going to be implemented. All this even though it was pretty clear from the start that the entire discussion would not help at all to improve Dolphin.

> Instead, I believe it is just laziness or lack of imagination.

This statement is a clear violation of almost every single word of the Code of Conduct.

I refuse to discuss any feature requests with you in the near future, I really have more important and more rewarding things to work on. You are welcome to propose new features at KDE Brainstorm:

http://forum.kde.org/viewforum.php?f=83

This is a more suitable place for the discussion of ideas how KDE applications could be improved.

Thanks for your understanding.

@Kai
I wasn't talking to you =)
(bugzilla needs threading...)

If you want to add such protocol yourself, please notice that tabbing in-process windows across the WM does hardly more than wasting resources (since the WM cannot free and load them on demand - unless the protocol specifies that ;-)

To spare vertical space for a distinct client it would be much simpler to have the tabs in the client and hint that to the WM (so that the WM can shape away required button space and does not extend the client)

With the input window (reasonably supported in 4.10) it should also be possible to write decorations that hover into the client when you reach the top border area.

This saddens me a lot, maybe I'm illusion to converse with those who want to use and exploit the graphical interface, I admit that the command line is powerful and one can not help but (and I would have ideas about) but this leads to the inevitable accurate knowledge of the system. The graphical interface instead, by contrast, must be intuitive and accessible to anyone with sense of observation to.
As I have written elsewhere: "I'm depressed and excited at the same time, there is much to do and fix, but no one listen. "
But here you can not have a conversation, and for now I close because I'm really tired (for the time I checked on multiple distributions and multiple versions of what I want to explain).

@Thomas:
My programming skills have opened and closed with simple courses analyst / programmer, and I programmed in qbasic on pc286 (although the dream was Amiga), the simple "Warehouse Management" (with adaptive graphical menu text) and "Hanoi towers" with less possible movements without limitation disks (all while attending the last school year). All the rest is pure fantasy.

@Frank:
- (I realize that my English is terrible, so I help with google, but it is not good!)
Free will is not denied to anyone, but it was not my intention to inflame, but rather, "reactivate a positive and inspiring atmosphere." I myself I'm "investing" a lot of time and patience, but I think the ultimate goal (get a system that works for the user and not vice versa) is a good thing to avoid anger and curses. The intent is to make the computer pleasant and useful.
The things I write are not "inventions or whims of the last minute," I am many many years that I cultivate. I'm tired of waiting, I decided to tackle the issue, at the cost of commit myself full-time, making a movie "virtual / concept" to be published on Youtube.

Current solution: You can save vertical space with some trick unintuitive and a waiver: -> Right click on the title bar -> Advanced -> Fullscreen (Alt + F3 to get back up the context menu) Ctrl + M to mute / unmute the main menu bar (it would be better and more intuitive to intercept the Alt key to display / clear the menu). The waiver is: taskbar.
- To give it more intuitive F11 key (similar to browsers etc) to mode "fullscreen", and (when possible) to extend the options in a cyclical fashion between normal / "free space" / fullscreen (with "free space" I mean the space not occupied by any other taskbar).

OT ?

- This is my fantasy: .. futuristic imagination? .. a hypothetical way of development:
Starting from the idea reported in: https://bugs.kde.org/show_bug.cgi?id=311662
1°) Implementation of an "innovative" context menu "double" (in lieu of Drag & Drop):
    a) the right side contains the classic context menu;
    b) the left side, containing the context menu of the working area of ​​the application associated with the button (found in the taskbar).
2°) Nesting taskbar: Any program (belonging to the main taskbar) may call a customizable taskbar (sub / daughter) in which to place new sessions (grandchildren) (similar to the current tabs) where:
    a) it is possible to configure the transparency (annoying if difficult to read);
    b) persistent display or hide-away, with classic slide, fade or both.
3°) The aforementioned taskbar instead of being positioned on a side of the screen can also overlap the title bar of the application and / or hide under an edge of the window in place of the edge of the screen of the point (2). (Note that the already existing toolbar Dolphin are very close to these concepts, in fact, already have some features that still expose below.)
4°) Any taskbar has the ability to:
    a) move / reorder the buttons;
    b) make multiple selections for common operations such as:
       - Assignment to a virtual desktop;
       - Provide automatic waterfall, flanked (horizontal / vertical)
       - Allocation to new sub-taskbar, etc. etc..
Similarly to what normally occurs in areas of objects.

Note: At the end of the functions / libraries to be called will always be the same, with a good chance and a bit of optimism (as required by the preamble to the Code of Conduct) you can optimize faster, and saving memory.

- If it is a mission impossible, I propose a few director for a science fiction movie, maybe I'll be luckier.

@Francesco
I will not claim to be able to read much sense in your talk, but it seems a lot as if you'd be talking about workspace concepts.
In that case you are completely OT here (filebrowser bugtracker, not related the least)
Please approach the Brainstorm section of http://forum.kde.org with your ideas and -frankly- make some illustrating sketches if you want anyone else to grasp whatever there is in your mind - i really had to force myself to read that.

FYI:
you can bind pretty much every action in the alt+f3 menu to a global shortcut.

@Frank (and everybody else risking to damage his brains by reading commt #11)

It *seems* as if his first point suggests to map the applications menubars into a second column of the taskitem contextmenus (without explaining what should happen with stacked taskitems)

Points 2-4 simply seem to talk about window tabbing, resp. having non strutting panels ("autohiding", "windows can go above / under")

Whether he requests to bind F11 (stupid idea, no single keys on preconfigured shortcuts) to the window fullscreen toggle action by default or at all (because he didn't figure that's possible) or that still points a present "solution" - i don't know, sorry.

Since the bug has been retagged invalid twice by maintainers and because of the apparent OT character of comment #11 - i'll dare to restore that state.

I concern the point 1): If the Drag&Drop among an active window and another lowered to icon (then directly on the button to it associate) has never been made by anybody in so many years there will be a motive to me stranger. To obviate to this, has proposed then, a two-tier menù, where (for example) the possibility is present to select (in the cases of dolphin) the command it glues.
The discussion is OT because it is over the single function described in the letterhead. To casua of the letter of request of great explanations.

When I have asked where it was found or where to insert a list of the desires, has been answered me to do him/it here in this way. Not to go on the suitable forum. (to me it seems that the forum is a way to discuss of fried air, and then to forget him of it) (here at least the ideas they are numbered, listed, etc).