Martin, should in theory be possible through KDecoration and what not? (Granted, will be a lot of work, hence the "in theory"). Usability, what do you think?

Created attachment 103836 [details]
attachment-12460-0.html

In theory possible.

Just for reference, I found an old post where it actually worked under kde 4
https://forum.kde.org/viewtopic.php?f=88&t=120180

It would be great to see this added.

Having an option for this would be trully awesome.

Not sure if this is helpful, but something like a locally integrated menu (LIM) was possible (for an earlier version of KDE) via the extension described here:

https://store.kde.org/content/show.php/Titlebar+menu?content=138804

Would love to see this working in a current and future versions of Plasma!

Disclaimer:  I never tried the "Titlebar menu" extension, so I can't vouch for how well it worked.

I don't think that'll work since it's still Qt4-based, and also I don't think that just overlaying a window there is the right approach. The right way would be to extend KDecoration to allow the decoration to paint the menu.

I didn't mean to suggest that the "Titlebar menu" extension would work (without modification) with Plasma.  Rather, I linked to it in hopes that it may   possibly serve as a starting point for an updated extension.

But sure, I'm 100% in favor of extending KDecoration as you suggest.

Would be great to have LIM working in Plasma!

P.S.  As an aside, I hope for an option (like in Unity) to show the menu in the titlebar (in place the "title" info) at all times, rather only upon mouse hovering.

Figured I'd poke at the code to see how this works.

The application menu button currently only has a single bool property that's exposed to the Breeze KDecoration via KWin's AbstractClient. This lets breeze draw the button, then signal kwin to open a "context menu" below the button. Right now, it's opening the "root" of the menu. In theory we could open a specific submenu (eg: File) if we know the index.

Essentially, the KDecoration needs to know the top level menu items. Their index + text label. We probably also have to consider the top level Alt+___ shortcuts too in the future.

Should show button?

* https://github.com/KDE/breeze/blob/master/kdecoration/breezebutton.cpp#L326
* https://github.com/KDE/kdecoration/blob/master/src/decorationbutton.cpp#L84
* https://github.com/KDE/kdecoration/blob/master/src/decoratedclient.cpp#L72
* https://github.com/KDE/kwin/blob/master/abstract_client.cpp#L1691

On button click

* https://github.com/KDE/breeze/blob/master/kdecoration/breezebutton.cpp#L326
* https://github.com/KDE/kdecoration/blob/master/src/decorationbutton.cpp#L88
* https://github.com/KDE/kdecoration/blob/master/src/decoration.cpp#L198
* https://github.com/KDE/kwin/blob/master/decorations/decoratedclient.cpp#L221
* https://github.com/KDE/kwin/blob/master/useractions.cpp#L1690
* https://github.com/KDE/kwin/blob/master/appmenu.cpp#L113

at least 3 repos need to be patched for this it seems.

The appmenu widget should be a good reference for parsing the top level menu items.

* https://github.com/KDE/plasma-workspace/tree/master/applets/appmenu/plugin

I wonder if the breeze kdecoration could connect directly to the appmenu qdbus interface without modifying the kwin or kdecoration repos. That way it could read the top level labels and draw "buttons" itself. Would be easier to get started/test. Could even use SierraBreeze as a testbed since the repo is just the kdecoration.

I just realized Aurorae = QML based, and the appmenu widget is QML based.

While we can't reuse the appmenu code since it will always show the menu for the active window, and it doesn't work without plasmoid.nativeInterface, we could probably use it as a reference for a custom qml plugin like:

AuroreaAppMenuModel {
    windowId: decoration.client.windowId
}

DecoratedClient would still need to expose the windowId(?) for this to work.

* https://github.com/KDE/kdecoration/blob/master/src/decoratedclient.h

Though the first version could simply just show the active window.

I did a quick mockup in: /usr/share/kwin/aurorae/aurorae.qml

* https://i.imgur.com/zFzGr9v.png
* https://streamable.com/ekyqf

