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. <div class="gmail_quote">On Wed, May 11, 2011 at 5:02 AM, Michal Suchanek <<a href="mailto:hramrach@centrum.cz">hramrach@centrum.cz</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2011/5/11 Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>>: <div class="im">> 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. </div>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. <div class="im"> > > 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. </div>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 <div><div></div><div class="h5">_______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </div></div></blockquote></div>