- Dillo-dev - lists.mailman3.com

dillo browser repaint
by Vikram Sept. 21, 2003

Sept. 21, 2003

Hi, I force dillo to browse to a new page based on some external event; the code is as follows [with text containing the url to goto] <snip> gchar* new_text = a_Url_string_strip_delimiters((gchar*)text); DilloUrl* url = a_Url_new(new_text, NULL, 0, 0); if (url) { a_Nav_push(transfer_bw,url); a_Url_free(url); } </snip> however i notice that the though the browser DOES goto the new url the screen [browser window] doesn't get painted properly. i seem to have to scroll up and down a couple of times to get it to repaint completely. Any idea why this would be ? [I don't know if this is related but the url's dillo is forced to goto are served typically by a tomcat servlet engine] Thanks, Vikram

2 1

patches
by landy Sept. 15, 2003

Sept. 15, 2003

where can i find patches for dillo

2 1

Image popup
by Jorge Arellano Cid Sept. 15, 2003

Sept. 15, 2003

Hi, A right-mouse-button popup for images has been added, please test and enjoy! :-) When the image is also a link, the link popup will appear instead. The plan is to add an "Image menu..." submenu entry at the end of it, and handle it in way similar to the "Jump to..." submenu in the page popup. Cheers Jorge.-

1 0

Re: [Dillo-dev] Re: [Patch] Search feature and more
by Jorge Arellano Cid Sept. 15, 2003

Sept. 15, 2003

Hi Johan! It took a long time to analyze the three patches, but finally here we are: [I'm not quoting the previous email bacause it got too big and can be easily found at the web archives] The patches were: 1.- Made main document window grab focus on startup and after open url. Commited! In the meanwhile, Owen taylor answered my post to GTK-list and it become clear that the "Nirvana"-widget issue is solved in GTK2. Thanks a lot for your comments on this. You may find interesting to read the answer: http://mail.gnome.org/archives/gtk-list/2003-June/msg00307.html 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. 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. 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). The icon's tooltip can be "Search the Internet", "Search the Web", or something better :-) The final touches: * While working on the location bar shortcuts, 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. * 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 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! Best Jorge.-

3 2

Cosmetic 0.7.3 patch
by Andrew R. Greenwood Sept. 13, 2003

Sept. 13, 2003

Greetings, I originally started changing the following for fun, but after I had finished I found these cosmetic touches give Dillo a more polished and appealing look. I felt it was a nice improvement, so I decided to diff the changes (as instructed on the site) and subscribe to this mailing list. I hope others like these changes as much as I do. Here is a summary of what I've done: * Added a space at the beginning and end of the image and page progressbar text to offer a nice clean padded look in all of the panel_size modes * Cleaned up case inconsistencies and wording in context menus; verbage from Mozilla * Removed trailing menu separators and uppercase title menu entries from context menus to give them a more polished look * Changed the "View Source" window title to "Dillo: View Source" for window management consistency Any feedback will be greatly appreciated =) Andrew R. Greenwood <shadearg(a)sdf.lonestar.org>

1 0

ipaq dash keys
by Vikram Sept. 12, 2003

Sept. 12, 2003

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

1 1

New dpid patch
by Ferdi Franceschini Sept. 11, 2003

Sept. 11, 2003

There is a new dpid patch for dillo-0.8-pre available from http://www.geocities.com/ferdif2003/ Plugins are now stored in a directory structure under libdir/dillo/dpi. You need to put dpi_dir=/usr/local/lib/dillo/dpi in ~/.dillo/dpidrc so that dpid can find the plugins, there should be no other entries in this file. Dpid now uses a .filter suffix in the plugin name to identify plugins which read and write to stdio (eg hello.filter.dpi). The following changes affect the CVS repository: Renamed dpiddir.[ch] to dpi_socket_dir.[ch] New files dpi_service.[ch] Cheers, Ferdi

2 1

[RFC] Find as you type, statusbar instead of popups, etc
by Frank de Lange Sept. 11, 2003

Sept. 11, 2003

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

3 3

[PATCHES] GTK1 focus problem, solution
by Frank de Lange Sept. 10, 2003

Sept. 10, 2003

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

1 0

[PATCHES] hand_cursor and image_popup, some remarks
by Frank de Lange Sept. 10, 2003

Sept. 10, 2003

[ Jorge, your mailserver is not healthy... I tried to send this 3 times without success, so it goes to the list instead... ] 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); Question is, how much sense does this make in a single-document window? When the window is created, the navigation stack is empty, so focus will always be on the location bar... 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. > 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. 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. > 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. As for using CTRL-L for clearing the location bar, I do not think this is a good idea. But, it is not for me to say it is a bad idea either. > PS: If you send me the requested patches, chances of fast commit > are very high Attached two patches, one for hand_cursor, one for right_click on image. Some remarks: The 'image save as' function in the image popup works, but is dependent on the dpi for the actual save function. That dpi (or, rather, wget) does not know how to handle some link types (eg. file: links), so it will fail on those. The hand_cursor patch works fine, but input_images do NOT work as stated in my previous message. Reverse the patch to dw_button.c to get them back to live... 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...) 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... 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." ]

2 2