Fvwm bug 1135 keysym documentation, not a bug

[Dan Espen]

I've closed this problem as "not a bug".


I found this comment in the keysymdef.h from the current Xorg release:


! The definitions here should match 
XF86AudioLowerVolume:1008FF11


Therefore I am closing this problem.  The header file should be
updated, not the Fvwm man page.


Date: Fri, 13 Feb 2004 03:37:32 -0600
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: XF86 custom keysyms are also usable

Full_Name: Emmanuel Thom..
Version: 2.4.x and 2.5.x
CVS_Date: 
OS: fedora core 1, kernel 2.6
X_Server: XFree86 4.3
Submission from: (NULL) (152.81.8.127)


Excerpt from the fvwm man page:

Key Keyname Context Modifiers Function
   [...]
   The Keyname is one of the entries from
/usr/include/X11/keysymdef.h,
   with the leading XK_ omitted.
   [...]

This is correct, but under XFree86, it turns out that the XF86
vendor-specific keysyms also work. These are defined in
/usr/include/X11/XF86keysym.h (or, as far as Xlib is concerned, in
/usr/X11R6/lib/X11/XKeysymDB). For example, I have successfully set up the
following binding:

Key XF86AudioLowerVolumeA A Function MMK "AudioLowerVolume"

This means that when you read along the lines of XF86keysym.h,
XF86XK_AudioLowerVolume should really be read as XF86AudioLowerVolume ; the
XK_ prefix isn't in XKeysymDB.

Of course, this is only possibly useful if the running X server does
generate such keysyms, which require some configuration work.

In short, I suggest augmenting the quoted sentence above by  the
following:

Under XFree86, you can also use any of the keysyms listed in
/usr/X11R6/lib/X11/XKeysymDB. You are responsible of having your X
server generating such events.

-- 
Dan Espen   E-mail: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]

bug report FvwmForm non-reproducible

[Dan Espen]

I've moved this problem to "unreproducible".
The action with the button not activating is a feature.
Using the Form FvwmForm-Defaults, you can change buttons
so they activate on a press.

I could not reproduce the button with two labels.

If you have questions about this, respond to fvwm-workers.

Bug report:

Full_Name: Sergey Prohorenko
Version: 2.5.7
CVS_Date: 
OS: Debian Unstable
X_Server: x-window-system_4.2.1-12.1
Submission from: (NULL) (212.44.95.112)


The form is called using:
*FvwmButtons(1x1, Title Logout, Icon 48x48-gnome/window-destroy.xpm, Action
`Module FvwmForm FvwmForm-QuitVerify`) 
(Using modified Debian-blue setup from
http://themes.freshmeat.net/projects/debian-blue/?topic_id=929)

So, after QuitVerify form appears, I press any button (Logout for example)
with left mouse button and then, not releasing it, move mouse cursor
outside the form button. And when it returns to "unpressed" state, text on
it becomes distorted, as if the old one hasn't been cleared. That is, two
labels, one on top of the other, are displayed.
I did not test it with other FvwmForm forms/buttons.

fvwm 2.5.7 is self-compiled using hand-tuned debian build rules (just some
minor tweaking).

-- 
Dan Espen   E-mail: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]