Please note that qml is no option for the default breeze window decoration.

Well I've gotten a little closer this weekend.

https://streamable.com/wq7g1

I've managed to modify the appmenu widget's AppMenuModel to support passing a specific windowId. The hardest with exposing the windowId is that it uses the datatype WId, which QML doesn't recognize. I wasn't sure how to register a primitive, as WId is apparently an "unsigned long long int" (on my X11 system at least). I got stuck trying to expose that till I found the qulonglong datatype.

I've managed to mask the caption, using a 10px wide gradient, when it falls behind the appmenu.

I tried exposing the "ActionId" role of the menu items, and calling:

    decoration.requestShowApplicationMenu(rect, actionId);

but it seems that's not the right way to do that, as you can see in the video.

To properly do it, the appmenu widget appears to create a new QMenu when a "menu bar item" is triggered. It calls a function in the plasmoid nativeInterface.

https://github.com/KDE/plasma-workspace/blob/master/applets/appmenu/lib/appmenuapplet.cpp#L164

Here's the kwin + plasma-workspace patches to get what I have so far.
https://gist.github.com/Zren/7b72293743f39b2b2ebac3d11f3ad59b

I second this wish. With today's 16:9 and even 21:9 displays, vertical screen space is extremely valuable.
I would very much welcome Unity's title bar & menu integration, but even more I would like to see this integrated with maximized windows so that their title bar is (optionally) integrated into a top panel, like the global menus.

Unity's development has stopped, Gnome's UI design seems to be moving away from window titles and menus completely, so what about KDE?

(In reply to Jens from comment #12)
> Unity's development has stopped, Gnome's UI design seems to be moving away
> from window titles and menus completely, so what about KDE?

There's no point in saving vertical space if it results in lost features or worse usability. Separate titlebars provide:
- A clear indication of which window is active and has keyboard focus.
- A guaranteed safe place you can click on to focus the window, or drag on to move the window
- A text label indicating what app the window belongs to and the name of the content it's displaying

Menubars can be integrated into a panel (macOS style) or merged with the titlebar when when the window is maximized (Unity style) which is what I believe this bug tracks. That's fine, and I believe various KDE developers are working towards it. But getting rid of window titlebars or using headerbars in the interest of saving 22 pixels would be a big step backwards in the usability department.

I'd like to see that various window contents could be moved to the title bar. E.g. a video player could put player controls there (pause, play, restart, volume) as buttons. Applications like video players should have an option to overlay the title bar with the video content, thus it could fade out on mouse-out or when the mouse was not moved for some time so you can watch the video distraction free. At least for maximized mode this would be a nice option.

As for menu bars in a global top-bar: I'm not in for that because Mac OS does it but because it has some real benefits:

1. It wouldn't take away screen real estate in windows because we can save some vertical space there.

2. It is much more easy to just push the mouse to the top screen border and click to hit a menu item. It must be ensured that the click-area touches the top of the screen.

3. Such a top bar should also integrate windows controls (maximize, minimize, full screen, various pinning options, the app-specific controls I mentioned before) because it is more easy to point to the right top screen corner to click the close button instead of somewhere in the window. But it should only include windows controls if the window was maximized. This is also why it would be important to put the controls into the top-bar when you maximize a window. For app-specific controls, I could imagine to make a container at the right side for it which could also act as a sys-tray container. The left side could take an application starter. This would remove app launchers and sys-tray from the button bar so we get some more horizontal space for the windows list which is a benefit also because buttons wouldn't be squashed together too soon (which often results in trimmed titles and less-easy navigation to the document you're looking for).

Putting windows into the title bar is an interesting option but I fear there will be problems with the amount of menus applications show: Cramming a document title AND the menus into the title bar results in poor usability. Reducing the application menu to one button (or even a single mini-icon as it is currently implemented) is a usability horror. If someone wants to do this, let them do. I think that in most applications that have a useful toolbar you only need the menu in rare occasions, so I'm fine with that in such cases. As more applications adapt, reducing the menu bar to a single button (but not a small icon) can become more useful. So it should always be an option, maybe even per application as a kwin app-specific setting.

