>>>>> "SR" == Scott Raney <raney_at_metacard.com> writes:
>> Good guess. I don't plan to change the default, although for what
>> it's worth I actually use ClickToFocus as my focus policy so changing
>> the default wouldn't bother me in the least.
>>
>> But I see no compelling arguement to change this default at this
>> point. It has been in there since the dawn of fvwm (and into it's
>> ancestor twm as well, if I remember correctly). If people don't like
>> it, they can change it individually.
SR> But only if they spend a lot of time wading around in config files
SR> (which new users especially are loath to do).
I'd say that depends on the person, but is probably generally true for
people who tend to be non "power users" of their tools. But what is
the biggest response to newbie questions? RTFM. They may be loath to
do it, but must learn sometime...
SR> I recommend adding a button in the default root menu to change the
SR> focus model
I think this is a good idea. It shouldn't be too bad to create a
simple menu to configure some simple things like that. I'll see about
putting one in the next beta.
SR> (CDE and HP's Vue both come with preferences dialogs that allow
SR> you do make this change without reading a manual).
Just as a side note, FvwmConfig (in the extras dir) and The Dotfile
Generator can both be used to configure aspects of fvwm in an
interactive way, although I have to admit that I haven't really even
looked at either. :) The latter supports fvwm 1.xx as well.
Dan> The "sample.fvwmrc" that comes with fvwm2, already assumes a
Dan> default focus policy and supplies overrides of clicktofocus for:
Dan> FvwmButtons, xbiff, Maker, Appointment, xcalc, xman, xvgr,
Dan> matlab, xmag, xgraph, sppeed6, and xmosaic.
SR> Sounds like apps that work best with explicit focus are actually very
SR> common. This is evidence that explicit should be the default, and
SR> xterm should have a pointer focus override...
Actually, I believe that the reason Rob put (most of) those in there
is because he never really wanted the focus to go to those while he
was moving the cursor about, particularily with sloppy focus, which I
believe he used. I think that was also the motivator behind per
window focus policies to begin with.
Dan> Any change to the default would break every .fvwm2rc file around.
>> Probably a safe bet.
SR> Maybe for fvwm 3 ;-)
Perhaps, but isn't that thinking a bit far ahead since I haven't even
managed to get an official version of 2.xx out? ;^)
Dan> My guess is that a POLITE request from the metacard people for
Dan> metacard to be added to the the clicktofocus list in the
Dan> "sample.fvwmrc", might be granted.
>> Certainly. Just need to know the window classes/resources to use in
>> the style lines. And it would be easy for MetaCard to provide this
>> info as well in the README that Scott said they already supply telling
>> how to put other window managers into ClickToFocus mode.
SR> The window class name is "MetaCard", but when I tried using the
SR> override it doesn't seem to make things much better.
Hm. Well, I'll put that in the list anyways. Do all of your
subwindows have that same class name as well?
>> But, on a related note and partly what Scott's original note dealt
>> with, I do need to verify that fvwm is handling the 4 input handling
>> policies correctly according to the ICCCM, which I'm not 100% certain
>> that it does.
SR> It doesn't, and when using the default configuration ("sloppy
SR> focus"?) MetaCard is basically unusable with fvwm2. Changing the
SR> default to clickToFocus improves things somewhat, but there are
SR> still serious problems.
Well, according to what you said your app is Globally Active, which is
the one input policy that I was really thinking might not be being
handled correctly. But I would not have imagined that it could make
any application unusable...
SR> The latest release of fvwm2 actually seems worse in general than
SR> 1.X was.
I assume you mean with respect to MetaCard. If not, I'd like to know
what you feel the other problems are with it.
>> So, if anyone out there has observed any violations of these
>> conventions that seem to need to be fixed in fvwm, please let me know
>> the details.
SR> I would be happy to help you work through these, and the problem about
SR> the missing configure notify message when an app raises its menu bar
SR> window. Here is my original report agains 1.24r, and all of these
SR> problems also exist in 2.0.43:
I do have your original note, but didn't get a chance to reply before
my mailbox got flooded and finding the time to reply to long notes is
difficult sometimes... I guess I'll reply now.
....
SR> 1) In the explict/click-to-type focus model, clicking in a window
SR> incorrectly automatically moves the keyboard focus to that window.
SR> The focus should remain in the source window until the application
SR> specifically requests it with XSetInputFocus.
Actually, this is true only for Locally & Globally Active windows
(those that have WM_TAKE_FOCUS defined) such as your application.
This is basically the situation that I thought fvwm might not be
handling correctly, although I haven't really investigated it yet.
I'll look the code over before the next beta and see if I can find any
holes.
....
SR> 2) In the pointer focus model, moving the mouse to a window doesn't
SR> always focus that window. Reproduce by opening the MetaCard
SR> Message Box and moving the mouse back and forth between it an the
SR> Home stack. Sometimes MetaCard thinks it has the focus (the
SR> cursor flashes in the Message Box) even when it doesn't,
SR> indicating either a missing FocusOut event, or the WM dropping (or
SR> getting confused by) MetaCard's XSetInputFocus call.
This seems a bit odd. I guess I may actually have to download
MetaCard to check this out, which I was hoping to avoid.
SR> 3) Calling XRaiseWindow does not cause a configureNotify event to be
SR> sent to the application like it does with mwm.
Hm. Are you sure this is supposed to happen? I just used xev to
watch the events being sent to a window that I was manually raising
and lowering, and under both fvwm and mwm NEITHER actually showed a
ConfigureNotify event happening (basically just visibiltynotify
events). Now, I was doing this under xmx, perhaps if I run them
normally...nope - same behavior that way. I did see ConfigureNotify
events if I moved them though, but not when I raised them.
SR> PS: I had some trouble getting fvwm2 set up and working, due
SR> primarily to the fact that the installation program doesn't
SR> install a system.fvwm2rc file, the fact that you changed the name
SR> of the file yet supply only samples without the "2" in them,
Whoops - forgot to make that symbolic link, like I did with the man
page. That'll be corrected for the next beta.
SR> the fact that the sample "system.fvwmrc" has "restart" wrong for
SR> fvwm2,
Another thing that slipped by - also will be corrected for the next
beta. A side note, I'd like to enhance (clean up) Restart so if there
are no parms (or if it's say just a '-') that it will restart using
argv[0], so you don't need to know if it was named fvwm or fvwm2.
I'll try and get this into the next beta as well.
SR> and the fact that both the samples start up a bunch of things that
SR> don't work on the system I installed it on (a Linux 1.2.13 system
SR> (Caldera's)).
That I'd believe. But they are samples after all and should probably
be customized before being installed at the end site. Perhaps I
should make a "bare bones" version as well and make that the default,
and spell out what I just said explicitly in the INSTALL file.
Damn, this took way too long to type. Gotta run!
Chuck
*******************************************************************************
Charles K. Hines <chuck_hines_at_vnet.ibm.com>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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 Thu Oct 24 1996 - 16:17:59 BST