Re: extended WM_TRANSIENT_FOR (was Re: _NET: Disabling shading)

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Oct 01, 2003 at 02:54:45PM +0200, Lubos Lunak wrote:
<snip>
>  Anyway, I couldn't come up with any idea for solving my problem better
> than extending WM_TRANSIENT_FOR. But let me first explain the problem,
> maybe somebody will known something better. The problem is roughly like
> this:
> 
>  KWin (in the comming-soon KDE3.2) has a feature called focus stealing 
> prevention - it simply tries to block all window activations that the
> user would find annoying (such as "you have new ICQ message" and so on).
> I already mentioned it here 
> http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00013.html . The 
> basic idea is that a window is allowed to be activated by itself only if
> it belongs to the application with which the user most recently worked.
> For this, I need to know which windows belong together. Just using
> WM_TRANSIENT_FOR, window_group and few tricks like comparing WM_CLASS
> works for most cases.
> 
>  An example of a case I have problem with is a cookie dialog ("do you
> want to accept this cookie from site XYZ?"). Cookies are not handled
> by Konqueror itself, but a special kcookiejar daemon handles them in
> one place. As it's a separate process, WM_CLASS, window_group and
> similar don't work. ...

Why not?

Processes are mostly irrelevant at the X server because the clients may
come from different machines and multiple clients may come from the same
process.

A single client could implement multiple applications and so its windows
would have different WM_CLASS.res_class hints. Likewise, multiple clients
could implement a single application, so their WM_CLASS hints would be
the same. The important thing is that the hint is set to provide the
window manager what data it needs.

The ICCCM explicitly identifies the WM_HINTS.window_group hint as
potentially grouping windows from different clients.
  http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.11


>                 ... WM_TRANSIENT for still can handle this, as long as
> there's only one Konqueror window - the dialog is simply made transient
> for the Konqueror window, and KWin knows that they belong together. The
> real problem occurs when you have two Konqueror instances, and they both
> receive a cookie. KCookieJar queues cookies, so it shows at most one
> dialog at a time, but this dialog in fact belong to both Konqueror
> windows - you cannot continue working with either of them, until you
> handle the cookie.

This sounds like a confusing interface, but this isn't a usability list.


>  So the dialog should be transient for both the main windows - otherwise
> the WM will fail to keep it above either of the windows, and focus
> stealing prevention will refuse automatic activation of the dialog. I
> tried to find a different solution, like explicit requests to activate
> the dialog, but I couldn't come up with anything usable. So this is the
> best solution I have, and unless there's some better way how to handle
> it, I'll possibly have to implement it, be it KDE specific extension or
> part of this spec.
> 
>  Any better idea?

If the KCookieJar dialog is shown on behalf of the Konqueror windows, its
WM_CLASS hint should be the same as Konqueror's.

The wm-spec advises setting WM_TRANSIENT_FOR to Root or None for group
transients. I presume that means WM_HINTS.window_group based groups.

I propose changing this to:

  Set WM_TRANSIENT_FOR to Root or None to make a window transient for
  normal windows of the same class. Most utility windows and some
  dialogs would be set this way.

The state _NET_WM_STATE_MODAL would have a similar interpretation:

  If the WM_TRANSIENT_FOR hint is set to another toplevel window,
  the dialog is modal for that window. Such a dialog is often said
  to be "document modal".

  If WM_TRANSIENT_FOR is not set, set to the root window, or set to None,
  the dialog is modal for windows of the same class. Such a dialog is
  often said to be "application modal".

This would not make it possible to set a dialog modal for (say) 2 out of
5 normal windows of an application. That shouldn't be a problem, but this
isn't a usability list.


Cheers,
Greg