Hello fvwm-list,
I've just got a couple of things/questions and possibly a patch.
I was playing around with FvwmProxy, trying to use it as a "poor mans
"expose" ala Max OS X. I don't care about the animations I just want to
be able to quickly select a window when I'm using the mouse. While I was
hacking around with it a few issues popped up.
First issue: when you bind a mouse button with "Mouse <X> A A <Command>"
the binding should be active -everywhere- correct? Windows, Root, etc.
It should work, yes? Also, if the mouse happens to be over a window when
the bound button is clicked should the resulting event be intercepted,
or interpreted and then passed on?
To clarify, I've got a 7 button mouse. I've bound button "6" to bring up
FvwmProxy when clicked. I would like it to do this anywhere as I don't
use buttons 6 or 7 in any application. I did this with:
Mouse 6 A A SendToModule FvwmProxy ShowToggle
This binding seems to work in that when I click button 6 FvwmProxy comes
up no matter where I am. However, if I click button 6 over a window it
seems the event is being intercepted (FvwmProxy does come up) but it is
also being passed to the window below . This is only noticeable in xev
and firefox, where it has the annoying habit of causing me to go back
one page in my history. I've looked into disabling the feature but have
not been able to decipher the possibilities there. I'm just curious if
this is the "correct" behavior for such a binding. I've been using Fvwm
in various versions and incarnations now for some time (something like 8
years) and it has always seemed to me that if I bind a key to the WM
then it will not be passed to the application regardless of focus. I
have never attempted to do a global binding with a mouse button before,
so perhaps the rules are different? Or perhaps the rules are different
because this is above the X11 allowed number of mouse buttons?
I plan on doing a debugging session on this tomorrow (when I'm more
awake) to see if I can figure it out but, as I said, I'm wondering what
the behavior -should- be.
Second, in working with FvwmProxy I was attempting to bind a function to
the mouse click event that would raise the selected window and hide
FvwmProxy. In attempting to do so a couple of things came up. First,
there seems to be a great number of events associated with FvwmProxy
(e.g. Select, Mark, Circulate, Show, Hide, Click[x]) and yet in looking
at the code I have not been able to determine exactly when Select and
Mark are supposed to be called. It has little to do with the mouse
clicks, as the event dispatcher calls the "Click[x]" event actions
directly... anyway, I was again wondering what the -correct- set of
events was supposed to be and when they were supposed to be activated.
Given a little guidance in this area I would be happy to try and clean
up the module a bit.
The other thing I noticed was that the syntax described in the man page
for binding an action to a mouse click did not work. After some time
spent poking around the code and a lot of debug print statements (btw,
what is the best way to debug a module?) I discovered a bug in the way
the "Click[x]" action specifier was being parsed that prevented the new
action from being properly linked to the "Click[x]" event. It is a very
simple fix, requiring the 7th line of the LinkAction function to be
changed like so:
old: i = scanf(string,"%d",&b);
new: i = scanf(token+5,"%d",&b); /* The button number came with the
Click in the token. +5 to get past Click to the number */
this fixes the problem and allows the action to be properly bound to the
event. Now I'm happily working with FvwmProxy configured as I like it.
---
The other area I was interested in was also a bit complicated. First, is
there any conditional command that would allow me to find windows by
their EWMH_WINDOW_TYPE? Something on the order of !Menus or
Type(Desktop) or some such? I don't see it in the man page, I did start
looking at the code, but it is late and it has been a while since I've
done any heavy C programming (not that I mind figuring it out for
myself, I just thought at this point I might as well ask).
Last thing, is there anyway to assign a style when a window is mapped
based on a conditional? Something like:
Style Transient UserDecor smallDecor, NoButton 3, NoButton 8
Ideally I would like to setup user defined styles for Transients, EWMH
Utility Windows, Splash Windows, Etc. I've looked into the man page and
the code, and this seems a) not possible at the moment, and b)
non-trivial to fix. Am I right? Or have I missed something?
Some of the EWMH_WINDOW_TYPES are not even noticed in ewmh.c, that seems
easy to fix, but I'm not sure yet that I understand how or if that info
is used outside of that file. It seems like all the style modifications
for states and types is down there, and so would not be available to the
conditional code or style code used to assign a style when the window is
mapped. Again, I just want to see if I'm reading this correctly. Again,
I'd if these features are not available and may be of interest to others
I would be interested in perhaps creating a patch to enable some of
this, I just don't want to duplicate work or go totally outside of some
other design goals and therefore produce dead end code.
---
Real Last thing, I see in the man page that UseDecor and UseStyle are
marked as "deprecated", has something else already replaced them? Or are
we simply being warned that they will go away sometime in the future?
---
Thank you for your time and thank you in advance for any answers you can
offer. Sorry for the long-winded email, I've been playing around for a
few hours now updating my dusty old Fvwm Config (first time I've touched
it except to add styles for new apps in about 4 years). Anyway, I had a
bunch of questions and I'm not the best at being concise when it's this
late.
Thank you again,
--Doug
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri Jul 02 2004 - 00:30:29 BST