On Tue, Mar 14, 2000 at 02:22:57PM +0000, Tim Phipps wrote:
> "Jan T. Kim" wrote:
> >
> > Hi all,
> >
> > here's a quick question: Is it possible to raise a window and rotate it
> > to the top of the windowlist without having to give that window the
> > keyboard focus?
>
> No. The windowlist is always headed by the window that has focus and is
> used as the starting point for next/prev commands in functions.
Ok. Does this imply that the root window is in the window list, and is
just skipped by the Next and Prev commands?
> The focus command has to work no matter what focus style is used or it
> would be useless. MouseFocus just means that an implicit focus command
> is run every time the mouse enters a window. ClickToFocus does the focus
> command when the mouse is clicked on a window.
> > Key Next R N Function Next-Focus-and-Raise
> > AddToFunc Next-Focus-and-Raise "I" Next [*] Raise
> > + "I" Next [*] Focus
> >
> > This works once, but not repeatedly. Somewhat weirdly, the the Focus
> > command gives the keyboard focus to the target window, even though
> > this is inconsistent with MouseFocus if the mouse pointer is over the
> > root window.
>
> The focus command has to work no matter what focus style is used or it
> would be useless. MouseFocus just means that an implicit focus command
> is run every time the mouse enters a window. ClickToFocus does the focus
> command when the mouse is clicked on a window.
This means that fvwm's focus policies are built on top of the functionality
that is accessible with the Focus command? Thanks for this info. If I
understood this correctly, then the question would become: Is there a
command which I could use to reclaim the focus for the root window? E.g.
could I simulate a mouseclick at the current position? Or is there some
generic name or classname for the root window, that I could append a line
like
+ "I" Next [Root] Focus
to the Next-Focus-and-Raise function shown above?
> Correct. The key binding is for the root context only, it means it is
> active when no window has the focus, it doesn't mean active when the
> mouse is in the root window. If you want that you could bind a mouse
> button:
Ok, but all three mouse buttons are used for popup menus. It's true,
though, that I don't use them that frequently. Furthermore, now that I
think of it, I like the idea of using the mouse instead of the keyboard
as I have to move the mouse onto a patch of root window anyway. Thanks
for pointing this out.
> A solution for (2) is to use a more convenient key binding. I use KP_Add
> and KP_Subtract. I haven't found a program yet thatneed these and can't
> use the normal plus/minus keys.
This is a matter of habits, I guess -- xcalc is perfectly happy with the
normal plus and minus keys, but personally, I find it more convenient to
use the keypad with xcalc...
> (1) is difficult. As you have found you can't have keyboard driven
> circulation without moving the focus, therefore you have to take those
> keys away from applications.
An alternative might be to take the focus away from the applications
after briefly giving it to them (as already mentioned above).
Greetinx, Jan
--
+- Jan T. Kim -------------------------------------------------------+
| email: kim_at_mpiz-koeln.mpg.de |
| WWW: http://www.mpiz-koeln.mpg.de/~kim/ |
*-----=< hierarchical systems are for files, not for humans >=-----*
--
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 Tue Mar 14 2000 - 09:25:15 GMT