Menu
▾
▴
#26 Improve support for panels
I realise this is a very big topic, but even limited support would be very handy. In particular:
_MOTIF_WM_HINTS to allow floating windows to request not to have window decoration.
_NET_WM_STRUT_PARTIAL to reserve space at the edge of the screen.
_NET_WM_WINDOW_TYPE to support unmanaged windows.
Combine these and we get proper support for things like Gnome panels, without needing to rely on mod_dock --- it would be very nice to be able to tile the area between panels, for example, and have it all Just Work.
See: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2505868
Discussion
Anonymous
Hello David, thanks for your report.
EMWH is also known as 'NETWM', and indeed Notion is trying to gradually add support for as much of it as makes sense. You'll notice 'NETWM' is one of the bug 'categories' in the sf.net feature request tracker, actually.
I'm OK with leaving this bug open as a sort of 'mother of all NETWM bugs', but for specific features (such as the 3 you mention) I'd prefer to have 3 separate reports: this way we can discuss implementing those specific features (perhaps even for specific example use cases) without going mad :).
_MOTIF_WM_HINTS is explicitly *not* an EWMH/NETWM hint and is in fact very much despised and are why things like _NET_WM_WINDOW_TYPE were devised instead (as explicitly called out in the ewmh spec).
There used to be support for doing what _NET_WM_STRUT does (at least at a code level) it may or may not still be there (it'd just need a script to read the atom and call the code if it does). Supporting _PARTIAL is going to be more work (since it'll have to conform to frame sizes) but should be possible using the statusbar/inline-dock code (at the cost of the statusbar/inline-dock as you can only have one of those at a time).
notion supports _TYPE_DOCK already (as ion has since at least 2004). I don't know how many of the other types make sense for notion to really support though that is certainly something that can be investigated.
I originally grouped these together because these are (AFAIK) the necessary properties needed to make panels worked. I'll happily file multiple feature requests but let me have a look first and see if I can make this work myself, first.
_TYPE_DOCK is currently supported, but AFAIK only by sucking the window into the dock, which isn't the behaviour a lot of apps expect. In particular in floating workspaces it'd be nice to support doing this in a more traditional fashion.
As for _MOTIF_WM_HINTS --- yes, it's evil and horrible, but it's also used enough that it may be worth supporting. e.g. gkrellm has an option to set it. Particularly if it's easy. (Which it may not be.)
Where should I look for the strut stuff?
In fact, Notion already has some support for _MOTIF_WM_HINTS and in particular the 'no decorations' stuff: check ioncore/mwmhints.c . Why this does not appear to have the desired behavior for gkrellm I don't know though.
_NET_WM_STRUT(_PARTIAL) is currently entirely ignored by notion
mwmhints.c does contain code that checks the _MOTIF_WM_HINTS property; it looks like xwindow_get_mwmhints() is consulted for full-screen windows (and, BTW, the result never seems to be freed anywhere), but xwindow_check_mwmhints_nodecor() isn't called from anywhere. And a quick hunt through the repository diffs shows that it never was. So, erm.
How would this work, then? Make the frame's style vary *if* it's a floating frame *and* if the frame contains one client *and* the client has no decorations (either via _NET_WM_TYPE or _MOTIF_WM_HINTS)? That sounds like something that's best done at the winprops level, but I don't know how to make the frame style depend on a winprop.
As for struts --- I know that it's possible to reserve space at the side of the screen because mod_dock and mod_statusbar do it. However the code's rather opaque and I'm having trouble figuring out how it works. Any suggestions as to which APIs to start looking at?
I would strongly suggest just forgetting about the mwm hints and getting apps that depend on them to use more reasonably mechanisms.
And the problem with support _TYPE_DOCK other than the current is exactly the sort of thing dtrg mentions. What would it mean? What should notion do with it?
Side note: Apps aren't allowed to "expect" any behaviour from the wm regarding how it handles window types. Users can expect anything they want (and should choose applications and wms based around those expectations) but apps can't expect anything. So not doing what other wms do for _TYPE_DOCK is completely acceptable.
(Sorry, been away...)
Thinking about the various requirements to make panels work in a more traditional way, I think I can divide my requirements up into three groups:
To make them work at all:
- panels need to have no decoration. (Via _TYPE_DOCK or _MWM_HINTS or any other such mechanism --- the details are unimportant.)
Better support:
- As above, plus panels appear on all floating workspaces.
Best support:
- As above, plus _NET_WM_STRUT is used to reserve space at the side of tiled workspaces, and the panels appear there too.
In the first case, this allows users to have a single floating workspace on which the panels appear. They're just normal windows. Leaving the decoration off means they'll look right and won't have embarrassing title bars. Other workspaces don't show them. To my mind, this gives a nicely useful compromise between Notion's special features and shallow learning-curve traditional behaviour.
The second case allows Notion to behave more like a traditional multi-workspace floating window manager. I doubt anyone will want to do this (because why else would they be wanting to use Notion?), but the functionality might be handy. I don't know what would be involved in implementing this.
The third case allows panels to appear on all workspaces, with Notion automatically tiling the space between the panels (I agree that _NET_WM_STRUT_PARTIAL doesn't seem to mean much with Notion). However I've looked at the stdisp code and I'm quite willing to admit that I don't understand a word of it and I think this would be non-trivial to do.
So I'm quite willing to dispense entirely with #2 and #3 and focus on #1, which is simply adding support for decorationless windows, because that gets me the bulk of what I want, and mod_dock does a decent job of supplying the rest. Plus I'm willing to do the work (because I want to use it). Any suggestions on the best way to do this? It sounds like the best way to do it is to vary the frame style for certain windows; are there any mechanisms in place to allow this?
stdisp is hairy. I don't think I've ever looked at it. I also believe, assuming I recall correctly, that one of the reasons that the statusbar and the dock can't both be embedded is because even Tuomo couldn't work out the math/logic to make that work correctly (or something like that).
Having a window appear on all workspaces is easy. Just look at the scratchpad. You just "float" a workspace and you are done. (See also my named_scratchpad and named_floating_groupws scripts in the script collection/repo.)
That being said that isn't quite the same as having the window actually *be* on all workspaces, that is tougher. It could be done with a script at the moment but it would all be manually tracked. You would need to manually specify a window to have follow and the script would need to take care of remembering the frame it was last on in each workspace. The correct solution to that problem is to expose the placeholder concept to lua so that the script could simply utilize that to handle the position tracking (or something to that effect, I don't fully understand the placeholder mechanism).
No decorations (read: titlebar) on a tiled workspace is also easy. See the frame-tiled-alt style (and the min_tabs script for a specific usage of it). I don't know if a no decorations style exists for floating workspaces (we'd have to check).
In terms of _STRUT (and _PARTIAL) the api I was thinking of for this (aside from the stdisp stuff) is screen_set_managed_offset(_extl). Which, assuming I understand it correctly, does almost exactly what _STRUT wants. The only question is once you've done that can notion even put managed clients in that space or not (I think the answer may, unfortunately, be no).
The question is, and a quick read of the spec doesn't make it entirely clear, whether a wm that wants to support _PARTIAL needs to actually honor the full request or not. Since there's no way that notion can do that. At best it could either devolve that into a normal _STRUT or a layout-constrained stdisp "strut".
It probably makes sense to have the notion dock understand _TYPE_DOCK as an auto-swallow hint.
I've thrown a lot of information out there (and at you) and I'm not exactly sure where that leaves things or what the best next step is.