Sebastian Geerken wrote:

Hi,

I've only taken a glance at it, but made two changes to Frank's work. The patch is attached, and is to be applied after Frank's patch: The changes:

- Fixed a bug in focus.c: Now, spaces are also drawn, between the words of a multi-word link. Somewhere, it is documented, that you have to highlight up to strlen(word->content.data.text) + 1, to highlight also the space.

Hmmm... that was intentional, so that focused links could be recognized more easily... Same for the next one by the way. Anyway, it would be even better if the focus could be drawn in another pattern or color, so that it is visible even when overlayed with a selection or found highlight. Btw, apart from looking only fleetingly at it, did you try keyboard navigation? If so, any remarks about the functionality itself? 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." ]

Sebastian Geerken wrote:

Hi,

I've only taken a glance at it, but made two changes to Frank's work. The patch is attached, and is to be applied after Frank's patch: The changes:

- Fixed a bug in focus.c: Now, spaces are also drawn, between the words of a multi-word link. Somewhere, it is documented, that you have to highlight up to strlen(word->content.data.text) + 1, to highlight also the space.

- I've modified the page widget to draw the focus-highlighted text with a border, not inverse, as done with found and selected text.

Sebastian

{Have you thought about | Is there} a way to highlight text using a pattern (like the 'gray-out' highlight for images)? I have explicitly not used a line-stile highlight for keyboard focus, because this makes it often hard to see where focus is. Links are sometimes small, no more than a '*' or a subscripted number. A line-style highlight is hard to see in those cases... I do agree that it is necessary to use a different highlight style for focus, search and selection, but the traditional focus highlight ((dotted/dashed) line around word) is not very useful in many cases. This goes even more for people with bad eyesight. 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." ]

Sebastian Geerken wrote:

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.

e.g. Alt-Tab is used by many window managers, and generally, I expect key combinations with the Alt modifier more at the level of windows. (IMO, no modifiers should be used for link navigation, conflicts with other functions have to be resolved somehow.)

Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that combination is not used by any of the window managers I use/have used. currently the bindings for Tab and Shift-Tab are the same as they are in CVS Dillo: they focus the next GTK+ widget in the page (in emulation of gtk_container_focus()). The modifier-less 'hjkl' key pattern is probably a good choice for those who are used to vi (and friends). Together with 'b' and space for scrolling, comma and period for history navigation and 'enter' for link activation it is possible to move anywhere you want using only one hand. Since the current version of the patch allows anyone to change keyboard bindings, user experimentation and feedback could be used to find the most acceptable combination. This can then be set as default, while those who do not like it for whatever reason are free to change it. [LIST]: given the slow uptake of the patches I might follow Sylpheed-claws' model of releasing an extended version in addition to just releasing patches. This should give the patches more exposure (they are now only known to those reading the list/archives), and should lead to a better quality - eventually. Any input on this? 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." ]

On Fri, 24 Oct 2003, Melvin Hadasht wrote:

...

...

e.g. Alt-Tab is used by many window managers, and generally, I expect key combinations with the Alt modifier more at the level of windows. (IMO, no modifiers should be used for link navigation, conflicts with other functions have to be resolved somehow.)

Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that combination is not used by any of the window managers I use/have used.

Just wanted to say that WindowMaker uses MOD1 (alt) Up/Down to raise/lower the window It also use CTRL-MOD1 Left/Rigth to switch to next/previous workspace MOD1-Tab is used to switch windows. But as long as the keys are configurable, I don't see this as a problem. I think WindowMaker is one of the most spread window manager among users that do not use Gnome or KDE.

I'd suggest Ctrl-Arrows. Ctrl-Arrows are used in text editor to jump to next words, so users will mostly try Ctrl-Arrow instead of Alt-Arrow

...

user experimentation and feedback could be used to find the most acceptable combination. This can then be set as default, while those who do not like it for whatever reason are free to change it.

Definitly!

-- Melvin Hadasht

Ditto! Cheers Jorge.-

On Fri, Oct 24, 2003 at 05:21:07PM +0200, Frank de Lange wrote:

Melvin Hadasht wrote:

...

...

...

e.g. Alt-Tab is used by many window managers, and generally, I expect key combinations with the Alt modifier more at the level of windows. (IMO, no modifiers should be used for link navigation, conflicts with other functions have to be resolved somehow.)

Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that combination is not used by any of the window managers I use/have used.

Just wanted to say that WindowMaker uses MOD1 (alt) Up/Down to raise/lower the window It also use CTRL-MOD1 Left/Rigth to switch to next/previous workspace MOD1-Tab is used to switch windows. But as long as the keys are configurable, I don't see this as a problem. I think WindowMaker is one of the most spread window manager among users that do not use Gnome or KDE.

I'd suggest Ctrl-Arrows. Ctrl-Arrows are used in text editor to jump to next words, so users will mostly try Ctrl-Arrow instead of Alt-Arrow

Ah, WindowMaker... used it around 1996, did not remember that binding...

Anyway, Ctrl-<cursor_keys> is used (by me at least) for workspace (or 'virtual desktop') switching, ALT-CTRL-<cursor_keys> for window movement between workspaces, etc.

