Mikko Levonmaa wrote:
i.e. when going from maximized/fullscreen to the default state the
compositor could remember the last size and propose that to the client.
The client has to know the default size:
1. It may have initially shown maximized. The compositor therefore has
not seen it in normal state and does not know the size.
2. The state of the client may have changed while it was maximized such
that it's normal size has changed.
An actual example of a bug we have run into repeatedly on Windows and in
Qt (though underlying X you can fix it) is that we want to save our
window state in a file, and we want to save both the fact that it is
maximized and what the un-maximized size is. This is not possible if
only the compositor knows it.
On Windows we are forced to blink a maximized window when created so
that Windows sees the normal size and remembers it. On X a big kludge is
done to get around Qt emulating the Windows bug.
It would be nice if Wayland avoided this problem.
So as I see it, if the user hits the "un-maximize" hot key:
1. The compositor sends a state_change event that turns off maximize
2. Client figures out it's un-maximized size, and configures the
surface, drawing the new resized image.
3. Client sends the state_change request to tell the compositor that
this new image is not maximized.
4. Client does a commit so the new size, image, and non-maximized state
are all updated atomically.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
