Re: client side decorations
On 10 May 2011 05:46, Russell Shaw rjs...@netspace.net.au wrote: On 10/05/11 07:29, Daniel wrote: El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va escriure: Though it is possible, I don't like the idea of clients sending hints about what areas are the close box or window border, since it implies there are such concepts as title bar and close box. The compositor can just have clicks anywhere raise and move the non-responsive window, and lots of clicks (indicating user frustration) pop up a box offering to kill the program. On Linux, since it is standard, compositors can also have Alt+click always raise/move windows, and alt +right click pop up a menu of compositor-side window actions. This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. Keeping track of dead clients could be done like this: A client program opens a socket connection to the window server, and the window server determines the PID of the client via a means that the client has no control over (some kind of kernel call that can determine the client using that socket). The client also sends the window server the title bar area that contains the maximize/minimize/close buttons. All clients must handle an is_alive probe event from the window server at any time, replying with something unspecified to confirm it is not dead. Whenever the mouse is clicked in the title bar, the window server can expect the client to send it an is_alive notification within say 1 second. If it doesn't, the window server can send the client an is_alive probe event. If there's no response after a certain time, the window server can kill the client. Alternatively, it could pop up a gui task manager window for the user to manually kill stuff. Clearly it's up to the user to decide if an application is stuck or not. The is_alive request may look like a nice idea at the first glance but it is not very reliable. How long timeout is allowed before the application is marked 'unresponsive'? This is clearly application and system specific. Any timeout based protocol is inherently unreliable. The application may have a separate thread to fulfill this is_alive requirement and the rest may still be stuck. The application may be running but in undesirable state which is not something the compositor can decide. An utility like xkill resolves all of the above. You don't like the application so you get rid of it. The compositor can resize or hide the application window at any time without any cooperation from the application. The application may publish hints as to how it wants the window content treated when it does not match the size of the displayed window and the compositor may use these to present the window in a reasonable way until the application resizes the content. This requires that the compositor notifies the application when the window is resized. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
On 11/05/11 18:55, Michal Suchanek wrote: On 10 May 2011 05:46, Russell Shawrjs...@netspace.net.au wrote: On 10/05/11 07:29, Daniel wrote: El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va escriure: Though it is possible, I don't like the idea of clients sending hints about what areas are the close box or window border, since it implies there are such concepts as title bar and close box. The compositor can just have clicks anywhere raise and move the non-responsive window, and lots of clicks (indicating user frustration) pop up a box offering to kill the program. On Linux, since it is standard, compositors can also have Alt+click always raise/move windows, and alt +right click pop up a menu of compositor-side window actions. This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. Keeping track of dead clients could be done like this: A client program opens a socket connection to the window server, and the window server determines the PID of the client via a means that the client has no control over (some kind of kernel call that can determine the client using that socket). The client also sends the window server the title bar area that contains the maximize/minimize/close buttons. All clients must handle an is_alive probe event from the window server at any time, replying with something unspecified to confirm it is not dead. Whenever the mouse is clicked in the title bar, the window server can expect the client to send it an is_alive notification within say 1 second. If it doesn't, the window server can send the client an is_alive probe event. If there's no response after a certain time, the window server can kill the client. Alternatively, it could pop up a gui task manager window for the user to manually kill stuff. Clearly it's up to the user to decide if an application is stuck or not. The is_alive request may look like a nice idea at the first glance but it is not very reliable. How long timeout is allowed before the application is marked 'unresponsive'? This is clearly application and system specific. Any timeout based protocol is inherently unreliable. In X, dragging or resizing a window is instantaneous. The proposed scheme was to allow a 1000 millisecond delay before assuming the client was stuck. It was assumed the user could also bring up a task manager with crtl-alt-delete and kill a client manually if needed. The application may have a separate thread to fulfill this is_alive requirement and the rest may still be stuck. The application may be running but in undesirable state which is not something the compositor can decide. An utility like xkill resolves all of the above. You don't like the application so you get rid of it. The compositor can resize or hide the application window at any time without any cooperation from the application. The application may publish hints as to how it wants the window content treated when it does not match the size of the displayed window and the compositor may use these to present the window in a reasonable way until the application resizes the content. This requires that the compositor notifies the application when the window is resized. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 2011-05-11, Michal Suchanek wrote: 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. Perhaps a compromise could be a wayland-client.so lib that all compliant Wayland applications must link to at runtime and it provides consistant window management functionality. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
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 hramr...@centrum.czwrote: 2011/5/11 Bill Spitzak spit...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: Moves and resizes implemented in the client can't work well. Any resize solution that does not allow an atomic on-screen update of a window to it's new size, with the resized decorations and contents, is unacceptable. The whole point of Wayland is that the user NEVER sees a partially-updated window. It is therefore impossible to finish a resize without waiting for the client to update the window contents. Since you have to wait for that, there is no reason the client can't also draw the decorations. I'm sorry if this makes writing clients harder. Deal with it. 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. That would look like crap. The window would blink rapidly between the haze and final version. 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. That is a problem with X design where they tried to override the actual call to resize the window. In wayland the change the window size and the I want to change the window size messages are distinct. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
Michal Suchanek wrote: I guess there is one thing that can be done. The compositor could publish a hint to the application that it takes care of decorating the windows (even if it is a tiling WM and in fact does not but the user does not want any decorations in the first place) Indeed this looks like a good idea. In fact doing some sketches it appears to be necessary for the compositor to tell the client to delete the decorations on each edge independently. and the client could publish a hint that it does draw decorations and its windows should not be decorated by the compositor (or it does not want decorations because it is a clock window and decorating it makes no sense). I don't think the compositor should ever decorate the windows so I very much disagree with any idea like this. It cannot draw into the texture for the window, as that memory belongs to the client. If the client is doing internal double-buffering, the compositor does not even have a pointer to the texture! Therefore the compositor would have to add extra surfaces that are the decorations. This could either be a larger underlay window, an overlay with a big transparent hole, or thin windows placed around the edges. The problem here is that resizing the window needs to be an atomic operation so the user never sees a partial update. This means that both windows must resize and have their image replaced in the same operation, while the images are produced by two different processes! This sounds very complex and difficult. When you add to this the insane amount of little details that clients need to send to control the decorations (such as whether there should be a resize box, etc) I think it is nonsense to ever consider such things. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
I personally does support and only support client side decoration. Move and resize ? Better be done in the server side. Average application should never care about where its windows is. The compositor cares and move them without notify the client. If the unusual application does care where its windows is , go and ask the compositor. And how big? They can't care how big a windows is in the pixel, but in the inch. People should have different monitors with different DPI. Windows should stay same size regardless the DPI. Force DPI==96 on every monitor is a stupid idea, and we should avoid it on the protocol side. I suggest, DPI should also be windows specific, so that compositor can *scale it*. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
