New keynav beta (includes alternate grid navigation!)
Jordan Sissel
There's a new keynav beta available for using. It includes some
drawing fixes (We draw with libcairo now) and more importantly
includes the new 'alternate navigation' feature suggested on this list
a year or two ago.
http://semicomplete.googlecode.com/files/keynav-0.20100403.2754.tar.gz
I still need to do some more testing and debugging, but this should
work well enough for now. Details in the changelist:
0.20100403.*:
- Use cairo graphics for drawing instead of raw Xlib. This makes drawing a
little bit less painful and will allow me to more quickly prototype ideas
in the future.
- Add 'grid nav' navigation. The original prototype was written by
Nazri in 2008.
This adds a new command: grid-nav. This command takes one argument, of:
toggle, on, off. When on grid navigation, you can select a specific grid
by coordinate. The coordinates at this time are A to Z for both row and
column.
For example, if your grid is 2x2, you can select the top-right cell by
typing 'AB' when grid nav is activated.
-Jordan
Wen-Yen Chuang
Hash: SHA1
Hi,
The clean target in Makefile should remove keynav_version.h. :-)
Kind regards
Wen-Yen Chuang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku4Y8sACgkQdEpXpumNYVksdwCfXqUZYehs5K8c3xG0zcpC4frx
RckAoIy4CsQ10l+yysDFL5EvBXoO8y+E
=0z4k
-----END PGP SIGNATURE-----
Nazri Ramliy
> 0.20100403.*:
> - Use cairo graphics for drawing instead of raw Xlib. This makes drawing a
> little bit less painful and will allow me to more quickly prototype ideas
> in the future.
> - Add 'grid nav' navigation. The original prototype was written by
> Nazri in 2008.
> This adds a new command: grid-nav. This command takes one argument, of:
> toggle, on, off. When on grid navigation, you can select a specific grid
> by coordinate. The coordinates at this time are A to Z for both row and
> column.
> For example, if your grid is 2x2, you can select the top-right cell by
> typing 'AB' when grid nav is activated.
I like the cairo-based implementation because it seems to solve the flickering
problem due to multiple redrawing of the grid in the raw-xlib-based version,
and also because it seems to be easier to grok than raw xlib.
But my keynav use case is adversely affected by this implementation of
grid-nav:
In the raw-xlib-based version I normally do:
1. start keynav with grid 22x25 - lots of small cells
2. Identify the cell intersection or cell center that I'm interested in
3. Move the grid a few pixels down/up/left/right such that that cell
intersection or cell center is right above the point where I want to
click on.
4. Hit either comma-alphabet-alphabet or apostrophe-alphabet-alphabet
combination depending on whether I want the click to happen on a
grid line intersection or a cell center (the alphabet-alphabet
sequence being the cell intersection 'id').
3. Issue a click command.
In the cairo-based version the behavior is changed to:
1. draw the grid (22x25 cells - many small ones),
2. Choose a cell by typing its column and row sequence,
3. Keynav readraws the grid, zoomed to fit that cell and because that
cell is so small it's just unusable for me anymore.
I'm not asking that you change the cairo-based version behavior to suit my use
case :) - rather I'm reporting this just for the record in the event that if it
became too much of an itch for me to use the xlib-based-version (due to the
multiple drawings) I can look back to this posting and see what can be changed
in the cairo-based version so that it is usable for me.
nazri
Jordan Sissel
Relative to a single grid cell, your version has the option of
choosing the center or top-left of the cell, right?
>
> 3. Issue a click command.
>
>
> In the cairo-based version the behavior is changed to:
>
> 1. draw the grid (22x25 cells - many small ones),
>
> 2. Choose a cell by typing its column and row sequence,
>
> 3. Keynav readraws the grid, zoomed to fit that cell and because that
> cell is so small it's just unusable for me anymore.
Thanks for the feedback :)
>
> I'm not asking that you change the cairo-based version behavior to suit my use
> case :) - rather I'm reporting this just for the record in the event that if it
> became too much of an itch for me to use the xlib-based-version (due to the
> multiple drawings) I can look back to this posting and see what can be changed
> in the cairo-based version so that it is usable for me.
Based on some of this, I'm going to try adding a few things:
* smartly shrinking font size and reducing the grid row and column
counts when the selection window is too small.
* allow targeting the center or (for now) top-left corner of the cell.
This should probably include a graphical hint showing you what your
selection will choose.
Feel free to let me know what else you think would be good for this
grid nav stuff. Mostly I'm implementing it for fun as I don't have a
personal use case for it just now, so it's up to you what goes in it
;)
-Jordan
Nazri Ramliy
> Relative to a single grid cell, your version has the option of
> choosing the center or top-left of the cell, right?
Yes, please see the last post (mine) in this [1] keynav-users thread.
>
> Based on some of this, I'm going to try adding a few things:
> * smartly shrinking font size and reducing the grid row and column
> counts when the selection window is too small.
IMHO shrinking the font size is not a good move. I've been using xlib-based
keynav on my 46in TV (1920x1080 resolution), and I'm using it solely with
the patch attached in [1] 'more.holes.patch'. At a distance of 8ft
(rough guess) and above the default font size used for labelling the
grid is too small to be readable, rendering keynav unusable from a
distance. I was just thinking about making the font size configurable
the other day so that keynav is usable from my couch. The idea was to
have less number of grid, with larger grid labels.
> * allow targeting the center or (for now) top-left corner of the cell.
> This should probably include a graphical hint showing you what your
> selection will choose.
The graphical hint is nice to have.
I've been using keynav solely with the more.holes.patch patch and the
lack of hint has not been a problem at all. This is because upon
activating keynav, I have already made a decision on which location I
want to click on and with keynav showing many cells, one of the grid
crossings (or cell centers) is guaranteed to be about 10-15 pixels away
from the target, which makes shrinking (cut-left etc.) of keynav grid
unnecessary (in fact it would be distracting).
See the screenshot [2] to see what I mean when I mention about the
target being about 10-15 pixels away. It is a screenshot of google
chrome showing [1]. Notice that all the clickable stuff - links, tab
close buttons, window minimize/maximize/close buttons - everything
- are all 10-15 pixels away from, if not right smack on either a grid
crossing or a cell center.
> Feel free to let me know what else you think would be good for this
> grid nav stuff.
I mentioned above that the graphical hint as "nice to have". With the
following refinement I think the graphical hint would be sleek:
1. Activate the grid, and we see something to the effect shown
in [2]
2. Upon choosing a grid crossing (or a cell center), keynav
hides all the grid and show only that graphical hint, which
could be a small cross with a hole at the center. This means
keynav don't spend time drawing irrelevant stuff - sleek!
3. We can then move this graphical hint in any direction to
further 'fine tune' the click location.
4. Make it so that we can toggle between the graphical hint mode
and the full grid mode so that if we change our mind then we
can see the whole grid and select a new focus point.
> Mostly I'm implementing it for fun as I don't have a
> personal use case for it just now, so it's up to you what goes in it
> ;)
Thanks!
nazri.
[1] http://groups.google.com/group/keynav-users/browse_thread/thread/bdcf240241945b25
[2] http://imgurl.filetac.com/img/05408160.png
(link expires a year from now)