client side decorations
spitzak at gmail.com
Sun May 8 09:47:11 PDT 2011
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...
More information about the wayland-devel