Re: [gtk-list] Re: Patch for modal windows, and more.

[Owen Taylor <owt1 cornell edu>]

Elliot Lee <sopwith@redhat.com> writes:

> Well, assuming one way or another is bad - I happen to use ClickToFocus
> sometimes (and like it). ClickToFocus is also much closer to
> Windoze/Mac... FocusFollowsMouse is *much* harder to do modals with...

I think finding a solution that is bad for neither is a must.
Although the tide of M$oft may eventually overwhelm the FollowFocus
camp, to ignore them is to alienate most long-time X users (like me).
Anyways, I don't think focus is much of an issue when modality
is implemented properly.

> A big problem I see is that X11 has no real concept of an "application".
> If the WM can some way understand how a group of top-level windows are
> related, then it can do things similar to the WM_TRANSIENT bit. 

I'm not sure how this is typically done, you could enforce almost any
stacking policy by monitoring Circulate events. Netscape it only
forces its modals to stay on top of the main window they were launched
on, but doesn't enforce other constraints.

> (BTW what examples do you have of X apps that implement modals well? I was
> playing with the a tcl/tk app, if you get one of those Yes/No type of
> dialog boxes, that is definitely modal - I may need to look at tk source
> code for enlightenment.) 

I looked at a couple of Motif applications: Netscape (as above),
acroread (just a grab, no enforcement of stacking order), the NYTimes
crossword puzzle viewer acrossl (no grab, enforcement of stacking
order like Netscape). (Somehow I don't think there is a real Motif
standard...), and the Xt applications xmorph, and xfig. (grab,
enforcement of stacking order - but only one main window, so hard
to extrapolate the multiple window case.) Looking at the Tk source
code, and book (but not at actual programs), it appears that Tk
only implements a local grab, without stacking order constraints.

> It should be kept on top of the set of windows for the application, but
> not necessarily on top of the windows for all apps (although implementing
> the latter is of course much easier).

This would be nice, but is IMHO not essential - the most important 
thing is the grab - the stacking order constraint does prevent
user frustration though ...

> One big problem is that one approach I've heard of (which I suspect is
> done in more than a few apps) is to have another event handling loop just
> for the specific modal. I really don't think that will fit with gdk :-)

This isn't necessary. (you right, unlike Xt, gtk does not allow this.)
As my example program I posted a few days ago demonstrated, you
can get pretty much the right event handling without even modifying
gtk. (To explain further, gtk in it's main event can decide to
send all events to one window, as in the implementation of gtk_add_grab.)

> The problem I see, again, is that X11 doesn't really have the concept of
> an application, so grabs are either all or nothing... If there is a way to
> grab the pointer & keyboard for only a group of windows, that would be the
> ultimate (since it would work with however you have your WM set up).

The concept of an application _is_ there - it's defined by your main
event loop. To do a local grab, you don't use XGrabPointer or it's
kin, you implement it by event loop policy.

Regards,
                                        Owen