- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Development

by Scorpio Rising

Behold, Carlos Daniel Ruvalcaba Valenzuela scribed in runic symbols on a tube chassis: > * ddm_srv.c Dillo Download Manager, a download plugin using wget, will be able to download multiple files and show their progress in dpi:/ddm/downloads Oy! Could I use this one :-)

Oct. 15, 2003

[PATCH] version 1 of keyboard navigation patch

by Frank de Lange

Hi'all, The first version (1) of my keyboard navigation patch is ready. See the end of this message for download instructions. Do note that the tab/frame patch already contains this functionality, so there is no need (and no way) to apply this patch on top of that or the other way around. The patch adds Keyboard navigation with configurable key bindings to (the CVS version of) Dillo. Please test it and let me know what you (don't) like. Even though keyboard navigation does not make much sense with devices without keyboards (pda's, etc), there is no configure option to disable it. Let me know if there is a need for such an option (it is easily implementable). Personally I think there is... For keyboard navigation to work Dillo has to track the position of individual words in a document, which increases memory overhead with 4 bytes per word. However, there seems to be some animosity against the added complexity of conditionally compiled code (enclosed in #ifdef ... #endif). More information on keyboard navigation can be found in the document "Keyboard_Navigation.txt" in the doc/ directory which I'll just reproduce it here: Keyboard Navigation =================== You can use the keyboard to navigate links and controls in Dillo. In the default configuration, the following keys are used: Alt-Up: link UP Alt-Down: link DOWN Alt-Left: link LEFT Alt-Right: link RIGHT Enter: follow link or activate GTK+ widget Escape: unhighlight link In a non-frames version of Dillo the following keys are also used: Tab: NEXT link Shift-Tab: PREVIOUS link these keys are not bound by default in a frames-capable version of Dillo because they are used to navigate between frames. You are free to bind them (or any other key combination) to these functions though (see Keyboard bindings) Sometimes the result of link UP and link DOWN seems a bit unpredictable. This can happen when the next UP or DOWN link is currently not visible (below the bottom or above the top of the window). The screen coordinates for words are only known when they are in the visible area of the viewport, so off-screen links are accessed sequentially instead. Search and keyboard navigation ------------------------------ Keyboard navigation works with the Search feature: if search hits a link, it will be focused. Press <Enter> in the viewport to follow the link, <Esc> to unhighlight it. When using the status bar for search (an optional feature in the tabbed version of Dillo), press <Esc> to close the search entry followed by <Enter> to follow the link. A second <Esc> will unhighlight the focused link. Pressing <Enter> in the search entry (popup or status bar) repeats the search. History ------- The focus location is saved when navigating to another document in the same window or tab. This makes it possible to go back in history and continue to the next link on the page. Form fields ----------- The same keys used for link navigation work for form field navigation. Do note however that form fields, being embedded GTK+ widgets, can have their own bindings for some functions. As an example, the space bar is bound to the activate function in radio buttons. Keyboard bindings ================= It is possible to change the keyboard bindings used for keyboard navigation, either through editing the dillorc or by adding a section to any of the current GTK+ rc-files. The syntax is the same, the only difference is the addition of the preference keyword "key_bindings" in the dillorc and the fact that the bindings have to be enclosed in double quotes. As an example, this configuration (in gtkrc) uses the numerical keypad for link navigation: binding "keypad-keys" { bind "KP_Add" { "focus_move" (0) } bind "KP_Subtract" { "focus_move" (1) } bind "KP_8" { "focus_move" (2) } bind "KP_2" { "focus_move" (3) } bind "KP_4" { "focus_move" (4) } bind "KP_6" { "focus_move" (5) } bind "KP_Enter" { "focus_activate" () } } class "GtkDwScrolledFrame" binding "keypad-keys" You can also use 'widget "*dillo-content" instead of 'class "GtkDwScrolledFrame" if you prefer to use widget names: widget "*dillo-content" binding "keypad-keys" This one (in dillorc, note the enclosing double quotes, the use of single quotes and the preference name 'key_bindings') makes Dillo behave like the vi editor when it comes to link navigation: key_bindings = "binding 'vi-keys' { bind 'k' { 'focus_move' (2) } bind 'j' { 'focus_move' (3) } bind 'h' { 'focus_move' (4) } bind 'l' { 'focus_move' (5) } } class 'GtkDwScrolledFrame' binding 'vi-keys'" The numerical values after "focus_move" are actually GTK enumeration values, but the current implementation does not support this. It would of course look much better to be able to write "focus_move" (GTK_DIR_DOWN) instead of "focus_move" (3)... It is also possible to bind a sequence of actions to a single keypress by adding more actions after the first. Bugz^Hs ======= - Image links without alt text do not work with keyboard navigation. - Image links with alt text work, but Dillo is currently not able to scroll to them. This can lead to 'hidden' focused links, use the scroll keys or scroll bars to bring them in to view. This problem is shared with the Search feature. It is caused by a deficiency in the widget iterator function which is used for scrolling. - The sometimes unpredictable behaviour of link UP/DOWN can be classified as a bug. Or not. It is probably hard to solve this. The root cause is the use of incremental display in dw_page, which is in itself a good feature. To good to mess it up with some hack to get each and every link in the right place before using keyboard navigation. TODO ==== Well, apart from fixing those bugs... Maybe merge focus with search, they have quite a lot in common. This would save some code and memory. It would also mess up the current design, so maybe this is not such a good idea. Add more GTK+ bindings, replacing current key_press event handling. ... Download instructions ===================== There is currently only one version of the patch, made against 20031014 CVS. Sorry, no 0.7.3 support (yet...). As always, have a look at the patch website (http://www.geocities.com/ikbenfrank/) for the latest version of the patch. This patch does NOT apply on top of the tab/frame patch, and the tab/frame patch does not apply on top of this one! The tab/frame patch already contains this functionality, so it is not needed. Also, there is some overlap in the patched files, so I'd have to create a special version of this patch for this purpose. http://www.geocities.com/ikbenfrank/dillo-200310142300-kbnav.patch.gz size: 14336 bytes (gzipped, as downloaded) 62481 bytes (uncompressed) md5sum: 06c21168960cc5de12437ab4abff6d45 (gzipped, as downloaded) a1317f63190ad0df9501bbb257f8c137 (uncompressed) 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." ] -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 15, 2003

[PATCH] version 11 of tab/frame patch, added keyboard navigation

by Frank de Lange

Hi'all, The next version (11) of my tab patch is ready (see bottom of this message for download instructions). The big new features are keyboard navigation and configurable key bindings (currently only for keyboard navigation and scrolling, more will be added later). See below for more information on these features. Keyboard navigation is also available in a separate patch, for those who do not want to apply the tab/frame patch. Watch the mailing list and/or see the patch website (http://www.geocities.com/ikbenfrank/) for more information. New features: - keyboard navigation! - configurable key bindings (for keyboard navigation and scrolling) Fixed bugs - solved the 'missing frames' problem for German (and other?) users. Stephan Goetter pointed me in the right direction (the German locale uses the "," as a decimal separator). Some behavioural changes with regard to stock (CVS) Dillo: - Shift-Ctrl-L (instead of Ctrl-L) for "open URL" dialog - Ctrl-L for "focus location bar" - Ctrl-S for "Save page As..." - Ctrl-U for "view source" while in a document, "clear entry" everywhere else (in stock Dillo this key is bound to "focus location bar" while in a document) - Ctrl-B for "Bookmark this page" - Alt-H for "Home" - "/" starts incremental search instead of normal search. For normal (non-incremental) search use Ctrl-F Support for the 0.7.3 branch has been dropped as of this version of this patch. Sorry, folks, but that is the price you pay for progress... Currently, both tab and frame support can be turned off completely, producing a smaller binary. I might (on request of other Dillo developers) remove the conditional compilation, thereby making tab and frame support a permanent feature of Dillo. If you want to keep the conditional compilation feature, speak out on the mailing list! Keyboard navigation can currently NOT be turned off, let me know if this is needed. Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - the frameborder attribute works, but dw_gtk_scrolled_frame always draws a (focus) shadow around itself - even with the border size is set to 0. This can be solved in several ways - adding a 'borderless' attribute to dw_gtk_scrolled_frame, using a special borderless GTK theme for the widget, etc. In GTK2 this is all much easier (just set the widget's style's xthickness/ythickness to 0), but we're not there yet... - borderless frames can not be resized, even though Dillo always shows a thin border (see above). Who cares about resizing borderless frames? Mozilla does it, but I don't think this is an issue. Agree? - iframes always have a border (see above) Keyboard Navigation =================== You can use the keyboard to navigate links and controls in Dillo. In the default configuration, the following keys are used: Alt-Up: link UP Alt-Down: link DOWN Alt-Left: link LEFT Alt-Right: link RIGHT Enter: follow link or activate GTK+ widget Escape: unhighlight link In a non-frames version of Dillo the following keys are also used: Tab: NEXT link Shift-Tab: PREVIOUS link these keys are not bound by default in a frames-capable version of Dillo because they are used to navigate between frames. You are free to bind them (or any other key combination) to these functions though (see Keyboard bindings) Sometimes the result of link UP and link DOWN seems a bit unpredictable. This can happen when the next UP or DOWN link is currently not visible (below the bottom or above the top of the window). The screen coordinates for words are only known when they are in the visible area of the viewport, so off-screen links are accessed sequentially instead. Search and keyboard navigation ------------------------------ Keyboard navigation works with the Search feature: if search hits a link, it will be focused. Press <Enter> in the viewport to follow the link, <Esc> to unhighlight it. When using the status bar for search (an optional feature in the tabbed version of Dillo), press <Esc> to close the search entry followed by <Enter> to follow the link. A second <Esc> will unhighlight the focused link. Pressing <Enter> in the search entry (popup or status bar) repeats the search. History ------- The focus location is saved when navigating to another document in the same window or tab. This makes it possible to go back in history and continue to the next link on the page. Form fields ----------- The same keys used for link navigation work for form field navigation. Do note however that form fields, being embedded GTK+ widgets, can have their own bindings for some functions. As an example, the space bar is bound to the activate function in radio buttons. Keyboard bindings ================= It is possible to change the keyboard bindings used for keyboard navigation, either through editing the dillorc or by adding a section to any of the current GTK+ rc-files. The syntax is the same, the only difference is the addition of the preference keyword "key_bindings" in the dillorc and the fact that the bindings have to be enclosed in double quotes. An example of the configuration syntax can be found in the dillorc and on the mailing list. Tabs, Frames, Keyboard navigation and browser bloat =================================================== version: 0.8.0-pre patch: dillo-20031015-tabs.patch.gz unpatched: 294132 bytes patched, no tabs, no frames: 308404 bytes patched, with tabs, no frames: 315220 bytes patched, no tabs, with frames: 324852 bytes patched, with tabs, with frames: 333108 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") The increase in size is due to the addition of keyboard navigation. If you want to be able to compile Dillo without this feature (it takes about 10 KB) let me know through the mailing list. Download instructions ===================== The patch is made against 20031014 CVS. Do not forget to run ./autogen.sh after applying the patch. You can find the patch on the usual (ad-happy, use an ad-blocking proxy or sane browser) site: http://www.geocities.com/ikbenfrank/ More specifically: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20031015-tabs.patch.gz size: 85716 bytes (gzipped, as downloaded) 371416 bytes (uncompressed) md5sum: 358041a00feeef1706b81d24a985613a (gzipped, as downloaded) bf61b1bdb212c69c30ee1fa6fa74f729 (uncompressed) As always, check the site for the most recent version 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." ]

Oct. 15, 2003

RE: [Dillo-dev] FLTK

by Eric GAUDET

-- En reponse de "RE: [Dillo-dev] FLTK" de Eric Gaudet, le 14-Oct-2003 : > I will give it a try. > >> Hi! >> >> To have some facts for this discussion, there is a (basicly working) >> patch for the Gtk2 port, at http://www.dillo.org/misc_files/gtk2.diff.gz >> It is a slightly modified version of a patch, which J�rgen sent me >> some time ago, and compiles with the current CVS (probably not with >> 0.7.3). >> >> Sebastian >> Ok, here are the numbers. But first, the test procedure. I did a fresh cvs checkout twice, and applied the patch to one of them and compiled both. I named dillo1 the one using gtk-1.2 and dillo the one using gtk-2.0. The only difference between dillo1 and dillo2 is the gtk version they use, everything else is the same (internal representation of the page widgets) I'm running debian testing and I updated my system just before the test today: gtk 2.2.1-6 and pango 1.2.5-1. My machine is a Toshiba 3020CT laptop, Pentium-MMX 300MHz with 64MB ram First run: ---------- I tried to render the front page of tigerdirect.com, which should represent a fairly common page design. First, I download the page and the images with 'wget -kp http://www.tigerdirect.com'. index.html is 66kB and it loads 30 gif and 23 jpg images. I loaded the page with both dillo1 and dillo2 with the command 'time dillo1 index.html'. I exited dillo shortly after the loading and rendering were completed. The idle time after rendering is not included in the results, nor is the system time used to actually load the page: I'm only giving the user time, which is the cpu time the application used. I'm also not giving the real time for this run, since it depend on the average cpu load, the memory swapping, etc, and would need a much more elaborate benchmark to be significant. For the memory usage, I used pmap on the dillo process, and added only the anonymous pages (mallocs). For each browser, I ran the test once, disregarding the time (to let buffering occur), then several times and calculated the average time. Results: time1 time2 delta/30 prps mem(KB) dillo1 1.36s 1.82s 15ms 67 2516 dillo2 3.10s 6.90s 126ms 8 3624 Legend: - time1 represent the time for starting the browser, wait for rendering to complete, and quit. - time2 represents the time for starting the browser, wait for rendering to complete, then press the pagedown key twice, then the pageup key twice, for a total of 30 redraws of the page, them quit - delta/30 is the difference between time2 and time1 divided by 30. This is the time to redraw the page. - rps is the number of page renderings per second: this is 1/(delta/30) - mem is the memory usage in KiloBytes. Conclusion: The starting time is longer for dillo2, but not too by much and I think I could live with it. Scrolling through the page is noticeably slower, with a significant delay between the clicks or key presses and the actual redraw. dillo1 is always snappy and blazing fast, even when dragging the page with the middle button. dillo2 feels heavy and slow, and it's hard to drag the page around, since the page display is following the mouse movements with a delay. Second run: ----------- For this run, I wanted to render a very large page. I used a 2.5MB html file without images, and only a few tables, displaying 7300 lines of mixed bold, italic, regular text and 2 links for each line. Results: time1 time2 dillo1 13.2s 14.2s dillo2 n/a n/a Legend: - time1 represent the time for starting the browser, wait for rendering to complete, and quit. - time2 represents the time for starting the browser, wait for rendering to complete, then press the pagedown key to scroll all the way down, then quit Conclusion: dillo2 could not complete this test: after a few minutes it started swapping like crazy and used all the memory and cpu. I had to kill it. I aborted this test and did not do mem usage. Third run: ---------- This is a scaled down version of the second run. I took the same file and kept only the first 2000 line. The test file is 684 KB. Results: time1 time2 mem(KB) dillo1 5.1s 35s 12708 dillo2 31.5s 2m53s 33520 Legend: - time1 represent the time for starting the browser, wait for rendering to complete, and quit. - time2 represent the real time for the same operations. I quit the window as soon a the page finished to load (the top-right box was grayed-out) - mem is the memory usage of the page. Conclusion: I like to use dillo to display documentation, and when I do that I always choose the "all in one big page" link, because I know dillo will swallow it without complaining, and I will be able to scroll through it to find what I need. With dillo2, I don't feel confident doing that anymore. Fourth run: ----------- This is the start time test: just display the start screen to see the mem usage. I did this test only because of the failure in the second run. I wanted to know more about the scallabilty issues of dillo2 and I needed a starting point. Result: mem(KB) dillo1 944 dillo2 2148 Conclusion: Dillo2 seems to use much more memory than dillo1 for pure text rendering. Image and other widgets seem to use the same amount of memory. Overall, displaying the same page in dillo2 needs 2 to 3 time more memory than in dillo1. Fifth run: ---------- This is a free run of internet browsing, to get an overall feeling. No numbers for this one. Conclusion: This test confirms the feeling I had throughout this test: dillo2 feels slow and everytime I scroll I find myself waiting the the page to redraw. Maybe I'm just used to dillo1's speed. During my every day usage, starting dillo1 is as fast as starting vi in a console, and you're merely displaying a text file for free. With dillo2, you really feel like you're starting an *application*: it needs a (small) investment (of time) every time. This is a different feeling. Also, I thought the main goal of dillo2 was to display unicode characters. I tried to display asian characters, but I had the same result as dillo1. Is this not coded yet? I though it was free with pango. As for the rendering itself, I must admit that anti-aliasing is nice. Kinda blurry but nice. But the characters are much larger than in dillo1: I had to use font-factor 0.8 for dillo2 and 1.2 for dillo1 to have the same texst height. Final conclusion: ----------------- I don't think I want to give up dillo1's speed for a marginally better rendering. I understand there are asian-fonts patches out there, maybe we could include them as a compile-time option. Being able to render very large documents without dragging the whole system down is also a big plus for me, and dillo2 really disapointed me there. Best, Eric

Oct. 15, 2003

Re: [Dillo-dev] FLTK

by Sebastian Geerken

Hi! To have some facts for this discussion, there is a (basicly working) patch for the Gtk2 port, at <http://www.dillo.org/misc_files/gtk2.diff.gz>. It is a slightly modified version of a patch, which Jörgen sent me some time ago, and compiles with the current CVS (probably not with 0.7.3). Sebastian

Oct. 14, 2003

RE: [Dillo-dev] FLTK

by Eric Gaudet

I will give it a try. > -----Original Message----- > From: Sebastian Geerken [mailto:s.geerken@ping.de] > Sent: Tuesday, October 14, 2003 1:55 PM > To: Dillo mailing list > Subject: Re: [Dillo-dev] FLTK > > > Hi! > > To have some facts for this discussion, there is a (basicly working) > patch for the Gtk2 port, at > <http://www.dillo.org/misc_files/gtk2.diff.gz>. > It is a slightly modified version of a patch, which Jörgen sent me > some time ago, and compiles with the current CVS (probably not with > 0.7.3). > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Oct. 14, 2003

RE: [Dillo-dev] FLTK

by Madis Janson

On Tue, 14 Oct 2003, Eric Gaudet wrote: > > Please back your opinions with links, docs, facts or with > > whatever helps better to understand the point. Maybe a single > > email can show there's no way to do it, or maybe not! > > Two applications I used to run regularly when they were on gtk1.2 were > ported to gtk2.0: pan and edonkey2000-gtk. > > I'm not using them anymore, because their rendering became painfully slow: > scrolling the lists down takes several seconds to refresh on my 300MMX > laptop. I had similar experience with xchat 1.x (based on gtk1.2) and 2.x (gtk2) - text scrolling in 2.x version was noticably slow, when i used it on 200MHz pentium. Even new irc messages caused visible redraw when old messages were scrolled up by 1 line.

Oct. 14, 2003

RE: [Dillo-dev] FLTK

by Eric Gaudet

> Please back your opinions with links, docs, facts or with > whatever helps better to understand the point. Maybe a single > email can show there's no way to do it, or maybe not! > Two applications I used to run regularly when they were on gtk1.2 were ported to gtk2.0: pan and edonkey2000-gtk. I'm not using them anymore, because their rendering became painfully slow: scrolling the lists down takes several seconds to refresh on my 300MMX laptop. After doing some research, is seems that Pango is the culprit: rendering unicode needs some advanced graphic operation also slows down any text rendering. As I yet have to see a fast application using it, I would recommend NOT going with gtk2.0 for Dillo. Best, Eric

Oct. 14, 2003

Re: [Dillo-dev] FLTK

by Madis Janson

On Tue, 14 Oct 2003, Jorge Arellano Cid wrote: > * Does it provide C bindings, or is for C++ only? C++ only, although event callbacks are done using C style function pointers http://www.fltk.org/documentation.php/doc-2.0/intro.html#2_1 commented fltk example program http://www.fltk.org/documentation.php/doc-2.0/editor.html#editor > * Does it have a table widget or similar to GTK+'s layout? http://www.fltk.org/documentation.php/doc-2.0/Fl_Pack.html#Fl_Widget http://www.fltk.org/documentation.php/doc-2.0/Fl_Group.html#Fl_Group > * Unicode and antialiasing support status? antialiasing yes. unicode support - seems, that it currently needs a patch for unicode support http://www.fltk.org/links.php?V111 google found this http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/53707

Oct. 14, 2003

FLTK

by Jorge Arellano Cid

On Fri, 3 Oct 2003, David Martin wrote: > Jorge, > > I would like to quickly comment on the todo list. > > [Snip] > > *Future Goals* (these may change in the future) > Port dillo to GTK+2.0 > > [/Snip] > > IMHO considering Dillo's concentration on speed and stability, it seems > like it would be more appropriate to port the future Dillo to fltk not > fat bloated GTK2.0. > > I would expect that a staticly compiled Dillo-fltk binary would be > considerably smaller then a dynamically compiled Dillo-GTK2 binary. > > > Food For Thought. The FLTK idea is certainly an insteresting issue to analize. The porting task would be far from simple (if possible at all). Dillo does not only uses GTK+ for the user interface but for HTML rendering. Dillo has its own widget system (Dw), that's embedded inside GTK+ widgets, and that at its turn can also embedd GTK+ widgets again. This is the core of the porting problem. The main reason for porting dillo to GTK+2 (instead of sticking to 1.2.10) is Unicode support (explained in the [Project Notes] link). And yes, I've been somewhat scared by the size of GTK+2. For instance in Slackware it jumps from 4Mb to 17Mb! Now, considering that FLTK has Unicode support, gathering more information becomes an interesting thing to do. I don't know FLTK :(, but here is a list with some preliminary concerns (AFAIK): * Does it provide C bindings, or is for C++ only? * Does it have a table widget or similar to GTK+'s layout? * Can it be extended with Dw in the way stated above? * Unicode and antialiasing support status? Please don't get me wrong. This email is just a RFC to make a more informed decision on the issue. The current plan is to go with GTK+2, but if this path shows better, things can change. This is also an RFC for information on GTK+2 (speed, size, linkings etc). Please back your opinions with links, docs, facts or with whatever helps better to understand the point. Maybe a single email can show there's no way to do it, or maybe not! Cheers Jorge.-

Oct. 14, 2003