I would also appreciate if the menu bar and tool bar of an application would blend with the title bar color. KDE already supports click-anywhere-to-drag so this would be a usability improvement and I could make title bars smaller.

I'm currently still using a classical bottom bar with app-launcher, quick launcher icons, the windows list, activity switcher (button mode), sys-tray and clock. This leaves only about 50% of horizontal space for the windows list, and I don't like when windows become grouped or end up as very narrow buttons or maybe only icons. The current grouping-implementation of the windows list is not very user-friendly: There's confusion when a click shows a list vs. when it focuses the application, especially because it also shows window previews on hover. These are similar semantics overlaying each other in daily use. But if you turn off grouping, there's too little space available to fit all the windows with reasonable button sizes. Maybe it would help if the windows list would not try to use the same size across all buttons but use shorter ones when the title is short.

(In reply to Kai Krakow from comment #14)
> I'd like to see that various window contents could be moved to the title
> bar. E.g. a video player could put player controls there (pause, play,
> restart, volume) as buttons...

They'd ever had an idea like this called DWD, but it's basically dead: https://www.reddit.com/r/kde/comments/77e7rt/are_dwd_still_a_thing/

"Menubars can be (...) merged with the titlebar when when the window is maximized (Unity style) which is what I believe this bug tracks."
d
Yes, I'm talking about Unity style menubars which are merged with the title bar when the window is *not* maximized, and merged with the top screen panel when it *is* maximized. This makes it easier to reach the buttons and menus with a top panel bar, as Kai already explained.

The top panel then contains the close/maximize/minimize buttons, the app menu items as well as right-aligned system tray icons, clock, etc.) I have never had an issue of overlapping or crushed menus in any app on Ubuntu in anything >= 1600 pixels screen width (the standard for some years is Full HD, i.e. 1920px).

I think the Unity developers have spent a lot of thought about this and it worked well for me since Ubuntu 14.04 LTS. Now that Unity is gone and Gnome seems to drop the idea of dedicated title bars and menus altogether, KDE would be perfect in providing an *option* to continue this design.

As far as I can see, the only thing missing for this to work, in addition to this bug (locally integrated menus), is a plasma widget that shows the configured title bar buttons for maximized windows (only) and causes their real title bar to be hidden when maximized.

Right?

