client side decorations

[Russell Shaw]

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

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.