client side decorations

[Michal Suchanek]

On 11 May 2011 12:05, Russell Shaw <rjshaw at netspace.net.au> wrote:
> 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.

Far from it. Sometimes the application is actually doing something,
not only idly waiting for the user to resize it. Sometimes it is
swapped out and has to be swapped in to resize.

Thanks

Michal