Proposing to extend the EWMH spec

[Sebastian Geiger (Lanoxx)]

Hello Freedesktop,

This is my first mail to the list, so I am not sure if this is the
correct approach to ask about this. And I am not sure how the procedure
for proposing changes or additions to an existing specification works.
Please feel free to suggest alternative approaches if this is the wrong
place to discuss my problem.

I have the following problem: I would like to programmatically change
the size of a window and be able to increase its size such that is fills
the whole work area on the current monitor. Currently on GTK+ this is
only possible for the primary monitor, because the implementation of
gdk_screen_get_monitor_workarea does not support multiple monitors.
Instead for non primary monitors I can only get the monitor geometry
which maybe wrong if there are panels on the secondary monitor. I have
discussed this issue in [2], but as I am being told this is a limitation
of the underlying EWMH protocol (specifically _NET_WORKAREA), which does
not support to query for individual monitors. In stead of the actual
workarea the GDK implementation currently just returns the monitor
geometry for non primary monitors. This leads to problems when resizing
the application window in the interval between the workarea and monitor
geometry (e.g. when I try to set the height to a value that exceeds the
avaliable height or the workarea).

I would like to ask if it is possible to extend the EWMH spec [1] and
add a new hint which could be named for example "_NET_WORKAREA_MONITOR",
the purpose would be to enable applications to query the maximum
available work area information on a per monitor basis. Since its
possible to query if a window manager supports a certain hin, libraries
and applications could check if this hint is supported and just fall
back to their current implementation if its not supported.

I am not an expert for either X or Window Manager development, so maybe
I got it all wrong and there are better solutions how this can be fixed,
in this case I would like to hear about your suggestions it.

Best Regards
Sebastian

[1]: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html
[2]: https://bugzilla.gnome.org/show_bug.cgi?id=755699

[Bastien Nocera]

Post by Sebastian Geiger (Lanoxx)
Hello Freedesktop,
This is my first mail to the list, so I am not sure if this is the
correct approach to ask about this. And I am not sure how the
procedure
for proposing changes or additions to an existing specification works.
Please feel free to suggest alternative approaches if this is the wrong
place to discuss my problem.
I have the following problem: I would like to programmatically change
the size of a window and be able to increase its size such that is fills
the whole work area on the current monitor.

Why does the application need to grow in size by itself? What does this
gain compared to the window manager's maximise function?

[Sebastian Geiger (Lanoxx)]

Post by Bastien Nocera

Post by Sebastian Geiger (Lanoxx)
Hello Freedesktop,
This is my first mail to the list, so I am not sure if this is the
correct approach to ask about this. And I am not sure how the
procedure
for proposing changes or additions to an existing specification works.
Please feel free to suggest alternative approaches if this is the wrong
place to discuss my problem.
I have the following problem: I would like to programmatically change
the size of a window and be able to increase its size such that is fills
the whole work area on the current monitor.

Why does the application need to grow in size by itself? What does this
gain compared to the window manager's maximise function?

The application in question is Tilda, which has a usage paradigm
different from regular applications. In particular, it does not have
window decorations so the user cannot just grab the edge of the window
and resize it. Usually the user configures the position and size of a
Tilda window once in the preferences dialog and then does not change it
too often. In particular the preferences dialog has GtkSpinners for
setting height, width and {X,Y} positions.

Anyway I think it does not really matter why I need this. Except for
Gnome Shell which AFAIK only has the shell UI on the primary monitor,
there exist many other desktop environments which allow placing panels
on every monitor and I think there should be a way for applications to
retrieve the available screen size (real screen size minus panel size)
on those monitors. That would be much more consistent then the current
solution which only allows to get this information for one - primary -
monitor.

[Bastien Nocera]

Post by Sebastian Geiger (Lanoxx)
Anyway I think it does not really matter why I need this.

I don't think people here will want to extend specs "just because".

[Sebastian Geiger (Lanoxx)]

Post by Bastien Nocera

Post by Sebastian Geiger (Lanoxx)
Anyway I think it does not really matter why I need this.

I don't think people here will want to extend specs "just because".

What I mean was that this should not be seen a feature just for my
specific use case, but a way to make the specification more consistent
in multi-monitor setups. As a result other applications might profit
from this as well. I am not sure how many applications use
gdk_screen_get_monitor_workarea, but each application that does might
exhibit wrong behaviour if its run on a multi-monitor setup with panels
on secondary monitors. Especially since different window managers behave
different when the window size is set bigger then the available workarea
size.

Some WMs just ignore the setting and limit it to its maximized size,
others expand the window but it overflows _under_ the panel. Again
others ignore the size if it exceeds the available work area, except if
the size is equal to the monitor size at which point the window is
handled as a fullscreen window, which can have undesired side effects.