Jorge Arellano Cid wrote:
Hi,
Here go my comments on the keyboard navigation patches.
I like them, and would like to commit it probably in the next version (kbd3).
Good! Maybe it would be a good idea to wait for patch #4 though, as #3 might (not sure yet) contain some big changes in the way links are found. This might introduce new bugs...
Note: we use to work heavily on patches and commit only after they're stable or polished. All this with a view to keep a relatively stable CVS source tree to work with. This is different to the usual model, but it has its rewards. With regard to the keyboard navigation patch, it probably can be polished better when on CVS, so here my remarks to make the next version into the sources.
I agree with screening patches for bugs, but I think there should be a way for patches to get more exposure than they currently do. Many eyes make all bugs shallow, release early release often, rinse, repeat, etc. I test te patches, but I can only try so many sites and combinations. Several bugs have been found by users (eg. the LOCALE bug in GtkFrameset) which I probably would not have found.
I would at least leave the traditional line, for reasons of consistence. Perhaps the link may be also highlighted, in a lighter color than the background color (and lightgray for white etc., look at Dw_style_color_create, which is used for shaded colors for borders)? This would make it unconfusable with text selections.
I have tried using tile and stipple fill patterns for focus highlight, this did not give useable results. Next on the line is color, with a (stippled/dashed) frame around the link.
This is a good idea. Having the spaces inside links highlighted and the whole kbd. nav. current link in a distinctive pattern or color
I have used Sebastian's patch for a while now, let my GF try it, and we are unanimous: looks much nicer ('more professional'), but is less useable (hard to see where focus is). The next version of the patch will use both color and a frame for focus highlight.
One thing I noticed between kbd1 and kbd2 is that sometimes the latter makes odd jumps when using UP and DOWN keys. For instance with "gtk-types.html" page from GTK+'s manual.
What problem are you referring to? I tried that page (both for the GTK+-1.2 and GTK+-2.2 manuals), and it reacted the way I would expect it to (down goes down a link, up takes focus one link up). Completely predictable and consistent. Which does not surprise me, as this is a relatively 'easy' page with many links to choose from. The places where I see inconsistent behaviour are mostly: - going UP in a page with few links sometimes takes me DOWN instead... This is caused by the fact that links which have not yet been displayed have their location set to '0,0'. The 'UP' code tries to find a link with a lower y-coordinate than the current cursor. The solution is probably to give such 'unknown' links a recognizable location (-1,-1) and ignore them for positional navigation. - sometimes a link is highlit when I did not ask for it (eg. first page of Google search results). Have to look in to this. - sometimes focus cycles to the top of the document when pressing 'DOWN' on the last link on the page. This should not happen. Cause probably the same as above. - it is currently not possible to use Tab to focus the next frame in a frameset. This is clearly a bug...
The "directional" navigation of links feels very handy and intuitive. One thing that can be improved is when the current link is outside the screen not to jump to it upon a key press but to find the most appropriate one within the displayed area. This would allow for a smooth keyboard navigation by integrating with the scrolling keys.
Ah, but what about those cases where there are no links inside the displayed area? This happens quite often, eg. the 'next/prev' links on the top and bottom of a document generated with LaTeX2html (and such). This is actually what made me notice the problem in the first place. I think that in these cases, 'sequential' focus (just take the next link from the document source) is the best compromise between useability and performance. To really solve this problem, the document would have to be pre-rendered once to learn the location of all links. That is to big a sacrifice for to little gain I think. [LIST: what do you think?] Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]