As laptops move to increasingly wide aspect ratios (4:3 -> 16:10 -> 16:9 -> 2:1), vertical space is at a premium. It would be wonderful if Kwin could merge the Window title-bar with the first menu-bar, if there is space to do so.
For example, the top of my current Firefox windo looks like this:
where 80% of the available space is unused,
[v][^][+] Enter A Bug - Mozilla Firefox ... 80% of the space here is empty.... [-][_][X]
File Edit View History Bookmarks Tools Help ....lots and lots of space here too......
I'm proposing an option for a single combined bar:
[v][^][+] File Edit View History Bookmarks Tools Help WINDOW_TITLE_HERE [-][_][X]
with some suitable graphical hints as to which is what, and the ability to detect if there is no space.
Reproducible: Couldn't Reproduce
Currently, we are short of vertical space, but often have plenty of unused horizontal space.
Better use of space, more room for the actual application
There are currently some attempts to do this, none of which are excellent, but may serve as demonstrations.
* Google-chrome has an option to draw its own window decorations. This works, but only supports the standard min/max/close, and removes the advanced features (eg always-on-top, window-menu, etc). It also forces the title-bar to be too large (no "thin bar on laptops"). Also, it's a per-application setting, and therefore doesn't fit in with the rest of the WM.
* MS Office also does something like this (though it's really ugly).
* Openbox supports an option to "tear off" the title-bar from a window. But you can't then put it back again.
* Maximus (a gnome-panel applet for gnome-2) strips off the title-bar for all windows; the name of the window is then shown in the title-bar, only for the foreground window. It's a bit unusual, but works remarkably well for 1024x600 netbooks.
* Firefox already has a tiny-menu extension that lets the file-edit-view menu be placed as a single "Menu" next to the location bar.
KWin and stock decos support the appmenu protocol for 4.10 and CLIENTS WHICH SUPPORT IT (sorry for shouting ;-)
Other than that there's indeed the possibilty to have the deco overlap the client and cover a particular space to show icons, but it's ugly and heuristic (carries the risc to cover important area of the cliene because we know nothing about it's internals)
I know what you mean about the heuristic being ugly - though in fairness, if it's an optional extra, I'd be perfectly happy to take the decision whether to enable it or not, for my personal combination of screen-size, font-size and selection of application.
Imho, this isn't something that belongs to kwin vs client, it should be a global pref for kwin, which is affected primarily by screen-size and font-size, whether or not the client can (or will) support it. I say this because google-chrome's way of doing this is quite poor: chrome caters to what it (chrome) thinks the WM buttons should be, and fails to use the advanced features of kwin.
[erhaps mark it as an experimental optional extra, and if enough people like it, work on getting more application support?]
However, when you say "clients which support the appmenu protocol", which ones would those be? I checked a few key KDE apps (konsole/kwrite/dolphin), and can't see how it might be done.
All Qt (incl. KDE) applications, usually gnome as well and if you use ubuntu, i think canonical patched in that stuff nearly everywhere.
What is will alloow you is to move the menubar into the titlebar.
It does not support eg. moving the titlebar buttons into a toolbar or such.
If you only worry about screen estate, you'll probably also talk about maximized applications and there's a setting to hide the titlebar for maximized applications and afaik a plasmoid to control the currently active window (check kde-look/-apps for it)
See also these related feature requests for conserving valuable vertical screen real estate in KDE:
This is a feature I really wish that KDE would include. But it would require some support from applications as well. Qt/KDE applications would do fine. But for GTK/GNOME some workaround will be needed otherwise we might end up with two menus.
I prefer menu bar to stick with title bar as I am used to menus being tied to their respective windows. In fact a solution presented in Dolphin and Chromium (one button for application menu) or one title bar button for menu (in some blog I do not remember) would be nice. Mac lile menus in plasma would be overkill (IIRC a similar thing was there in KDE3).
Very similar request with mocups: https://bugs.kde.org/show_bug.cgi?id=311711