September 2003 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] [RFC] Find as you type, statusbar instead of popups, etc

by Johan Hovold

On Wed, Sep 10, 2003 at 09:27:29PM +0200, Frank de Lange wrote: > User controls for find (and find_as_you_type) are the same as the normal find dialog ("/" or CTRL-F to start find, ESC to close, enter to search/search next), but find now retains the last search string between searches. A find_as_you_type feature would be great (I'm not a great fan of dialogs either). But wouldn't the mozilla style, '/' for find_as_you_type and ctrl-f for find_using_dialog, be a better approach? I'd also prefer ctrl-g for find_again (rather than enter), which could be used both with find_dialog and find_as_you_type. If/when keyboard navigation support is implemented, enter would probably be used to follow links. Regards, Johan

Sept. 11, 2003

Re: [Dillo-dev] Re: [RFC] Find as you type, statusbar instead of popups, etc

by Frank de Lange

On Thu, 11 Sep 2003 01:02:53 +0200 Melvin Hadasht <mhadasht(a)freefluid.dyndns.org> wrote: > Hi, > > > My current tab/frame patch (which will probably be released AFTER the 20th of september, as I am going abroad for a while) contains a find_as_you_type implementation (like Mozilla, search results are updated interactively). > > I was very happy when Mozilla implemented Emacs' incremental seach, so > I would really like to find it in Dillo, too. Is the patch available somewhere? Well, the highly-experimental-not-for-release-yet current version of the tab/frame patch, containing this feature, is at the patch site: http://www.geocities.com/ikbenfrank/dillo-200309102310-tabs.patch.gz size: 83700 bytes (gzipped, as downloaded) 366075 bytes (uncompressed) md5sum: 7df18dc069447dcc725abdcb64477a21 (gzipped, as downloaded) ad5ed7c538c8ae3801aebe229e79b177 (uncompressed) It is not even guaranteed to compile though, as it is just a current patch between my development tree and yesterdays CVS. Feel free to give it a try though. Set (in dillorc) 'popup_dialogs=NO' to use the status-bar version, otherwise you get the popup version (which also supports find_as_you_type by the way). Set find_as_you_type=YES to get that feature. > (could we add shift-enter to search backwards?) Yes, we could. > So what do you think about making a menu entry for each Dillo command? > That would create numerous new entries but then the user does not need Well, I would not make menu-entries for everything, but might consider making everything available for binding. Just like you can do in Emacs... > I would also find it useful if we could navigate through links using the keyboard. Yes, that is another planned feature. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 11, 2003

ipaq dash keys

by Vikram

Hi I am using familiar 0.7 on a h3670. I have a modified version of dillo which adds some custom functionality to it. I need to be able to trigger certain events on pressing the ipaq dash buttons [these are the ones which launch calendar, filemanager etc and are wrapped all round the arrow keys of the ipaq]. I see that dillo via GdkEventKey [in interface.c] senses the arrow keys but this function does not seem to get events from the ipaq dash key presses. Is there anyway I can get such keypresses ? Is it necessary I have change some system wide seting [like use xmodmap?] ? Thanks, Vikram

Sept. 11, 2003

Re: [RFC] Find as you type, statusbar instead of popups, etc

by Melvin Hadasht

Hi, > My current tab/frame patch (which will probably be released AFTER the 20th of september, as I am going abroad for a while) contains a find_as_you_type implementation (like Mozilla, search results are updated interactively). I was very happy when Mozilla implemented Emacs' incremental seach, so I would really like to find it in Dillo, too. Is the patch available somewhere? > I also included an option to use the status bar and location bar instead of popup windows for search and open_url (popups are quite often not worth the hassle...). Yes, I agree, and I would make use of this patch. But popups should still be there, so new users won't be lost. > User controls for find (and find_as_you_type) are the same as the normal find dialog ("/" or CTRL-F to start find, ESC to close, enter to search/search next), but find now retains the last search string between searches. (could we add shift-enter to search backwards?) I really liked Gtk ability to let the user customize menu key bindings. So what do you think about making a menu entry for each Dillo command? That would create numerous new entries but then the user does not need to read the manual to know that '/' is for incremental-search and he would be able to customize the key-bindings to his taste. The drawback, is that there will be more menu entries. (You use Sylpheed-Claws, you can see that we moved most advanced editing commands in Compose/Edit/ Advanced.. to lighten the edit menu while allowing the user to set her preferred key-bindings (Ctrl-A being one of the most controversial)). > Is this something you'd like to see in Dillo, or should I keep these to myself? Definitely, I would use it quite frequently. I would also find it useful if we could navigate through links using the keyboard.

Sept. 10, 2003

[RFC] Find as you type, statusbar instead of popups, etc

by Frank de Lange

Hi'all, My current tab/frame patch (which will probably be released AFTER the 20th of september, as I am going abroad for a while) contains a find_as_you_type implementation (like Mozilla, search results are updated interactively). I also included an option to use the status bar and location bar instead of popup windows for search and open_url (popups are quite often not worth the hassle...). User controls for find (and find_as_you_type) are the same as the normal find dialog ("/" or CTRL-F to start find, ESC to close, enter to search/search next), but find now retains the last search string between searches. Code size impact is minimal, in case of a popup_less version code is actually quite a bit less complex (and a bit smaller) than the current CVS implementation. Is this something you'd like to see in Dillo, or should I keep these to myself? On the frameset front, control over margins in (i)frames has been improved (no more extraneous margin space in iframe). Dillo (when configured for frameset support) now always renders frameset - even when body content is placed outside the frameset. Frame resize support has been improved a bit. These changes introduce two new preferences (popup_dialogs and find_as_you_type). Both have defaults which reflect unpatched Dillo's behaviour. Please let me know if this sounds like an improvement (or the opposite) to you. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 10, 2003

[PATCHES] GTK1 focus problem, solution

by Frank de Lange

Jorge, Sebastian, world, In a previous message I described a focus problem with Dillo (focus is 'trapped' in invisible widget). I have traced the problem to the GtkToolbar class. GtkToolbar is a GtkContainer, so it always gets focus even when GTK_CAN_FOCUS is unset. Hoewever, it redefines the focus signal function to NULL, thereby trapping focus inside the widget. To get normal focus behaviour, the GtkToolbar class's focus function needs to be changed to something like { return FALSE; }. I have patched interface.c to this extent. Patch is attached to this message. To get a complete, two-way tab focus chain (ability to tab around all focusable widgets in Dillo, forward and backward) my focus patch for dw_gtk_scrolled_frame is needed, otherwise dw_gtk_scrolled_frame will trap focus inside itself. You can find the patches on my patch site: http://www.geocities.com/ikbenfrank/dillo-200309101437-interface_focus.patc… (size: 660 bytes) http://www.geocities.com/ikbenfrank/dillo-200309101116-focus_chain.patch.gz (size: 910 bytes) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 10, 2003

Re: [Dillo-dev] Re: [Patch] Search feature and more

by Johan Hovold

Hi Jorge! > 2.- Accelerator keys. > > Huh! These are to be picked very carefully! It took me a lot of > work to figure simple mnemonic shortcuts that integrate well with > the UI model. > > The chosen ones are: > > Shortcut Mnemonic > ------------------------------------------------------------ > Ctrl-U "Ctrl-URL" (to edit the URL) > Ctrl-H "Ctrl-Hide" (Hide/show controls) > Ctrl-S "Ctrl-Search" (search the web) > Ctrl-R "Ctrl-Reload" (reload current page) > ------------------------------------------------------------ > (integrating with the existent) > Ctrl-L "Ctrl-Location" (enters a new URL) > Ctrl-F "Ctrl-Find" (find text) > Ctrl-Q "ctrl-Quit" (quit window) > > (Note: Ctrl-S is not implemented yet) > > These should provide good defaults as Havoc suggests. Please > give them a test drive to get the feel. Some issues noted (which you may already have considered): Ctrl-U "Ctrl-URL" (to edit the URL) - Conflicts with gtk text entry's "Delete line" shortcut. - Could perhaps be considered a feature, since one ctrl-u gets you to the location bar and another clears it? - Has the irritating consequence that you cannot use it while in a html text entry widged. - May cause undesired "url lossage" ;-) when already in the location entry. Ctrl-H "Ctrl-Hide" (Hide/show controls) - Conflicts with the gtk text entry's "Delete Backward Character (Backspace)" - Hence cannot be used while in html text entry forms or location entry. - F11 seems to be the standard keybinding for full screen. Ctrl-S "Ctrl-Search" (search the web) - Frank's note that this is a standard shortcut for "Save Page", implies that perhaps Ctrl-S isn't such a good choice, and an alternative should be thought out. - ...but a search bar doesn't solve the problem, since it should also be accessible through a shortcut. - My original proposal "s <keywords>" is still an option... General issues concerning the Locationbar/dialog - Ctrl-U doesn't select the url (just focuses), hence another keypress is required in order to enter a new url (same goes for Ctrl-L - open location dialog). - Perhaps both the location dialog and location entry, should select all text on Ctrl-L and Ctrl-U respectively? - Considering the conflicts noted above, isn't Ctrl-L for focusing (and perhaps selecting the contents of) the location bar and Ctrl-Shift-L for opening location dialog a better and more consistent solution? > Ah, while thinking of it, I thought it'd be good to add the ESC > key as a way to switch from the location box into the main > window, it can be easily done with the key handler you wrote. Isn't this a (unneccessary) violation of Havoc's guidelines, since a single tab press focuses the document window? (I.e. it would be a duplication.) (Just a note: an ESC press in the location box in mozilla and opera selects the text and clears the text, respectively) > 3.- Search feature > > Uncommited yet, the functionality is perfect. Just some minor > details in the UI: > > A small icon to the right of the location box (hideable as the > othe icons), with Ctrl-S as shortcut, that pops up a dialog (just > as find text and open url). Shall I keep the "s <keywords>" interface as well, or just go with the search box. The overhead is minimal, and people disliking dialogs would be pleased. Is there someone out there who could add a nice magnifying glass icon (or whatever is preferred), to pixmap.h? > The icon's tooltip can be "Search the Internet", "Search the > Web", or something better :-) Since the search engine to us is an option(search_url), perhaps another preference is desired, e.g. a search_name option, and then setting the tooltip to "Search using <search_name>". Alternatively, the server name could be extracted from search_url, but this may not always work as desired. > * It'd be also good to add middle-click over the clear-url > button, as a way to "paste-push" an URLs. Instead of the the > current three step sequence: > > - Press clear-url > - Paste URL > - Press enter A really great idea! But, just to be a smart ass ;-), doesn't this break the cognitive model behind dillo's interface in the same way as did the "s <keywords>" interface... > I carefully considered your previous email and this model > should take good care of the several points we talked about. Half > of the work is on CVS now, and the above mentioned details are > pending. Please send me a new patch with the modifications to > fast-track-commit-it-in! As noted above, you may already have considered the issues noted. So if you've already made up your mind, I'll go ahead and implement the remaining parts as soon as possible. Is there planned release date for 0.8.0? Best regards, Johan Hovold

