,--
| > Now, take the mouse and quickly slide it to the bottom border of the
| > xterm and click the left button. Since the mouse is in the window's
| > border region, it SHOULD perform the Mouse 1 action associated with
| > the window side (in my case, Raise-or-Resize). Unfortunately, what it
| > does is perform the action associated with clicking in the root window
| > (in my case, popping up a "Root Menu").
| >
| > I've looked at the code in virtual.c, and it appears that fvwm creates
| > four windows around the edge of the screen that it uses strictly for
| > "input notification" to tell when the mouse has entered one of these
| > four "invisible" windows around the edge of the screen (they are 2
| > pixels wide). I think somehow these windows are interfering with the
| > desired action, but that is just a guess.
|
| Try to comment out the following line in the file 'misc.c' under
| the directory 'fvwm-2.0.46/fvwm'
|
| void RaiseWindow(FvwmWindow *t)
| {
| ....
|
| /* raisePanFrames(); */
| }
|
| and recompile fvwm2. I guess here is the only place raisePanFrames
| is called. Hope this helps.
`--
Unfortunately, this did NOT have any affect, from what I could tell.
The one thing that did have an effect was changing the
PAN_FRAME_THICKNESS in fvwm.h from 2 to 0 and recompiling.
Of course, a thickness of zero on the pan frames means you cannot use
the mouse to change virtual screens; you must rely on FvwmPager or
key bindings.
I would like to see a solution that allows both; I can see no reason
where clicking on the border of a window should not perform the action
associated with clicking on the border. Why a window-border click is
being treated as a root-window click makes no sense to me and seems
very broken.
Eddy
--
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 Mon Mar 16 1998 - 12:38:07 GMT