- Dillo-dev - lists.mailman3.com

[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

Development

by Carlos Daniel Ruvalcaba Valenzuela

Hi everyone It sems i lost a lot of the development cycle, now even plugins are implemented! Anyways, here is my wasted effort with dillo-0.7.3: * Fixed dpi.c capi.c, to handle launching multiple dpis via url, example dpi:/bm/ will launch bookmarks plaugs, dpi:/cfg/ will launch the configuration plugin. * Worked on dpilib a bunch of code to initialize comunications from a dpi to dillo, it works pretty well, also handles tag params, and url passed vars. * 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 * cfg_srv.c Configuration, It can tweak a bunch of options for Dillo and DDM. Way back about a month i worked on a plugin daemon too. But with current changes i maded the daemon is not necesary, also dillo can load plugins if necesary. Any comments?, anyone wants the patches? Anyway, cheers. Carlos Daniel Ruvalcaba Valenzuela --------------------------------- Do You Yahoo!? Yahoo! Net: La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.

Oct. 14, 2003

PLEASE CONTACT ME

by Mr. George Rhoney

Dear Friend, I am an accountant and a member of the Contract Tender Board (CTB) of the Petroleum, Oil & Gas Corporation of South Africa (PTY) Ltd also known as PetroSA. I am presently on a special diplomatic duty in the South Africa foreign office in Amsterdam, the Netherlands. I got your contact through discreet inquiries in my search for a reliable individual or company who can handle a strictly confidential transaction that involves the transfer of a reasonable sum of money to a foreign account. I have no doubt in your ability to handle a financial business of considerable amount, which will form the bedrock of an extensive business partnership in due course. In unfolding this proposal, I want to count on your status that you will handle this transaction with all maturity and confidentiality it deserves. The money we want to transfer to you amount to a total of US$15.500,000.00 (Fifteen Million, Five Hundred Thousand United States Dollars) only. It was extracted from various over-invoiced contracts, masterminded by myself and some of my colleagues for our mutual benefit when the contracts was awarded by the Contracts Tender Board (CTB) of the Petroleum, Oil & Gas Corporation of South Africa (PeTROSA) Ltd. The above over-invoiced sum has been drafted and short-listed for final payment to a foreign bank account and it has been reflected as an amount to be paid to a foreign contractor for contract that has been executed for the Petroleum, Oil & Gas Corporation of South Africa (PTY) Ltd. The money is currently floating in the suspense account of the South Africa Reserve Bank (SARB) awaiting claim by a foreign partner, which status we absolutely want you to assume. The code of conduct bureau in South Africa has made it an offence for civil servants like us to(A) operate a foreign account (B) own a foreign company and (C) take up contract while still in active service. This is why we need your assistance. Now is the optimum period to realize this fund following the recent directive given to all-federal parastatals and corporations to pay off all foreign debts. I therefore seek your assistance to allow the remittance of this fund to be made to your personal or companys bank account. We have agreed that 30% of the total sum will be given to you, 65% will be for me and my colleagues and 5% for any expenses that maybe incured during this transaction, after the successful transference of the fund to your bank account. I want to assure you that all modalities for the successful transfer of this money to your account has been perfectly worked out and as such, there is no fear of failure. However, I would want to believe that you are honest enough and will not raise any misgiving attitude in any aspect of the transaction. Most importantly, you will keep this transaction very confidential so as not to tarnish the confidence reposed on these officials by the nations financial house. If this business proposal interest you, kindly indicate your willingness to me through email or by phone (+ 31-619-310-577) for immediate commencement of the transaction. To enable this fund to be successfully transferred to your account, you will also have to provide the following information: 1.Your company name and address that you wish to use as the beneficiary to claim the fund. 2.Your private telephone, fax Numbers. 3.Your Bank name, address and account number where you would want the money remitted. More information about the remittance of the fund to your account will be sent to you when I receive your response. Meanwhile, your swift response will help to meet the ultimatum given to all foreign contractors in this payment quarter to ensure that funds are claimed. We also wish to discuss investment strategy with you. We have the plan of investing part of our fund in real estate with your assistance in your country. Please, treat this information as confidential. Yours faithfully, Mr.George Rhoney.

Oct. 13, 2003