<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 7, 2011, at 9:30 AM, Mike Paquette wrote:</div><blockquote type="cite"><div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><blockquote type="cite">Like I said, the compositor can call the client unconditional via<br></blockquote><blockquote type="cite">signal. No matter it is live or dead lock.<br></blockquote><br>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.<br></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></body></html>