client side decorations

[Bill Spitzak]

On May 7, 2011, at 9:30 AM, Mike Paquette wrote:
>>
>> Like I said, the compositor can call the client unconditional via
>> signal. No matter it is live or dead lock.
>
> I'm not entirely sure this is a workable idea.   Signals are not a  
> reliable inter-process communications mechanism.  There are also  
> limits as to what state can be safely modified from within a signal  
> handler. Non-async-signal-safe functions cannot be invoked from a  
> signal handler.   That would include functions that alter graphics  
> state.  A normal thread of execution within a client may not be  
> coded to anticipate asynchronous modification of the current  
> graphics state.

I do not think the intention was to use a signal to communicate  
complex ideas to the client. It was just a last-ditch "wake up" before  
the client is killed for non-responsiveness, right?

The solution to lock-up is for the clients themselves to use a ui  
thread that is different from any blocking operations. This is needed  
so that buttons and other controls don't "lock up". It is odd that  
people here put so much importance on resizing or closing apps when in  
reality users are just as frustrated when buttons inside the app don't  
respond. A client-side solution will fix all of these at once, and  
using the same code, reducing complexity.

Now of course some apps are not going to do this, or do it  
incorrectly. Clients are expected to echo the handling of events back  
to the compositor (they can also indicate they ignored the event,  
allowing the compositor to send it elsewhere). If the client does not  
echo in a reasonable amount of time, the compositor can assume the  
client is locked up. It can then render the client window differently  
to indicate this (ie grayed out like Gnome does). It can also decide  
to do something with the events itself, such as move and raise or  
lower the window, or offer the user the chance to kill the program.  
This killing may be a signal that toolkits can decide to catch if they  
have some idea how to internally kill whatever is locking up,  
otherwise the program exits on the signal.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110508/7fa6c01c/attachment.htm>