Hi. I know this basically falls under the FAQ of "I would like
really cool feature 'X'", but in this case it is a fairly small
extention of existing capabilities, and it's very useful to me in at
least one case. I assume it might be useful enough to others to
justify the cost of adding it (which shouldn't be great, I don't
think). I wanted to discuss with people more familiar with the design
and current workings of fvwm the idea, tho, and see what everyone
thinks...
The behaviour I want is the behaviour I put into tvtwm into a
function called "RelativeMove". You give it a geometry spec, and it
will operate on the current window. (Or you could select one, if you
invoked it somewhere where that would be necessary). But anyway, I
bind it to a set of keys, so that "Shift-Left", for example, in a
window context will move that window by the specified amount. (I
defined Shift-Left to be +1+0, but it could be anything) Obviously, I
also defined the rest of the arrow keys, at a variety of distances per
move with various modifiers.
I find this very useful for doing precise positioning of a window,
and for the times that do seem to exist where I want to move a window
a few (20-40) pixels out of the way, but don't want to have to go all
the way to the mouse, then find a titlebar/frame/etc, then move it;
all just for 20 pixels so I can read something in another window for a
moment.
Having explained what I want and why, now I wanted to mention what I
think might be an acceptable, and "least-intrusive" method to do the
same in fvwm (2.0.42 is where I am now). I think if the behaviour of
GetTwoArguments (in misc.c) was extended to handle a 'r' (or 'R')
qualifier, in addition to the already special 'p' qualifier, that it
would indicate to the caller somehow that it was to be relative. This
seems gentler than making a new function to do a RelativeMove, and
there are other cases (RelativeResize) where one might want something
similar.
To get this information back to GetTwoArgument's caller, we'd either
have to pass in more arguments, or change the way the val1_unit
argument is dealt with. Not just use it as a divisor all the time,
like it is now. This is the short-term solution I took to make it
work for Move for me right now. But, I didn't modify the behaviour of
the other things that call GetTwoArguments, and that would definately
have to be done so they wouldn't choke on an odd value of
val1_unit/val2_unit being returned.
I'd be happy to hear anyone else's opinions on this, and any
suggestions you have. I'd be happy to implement whatever we decide on
if anyone would like me to.
(and yes, I did subscribe to this list before posting this; so I
could hear discussions about current developments...)
- Chris
--
Chris P. Ross Pubnix systems (a division of
cross_at_va.pubnix.com UUNET Technologies, Inc.)
cross_at_uu.net
--
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 Dec 13 1997 - 01:06:28 GMT