client side decorations

[Michal Suchanek]

On 10 May 2011 05:46, Russell Shaw <rjshaw at 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