Scott,
(and the fvwm list; I include this because there may be programmers out
there who see ways to implement what may be worthwhile in what I have to
say. I will contribute no more to this thread, but I'm trying to be
constructive in this addition.)
Not to bash anyone or anything like that, but to my feeble understanding,
the dialog boxes you seem to be talking about are graphically disjoint
from the main window. The features you seem to be favoring include the
dialog boxes logically in the main window focus (presumably a
multi-tasking machine is involved here and one should be able to receive
mail and such things without closing the application of primary interest),
but it should be possible to transfer the focus to another window.
The ability to type into a dialog box which has snatched the focus from
the main window (we might choose to view it as an appendage of the main
window, attached by virtue of its being really the same application) is
useful. But the fact that the dialog and main window are separated is
really an artificial thing. If you have used (for instance) tcl/tk to
generate windows, you know that events calling for input information or
display features can result in either calling up another window or in
extending or otherwise repacking the existing window. You may pass the
focus around among the sub-widgets as you please. The features you
mention seem to treat the dialogs as somehow extensions of the main
window, and you should be able to do the same thing even if they live in
different windows.
Any implementation of pointer focus which forced each subwindow of an app
to be treated independently of its parent, and on equal footing with any
other window, *could* disable this feature. I believe that the X wm
standards do not do this. The X windows standard seems to allow dialogs
to be ignored by the window manager. Can't you as the programmer
(institutionally) take the input focus which remains with the main window,
and knowing what dialog was requested, feed the input stream to that
dialog? When you sense the dialog getting explicit focus or the main
window losing it as a result of a user's direct mouse actions, you could
go back to the other way of doing things. Since the dialog is truly a
child of the parent process, they should have access to the same
information. There seems to be no necessary conflict with either
click-to-focus or pointer-focus paradigms.
> No, you click on a button (or choose from a menu, or activate a menu
> item with a mnemonic or accelerator) and it opens a dialog that gets
> the focus. You then type whatever you want and then close it by
> pressing return, upon which the dialog closes and focus returns to the
> application window that had it before. This is the most standard
> operating method of modern GUI applications, and it just doesn't work
> very well with pointer focus.
You seem to insist that in pointer-focus mode, there is no way to get the
info for the dialog without transferring focus to the sub-window. This
seems to be a programming obstacle, not a window manager matter. Today's
commonly used techniques are not those of a decade ago, and today's
techniques stand about as much a chance of being those of a decade from
now. Developing programming techniques to handle both pointer- and
click-focus would give you a headstart for tomorrow's work. It shouldn't
be a great obstacle, unless the program really can't know which window
has focus. In which case the standards should maybe be modified. But
then again, Scott's first message mentioned an apparent ConfigureNotify
event failure from fvwm....
Michael Tiefenback
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Oct 23 1996 - 16:36:16 BST