Window management

[Nick Kisialiou]

Thorben, you have to be very careful with your assumptions here if you
want Wayland
to be agnostic of any particular UI paradigm.

Maximize doesn't always mean taking all space. What happens if there are
2-3 monitors with different resolutions?
What does fullscreen mean with multiple monitors? If a window is partially
visible on both monitors, which one should take the window in a fullscreen
mode?
Minimize doesn't always mean hiding window outputs. What happens if it is
minimized into a thumbnail bar in some fancy desktop?

There are plenty of opportunities here to get the protocol wrong.

Nick



On Sat, May 25, 2013 at 4:09 PM, Thorben <thorbenj+freedesktop at eryri.ch>wrote:

> Hi all,
>
> Resent because I was not on this list, I normally just skim the archive
> from time to time as this project very much interests me. I can't wait for
> the day when I can try KDE5 on wayland.
>
> A couple of things have been bugging me and I thought I might give my
> thoughts on them. I'll post separate emails as to not mix topics.
>
> Problem 1 window management.
>
> There has been a lot of discussion on window management (minimise,
> maximise, etc) and some attempts at a solutions.
>
> I had some thoughts on the matter, be chose to stay silent because a)
> There are people that know about this stuff then I, b) The discussion
> exploded in April and so I didn't feel I should bring it up again.
>
> The main issue as it seems to me, is keeping Wayland agnostic of any
> particular UI paradigm (Desktop, Mobile, Tablet, Car, Fridge, etc) and
> there is the second issue of not breaking the existing protocol API.
>
> My idea would be to not mix this concept of "minimise" with other concepts
> to do with size (such as maximise).
>
> I would suggest a size state system of:
>
>  - Windowed (and maybe variances like popup)
>  - Maximised (Fills all screen space minus whatever the shell uses)
>  - (Maybe vertical and horizontal maximise also being possible states?)
>  - Fullscreen (Take all screen space)
>
> "Minimised" or hidden would better fit in with another state system like
> window stacking. My idea is that the Homescreen/Desktop/Whatever drawn by
> the shell is at stacking position 0 and that visible windows are above it.
> Thus having a positive stacking number; windows that are hidden (minimised)
> are behind it with a negative stacking number. Obviously the windows size
> state remains as is.
>
> This is at the protocol level. How a user sees or drives this is entirely
> up to the shell. Maybe a taskbar, a window list, a button or a combination
> there of.
>
> There is the other issue of, if having a negative stacking number is
> enough indication to a window that it is hidden. I don't know wayland well
> enough, maybe that sort of information is not available to clients. In
> which case there needs to be a notification.
>
> Whether a hidden (minimised) window chooses to continue updating it's
> surface should be a clients choice. It can be based on existing mechanism
> of what is obscured or visible, or whatever. Does a covered window normally
> repaint covered parts?
>
> The compositor should not waste any further resources on compositing such
> windows/surfaces into the final screen image. With the possible of
> exception of shells that want to 'preview' a hidden window. Like most
> desktops do, and I am guessing some tablets would like to too.
>
> So that's my thought, stop try to fit the concept of 'minimised' into the
> concept of window size. Decouple it entirely from 'maximised'. Shuffle it
> behind whatever fills the screen when no windows are visible (Desktop,
> Homescreen, etc).
>
>
> Regards,
>
> Thorben
> ______________________________**_________________
> wayland-devel mailing list
> wayland-devel at lists.**freedesktop.org<wayland-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/wayland-devel<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130525/e241b6ac/attachment.html>