DWD (I didn't even know this was a word) are being actively pursued by many Gnome apps, and is actively used by a LOT of large apps that people use all the time, e.g. Chrome/Chromium. If KDE implements this in any way it must absolutely be compatible to these existing apps and APIs.

And KDE has done some work on them already, see https://kver.wordpress.com/tag/dwd/.

Yes, this makes the separation between window management and application window more blurry, and it requires more cooperation between both, but it is also nothing new and has a lot of advantages.

But this is a different bug. Let's keep this one called "locally integrated menus" on topic. Sorry :)

Can we please stop debating this stuff as novels in a bugtracker.

The issue is: implementing this is quite difficult code-wise, and if it weren't, I would have long implemented it.

would love this

I'd love this as well! Thanks and keep up the good job! :)

The prototype looks really promising and very impressive. Can't wait for this to land in plasma. Great work!

I miss this feature so much from Unity. beautiful, space-saving, efficient (if there's no excessive fade in timer)

I wish this feature would be available too!
It would be very useful. The hamburger menu on the title bar saves space but is not very practical. It requires an extra click and then it opens a vertical menu which in as practical as a horizontal one.

This is a must have feature and a very intuitive way of accessing the menu rather than wasting space in the window.

Too much space is wasted in the title bar, would be nice to have an option to use this space for app menues. It would also look more compact and intuitive.

I've restarted interest in this feature after finding and modifying zzag's material decoration. I've bundled psifidotos's AppMenuModel.cpp from his appmenu widget. He bundled libdbusmenuqt so I've done the same as I couldn't iron out how to link to it.

* https://i.imgur.com/R3qHgaN.png
* https://github.com/Zren/material-decoration/tree/lim
* https://github.com/psifidotos/applet-window-appmenu/tree/master/plugin
* https://github.com/KDE/breeze/blob/master/kdecoration/breezesizegrip.cpp

It's a work in progress. I'm not sure if I'll attempt to embed a Widget QMenu somehow, or if I'll stick with using KDecoration2::DecorationButtonType::Custom. While it'll be easier to theme "Custom" buttons, QMenu comes with "hover"+Left/Right Arrows to change submenues and other basic menu features.

I recommend using the following command to test the LIM branch. It filters out the non-essential logging, and restarts KWin.

    sudo make install && QT_LOGGING_RULES="*=false;kdecoration.material=true" kstart5 -- kwin_x11 --replace

Tip: I also found that just opening the System Settings > Window Decorations kcm was more convenient for testing the close/maximize/minimize buttons.

    kcmshell5 kwindecoration

Pragmatically this cannot be done in a way that still works with CSDs and give a consistent result.

It also would not be doable in a way that can retrofit into every existing kwin decoration in a way that works.

IMHO if we can't deliver it reliably we (upstream) shouldn't try something that we know can't be reliable. I think Chris's approach as an out of tree option is probably the best compromise.

(In reply to David Edmundson from comment #28)
> Pragmatically this cannot be done in a way that still works with CSDs and
> give a consistent result.
> 
> It also would not be doable in a way that can retrofit into every existing
> kwin decoration in a way that works.
> 
> IMHO if we can't deliver it reliably we (upstream) shouldn't try something
> that we know can't be reliable. I think Chris's approach as an out of tree
> option is probably the best compromise.

the locally integrated menu is just an improved application menu button, themes not supporting the integrated menu would fall back to the current implementation

(In reply to David Edmundson from comment #28)
> Pragmatically this cannot be done in a way that still works with CSDs and
> give a consistent result.
> 
> It also would not be doable in a way that can retrofit into every existing
> kwin decoration in a way that works.
> 
> IMHO if we can't deliver it reliably we (upstream) shouldn't try something
> that we know can't be reliable. I think Chris's approach as an out of tree
> option is probably the best compromise.

Most CSD apps doesn't have standard menu anyway, so it's obvious that some apps won't support it, but most will. There are apps that won't support global menus (Spotify, Steam, Vivaldi and few others) and yet this isn't a problem for most of us, because those are exceptions and the average Plasma users won't install too many of CSD apps anyway.

If this worked for most apps that support global menus on breeze aurorae theme and some third party aurorae themes, this should be enough, at least in my opinion.

I think a more click-friendly hamburger menu would be a good compromise to drawing full menubars on each titlebar. The current menu button is a tiny circle, and the popup menu is tiny.

Why not make it a large rectangle and make the popup hamburger menu bigger and more click-friendly? One could turn this popup into a rich pallette that could be customized depending on the demands of the particular application. Furthermore, a HUD could be intergrated into this popup.If necessary, you could even break up the hamburger menu into multiple menus or even extract individual menu items as separate buttons and place those in the decoration.

This way you don't lose too much whitespace and you don't overtax the compositor. 

(Although I should add that I don't really buy the Nate's whitespace argument because clicking on titlebars to focus a window is always hairy due to the small click target. It's always easier to find whitespace to click on inside the app, to focus using middle-click, or to just use sloppy focus. Whitespace isn't necessary to ensure the window is draggable either, since there is no reason why you can't drag from widgets in the decoration - this is how GTK does it).

(In reply to Chris Holland from comment #27)

I tested the material decoration with LIM, it works very well, a breeze version with Lim would be fantastic.

Created attachment 128411 [details]
Demo

An application with LIM will look like a normal application because the menu is hidden in the title bar and will only appear when the mouse is over it bringing a more consistent look with CSD and applications that don't have a menu bar such as Spotify, Zoom, mpv.

I would love to see LIM. Having the two bars is a waste of space imo.

I tried with the menu button before, but then you don't see which menus are available, and there is the additional click, after which you have to find the menu you are looking for, and move the mouse.

It would be a bit faster with the hiding menu in the title bar. But still, there would be the problem of not seeing everything from the start, discoverability, and having to hover the title bar before being able to move to the right menu.
Therefore I would prefer to have menu and title side by side. If there is little space, it could degenerate to a hamburger or traditional 2 line setup.

The quickest way to access menus is using shortcuts.
The quickest way to discover menus is using HUB (Bug 371181).

In addition, Ubuntu Unity also had the option to always show the menu.

@João Paulo that Demo looks pretty good! Some transition effect (blending the menu + app name in and out) would IMO make it look perfect.
I guess it's not (yet) possible to move a window by dragging it on the menu though?

I am currently on the zzag material decoration window decorations and it did take a bit of time getting used to not being able to drag the window on the left ~half.

+1 in that bug request.

(In reply to Adam from comment #34)
> I would love to see LIM. Having the two bars is a waste of space imo.
> 
> I tried with the menu button before, but then you don't see which menus are
> available, and there is the additional click, after which you have to find
> the menu you are looking for, and move the mouse.
> 
> It would be a bit faster with the hiding menu in the title bar. But still,
> there would be the problem of not seeing everything from the start,
> discoverability, and having to hover the title bar before being able to move
> to the right menu.
> Therefore I would prefer to have menu and title side by side. If there is
> little space, it could degenerate to a hamburger or traditional 2 line setup.

Do we really need a title at all? Most multi-document apps today are tabbed anyways, so we have the document title in the tab bar. And it's pretty clear which application is which by just looking at it's appearance. Why duplicate the title in the decoration when we already have it in the task bar?

I already made my decoration "title" bar as small as possible because I'm rarely interested in what the title is - and I can already drag most windows by dragging from some blank space in the window.

I'm not even sure if classical menu items should be in a title bar at all: It's not too easy to point at them unless the window is maximized (because then the mouse pointer would stop at the top of the screen). So menu bars should be at the top of the screen and change when I switch the window. I'm seeing the "title" bar to be more useful for items like some often used functions of the application (the core function if you want so). And by eliminating the menu from it completely, there'd also be space for a document title.

But yes, if menu items right within the window should be the way to go, I'd rather see the expanded list of items across the decoration instead of a title, and instead of hiding away possibly important menu items in a hamburger menu. I consider the application title or document title the least important thing to have in the decoration, as usually that's duplicated to the task bar and tab bars anyways. But that's probably not true for all applications.

The current miniature hamburger menu is just a pita to use - did you ever try to click it without precise targeting the mouse pointer at it? A temporary solution could be to make the hamburger icon just a real button that says "Menu" or "Application Name".

PS: I almost stopped using menu bars. Either using keyboard shortcuts or avoid using such applications. However, that's not always possible. And for some reason most GTK apps ignore it anyways and show a menu bar - if at least that would be colored like the decorations... May I still dream? ;-)

I +1 this feature request. Like many others, I hide the title bar for maximized windows and therefore have to show plasmoids for app title and app buttons.

Integrating these into the title bar, would hit several flies with one stroke:
In a mac-like desktop arrangement, currently, Window Buttons, Application Title and Global Menu sometimes get out of sync. It is not always clear which window you are closing.
And it is weird to have different window buttons for maximized windows from a usability standpoint.

If the menu was integrated into the title-bar, there would be no difference between maximized and windowed windows. Animations would be consistent, vertical screen space would be saved. It would thus unify both words.

I would like to see this feature too! I also had the idea that, if the app menu is eating up too much space in the title bar, it could collapse to the hamburger menu button that is currently available as a window decoration. I don't know how complicated that is, but I think it makes sense. ^^

The "show more" hamburger icon when the titlebar doesn't have enough room for the full menu has already been implemented in the Material Window Decoration.

https://github.com/Zren/material-decoration

I also recently added a reveal menu on hover toggle.
https://github.com/Zren/material-decoration/issues/16#issuecomment-776291194

Just tried it and it's awesome, Chris! Thank you! Should definitely be upstreamed.

Putting the menu in the titlebar is a good idea for certain applications, but will not work for all. Therefore, I think this would be best implemented not as a global setting, but as a setting which you would apply on a per-application / per-window basis through the "Special Application Settings" or "Special Window Settings" dialogue. It could also be that the application itself would specify whether it wants to use this feature or not by default.

(In reply to Paul McAuley from comment #43)
> Putting the menu in the titlebar is a good idea for certain applications,
> but will not work for all.

I would yet have to find an application, where I would not want the menu at a specific place but at another.
Either I want menus or I don't, either I want them in the sandwich, menu-, or title bar, this is up to me, but to configure this for certain applications?

Put menu in ALL applications and you can remove them with Ctrl + M or use LIM to hide the menus in the title bar as shown in the attached file.

Created attachment 135969 [details]
Mock-up showing feature implementation idea in Strawberry

Attached are some mock-ups of a few example applications exploring how I would implement this feature.

If I were to design it for a default mainstream implementation, I would not ever hide or replace the title as hiding information from the user is not intuitive, and it is not up to the window manager to decide if the title is useful. I would never hide the menu (as I have seen in some implementations, only showing on mouse-over) as this is not intuitive either. Instead, I would reserve a minimum width for the title and try to show the menu and title side-by-side, re-centring the title towards the right-hand-side (assuming a left-to-right language). Reserving space for the title also guarantees a draggable area.

If there were not enough space for both the menu and the title to be displayed side-by-side, then I would simply not show the menu in the titlebar, instead showing the menu in its normal place. I do not think collapsing the menu into a small icon or overflow icon is usable as it is both harder to click and hides functionality from the user. To reiterate, I am discussing default behaviour, with different behaviour configurable in the settings.

On the appearance of the menu in the titlebar, I have added drop-down arrows to the menu items in my mock-ups. This is to distinguish the interactivity of the menu from the title, and is consistent with how things are done in GTK applications with client-side decorations. One small issue with this is that the default Breeze window decorations have a (IMO illogical, as I argued at length at https://forum.kde.org/viewtopic.php?f=83&t=109466&start=15#p370821 ) minimize button which looks the same as a menu drop-down; in my mock-ups I use my own Ozone window decoration which does not have this issue ( https://www.pling.com/p/1482837/ ).

Created attachment 135970 [details]
Mock-up showing feature implementation idea in Inkscape

(In reply to Paul McAuley from comment #46)
> Instead, I would reserve a minimum width for the title and try to show
> the menu and title side-by-side, re-centring the title towards the
> right-hand-side (assuming a left-to-right language). Reserving space for
> the title also guarantees a draggable area.

I think centring the title in the available space looks a bit strange. Why not just right-align it? Then it will always be in a consistent place.

One reason the title is currently centred, is to have it in the same place in different applications/windows. But other alignments also achieve this. On Windows, the title is left-aligned.

(In reply to Karl Ove Hufthammer from comment #48)
> I think centring the title in the available space looks a bit strange. Why
> not just right-align it? Then it will always be in a consistent place.

I think it would be worthwhile to evaluate whether a title is necessary at all. I, for one, never read it and would consider it superfluous information. For me the application icon would be good enough.
Also, in the window, when there is a good use for a title, there is usually other chrome for that, such as tabs.

Created attachment 135995 [details]
attachment-22657-0.html

I tested material decoration and hiding title + showing menu on hover is 
very convenient. Anything else would be a loss of functionality.

On February 20, 2021 21:37:19 Jan <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=375951
>
> --- Comment #49 from Jan <kde@jan.limpens.com> ---
> (In reply to Karl Ove Hufthammer from comment #48)
>> I think centring the title in the available space looks a bit strange. Why
>> not just right-align it? Then it will always be in a consistent place.
>
> I think it would be worthwhile to evaluate whether a title is necessary at all.
> I, for one, never read it and would consider it superfluous information. For me
> the application icon would be good enough.
> Also, in the window, when there is a good use for a title, there is usually
> other chrome for that, such as tabs.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Hi, I am trying this decoration and it is really good.
I don't know if it's just my problem, but for some reason if added "roll up" it doesn't show
Not a big deal, anyway.
Thank you

PS: I installed it on Arch via AUR

(In reply to Salvatore from comment #51)
> Hi, I am trying this decoration and it is really good.
> I don't know if it's just my problem, but for some reason if added "roll up"
> it doesn't show
> Not a big deal, anyway.
> Thank you
> 
> PS: I installed it on Arch via AUR

Report it on its github page.

Working on it right now.

Is there any progress on this feature as I would like to see this implemented as well

Yes, it is being worked on. See https://www.reddit.com/r/kde/comments/p6vqoa/breeze_locally_integrated_menu_support_beta/

(In reply to Nate Graham from comment #55)
> Yes, it is being worked on. See
> https://www.reddit.com/r/kde/comments/p6vqoa/
> breeze_locally_integrated_menu_support_beta/

Great!

Using Inkscape and Gimp where menus are part of the workflow, the menu must be always visible with direct mouse access. So hover-to-display the menu would bad for productivity. As you would need to move the mouse up to the top, hover and look, then move over to the right menu item. 3 steps instead of one. So permanent display of the menu must be somehow available.  Even if just as an option.

(In reply to ianp from comment #57)
> Using Inkscape and Gimp where menus are part of the workflow, the menu must
> be always visible with direct mouse access. So hover-to-display the menu
> would bad for productivity. As you would need to move the mouse up to the
> top, hover and look, then move over to the right menu item. 3 steps instead
> of one. So permanent display of the menu must be somehow available.  Even if
> just as an option.

Well, using LiM in Unity/ubuntu for years, the implementation was correct : 
⋅ left aligned, far left are windows control buttons, then title or menu,
⋅ by default, displayed title window - much needed in gimp or blender and the likes,
⋅ hovering there, instantly displayed menu.

There were not 3 steps. Just the same one as usual : move mouse cursor where you'd *expect* menu.

There was an option for always show menu ( but losing window title then. )

*** Bug 459339 has been marked as a duplicate of this bug. ***

Maybe try doing it this way, I really don't like when stuff is shown on hoover, it makes the workflow much more confusing than it needs to be

Show program's title without application's name, use limited space, just enough for the user to know what they're working on and without making the menus go out of the way (Maybe if the name's being cut-out, do <abc...gh> type thing), title being on the left to the menubar
Do not show the menubar *if* kburgermenu is available

Thinking about this now, the application title could also double as "More window options" button in this scenario

Hope this feature can receive some love.
Thank you!

*** Bug 466849 has been marked as a duplicate of this bug. ***

*** Bug 466816 has been marked as a duplicate of this bug. ***

(In reply to Bronson from comment #0)
> Now that plasma 5.9 is out and there is support for a global menu button in
> each window. I would love to see this extended to have the option for a
> ubuntu style locally integrated menu.
> 
> That is, instead of having to click a button which contains the menu. The
> title bar contains the menu, so when the user mouse's over the window title
> it displays the apps menu in the window bar. I find this more intuitive, and
> works great for fullscreen apps more so...

If this is integrated, I'd love for it to replace the window title – that is, I'd like to be able to disable the auto hide functionality.

*** Bug 376587 has been marked as a duplicate of this bug. ***

Those looking for some code can find it here:

https://invent.kde.org/plasma/breeze/-/merge_requests/126#note_681777

Sorry, that I had marked it as confirmed and generated noise as I had not seen any MR in this report here until Guido posted the link in comment 71.