protocol questions

[Thiago Macieira]

On quarta-feira, 3 de abril de 2013 12.43.35, Kristian Høgsberg wrote:
> > But the client may still want to popup a grabbing window (e.g. system-tray
> > menu) in response to other event (e.g. dbus event) indirectly caused
> > (handler in another process) by the user input.
> 
> I can't think of anything that does this in any desktop environment
> I've ever seen.

The only case I currently have of something grabbing my X server is the GPG 
Agent pinentry program. But in that case, we've discussed in the past that we 
actually want to solve this problem differently: inform the compositor that 
this is a password / input-sensitive dialog and let the compositor handle it 
as it will.

Anything else that pops up in my desktop won't get focus due to focus-stealing 
prevention anyway.

The one thing that needs to break out of that are out-of-process windows that 
still logically belong to the same "application". KDE, for example, does that 
for the KWallet password but also for those file transfer dialogs, showing 
progress. You can also easily go further, like having a separate settings 
application for configuring an application, but launched from inside the 
application.

Do we have a defined way of transferring focus and modality, enforcing stacking 
order?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130403/6ed4939c/attachment.pgp>