So... more opinions?

The default setup of the Ion window manager uses only Mod1-* bindings, but requires rather a lot of them. I am using Ctrl-arrows for that reason. Also I agree with Melvin that this choice is intuitive because Ctrl-arrows jumps across words in many word processors. Of course, you won't find me complaining as long as the gtkrc magic is available... Paul

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." ]

Jorge Arellano Cid wrote:

For instance: placing the nav cursor in the [gtk_type_new] link inside the "struct GtkTypeObject" section and pressing DOWN, brings the cursor to the leftmost [GtkType] under gtk_type_unique but it is possible to get to the leftmost [GtkType] too! That is focusing the leftmost one, then going UP then DOWN again.

You mean left- and right-most link? As in... A . . B . . C Going from A sometimes lands you in B, sometimes in C, depending where you came from? If so, that is by design. The code only modifies the 'x' cursor coordinate when the link is explicitly moved to the left or right, NOT when it is moved up or down. The reason for this is best explained in yet another ASCII-graphic: A . . . B . C . . . D . E . F . . . G . H . I When moving focus DOWN from A, it will land in B (because that is the next LOWER link closest to A). Moving it down again lands it in C (NOT E), as that is the next LOWER link closest to the original x-coordinate. If you now were to move focus to link E (by moving it to the right), it would update the 'x' cursor coordinate, so the next move DOWN after that would end up on H. The cursor is ALWAYS set to the current link's 'y' coordinate. In case focus is moved out of context (eg when it is set by the search feature) it should be set to the current link's 'x' coordinate as well. That's the theory, which is followed in the code - mostly. It might be that there are some cases where context is retained while it should be discarded. Combined with the unknown-location-problems this can lead to unexpected behaviour.

The gain I see with this scheme is that you can scroll down a page, and when you find an interesting link "call" the keyboard navigation cursor and quickly select the link. Otherwise you're carried to the top of the page (or to wherever the cursor was left) and will have to start finding the scrolled region where the to-be-clicked link is.

Ah, that's what you mean. Yes, this will be implemented in the next version as well. 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." ]

Melvin Hadasht wrote:

...

A . . . B . C . . . D . E . F . . . G . H . I

When moving focus DOWN from A, it will land in B (because that is the next LOWER link closest to A).

I agree with this. It is also the common behaviour in text editors and text processors.

...

Moving it down again lands it in C (NOT E), as that is the next LOWER link closest to the original x-coordinate.

Of course I meant D, not C...

I would expect that moving down will bring me to one of the links in the D.E.F line, the link which x position is the closest to A's. As this is a geometrical/(geographical) navigation, I'd expect a behaviour similar to cursor motion in text editors.

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." ]

On Sat, Oct 25, 2003 at 03:14:22PM +0200, Frank de Lange wrote:

Jorge Arellano Cid wrote:

...

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.

Aren't these sorts of problems generally solved by using CVS branches? The main tree can remain stable, and the development code would be (marginally) easier to obtain and work with if it could be tracked via a CVS branch. Paul

El Fri, 24 Oct 2003 20:31:46 +0100 Maurice McCarthy <maurice.mccarthy@ntlworld.com> escribio:

Hi folks

Just to say thanks one last time. I'm going to leave you all in peace to get on with your projects. This can be your proyect too and you do not need to make a war for it ;)

Diego.

The invitation is nice but I don't think I have the skill. Where I work if something is not functioning then you a) hit it with a scaffold pole b) if its too small, hit it with a shifter (adjustable spanner) c) take it apart and clean it d) if its electrical push every button in sight e) when you know you've really broken it then f) call the maintenance dept. Maurice On Sat, Oct 25, 2003 at 12:05:36AM +0200 or thereabouts, Diego S?enz wrote:

El Fri, 24 Oct 2003 20:31:46 +0100 Maurice McCarthy <maurice.mccarthy@ntlworld.com> escribio:

...

Hi folks

Just to say thanks one last time. I'm going to leave you all in peace to get on with your projects. This can be your proyect too and you do not need to make a war for it ;)

Diego.

_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Frank, I'll do my best to give you the most accurate description that I can but I'm afraid I'll be away from my machine for 3 to 4 weeks. (I work in the North Sea oil fields. There is no linux machine there and we have only email but no internet accesss.) Maybe I can sort it myself as partly it does compile OK but I've not got frames support. Best Maurice On Sat, Oct 25, 2003 at 03:40:18PM +0200 or thereabouts, Frank de Lange wrote:

Maurice McCarthy wrote:

...

The invitation is nice but I don't think I have the skill. Where I work if something is not functioning then you

a) hit it with a scaffold pole b) if its too small, hit it with a shifter (adjustable spanner) c) take it apart and clean it d) if its electrical push every button in sight e) when you know you've really broken it then f) call the maintenance dept.

Good! Do this to my tab/frame and keyboard_navigatino patches and tell me what you've managed to break!

I'll release new versions of the patches RSN (tm) which should apply to current CVS.

Cheers//Frank