Hi and thanks for your comments!

...

dillo-search.diff: - * Added search feature to location entry/open url. ("s key words...") (BUG#473)

Very interesting, and certainly easy to use. Unfortunately it comes with a kind of interface that's out of the cognitive model behind Dillo's UI. In simple terms it means that users will have to learn how to use it from the help file and that it's not quite oobvious from the GUI and that it is different from what you come to expect when using dillo.

The search problem had been in my mind for some time, so I know it is necesary to do something about it.

I think that a small icon (like "clear URL box"), shaped as a magnifier, can pop up a dialog (like "Open URL"), but for search. If we add a short-cut for it (Ctrl-s), and the option to hide the icon (as with the rest of the interface icons), it integrates better with the user interface model. I agree that e.g. a search dialog would be easier to find for new users. On the other hand after a while you'll probably start looking for keyboard shortcuts to speed up browsing, and there the "s key words" feature could be listed. My point is that you already have to review the help file in order to find all features of dillo (or any other browser).

...

dillo-accel.diff: - * Added keyboard shortcuts to - reload (Ctrl+R). - full screen (F11). - select all text in location entry (F8). - focus location entry (Ctrl+Shift+L) (BUG#474)

Files affected: interface.c

This patch adds a few useful keyboard shortcuts which eases mouse less browsing. Most browsers have a focus-and-select the location entry shortcut (Ctrl-L in mozilla, F8 in opera). I tried to get some feedback on if this was the desired behaviour for dillo by posting the mailing list, but no one seemed very interested. I therefore settled on a two shortcut solution; F8 selects all text and Ctrl-Shift-L just focuses the location entry. In this way you can easily modify an existing url or just enter a new one without the use of the open url dialog.

As I wanted the F8 key to work also within the location entry I had to add a key press handler to the main window (the existing one just handles key presses within the view port (docwin)). I decided on this solution since adding a handler to the location entry didn't seem right and moving the docwin key press handler to the main window didn't work as this handler gets called before a text widgets default handler (and thus a backspace in a html form would trigger back).

Perhaps a better solution would be two plain accelerators; one for the clear-location button and one to just focus the location entry. This way there'd be no need for an extra key press handler. But I figure that a "global" key press handler may be needed in the future. Am I wrong?

Maybe Ctrl+L would be a better shortcut to select all text in the location entry and Ctrl+Shift+L the shortcut to open an open url dialog (as in Mozilla), but I didn't dare changing the default behaviour without getting some feedback first.

I think: - reload (Ctrl+R). - full screen (F11).

could be easily agreed into a short-cut key.

The problem is that everybody comes with his favorite set of shortcuts (you'd be amazed to look in my Mailbox!). OTOH this is not rare; evreyone uses some different apps. and get accustomed to different key combinations.

I prefer to take Havoc's approach on this:

http://www.dillo.org/ui-prefs-tips.html Do you mean that there should be no shortcut to focus (and/or) select

Minimalism is something I've come to appreciate, and hence being able to browse with just keyboard shortcuts and a location entry (and no buttons/dialogs) is something at least I'd prefer. Is it possible to have both options in dillo, without violating Havocs guidelines too much? I.e. having both a search dialog and the "s key words" "shortcut"? Another solution could be to enter the keywords in the location entry and then press a search button (with accelerator Ctrl-S) to perform a search. A good compromise? An alternative approach is found in recent versions of mozilla. Entering key words in the location entry brings up a drop down list (with matching urls from history) AND a "search <your-search-engine>" entry. Perhaps not as quick as the above mentioned solutions, and it wouldn't be my first choiche, but it is quite easily found by new users. the location entry, besided tab/Shift-tab? I think that we should implement this shortcut even after the tab/Shift tab issue is solved. There's at least three reasons: 1. The Tab/Shift-Tab is used to cycle between widgets in the viewport. Browsing a page with a lot of buttons/forms would require too many tab presses to focus the location entry. 2. This feature is common in other browsers so perhaps new users expect to find it? (At least I did.) 3. The "Open URL" dialog/shortcut isn't sufficent since it doesn't give you the option to modify the current url. If I've been able to convince you, what would you prefer: a focus or a select shortcut (or both)? Or two shortcuts: focus and clear respectively?

...

dillo-focus.diff: - * Made main document window grab focus on startup and after open url. (BUG#330)

Files affected: interface.c

This is just a two line patch which implements the behaviour found in other browsers as mozilla and opera. Makes mouse less browsing easier.

Well, this is a long time unsolved problem for us :(.

Please give a read to my last post about it:

http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-June/000770.html By adding a key press handler to the main window (in your test app) with the following code and passing it the window as client_data:

switch (event->keyval) { case GDK_F1: g_print("Widget @ %p - %s has focus\n", GTK_WINDOW(client_data)->focus_widget, gtk_widget_get_name(GTK_WIDGET(GTK_WINDOW(client_data)->focus_widget))); break; } I was able to find out (perhaps you already know), that the "Nirvana widget" you mentioned is NULL!. You app initially focuses nothing since GTK_WIDGET_SET_FLAGS(entry, GTK_HAS_FOCUS) just seems to makes the widget look like it's focused. A gtk_widget_grab_focus(entry1); after the window has been shown sets the initial focus to entry one. Then hitting tab focuses the three entries in turn, and then focus_widget is again set to NULL. I tried this in dillo as well with similar result: Without my patch focus_widget is initially NULL and hitting Tab doesn't change this. Shift-Tab focuses the location entry. Another Shift-Tab again sets focus_widget to NULL. And a third Shift-Tab gives the viewport focus. The difference here (from the your test app) is that the focus hangs when cycling forward (initially at NULL and later on the viewport) but not when cycling backwards! I hope these observations can be to some use.

If you can make a temporary subscription and send it to the GTK+ list, it'd be a great favor to us. A noticed that someone else just posted it.

In the meanwhile (or if the post gets no answer), I think your approach will make it into the source as a workaround. IMO the inital focus of the viewport and focusing of the viewport after opening an url is not just a temporary workaround for the focus-cycle issue. When starting dillo I think the focus should be set to either the location entry or the viewport. I decided on the viewport since you may have passed dillo a URL argument, and otherwise you could easily focus the location entry with the above mentioned shortcuts (or Shift-Tab). (This is also the behaviour of mozilla and opera).

Likewise, entering an URL and hitting enter you normally expect to load a page for browsing. Then I find it natural that the focus is automatically set to viewport so you can use pageup/down etc while reading (this is the approach in mozilla and opera). If you've misspelled the URL you can focus the location entry with either Shift-Tab or a shortcut.

Note that if we solve this, it becomes easy to focus the location box (or viewport) in tyhe standard GTK+ way:

TAB/ShiftTAb See note above.

Cheers Johan