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

[Gregory Merchan <merchan phys lsu edu>]

On Tue, Oct 14, 2003 at 02:47:36PM +0200, Lubos Lunak wrote:
> On Monday 13 of October 2003 22:39, Gregory Merchan wrote:
> > Hi,
> >
> > I'm replying off-list because this reply doesn't directly deal with WM
> > issues.
> 
>  IMHO it's related enough.

Well, ok. *wince*


> > <snip>
> > What concerns me is that, while extending WM_TRANSIENT_FOR would allow the
> > windows to be related as the window manager sees them, they might not be
> > related as the user sees them. I think that a window modal for two or more
> > otherwise unrelated windows, but not all windows, would be confusing.
> 
>  Confusing? Well, perhaps a bit unusual. But this is so far the best idea I 
> have.

Before I replied previously, I tried to think of a way to handle it without
a mode. There's probably a way to do it, but I don't know KDE well enough
to know that it would fit or that your developers would be willing to try.
Every app using KWallet would have to change to support a modeless service.

Of course, it can't really be modeless - authentication is a stopping point -
but what's locked down by the mode can be limited. Instead of blocking the
entire UI, each app would block its parts that need authentication and
indicate the the blocked state. E.g., some of the menus would work, the
main area of the app would be "dimmed", and the statusbar would say,
"Waiting for authentication . . ." Meanwhile, a modeless window would
appear, perhaps with _NET_WM_STATE_ABOVE, for authentication. Attempt to
do something that's blocked waiting for authentication could signal KWallet
to do something interesting with its window, like set the UrgentHint.


> > Since KWallet is a system service, it seems like one of those rare things
> > that should use a system modal dialog. Without a system modal dialog, the
> > user could start more applications that would need to be blocked. Worst
> > case scenario: the user will try to get around the dialog by launching
> > the app a second, third, fourth, etc. time and he'll just conclude that
> > the system is broken.
> 
>  I don't think that blocking all windows instead of only two of them
> makes it better. What if the user is following some HOWTO, and need to
> check another step, or simply needs to check something in another app?
> The dialog will usually be shown only for one application, I'd just
> like to handle somehow the rare case where it will be shown for more
> of them.

Indeed, system modal dialogs suck. :-) As assistive technologies would
have to be free of the mode, perhaps help systems would too. At two
exceptions to the mode, we're on a fast track to chaos.


>  I don't actually quite understand your reasoning. If the user starts
> KMail/Konqueror/whatever and get the KWallet dialog, why should they try
> to start it again? Everytime they'll try to work with the application,
> they'll get the dialog activated instead, so they'll see that's where
> they have to do  something. I don't see how that should be broken.

They shouldn't, but they do. Suppose the user has usually run one app which
requires authentication then another. He's always authenticated with the
first app. Today he runs the second app first for whatever reason. He's
never had to authenticate with it, so he's not used to seeing an
authentication dialog. Instead of thinking, "oh, I need to give a password,"
the user might think, "damnit! this application broke!" and then restart it.
Frustrated in that effort, he may choose to do something else for a while.
If that something else is using the first app, which he knows requires
authentication, then he'll give the password and proceed. When he returns
to the app he thought was broken, he'll find it has been "fixed". ("Never"
here means "never in the user's recollection". He may have done something
once and forgotten about it.)

A system modal dialog would prevent the user from persuing alternatives to
get around what he believes to be broken - but they wouldn't stop him from
rebooting (and rebooting, and rebooting, . . .), so perhaps the system
mode wouldn't help at all. The modeless design only helps a little bit:
because some parts of the app work and it indicates its state, perhaps
the user will be less inclined to think the app is broken.


>  And I also think some people here will jump after seeing "system modal 
> dialog"  ;).

Bill Haneman wrote:
> <soapbox>
> For the record, true system modal dialogs are a complete stopper for
> certain types of accessibility support.  Please don't endorse them or
> use them!
> </soapbox>

It would be a window manager-enforced mode, so the same mode-overriding
rules for accessibility support on locked screens would apply. Doesn't
GNOME still use an (inaccessible) override-redirect window for logout
confirmation? Unless that can be completely redesigned, support in the
window manager for system modal dialogs is still needed to allow AT to
work when logging out.


Cheers,
Greg