>>>>> Brady Montz writes:
Brady> As you know, there are three ways you can specify a button:
Brady> abolutely (like button 4), relative to the focused button, or
Brady> relative to the selected button. In the current state of
Brady> things, when the cursor is outside of the manager window,
Brady> there is no selected button, so you can't use that in your
Brady> SendToModule command, and that's what you (and I) would like
Brady> to be able to do. I left that ouy cause I couldn't decide
Brady> which would be better: to remember what the last selected
Brady> button was, and use that if none is selected, or start at
Brady> someweel known place, like button 0.
I think I don't really want to start from the button that has last
been selected. Here's what I want:
- Simple case: There is a window that has focus and it is displayed
in IconMan. In this case, start moving relative to the button
corresponding to the window that currently has focus.
- Complicated case: No window has the focus or the window that has
focus isn't displayed in IconMan. In this case, the best thing
would be, I guess, to remember which of the windows displayed in
FvwmIconMan last had focus and to start moving relative to that.
I think this is a rather intuitive behavior, especially for the
"simple" case. For the complex case, one could imagine a different
behavior: pretend the window that currently has focus were inserted
into the IconMan and start moving relative to that position (which is
between two buttons, of course). For an alphabetically sorted list,
this could conceivably be what someone wants, but I find it strange.
Brady> The other problem with using the focus button for this is
Brady> that you can't give the focus to an iconified window, so any
Brady> iconified window will act as a barrier.
I didn't want to move the focus, I wanted to move the selection and
have a key that focuses the selected window. To clarify: suppose the
button corresponding to the window that currently has focus is red;
suppose the selected button is green. Suppose further that the
IconMan contains buttons for windows A to E in that order, and that C
is red (ie has focus). Suppose I hit CursorUp, then I want the red
button to disappear, and I want B to be green. Then hitting
CursorDown should move the green to C, then to D. Then hitting Return
should focus D so that D becomes red. See?
Brady> I'm probably going to switch to using the syntax that the
Brady> Next and Prev commands use, but I still haven't figured out
Brady> an elegant way to handle the complications of: specifying the
Brady> "current" button from which the command is relative, and
Brady> specifying the manager as well as the window.
I have no strong feelings about the syntax. Choose whichever syntax
you like. As long as there is an example in the man page that shows
me how to get what I want, I'm happy :-)
Did I explain clearly enough so that you can understand what I'm
trying to say? What do you think about my suggestion? Can this be
implemented?
regards,
kai
--
Life is hard and then you die.
--
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 Wed Oct 02 1996 - 02:39:19 BST