Wayland Window Management Proposal

[cat]

If I understand the proposal correctly this shouldn't be a problem. If the
application becomes unresponsive the server has the ability to manage it
(move, resize, raise, lower, possibly hide/show, and an option to kill it)
and it knows if it didn't respond to events.

I do think that there is one thing it should also have, when a client is
going to appear/move/resize, it should send a request to the server with a
tag, a nospace string to identify the request, the new location, and new
dimentions.
the server responds with a message that has the same tag, and a yes or no
response (possibly a hint as to why it was rejected), and if the resonce is
no then the client should not preform that particular operation. this at its
basics can prevent applications from accidentally moving off screen,
covering some more important window(like a taskbar), or from acting as a
floating window in a tiling environment, and allows the server the freedom
to do something more advanced.


On Wed, May 11, 2011 at 5:02 AM, Michal Suchanek <hramrach at centrum.cz>wrote:

> 2011/5/11 Bill Spitzak <spitzak at gmail.com>:
> > Kristian Høgsberg wrote:
> >
> >> I had a quick read through this and there is a lot of overlap with how
> >> Wayland works today... are you proposing to change how Wayland works
> >> or are you not familiar with what's already in place?
> >
> > A lot of this is based on my understanding of how Wayland works, and from
> > the XML description of the protocol. I tried to document what I believe
> but
> > has never been really stated for Wayland.
> >
> > Main addition I made without previous knowledge was the parent and the
> task
> > objects (so that a task manager client can figure out what to display),
> and
> > the window management events (rather than try to guess what happens based
> on
> > movements of the windows, which seemed to be what was planned for
> Wayland).
> >
> >> Anyway, for decorations and tiling window managers, bear in mind that
> >> CSD is not about insisting that clients always draws decorations, but
> >> about making clients draw the decorations *when* decorations are
> >> desired.
> >
> > I mostly see CSD as meaning "the server never draws any kind of
> > decorations". I agree it is a good idea for the server to be able to tell
> > the client to not to draw decorations (done in this proposal with the
> resize
> > events having 4 flags to turn the edges on/off and another flag for the
> > title bar). But the server must *never* draw them, because that would
> > require the api by which the client describes the decorations to the
> server,
> > which is the source of the complexity and interface lock-in that we have
> in
> > X and Windows.
>
> I don't think you need an API for that. Either the application accepts
> what the server draws or it wants to draw its own.
> So it's like
>  - application wants its own borders (bool)
>  - server takes care of borders (bool)
> two bits.
>
> >
> > I also believe window actions such as move, map, and raise must be
> > client-side. Otherwise correct movement of child windows will require an
> > equally-complex api to send this information to the server. So I really
> > tried to make it clear how I see this working. Proper child windows where
> > the app has complete control could be a major user interface advantage
> over
> > Windows and OS/X.
>
> Moves and resizes implemented in the client can't work well.
>
> Maybe in an ideal world each application would be split into two (or
> more) processes, one taking care of the UI interaction and the
> other(s) doing the actual work so that the UI is always responsive.
>
> However, this is not the case and for moves and resizes to work
> properly they have to be done in the window manager. For many
> applications responding to UI events is rather low priority and when
> they are busy doing something the UI is not going to be handled.
>
> So the user initiated resizes should happen in the compositor which
> paints the current content in the window of the new size and can
> possibly mix in some haze to make it obvious that the window was not
> resized yet and later the application should update the content size
> to match the window size and move any toolbars appropriately.
>
> The problem is with broken applications (such as gimp) that respond to
> a resize of their window with application-initiated resize of the same
> window leading to a resize loop in tiling WMs.
>
> Thanks
>
> Michal
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110511/38d785dc/attachment.html>