Bug 312900 - wish: kwin option to save vertical space: merge window buttons into menu-bar
Summary: wish: kwin option to save vertical space: merge window buttons into menu-bar
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: 4.9.5
Platform: Other Linux
: NOR wishlist
Target Milestone: 4.10
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-08 18:56 UTC by Richard Neill
Modified: 2018-11-08 23:23 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Neill 2013-01-08 18:56:52 UTC
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

Actual Results:  
Currently, we are short of vertical space, but often have plenty of unused horizontal space.

Expected Results:  
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.
Comment 1 Thomas Lübking 2013-01-08 19:26:56 UTC
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)
Comment 2 Richard Neill 2013-01-09 00:08:03 UTC
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.
Comment 3 Thomas Lübking 2013-01-09 00:20:31 UTC
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)
Comment 4 Dotan Cohen 2013-01-15 06:16:47 UTC
See also these related feature requests for conserving valuable vertical screen real estate in KDE:
https://bugs.kde.org/show_bug.cgi?id=169043
https://bugs.kde.org/show_bug.cgi?id=211304
Comment 5 Ravi Arora 2013-01-15 15:32:25 UTC
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).
Comment 6 Luke 2013-01-15 21:00:56 UTC
Very similar request with mocups: https://bugs.kde.org/show_bug.cgi?id=311711
Comment 7 Davide Peressoni 2018-11-08 23:23:01 UTC
Any news?