Draw Grid in Currently Focused Window
Nazri Ramliy
somewhere in the currently active window.
Attached patch draws the initial grid confined to the currently active
window, written on top of my 'alternate-navigation' patch.
The attached 'alternate-navigation' patch is slightly different with the
one I originally sent to the list - better precision, alphabet only
instead of numerical+alphabet grid label.
Put an entry like the following in .keynavrc to see it in action, after
applying both patches on top of keynav-20091108:
ctrl+semicolon start, focused-grid
There are some ugly artifacts when the grid size is reduced using the
'h' (left) and 'k' (up) but I don't know how to fix that because my Xlib-fu
skill is very near to zero. Ugliness aside, keynav is good for my wrist so
I'm willing to live with that artifacts.
Nazri.
P.S: For the alternate navigation patch there is a bug where keynav
could segfault if you reduce the grid and select (click) a grid quickly
before the grid is fully redrawn.
Jordan Sissel
> When I use keynav most of the time I want to use it to click on
> somewhere in the currently active window.
>
> Attached patch draws the initial grid confined to the currently active
> window, written on top of my 'alternate-navigation' patch.
>
> The attached 'alternate-navigation' patch is slightly different with the
> one I originally sent to the list - better precision, alphabet only
> instead of numerical+alphabet grid label.
>
> Put an entry like the following in .keynavrc to see it in action, after
> applying both patches on top of keynav-20091108:
>
> ctrl+semicolon start, focused-grid
>
> There are some ugly artifacts when the grid size is reduced using the
> 'h' (left) and 'k' (up) but I don't know how to fix that because my Xlib-fu
> skill is very near to zero. Ugliness aside, keynav is good for my wrist so
> I'm willing to live with that artifacts.
>
> Nazri.
>
> P.S: For the alternate navigation patch there is a bug where keynav
> could segfault if you reduce the grid and select (click) a grid quickly
> before the grid is fully redrawn.
>
this week). :)
-Jordan
Yuri D'Elia
Jordan Sissel <j...@semicomplete.com> wrote:
> > The attached 'alternate-navigation' patch is slightly different
> > with the one I originally sent to the list - better precision,
> > alphabet only instead of numerical+alphabet grid label.
> >
> > Put an entry like the following in .keynavrc to see it in action,
> > after applying both patches on top of keynav-20091108:
> >
> > ctrl+semicolon start, focused-grid
(focused-grid 3x3?). Does the grid labels use the currently setup
bindings?
> > There are some ugly artifacts when the grid size is reduced using
> > the 'h' (left) and 'k' (up) but I don't know how to fix that
> > because my Xlib-fu skill is very near to zero. Ugliness aside,
> > keynav is good for my wrist so I'm willing to live with that
> > artifacts.
keynav :)
- The grid should probably be drawn in XOR'ed mode (the 3 pixels width
does eat a lot of space)
- You still cannot click 'through' the grid: if you move the mouse over
the grid, and attempt a click (with a keynav binding or though the
real thing) it's still sent to keynav, not to the underlying
application. This especially happens if you reduce the grid area a
lot: with a 3x3 grid, you can get up to a point (very quickly) where
you cannot 'click' anymore by using a 'click [123]' action *unless*
you also remove the grid by 'end'ing.
If Jordan remembers, I was asking for 'click [123]' to avoid warping,
so that I could use keynav to perform clicks without exiting (for
driving menus or other stuff that requires nearby clicks). In the last
version this feature works correctly, but it doesn't play well with GTK
menus: if you start keynav, move the pointer over a menu and 'click 1',
you will see that the menu gets highlighted (the click is sent to the
application), but the menu doesn't appear -> it's shown as soon as you
exit keynav. This is probably a 'grab' issue... I'm just mentioning
this here for posterity.
A minor note is that tooltips still go over the grid.
Thanks again everyone. I couldn't use the computer the same way without
it anymore.
Nazri Ramliy
> (focused-grid 3x3?).
certain width and height for the cell depending on the size of the focused
window. In my current local modified keynav i've made it so that you can
specify the grid MxN or ask it to go auto. New patch coming soon, after I fix
bugs related to xinerama stuff introduced by my latest patch:
1. Grid won't be drawn correctly on top of currently focused window if the
window overlaps viewport or goes over viewport boundaries (IIRC).
2. The behavior of moving Grid after invoking cmd_focused is not consistent
with the one after invoking cmd_grid.
> Does the grid labels use the currently setup
> bindings?
alphabet for selecting a grid grid crossing, and apostrophe + alphabet +
alphabet for selecting the center of a cell (right, up side relative to the
grid crossing). To illustrate, best viewed in fixed-width font:
p|q p|r
----+----------------------------------+----
| |
| |
| x |
| \ |
| apostrophe + q + q |
q|q q|r
----+----------------------------------+----
|\ |
\
comma + q + q
> - The grid should probably be drawn in XOR'ed mode (the 3 pixels width
> does eat a lot of space)
:) the grid lines are drawn similar to twm's cells that appear when you run a
new X11 GUI app where you are given a skeleton frame with 3x3 cells and you
move the mouse to position and resize it to tell twm where you want the window
to be mapped, anybody remember that?. Hmmm twm's source might be a good source
to get inspiration for this.
> - You still cannot click 'through' the grid: if you move the mouse over
> the grid, and attempt a click (with a keynav binding or though the
> real thing) it's still sent to keynav, not to the underlying
> application. This especially happens if you reduce the grid area a
> lot: with a 3x3 grid, you can get up to a point (very quickly) where
> you cannot 'click' anymore by using a 'click [123]' action *unless*
> you also remove the grid by 'end'ing.
> Thanks again everyone. I couldn't use the computer the same way without
> it anymore.
flat on my back browsing on the big screen with my keyboard on my stomach and
mouse far far away.
Talk about user friendliness!
Nazri.
Nazri Ramliy
> :) the grid lines are drawn similar to twm's cells that appear when you run a
> new X11 GUI app where you are given a skeleton frame with 3x3 cells and you
> move the mouse to position and resize it to tell twm where you want the window
> to be mapped, anybody remember that?. Hmmm twm's source might be a good source
> to get inspiration for this.
current one.
In the current way the grids kind of flicker when they are resized.
Nazri
Nazri Ramliy
> New patch coming soon, after I fix bugs related to xinerama stuff introduced
> by my latest patch:
patches (git-format-patch rocks!) I sent earlier:
0001-Lotsa-holes-Alternate-navigation-labeled-grid.patch
0002-cmd_focused_grid-draw-grid-in-currently-focused-wind.patch
> 1. Grid won't be drawn correctly on top of currently focused window if the
> window overlaps viewport or goes over viewport boundaries (IIRC).
> 2. The behavior of moving Grid after invoking cmd_focused is not consistent
> with the one after invoking cmd_grid.
there's no limit as to where your keynav window can go. Freedom baby!
After trying out stuff I found that limiting the keynav window for
focused mode so that it behaves the same as like non-focused window mode
is more trouble than it's worth. It's just easier to give the full
control to the user. If the window moves outside of the viewable area
then he/she can always move it back into view or just rerun the
grid/focused-grid command.
To try out the focused-grid feature put the following in your
~/.keynavrc:
--- >8 ---
# Let keynav calculate grid row and columns based on the size of the
# focused window:
ctrl+semicolon start, focused-grid auto
#
# Or specify the approximate width and height of each cell you want:
# ctrl+semicolon start, focused-grid auto:100x50
# (default cell size is 100x70)
#
# Or specify the row and column explicitly:
# ctrl+semicolon start, focused-grid 5x5
#
# In all cases the grid size is limited to 26x26 so that each grid row
# and column gets one unique letter of the alphabet.
j move-down .01
k move-up .01
l move-right .01
h move-left .01
1 warp,end,click 1
2 warp,end,click 2
3 warp,end,click 3
--- 8< ---
And as for the ugly artifact issue:
On Wed, Dec 2, 2009 at 6:01 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
> There are some ugly artifacts when the grid size is reduced using the
> 'h' (left) and 'k' (up) but I don't know how to fix that because my Xlib-fu
> skill is very near to zero. Ugliness aside, keynav is good for my wrist so
> I'm willing to live with that artifacts.
j move-down .01
k move-up .01
l move-right .01
h move-left .01
instead of:
j cut-down .99
k cut-up .99
l cut-right .99
h cut-left .99
leaves no artifacts!
I'm happy!
Nazri.
Nazri Ramliy
1. 0001-Lotsa-holes-Alternate-navigation-labeled-grid.patch
There's a bug in my previous patch where if you have ctrl+comma and
ctrl+apostrophe in your keynavrc it does not trigger anything. My
new patch fixes this (attached).
2. 0002-Focused-grid-draw-grid-in-focused-window-or-a-given-.patch
I've also refactored the implementation of focused-grid and made it
more flexible where you can make keynav to appear on top of the
currently active window or at an explicit location and size using the
widthxheight+x+y X-window geometry notation. See the Synopsis in the
patch for the documentation on how to use this feature.
As for the command name, "focused-grid" may not be a good one but I
can't think of a better name to reflect it's functionality.
Using the explicit location and size feature I can create a shortcut
for keynav to appear on top of the subscription list in my google
reader. This is much faster (read: no flicker) than having it cover
the whole of the browser window.
3. 0003-bugfix-move-at-least-one-pixel-when-the-resulting-va.patch
This is a bugfix - When the value calculated from the percentage is
to small it gets casted to 0 as integer, which resulting in keynav
not moving the window at all, which is not nice.
4. 0004-Dejavu-Re-run-previous-click-at-previous-clicked-loc.patch
New command - "save-dejavu" and "dejavu". This is for remembering
a certain location and click so that we can re-click that same
position later on without having to manually warp to that location.
See the 'Example use case' usage instruction.
Nazri
Jordan Sissel
feature. Feels like we could extend the dejavu thing and allow you to,
at run time, create multiple dejavu points that, again at runtime, are
bound to certain keystrokes - like vi macros that you can record and
replay.
Other comments -
* "get_focused_frame" can be removed in favor of xdo_window_get_active
(see cmd_windowzoom)
* In parse_focused_grid_arg, rather than computing the geometry, etc,
you can just call cmd_windowzoom(NULL), though, that may complicate
things with the way it's implemented.
Lastly, one of these patches breaks screen edge hugging (where the
grid will stop along the screen edges).
Looks good, though, so far.
About coordinating these changes: I've put keynav on github just now
and created a branch called 'altnav' with your patches, unmodified. If
you have a github account, I can probaly grant you commit access so we
can more easily hack on this.
http://github.com/jordansissel/keynav/tree/altnav
-Jordan
Nazri Ramliy
> I like all of the ideas here, especially the dejavu/save-this-thing
> feature. Feels like we could extend the dejavu thing and allow you to,
> at run time, create multiple dejavu points that, again at runtime, are
> bound to certain keystrokes - like vi macros that you can record and
> replay.
making its behavior mirror that of vim's is just natural.
> Other comments -
> * "get_focused_frame" can be removed in favor of xdo_window_get_active
> (see cmd_windowzoom)
> * In parse_focused_grid_arg, rather than computing the geometry, etc,
> you can just call cmd_windowzoom(NULL), though, that may complicate
> things with the way it's implemented.
> Lastly, one of these patches breaks screen edge hugging (where the
> grid will stop along the screen edges).
> About coordinating these changes: I've put keynav on github just now
> and created a branch called 'altnav' with your patches, unmodified. If
> you have a github account, I can probaly grant you commit access so we
> can more easily hack on this.
I'll see what I can do here.
Cheers!
Nazri.
Nazri Ramliy
> On Mon, Dec 7, 2009 at 4:15 PM, Jordan Sissel <j...@semicomplete.com> wrote:
>> Other comments -
>> * "get_focused_frame" can be removed in favor of xdo_window_get_active
>> (see cmd_windowzoom)
>> * In parse_focused_grid_arg, rather than computing the geometry, etc,
>> you can just call cmd_windowzoom(NULL), though, that may complicate
>> things with the way it's implemented.
>
> I'll see what I can do about the above. Reduced code is better code.
it does not cover the window manager title bar and borders. While this is fine
when the title and borders are not there (common in tiled window managers), I
think it is desirable for cmd_windowzoom to cover the border and
window title too
if they are present.
I have not tested get_focused_frame whether it behaves well when there's no
title and border. The core part of get_focused_frame (the while loop) is
copied verbatim from xwininfo.c from x11-utils ubuntu source package (on
licensing side maybe the copyright stuff mentioned at the top of xwininfo.c
should be included in keynav.c as well, to comply with their licensing
requirements). I think keynav and xwininfo's licence are basically the same so
there should be no issue if you decide to use that.
>> Lastly, one of these patches breaks screen edge hugging (where the
>> grid will stop along the screen edges).
>
> I'll look into this as well.
it (haha). While fixing the 'edge hugging' issue I noticed logic errors in
keynav.c and it is repeated in many places throughout the file:
if (appstate & STATE_ACTIVE == 0)
If my C-fu is correct the '==' operator has higher precedence than the '&'
operator hence the effect of the above statement is actually:
if (appstate & (STATE_ACTIVE == 0))
which is not the same as what I think the intention is:
if ((appstate & STATE_ACTIVE) == 0)
which is better written as:
if (!(appstate & STATE_ACTIVE))
because it's more readable, at least to me. I'm not attaching any patch here
because I'm not sure if the patch should be against keynav 20091108 or
the altnav tip. Either way the fixes are easy to implement in vim:
$ vi keynav.c -c '%s/\(appstate & STATE_ACTIVE\) == 0/!(\1)/ | wq'
>> About coordinating these changes: I've put keynav on github just now
>> and created a branch called 'altnav' with your patches, unmodified. If
>> you have a github account, I can probaly grant you commit access so we
>> can more easily hack on this.
>
> Cool! I had an account once, but it's been a long time that I accessed it.
> I'll see what I can do here.
I've cloned keynav github repo and noticed that the remotes/origin/altnav has
all the four patches committed as a single commit. Maybe it's better if you
could mangle that branch so that there are four commits instead - one for each
patch? (rebase, remove that one commit and then git am <all four of my
patches>)
The main reason is so that it's easier in the future to track down which of my
four patches introduce other (still) hidden bugs.
And one last tidbit: When/If you reapply my patches, before applying the
patches, could you change the email addresses inside the patches to my gmail
address:
perl -p -i -e 's/From:.*/From: Nazri Ramliy <ayiehere\@gmail.com>/' 000[1234]*
The email na...@myfamilyhealth.com is an outdated work email which may or may
not work anymore. Thanks.
Regards,
Nazri.
Jordan Sissel
to hack there.
My git-fu is pretty weak (I've never used it) and I'm otherwise
occupied with sysadvent this month. So it might be January before I'm
able to do much other than test your patches.
-Jordan
Nazri Ramliy
> I gave you commit access to the keynav repo on github. You're welcome
> to hack there.
> My git-fu is pretty weak (I've never used it) and I'm otherwise
> occupied with sysadvent this month. So it might be January before I'm
> able to do much other than test your patches.
Since I have a commit access to your keynav repo on github, I'll push my
patches to a new branch there.
I'm confident that you'll find git fun to learn and work with.
Once your git-fu is up to speed, you can choose the appropriate workflow for
keynav.git from the ones listed in the progit book:
http://progit.org/book/ch5-1.html
Regards,
Nazri.
Jordan Sissel
> On Wed, 2 Dec 2009 02:05:20 -0800
> Jordan Sissel <j...@semicomplete.com> wrote:
>
>> > The attached 'alternate-navigation' patch is slightly different
>> > with the one I originally sent to the list - better precision,
>> > alphabet only instead of numerical+alphabet grid label.
>> >
>> > Put an entry like the following in .keynavrc to see it in action,
>> > after applying both patches on top of keynav-20091108:
>> >
>> > ctrl+semicolon start, focused-grid
>
> Sounds immensely useful. Does it allow to setup a custom grid?
> (focused-grid 3x3?). Does the grid labels use the currently setup
> bindings?
>
>> > There are some ugly artifacts when the grid size is reduced using
>> > the 'h' (left) and 'k' (up) but I don't know how to fix that
>> > because my Xlib-fu skill is very near to zero. Ugliness aside,
>> > keynav is good for my wrist so I'm willing to live with that
>> > artifacts.
>
> I would like to add that there are still some issues I have with
> keynav :)
>
> - The grid should probably be drawn in XOR'ed mode (the 3 pixels width
> does eat a lot of space)
Spent some time hacking on this tonight. I read about how to do this
in the X11 manuals, twm's source, and wmii's source, and I was still
completely unsuccessful drawing in XOR'ed mode. Not sure what I was
doing wrong, but I gave up for tonight :)
According to the docs, to actually draw in XOR mode you have to:
- draw on the root window
- XGrabServer() throughout the drawing
The 2nd one is what concerns me. Doing XGrabServer will block all
other events to other clients in the server, blocking interactivity
and other stuff (especially dragging and clicking) while the server
grab is held.
It's possible I can support this, but the server grab would be not
default. Most of this hinges on a functioning XOR graphics
implementation. I'll take patches or even sample code, but given the
circus of failures from tonight, I think I'll defer working XOR myself
until some other features get finished (macro recording, mouse cursor
pixel clipping (see below), etc).
> - You still cannot click 'through' the grid: if you move the mouse over
> the grid, and attempt a click (with a keynav binding or though the
> real thing) it's still sent to keynav, not to the underlying
> application. This especially happens if you reduce the grid area a
> lot: with a 3x3 grid, you can get up to a point (very quickly) where
> you cannot 'click' anymore by using a 'click [123]' action *unless*
> you also remove the grid by 'end'ing.
This can be fixed by making sure the pixel under the mouse is always
clipped clean (just like the grid areas and the center are today).
Shouldn't be too difficult to do this. I put it on the todo list ;)
>
> If Jordan remembers, I was asking for 'click [123]' to avoid warping,
> so that I could use keynav to perform clicks without exiting (for
> driving menus or other stuff that requires nearby clicks). In the last
> version this feature works correctly, but it doesn't play well with GTK
> menus: if you start keynav, move the pointer over a menu and 'click 1',
> you will see that the menu gets highlighted (the click is sent to the
> application), but the menu doesn't appear -> it's shown as soon as you
> exit keynav. This is probably a 'grab' issue... I'm just mentioning
> this here for posterity.
Yeah, popups generally invoke XGrabKeyboard or XGrabPointer. For
example, in Google Chrome linux, if I attach via gdb:
(gdb) break XGrabPointer
Breakpoint 1 at 0x7f659a826500
(gdb) break XGrabKeyboard
Breakpoint 2 at 0x7f659a8262e0
(gdb) cont
Continuing.
[Switching to Thread 0x7f659ace6790 (LWP 20020)]
# Now, I right-click in Chrome:
Breakpoint 1, 0x00007f659a826500 in XGrabPointer () from /usr/lib/libX11.so.6
:(
-Jordan
Jordan Sissel
> On Wed, Dec 2, 2009 at 3:48 AM, Yuri D'Elia <wav...@thregr.org> wrote:
>> - You still cannot click 'through' the grid: if you move the mouse over
>> the grid, and attempt a click (with a keynav binding or though the
>> real thing) it's still sent to keynav, not to the underlying
>> application. This especially happens if you reduce the grid area a
>> lot: with a 3x3 grid, you can get up to a point (very quickly) where
>> you cannot 'click' anymore by using a 'click [123]' action *unless*
>> you also remove the grid by 'end'ing.
>
> This can be fixed by making sure the pixel under the mouse is always
> clipped clean (just like the grid areas and the center are today).
> Shouldn't be too difficult to do this. I put it on the todo list ;)
svn r2547 implements click-through by detecting mouse movement and
making that portion of the window vanish.
http://code.google.com/p/semicomplete/source/detail?r=2547
The current size of the 'click through' is a 1x1 (svn r2548) so you
shouldn't notice any visible changes in the window when you mouse over
it other than that your clicks/drags/etc go through the window. I've
experimented with a 20x20 cut, but this looks blocky.
This does introduce some flicker as the window is reshaped every time
the mouse overs over it. We can fix that later. The important feature
of 'click through' is now available in svn.
-Jordan
Yuri D'Elia
>> This can be fixed by making sure the pixel under the mouse is always
>> clipped clean (just like the grid areas and the center are today).
>> Shouldn't be too difficult to do this. I put it on the todo list ;)
>
> svn r2547 implements click-through by detecting mouse movement and
> making that portion of the window vanish.
> http://code.google.com/p/semicomplete/source/detail?r=2547
>
> The current size of the 'click through' is a 1x1 (svn r2548) so you
> shouldn't notice any visible changes in the window when you mouse over
> it other than that your clicks/drags/etc go through the window. I've
> experimented with a 20x20 cut, but this looks blocky.
>
> This does introduce some flicker as the window is reshaped every time
> the mouse overs over it. We can fix that later. The important feature
> of 'click through' is now available in svn.
Just out of curiosity: can't you just receive the mouse event/s, and
reinject them in the event queue below the keynav window?
Jordan Sissel
I don't think there's a way to simply specify "pass this event to the
window directly below this window, at this pixel"
In theory, we'd have to search for windows that occupy that pixel and
inspect the window stack, then use XSendEvent to send the event to
that window. However, most apps ignore events that come from other
applications via XSendEvent. Using XShape to clip the pixel seemed the
shortest path (it was a tiny amount of code) and seems to work well.
There may be other ways, but none I am aware of.
-Jordan
Yuri D'Elia
On 29 Dec 2009, at 22:15, Jordan Sissel wrote:
>> Just out of curiosity: can't you just receive the mouse event/s, and
>> reinject them in the event queue below the keynav window?
>
> I don't think there's a way to simply specify "pass this event to the
> window directly below this window, at this pixel"
Unfortunately, yes, you have to locate the window id at the requested
coordinates yourself.
> In theory, we'd have to search for windows that occupy that pixel and
> inspect the window stack, then use XSendEvent to send the event to
> that window. However, most apps ignore events that come from other
> applications via XSendEvent. Using XShape to clip the pixel seemed the
> shortest path (it was a tiny amount of code) and seems to work well.
What method are you using to send 'click' and 'drag' events then? I
thought you were sending synthetic events through XSendEvent.
> There may be other ways, but none I am aware of.
A quick look at the x11 reference manual didn't help, but I would
need to look into the new event device/handling mechanism xev/
xinput2, of which I'm totally clueless.
Poking holes via xshape is reasonable, but you know, doesn't seem the
'right way'.
I was just thinking aloud.
Jordan Sissel
>
> On 29 Dec 2009, at 22:15, Jordan Sissel wrote:
>
>>> Just out of curiosity: can't you just receive the mouse event/s, and
>>> reinject them in the event queue below the keynav window?
>>
>> I don't think there's a way to simply specify "pass this event to the
>> window directly below this window, at this pixel"
>
> Unfortunately, yes, you have to locate the window id at the requested
> coordinates yourself.
>
>> In theory, we'd have to search for windows that occupy that pixel and
>> inspect the window stack, then use XSendEvent to send the event to
>> that window. However, most apps ignore events that come from other
>> applications via XSendEvent. Using XShape to clip the pixel seemed the
>> shortest path (it was a tiny amount of code) and seems to work well.
>
> What method are you using to send 'click' and 'drag' events then? I
> thought you were sending synthetic events through XSendEvent.
>
It uses XTEST. The XTEST extension lets you send input as if you were
a mouse or keyboard. This extension has no way to send events to a
specific window, as far as I can tell. Applications have no knowledge
that events they receive come from XTEST, unlike with XSendEvent.
>> There may be other ways, but none I am aware of.
>
> A quick look at the x11 reference manual didn't help, but I would
> need to look into the new event device/handling mechanism xev/
> xinput2, of which I'm totally clueless.
>
> Poking holes via xshape is reasonable, but you know, doesn't seem the
> 'right way'.
> I was just thinking aloud.
Thinking aloud always welcome; it actually made me double check some
of the xlib apis to make sure I wasn't missing something. ;)
-Jordan
Jordan Sissel
> On Wed, 2 Dec 2009 02:05:20 -0800
> Jordan Sissel <j...@semicomplete.com> wrote:
>
>> > The attached 'alternate-navigation' patch is slightly different
>> > with the one I originally sent to the list - better precision,
>> > alphabet only instead of numerical+alphabet grid label.
>> >
>> > Put an entry like the following in .keynavrc to see it in action,
>> > after applying both patches on top of keynav-20091108:
>> >
>> > ctrl+semicolon start, focused-grid
>
> Sounds immensely useful. Does it allow to setup a custom grid?
> (focused-grid 3x3?). Does the grid labels use the currently setup
> bindings?
>
>> > There are some ugly artifacts when the grid size is reduced using
>> > the 'h' (left) and 'k' (up) but I don't know how to fix that
>> > because my Xlib-fu skill is very near to zero. Ugliness aside,
>> > keynav is good for my wrist so I'm willing to live with that
>> > artifacts.
>
> I would like to add that there are still some issues I have with
> keynav :)
>
> - The grid should probably be drawn in XOR'ed mode (the 3 pixels width
> does eat a lot of space)
I found an alternative to this tonight.
Turns out xcompmgr has gotten way less crappy since I tried it years
ago. Using xcompmgr, transset-df, and xdotool, we can make the keynav
window translucent.
This requires the latest svn HEAD as of tonight, and the following in
.keynavrc (or however you start your keynavrc)
ctrl+semicolon start, sh "exec transset-df -i $(xdotool search
--class keynav) 0.3"
This will have xdotool find the window 'keynav' and tell transset-df
to set the opacity to 30%. Seems to work OK, but has some strange
copy-artifacts I see when moving the window. At any rate, the next
release should provide y'all with the ability (should you choose to
use xcompmgr) to make the grid see-through.
-Jordan
Jordan Sissel
4. 0004-Dejavu-Re-run-previous-click-at-previous-clicked-loc.patch
New command - "save-dejavu" and "dejavu". This is for remembering
a certain location and click so that we can re-click that same
position later on without having to manually warp to that location.
See the 'Example use case' usage instruction.
Nazri Ramliy
> Check out the new 'record' feature I just checked in to svn, tonight. I can
> build you a tarball if you don't have a subversion client.
> -Jordan
Thanks for the notice. I'll check it out later using subversion.
Nazri.