Sept. 10, 2003

Re: [Dillo-dev] Re: [PATCHES] hand_cursor and image_popup, some remarks

by Frank de Lange

On Tue, 9 Sep 2003 15:57:42 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Yes, that problem is known since a long time. It was very hard > to root down! The good news is that it's solved. > > It's not a problem of dillo but of GTK1. details here: > > http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html > > (As Sebastian, I think we'd better solve this with GTK2.) This is not the same problem. set-focus-chain allows you to program around this problem... The real problem, however, is still there... There is a widget, somewhere, which gets focussed without showing a visible focus cue (this is the problem you described, which could be avoided by setting an explicit focus chain) and - the real problem - does not allow the tab key OR gtk_widget_grab_focus(some_other_widget) to shift away focus from it. > > > > Clashing with other apps. is almost unavoidable (unless we > > > clone), but we have chosen to rely over an underlying cognitive > > > model for our UI. It has been very succesful, and praised! > > > > > > Now, as a matter of serendipity :), the bouncing keyboard may > > > have shown us both a better way. If we make Ctrl-L focus the > > > location bar (as Ctrl-U does now) and a second Ctrl-L to clear > > > it, that may be a good choice. > > > > Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not > > in GTK2 though), so I think it is best to use it for that purpose > > in Dillo as well. For GTK2, following the toolkit default > > bindings is the logical thing to do. > > For now, I'll leave it as explained here: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.ht… Well, let's just say that I do not agree with all the choices (Ctrl-S for searhc the web? While just about every other application uses that for 'save'? And while searching can be done from the location bar or a search box? Please, no...) and, since I am not only a developer of (my version of) Dillo but also a user, I want my browser to do what I want, not what someone else thinks it should do. Hence the preferences. I guess I'm not the only one who feels like that - I know I'm not - so I feel that user choice is a good thing. Havoc's ideas notwithstanding. By the way, Havoc speaks about 'having good defaults'. Well, I think Dillo has some good defaults. But some defaults are less than good. Those which are - in the user's opinion - less than good can be changed using a preference (in the dillorc or some future preference plugin), those which are fine are left at their default setting. So, the user has as few or many preferences in the preference file as s/he wishes. Ain't choice a beautiful thing? Those who want their I-want-to-be-able-to-control-EVERYTHING app can have it, while those who are happy with the defaults can go by without any preferences at all... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 10, 2003

Re: [PATCHES] hand_cursor and image_popup, some remarks

by Jorge Arellano Cid

Hi there! On Tue, 9 Sep 2003, Frank de Lange wrote: > [ Jorge, your mailserver is not healthy... I tried to send this 3 times > without success, so it goes to the list instead... ] Yes, softhome has being acting strange the latter months. Fortunately we've being working with Andi K. to enable email from the wearlab. Please try: jcid at dillo.org It's working, so please use it (we're testing). With regard to softhome, I've received two of your 3 email attempts there (it sometimes reports a timeout error and _after_ that, accepts the mail ;) > On Mon, 8 Sep 2003 11:13:32 -0400 (CLT) > Jorge Arellano Cid <jcid(a)softhome.org> wrote: > > > You're right. In that case it causes more troubles than help. > > Please send me the patch to commit it to CVS. > > It is part of the tab/frame patch... It uses the document > abstraction. In non-patched Dillo, it would be something like: > > if(bw->nav_stack_ptr != -1) > gtk_widget_grab_focus(GTK_BIN(bw->docwin)->child); > else > gtk_widget_grab_focus(bw->location); Hmmm, I see. Read below. > > By the way, there are some problems with 'hidden focus' in Dw. > These problems only become directly noticeable in the tab/frame > patched version, but they are present in CVS Dillo as well. To > see the problem: > > 1. start dillo on a longish directory listing or a long document (so that the vertical scroll bar appears) > 2. use up and down arrow keys to scroll the document. This works in unpatched Dillo. In the (current) patched version, it only works AFTER pressing the UP key once... > 3. press SHIFT-TAB twice. Focus is now set on... something. Something invisible. There is no visible focus cue > 4. press DOWN key. Nothing happens, no matter how often you press it... Same for TAB, ENTER, RIGHT, ... > 5. press UP or SHIFT-TAB or LEFT key. Focus is now on the document, and scrolling keys work as they should. > > The problem does not show (in patched or unpatched Dillo) when in fullscreen mode. > > I've searched for the cause of this problem, but have not yet found it. Yes, that problem is known since a long time. It was very hard to root down! The good news is that it's solved. It's not a problem of dillo but of GTK1. details here: http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html (As Sebastian, I think we'd better solve this with GTK2.) > > Clashing with other apps. is almost unavoidable (unless we > > clone), but we have chosen to rely over an underlying cognitive > > model for our UI. It has been very succesful, and praised! > > > > Now, as a matter of serendipity :), the bouncing keyboard may > > have shown us both a better way. If we make Ctrl-L focus the > > location bar (as Ctrl-U does now) and a second Ctrl-L to clear > > it, that may be a good choice. > > Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not > in GTK2 though), so I think it is best to use it for that purpose > in Dillo as well. For GTK2, following the toolkit default > bindings is the logical thing to do. For now, I'll leave it as explained here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.ht… > Even better is to allow users to decide for themselves which > bindings they want. GTK2 does not allow this by default, but it > can be re-enabled. No matter how well thought out a model is, the > user should *always* be able to override the designer's defaults. > Even if that user messes up a perfectly thought out cognitive model. > > That is also why I make just about everything user-selectable > using preferences with sane default values. > > So, one of my next goals will probably be to implement > user-selectable accelerators in Dillo... Based on GTK's default > mechanisms for doing such a thing. We agree more with the line of GTK+2 authors. BTW, we follow Havoc's guidelines: http://www.dillo.org/ui-prefs-tips.html http://ometer.com/free-software-ui.html Consequently, I'd rather set a low priority on it. I'd much prefer the work to be focused on enabling basic DOM data-access, CSS parsing, floating-objects handling and thinks like that. > > > Of course, a more orthogonal way to do it, is the same > > functionality, but inside the location popup. But please > > experiment with the above suggested idea, and tell me your > > findings. > > Generally I find that popup menu's are more a hinder than a > help. This is more of a problem with window managers which do not > correctly manage them than with the basic concept of popups, but > as the state of the art currently stands I try to avoid them as > much as possible. > > I will therefore try to implement the functionality of Dillo's > transient popups (find and open url) in the main window, the > former probably in the status bar and the latter in the location > bar. And, of course, make a preference to allow the user to choose > which version to use - popup or main window. (same as above) > > Attached two patches, one for hand_cursor, one for right_click on image. > Some remarks: > > [...] Thanks. We'll look at them with Sebastian. > Maybe the image popup should be a submenu on other popups? See > the frame/frameset popups (in the tab/frame patch) for an example > of what I mean. That way, the image can also be accessed in links > (and, maybe, in input images, even those currently do not react > to RMB-clicks for obvious reason...) FWIW, we have this implemented with Eric for probably more than a year. The only reason it was held is to keep the UI consistent. > Please be aware of the fact that I will have to keep on adding > these patches to the tab/frame patch while the document > abstraction has not been committed to CVS... So I will have to > patch my own patches, not something I want to keep on doing too > long... I know the problem pretty well: that's why I suggested to select a release, or CVS date to base the patch on. Now, considering all the facts, the document abstraction seems a good part to start reviewing/merging. Please isolate it to start working on it. Regards Jorge.-

Sept. 9, 2003

Re: FW: [Dillo-dev] How do your clear the dillo cache

by Thorben Thuermer

On Sun, 7 Sep 2003 17:25:08 -0400 "Ronald W. Henderson" <rwhalb(a)nycap.rr.com> wrote: > The graphic images (which are *.png files) are the ones which are cached. If > I hit the reload botton the html code updates ok but the graphics don't. I > need to start and stop > Dillo for the graphic images to be updated. the way dillo implements refreshing does currently not support this, only the main document is reloaded, images referenced from it remain in the cache unchanged. you can, for example, open the individual images and reload them, then they will be updated on the next reload of the page.

Sept. 9, 2003