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

[Elliot Lee <sopwith redhat com>]

On 4 Jul 1997, Owen Taylor wrote:

> > It will drive you crazy if you have your WM in FocusFollowsMouse
> > mode,
> 
> Yep. And I think that may still (always!) be the majority setting.

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...

[Take in mind that I have been doing X11 programming for about two weeks,
so I'm bound to have missed something that is obvious to you all]

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. 

> >  but the point of it is to make sure the modal window always has
> > focus.
> 
> Not sure why we want this. It's just as important to catch mouse
> events outside the window. Unfortunately, as in all things X,
> there is no uniformity in the implementation of modal dialogs, but
> a quick survey of a few applications revealed some salient features:

(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.) 

> 1. Only events in the topmost modal dialog are processed normally,
> others are either ignored, or in some programs responded to with a
> beep. (But only mouse clicks or key presses should get a beep, not
> enter/leave etc.)
>
> 2. The window is (usually, not always) kept on top of all windows
> (including those of other programs). I'm not sure if this is done
> by setting some type of WM hint, or by responding to Circulate
> Events. 

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). My personal preference would be that
all windows for an application be grouped together in the stacking order.

> We probably should try to stick somewhat close to this model -
> though gtk fortunately doesn't slavishly imitate Motif, it shouldn't
> become too nonstandard for no good reason.

I may look at how motif implements it, as well.

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 :-)

> #2 could be handled pretty much like you've done for focus events -
> create a window type with special handling; #1 should probably be
> handled by generalizing gtk's grabs.

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).

-- Elliot					http://www.redhat.com/
What's nice about GUI is that you see what you manipulate.
What's bad about GUI is that you can only manipulate what you see.