GNOME Bugzilla – Bug 729788
Context menu on window decoration is not the one of the environment
Last modified: 2015-12-08 08:40:51 UTC
Created attachment 276133 [details] On the left the KWin provided context menu, on the right the GTK provided context menu The CSD-styled windows ship their own context menu. This is not matching the one provided by the window manager of the desktop environment. Thus it has a different order and important entries are missing while other entries are provided which are not supported by the desktop environment. See attached screenshot for a comparison of the context menu provided by KWin and GTK for the same window. Features missing from KWin: * move to screen * activities * window tabs * more actions with ** fullscreen ** keep below ** shade ** window shortcut ** special window settings ** special application settings ** window manager settings Strongly changes: Everything about workspaces. They are called "Desktops" in Plasma session. Recommended change: extend the NETWM specification to send a client message to open the window manager's provided context menu.
we're working on that. Jasper has a branch somewhere
(In reply to comment #1) > we're working on that. Jasper has a branch somewhere what's the state of this? We have the release of frameworks 5.0 coming and if we don't add an API hook for this in the next week it will be difficult to ever get support for it (requires a new virtual method in NETRootInfo and now that's still easy to do without introducing a NETRootInfo2).
This has landed in GTK+ master with https://git.gnome.org/browse/gtk+/commit/?id=0ea1a526f93411f8a2aef60dcb5a429a7694ca99 and will be included in GTK+ 2.13.3 later today.
I hope this will make it to NETWM soon. I started implementing support for it, but I do not completely understand what's supposed to be going on. The event is for the window, but what is the device_id supposed to be which is passed as the first data element?
Review requests created: * https://git.reviewboard.kde.org/r/118928/ * https://git.reviewboard.kde.org/r/118929/ This is without the device id. I don't know what it is and which datatype it is. The deadline to add it to our API is tomorrow, after that we can only add with next ABI break (aka KDE 6).
(In reply to comment #5) > This is without the device id. I don't know what it is and which datatype it > is. The deadline to add it to our API is tomorrow, after that we can only add > with next ABI break (aka KDE 6). The device_id is an XInput2 device that right-clicked or or sent the event, which is used to figure out which device to take the grab on if you use MPX or similar. If you're using XInput2, it should be in the "device" field of the events you receive. If you're not sure what it is, just use the device ID of the virtual client pointer, which is always "2".
looks like it won't make it for frameworks 5.0 on our side. My peers would prefer if we wait for the NETWM hint before adding it to our public API. As freeze is tomorrow this seems unlikely to happen. But 5.1 will already be released a month later. So we could try to get all those new needed hints into that. We might be able to add support for KWin 5.0 nevertheless, just we won't be able to announce it in _NET_SUPPORTED.
I don't maintain the specifications, and every one of my attempts to add new things to the spec have failed. I can just start using the _NET_WM prefix directly if you would prefer that, even if it isn't in the spec. If you believe you would have better luck getting it standardized, please try.
sent a proposal to netwm spec list: https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html
I think I'll close this one now. As far as gtk is concerned, this is done.
sorry? There is no standard yet, which means nobody else can implement it.
No attempt at creating a standard succeeded. GTK+ has the feature using its own protocol. Feel free to implement GTK+'s protocol in the complete absence of anybody maintaining EWMH.
Sorry, but I don't think it's a solution. It's not documented, so WMs just cannot provide support for it. I don't think it's a solution that KWin now implements it and everyone else is left out because they are not subscribed to this bug report. We need to try harder to get it standardized in EWMH! And yes I'm aware that I currently have a pending proposal I haven't updated the last two weeks.