Using keynav as an on-demand program instead of waiting in the background?
Evaryont
instead of drawing the grid, etc, immediately, it waits until it's
configured start keybinding is pressed. Is there a way to disable this
behaviour, and instead immediately draw (then exit) after being
called?
I would also be happy (kinda, I do like having all my keybindings
managed by a single program, external to the WM) if I could bind `Super
+R` (aka the logo key) as the bound key sequence to start keynav.
Super_L+R nor Super_R+R works...
Jordan Sissel
> I'm trying to use keynav as a program started by xbindkeys. Except,
> instead of drawing the grid, etc, immediately, it waits until it's
> configured start keybinding is pressed. Is there a way to disable this
> behaviour, and instead immediately draw (then exit) after being
> called?
I might be misunderstanding what you need here.
What is the difference between these two things:
* having xbindkeys grab super+r and launching keynav started in grid mode.
* having keynav grab super+r and running normally
Seems like the end result and behavior would be the same for both.
Probably would be easy to add a 'start' option to keynav so it does
'start' on startup (and exit when done), but what's the goal? You'd
still have to have all the keynav keybindings within keynavrc, even if
you just remove the need for the start binding.
Still, if I am understanding correctly what you want, adding this
feature should be pretty simple. Let me know if I've understood, and
I'll see what I can do :)
>
> I would also be happy (kinda, I do like having all my keybindings
> managed by a single program, external to the WM) if I could bind `Super
> +R` (aka the logo key) as the bound key sequence to start keynav.
> Super_L+R nor Super_R+R works...
This could be a bug in keynav. "Super_L+R" and "Super_R+R" work for
me. However, the code assumes Super_L and Super_R are Mod4, and this
assumption can be incorrect (Super_R can be any modifier)
Can you show me the output of 'xmodmap' for you?
Here's mine:
% xmodmap | grep Super_
mod4 Super_L (0xce), Hyper_L (0xcf), Super_R (0x6c), Super_R
(0x86), Super_L (0x85)
-Jordan
>
> --
>
> You received this message because you are subscribed to the Google Groups "keynav-users" group.
> To post to this group, send email to keynav...@googlegroups.com.
> To unsubscribe from this group, send email to keynav-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/keynav-users?hl=en.
>
>
>
Colin Shea
On Thu, Dec 24, 2009 at 10:05 AM, Evaryont <co...@evaryont.me> wrote:
> I'm trying to use keynav as a program started by xbindkeys. Except,
> instead of drawing the grid, etc, immediately, it waits until it's
> configured start keybinding is pressed. Is there a way to disable this
> behaviour, and instead immediately draw (then exit) after being
> called?
I might be misunderstanding what you need here.
What is the difference between these two things:
* having xbindkeys grab super+r and launching keynav started in grid mode.
* having keynav grab super+r and running normally
Seems like the end result and behavior would be the same for both.
Probably would be easy to add a 'start' option to keynav so it does
'start' on startup (and exit when done), but what's the goal? You'd
still have to have all the keynav keybindings within keynavrc, even if
you just remove the need for the start binding.
Still, if I am understanding correctly what you want, adding this
feature should be pretty simple. Let me know if I've understood, and
I'll see what I can do :)
The end result may be the same, but call me silly. :) I just like having everything
managed under one 'roof' (XBindkeys) rather than, say, every application trying to
grab it's own keybindings. And I prefer xbindkeys cause I run a light ship. No GNOME
or KDE here. :P
Unfortunetly, I may not have this work fully. I already don't anyways, switching windows
and it's related keybinds are managed by the WM itself. I can't seem to get EWMH things
to work just right.
>
> I would also be happy (kinda, I do like having all my keybindings
> managed by a single program, external to the WM) if I could bind `Super
> +R` (aka the logo key) as the bound key sequence to start keynav.
> Super_L+R nor Super_R+R works...
This could be a bug in keynav. "Super_L+R" and "Super_R+R" work for
me. However, the code assumes Super_L and Super_R are Mod4, and this
assumption can be incorrect (Super_R can be any modifier)
Can you show me the output of 'xmodmap' for you?
Here's mine:
% xmodmap | grep Super_
mod4 Super_L (0xce), Hyper_L (0xcf), Super_R (0x6c), Super_R
(0x86), Super_L (0x85)
-Jordan
xmodmap output:
mod4 Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L (0x80)
Different keycodes, but they are all mapped to mod4...
Jordan Sissel
Sounds fine to me :)
I'll get working on this feature.
>
>> Can you show me the output of 'xmodmap' for you?
>>
>> Here's mine:
>> % xmodmap | grep Super_
>> mod4 Super_L (0xce), Hyper_L (0xcf), Super_R (0x6c), Super_R
>> (0x86), Super_L (0x85)
>>
>> -Jordan
>
> xmodmap output:
>
> mod4 Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L
> (0x80)
>
> Different keycodes, but they are all mapped to mod4...
And your Super_L and Super_R don't show up in any other modifier maps than mod4?
Colin Shea
Super_L and Super_R only appear in the mod4 modifier. Trying "mod4+r start" in
keynavrc doesn't work, either.
Jordan Sissel
Can you run xev, and then press logo+r while the xev window is
focused, and send me the output from xev? For example. mine looks like
this:
% xev | sgrep KeyPress
KeyPress event, serial 28, synthetic NO, window 0x4600001,
root 0x7e, subw 0x0, time 3427315654, (777,444), root:(2458,459),
state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 28, synthetic NO, window 0x4600001,
root 0x7e, subw 0x0, time 3427315870, (777,444), root:(2458,459),
state 0x40, keycode 27 (keysym 0x72, r), same_screen YES,
XLookupString gives 1 bytes: (72) "r"
XmbLookupString gives 1 bytes: (72) "r"
XFilterEvent returns: False
xev kind of outputs a lot, so I use sgrep ("section grep") to only
find output related to keypresses.
The specific data I am looking for is the 3rd line which includes
state and keycode.
State 0x40 == 1<<6 == Mod4Mask in X11/X.h
sgrep lives here, if you want to use it:
http://www.semicomplete.com/scripts/sgrep
-Jordan