>
> Scott Raney <raney_at_metacard.com> writes:
> > PS: I've just discovered another interesting problem with fvwm that is
> > just more evidence that most people using it are not using real GUI
> > applications very much: it doesn't even enforce modal dialog behavior!
> > Both mwm and olwm have properties that an application sets to indicate
> > that a window is a modal dialog (e.g., an error message) and the user
> > must respond to that dialog before continuing to work with the main
> > window. MetaCard sets both sets of properties, and fvwm is apparently
> > not honoring either of them...
>
> If I remember correctly, then FVWM allows you to enable/disable
> (system) modal dialogs. This is a very good thing! I just hate modal
> dialogs! I cannot image any situation where they would really be
> required. This is especially true for system modal dialogs. In most
> cases, when applications sport modal dialogs, these have seriously
> been getting in my way and they definitly decreased productivity.
All I can find in the 2.0.43 source regarding this is the
"MODALITY_IS_EVIL" #define which just changes the properties a Motif
window (I'm not sure why, perhaps it is just to tell the Motif window
that modal enforcement is not supported).
> In my opinion, modal dialogs show that the application programmer
> mis-designed the application and that he does not understand how to
> program event-driven GUI interfaces. These are relicts from the past
> that should have been removed long ago.
While I'd agree with you that they should be used sparingly, you'll
have even less luck convincing UI designers that they're obsolete than
I've had convincing pointer-focus afficianados that *that's* obsolete
;-) The fact that nearly all apps on MS-Windows and the Mac use modal
dialogs is pretty clear evidence that you're way out on the fringe on
this one.
And from arwild01_at_starbase.spd.louisville.edu (Alan Wild):
> Scott Raney wrote:
> > If you'll take a look at some "real" GUI applications, such as
> > Netscape, most of the CDE tools, and MetaCard, you'll see that they do
> > use modal dialogs. My hunch is that you can cause program crashes and
>
> Hmmm. . well, I'll admit that I am ignorant compared to many of the
> people who frequent this list when it comes X protocol. However, by
> your own assertion, Netscape uses modal dialogs. Now, given my
> ignorance, I am not sure that I have experienced a modal dialog, but
> Would not the Popup that is activated when I selected Options->"General
> Preferences" from the pull-downs be a modal dialog?
>
> If it is, then fvwm handles this correctly, because I have used fvwm
> 1.24 and fvwm2 for about a year and a half and it has ALWAYS behaved the
> same; When this dialog is active, I cannot interact whatsoever with the
> main window.
Well Netscape does seem to *partially* do the right thing. Apparently
they added some internal event-dispatching protection to handle the
case where the window manager doesn't properly handle the modal
request. Still, it's not totally the right thing because the main
window still gets the focus (the window border changes and the
insertion cursor resumes flashing) and no feedback (beep) is given to
the user to indicate that they can't use the main window when they try
to.
> Again, My knowledge is limited, but from my minimal understanding, I
> have not experienced any problems. In fact, I use fvwm2 on Linux, AIX,
> OSF/1 and HP-UX boxes and I have NEVER had the sorts of problems that
> you report.
>
> Personally, I think that fvwm2 is one of the greatest programs ever
> developed. Sure, the source is a bit sloppy and there are bugs, but
> fvwm lets me create attractive, functional desktop across any UN*X box
> I've used and always maintained an efficient level of memory usage.
> Fvwm works the way I like it to, and has outperformed almost every other
> window managers I've demo-ed.
>
> But enough preaching. . . back to the point at hand. Is the dialog box
> I mentioned a modal dialog, and if so, what behavior do you observe that
> is different from what I get?
The problem is that apparently there is no support whatsoever for
modal dialogs in fvwm (that I can find, anyway). The key issue as far
as Motif applications is concerned is that fvwm is not looking at the
"input_mode" member structure stored in the _MOTIF_WM_HINTS atom.
According to the standard include file MwmUtil.h, the _MOTIF_WM_HINTS
atom is a structure with five elements:
long flags;
long functions;
long decorations;
int input_mode;
long status
In decorations.c, fvwm looks at the "decorations" member, but the
input_mode member isn't used anywhere I can find. The values of that
member are one of:
/* values for MwmHints.input_mode */
#define MWM_INPUT_MODELESS 0
#define MWM_INPUT_PRIMARY_APPLICATION_MODAL 1
#define MWM_INPUT_SYSTEM_MODAL 2
#define MWM_INPUT_FULL_APPLICATION_MODAL 3
If there is support for modal dialogs in fvwm someplace I missed, it
shouldn't be hard to add support for the Motif-standard way of
specifying it. If there really is no support, things get a little
more complicated, since all places where the focus is assigned to a
window will have to be modified (mwm doesn't allow the focus to go to
a window at all if a modal transient-for window is open, preventing
the user from getting confused by a window getting the focus and yet
not responding to key or mouse presses). Furthermore, all mouse
buttons need to be grabbed when the mouse is in the window pointed to
by the transient-for prop (mwm beeps when you try to use that window).
> - -Alan
>
> As a side-note: FVWM is not just popular among it's developers and
> Linux users. According to the X11 window manager homepage it is one THE
> most popular window manager across UNIX platforms. If you notice,
> according to this page fvwm, fvwm95, and afterstep (all direct
> descendants of fvwm1.24r) are way more popular among voters than mwm and
> ol(v)wm.
There is obviously a *serious* survey bias problem here: I've never
even heard of "afterstep", yet it is the most popular wm on that
list. The "real world" usage pattern is probably more like 95% mwm
and olwm. We've only recently started getting bug reports about these
MetaCard/fvwm compatibility problems, despite MetaCard having been
available since 1992.
> You can review the numbers yourself at:
>
> http://www.emptysky.com/xwinman/
>
> And although the voting was recently reset, the present results are
> pretty consistent with the results of the list year and a half or so.
I think fvwm is a fine tool, and believe that all the popularity it is
acquiring is a Good Thing. But its growing presence makes it even
more important that it properly support modal dialogs without
requiring apps (or toolkits) to do keyboard or pointer grabs.
There is one more point I should make: this is not just for us as an
application vendor: MetaCard is a GUI *development* tool, which means
that our *customers* are the ones deciding whether or not they need
modal dialogs, not us. Unless you want to tell all of *them* and all
of *their* customers that it's OK that fvwm does not support modal
dialogs, then we should start figuring out how to implement this
functionality. While we're willing and able to help fix the "active
focus" problems, I'm afraid that adding support for modal dialogs is
something that's going to require the attention of somebody that knows
fvwm internals very well.
Regards,
Scott
> - --
> Alan Wild <arwild01_at_starbase.spd.louisville.edu> /T\ f/s/c lou95
> IT-HSC Consultant Speed School Student Council Speed News Guy
> http://www.spd.louisville.edu/~arwild01 or ==> ~triangle/ ~spdnews/ ~sssc/
> Markus
>
> --
> 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.
>
--
***************************************************************
Scott Raney raney_at_metacard.com http://www.metacard.com
Tcl and ksh: syntactic gymnastics
MetaCard: it does what you think
--
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 Sat Oct 26 1996 - 13:48:36 BST