On 11/05/11 18:55, Michal Suchanek wrote:
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.
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
