Currently, we have this settings option where we can add a Tool Button for the Applications Menu in the Titlebar Buttons.
Adding Applications Menu as shown in the above gives the following result…
This would mean one less click for opening the Applications menu and not just that. The user gets to see all top level application menu items without having to move the cursor or use a key combination.
I have tried looking into it, but I’m still new to the codebase and pretty slow due to lack of free weekends.
Would anyone be interested in implementing this, as it seems like something desirable to many.
Another part of this might be that, in case there are to many entries in the Application Menu or if the title needs more space, you could make an overflow menu that would work similar to the current implementation (just with only those entries that couldn’t fit).
This doesn’t require dbus menu. If your app has a menubar on top, which has space on the right side, you can turn on the overlay.
And it makes clear cut between the application part and the window decoration part of the title bar, which solves one of Nate Graham’s complaints on CSD.
The downside is now you can only place windows buttons on the right side.
Drag space reduction is a tradeoff for most space utilisation features, so as long as there’s enough, it’s fine. e.g. Firefox completely gets rid of the drag space when there are enough tabs and even though I find it annoying and would want at least some, not many are complaining.
That’s probably why @redstrate 's option seems to be better. We can add an overflow menu when there is not enough space.
In case of Chromi, the best way I can think of is to somehow tell the app that it has less width available specifically for the menu-bar and hope that the application handles it properly. I have a feeling, even if it could be done, it won’t be a decoration-only code.
It can be done by having an “overflow” button in the decoration that, when clicked, temporarily hides the decoration so you can click on menu items below.
It requires the same number of clicks as with a “normal” overflow menu.
It could be possible to drag the titlebar even on the menu buttons. We’d have to make it so that the menus open on click rather than open on press since on X11 menus block all mouse input to other windows (standard menus are windows).
Yeah that would work. There is also no reason why you shouldn’t be able to drag the window from even the close button. One could also implement right-click to maximize instead of double click. This is what Gnome does.
But the decoration would need to be user customizable, per window, in order to actually be seamless (and/or have the app interface with it directly via API). If the app is resized to the point where there’s not enough space to accommodate both menubar and decoration, the app would just get a normal titlebar.
I also see a major use case for this with apps that insist on CSD. You could just use the decoration to paint proper buttons over the apps window controls. This would essentially solve the CSD problem.
If the decoration is sufficiently customizable, then it could just be configured to deal with the specific apps. Except for apps that have a lot going on in the top area so it’s essentially unpredictable without the application telling kwin exactly what it’s doing. These apps could just be ignored.
And we can simply set a second hotkey for “Show Decoration” that would get the titlebar and buttons on top when required in that case.
Note that there is already a binding for “Show/Hide Decoration” and that one will get rid of the decoration as a whole. In our case, it would be desirable to have the “window border” part of the decoration (if it exists) still active when the titlebar overlay is gone.
I have actually been thinking about a 2 mode decoration for a while, in which we can set it to “border only” mode when we want more screen area and “full display” mode whenever we want to see the titlebar. This would also allow different decorations to have different modes (instead of border only, they can implement some other functionality).
The difficulty here, is that it would require additional functionality from KWin, unless there is a way to add decoration specific hotkeys that I don’t know of.
Currently, I just hide the decoration in those cases, but then I don’t get the 1px border that I would definitely prefer.
–
The extra thing I talked about would also help get a visible border on GTK apps like Firefox on a full-black non-material theme.
Well it would be nice to be able to launch application-specific scripts from buttons/widgets in the decoration. E.g. you’d have buttons there to automate certain actions within the application.
If furthermore KDE were to have a desktop automation IDE a la Microsoft Power Automate or Automator, this would be a killer feature.
not a fan of showing decorations on hotkey. who wants to press a hotkey to view window decoration? if its not there it’s not there and you’d just use hotkeys to drag or close the window directly without the aid of the decoration.
I get the impression you are taking the functionality of “showing decorations on hotkey” a different way.
When the decoration doesn’t have a menu bar, you would normally have to press the menu button and then open the menu, or you would press Alt to show the menu bar (as in Firefox) and then interact with it. [2 actions]
In case of a Toggle hotkey, you can decide beforehand if you want to have the extra 20px of real estate for your application or you want to keep the decoration on top (which will hopefully also have a menu bar). [1 action after setting up beforehand]
Normally one wouldn’t show/hide the decoration right when they need to see the title bar or move the window. Since this is a toggle, you would normally set it up when you are deciding your current work mode, or you would set a KWin rule beforehand in case it is going to be the same for a given application everytime.
e.g. I usually have multiple Konsole windows and some of them don’t need a decoration, so I toggle off the decoration for those specific ones and the other Konsole windows that need a Decoration have it on. This information stays as part of the Plasma Session and the same Konsole window opens up in the same location with the same size and the same decoration state on restart. The above meaning that I won’t be pressing the shortcut all the time.
Going on a tangent here: KWin currently gives a shortcut for “Wndow Operations Menu”, but not for “Application Menu”. The reason being that the latter is added as a custom icon by the user and cannot be set-up the same way as the former.
Perhaps we can decide how it may be implemented in another thread, as having a shortcut to directly show the “Application Menu” also seems to be a useful thing.
