[PATCH] Version 16 of tab/frame/kbnav/etc patch is ready
Hi'all, The next version (16) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). This is mainly a bug-fix and CVS resync release. For an overview of the new features in this release, see the posting I made to the list on version 15. Fixed bugs ---------- keyboard navigation - erroneously highlighted link after leaving a form element, was caused by wrong function call order in focus_next_link. Fixed. keywords - problem with keywords separated by more than one space is fixed. Keywords can now be separated by any whitespace character, including newlines (but don't forget that you still have to enclose the whole keywords string in double quotes for the parser to recognize it!). splash screem - the splash screen is now installed in $(datadir)/dillo/dillo.html CVS date/time ============= The patch is made against CVS as it was on 20031124@13:18 GMT. It should apply against CVS as it was on 20031121@21.33 GMT and later. For those who can not or do not want to use CVS, a snapshot can be found here: http://www.geocities.com/ikbenfrank/dillo-200311241318.tar.gz Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20031124-tabs.patch.gz unpatched: 297204 bytes patched: 333460 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Download instructions ===================== The patch is made against 20031124@13:18 GMT 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-20031124-tabs.patch.gz size: 117192 bytes (gzipped, as downloaded) 531247 bytes (uncompressed) md5sum: 387f4dd85ead27de04d6527cc71504f5 (gzipped, as downloaded) 23ef8335f885d5657c75c7e9e0e18a3c (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@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 \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Hi,
The next version (16) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions).
Pasting from a web page to the URL entry does not work. (But pasting to an entry field in the web page or in another X app works). It looks also that selecting a link, we cannot paste the text of the link (not the link itself). I don't have a non-patched dillo anymore to test if this is due to your patch or not. Thanks for your work: it really suits my browsing habits (incremental search, no dialog for searching, keywords, keyboard navigation). Concerning the keyboard navigation, thanks for adding support to open the menu popup from the keyboard. Concerning the accessibility, I must say I have no experience, but adding keyboard navigation is surely a real improvement: it is n°1 on the Checkpoints for User Agent Accessibility Guidelines 1.0 at: http://www.w3.org/TR/UAAG10/uaag10-chktable.html. -- Melvin Hadasht
Melvin Hadasht wrote:
Pasting from a web page to the URL entry does not work. (But pasting to an entry field in the web page or in another X app works).
Noticed. Might have something to do with the focus-related code. I'll see what I can do about this..
It looks also that selecting a link, we cannot paste the text of the link (not the link itself). I don't have a non-patched dillo anymore to test if this is due to your patch or not.
I noticed this as well - even before the release - but forgot to fix it. The fix should be really simple if it is what I think it is: a case of the selection code (or ext_iterator) not knowing how to handle combined content types. Should be fixed in next release. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Melvin Hadasht wrote:
Pasting from a web page to the URL entry does not work. (But pasting to an entry field in the web page or in another X app works).
This is related to the new focus-related code: on grab-focus the location bar (and the search entry fields) select their contents. This causes the selection in the page to be destroyed. I'll see if I can find a way around this problem.
It looks also that selecting a link, we cannot paste the text of the link (not the link itself). I don't have a non-patched dillo anymore to test if this is due to your patch or not.
This is solved. It was, as I expected, a missing update to selection.c. A new macro (DW_CONTENT_ALL(content.type)) can be used in situations where the DW_CONTENT_FOCUSABLE type should be filtered out (eg. switch statements). Fix in next release of patch, if you want to have the fix now apply the short patch which is attached to this message to a PATCHED dillo tree. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] --- dillo_patched/src/selection.c.org 2003-11-25 12:39:16.119342032 +0100 +++ dillo_patched/src/selection.c 2003-11-25 12:40:26.743605512 +0100 @@ -568,7 +568,8 @@ (cmp = a_Dw_ext_iterator_compare (i, b)) <= 0; a_Dw_ext_iterator_next (i), start = FALSE) { si = i->stack[i->stack_top]; - switch (si->content.type) { + switch (si->content.type & + (DW_CONTENT_ALL ^ DW_CONTENT_FOCUSABLE)) { case DW_CONTENT_TEXT: if (start) { tmp = g_strndup(si->content.data.text + a_char,
Hi, Things I noticed: Frames with zero border aren't supported. When there is a scrollbar in a frame it has a fat border to the left, making it a little bit ugly, even wider than it already is, and making it look more a part of the right frame because there is no such border at that side (see www.xenon.nl for what I mean, or any other site with similar frames). Reload doesn't reload all the frames. Known issue, but still annoying. :) Random site that doesn't work (thanks google): http://www.public.iastate.edu/~stvoh/homepage.html "works" with the normal Dillo, but renders nothing with the frames patch (non-standard frames?). I will change my installer setup, I'll just use your patched Dillo code and apply my own patches on it, or download Dillo CVS and apply all the patches on it and make a tarball. I figured out that that's less work and better because people don't need to have CVS. This is such an obvious thing to do, and still I didn't think of it, sigh... Greetings, Indan
Other issues: When resizing a vertical frame, a horizontal scrollbar is rendered in a blinking way, even when it's not needed. This seems to appear only if a scrollbar will be rendered when the frame doesn't fit, so when you'll never see one it won't blink while resizing either. I guess this is the case with horizontal frames too, but didn't find one to test it with (example url: http://members.ams.chello.nl/wasscher/weer/). Should be easy to fix, I guess initializing the size to 0xffffffff or something instead of 0 at the right place could fix it, if it isn't a GTK issue. Also the history seems very broken/buggy with framed webpages. Only thing that worked for me on one page was forward/backward for the main frame, and for most other sites there doesn't seem to be any history for frames at all, even right-clicking gives no forward/backward options (know issue I assume). Side note: Paul Pelzl's toggle force-my-colours patch seems to work fine. Another one: Could you please edit your version of capi.c slightly, so that I don't have to make a seperate version of my patch? Just an extra #ifndef HTTPS / #endif somewhere, so it won't affect your code at all. The diff: @@ -253,15 +253,17 @@ gint a_Capi_open_url(DilloWeb *web, CA_C (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->dd, cmd, "ftp", 1); g_free(cmd); +#ifndef HTTPS } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->dd, cmd, "https", 1); g_free(cmd); +#endif } else { return a_Cache_open_url(web, Call, CbData); I would be grateful if you add this change to the next version of your patch. Greetings, Indan
Indan Zupancic wrote:
Other issues:
When resizing a vertical frame, a horizontal scrollbar is rendered in a blinking way, even when it's not needed. This seems to appear only if a scrollbar will be rendered when the frame doesn't fit, so when you'll never see one it won't blink while resizing either. I guess this is the case with horizontal frames too, but didn't find one to test it with (example url: http://members.ams.chello.nl/wasscher/weer/). Should be easy to fix, I guess initializing the size to 0xffffffff or something instead of 0 at the right place could fix it, if it isn't a GTK issue.
This is explained in dw_gtk_viewport.c (Dw_gtk_viewport_calc_size): /* * Determine the size hints for the Dw widget. This is a bit * tricky, because you must know if scrollbars are visible or * not, which depends on the size of the Dw widget, which then * depends on the hints. The idea is to test several * configurations, there are four of them, from combining the * cases horizontal/vertical scrollbar visible/invisible. *
* For optimization, the horizontal scrollbar is currently not * regarded, the height hint is always the same, as if the * scrollbar was allways visible. In future, this may be * implemented correctly, by using the minimal width to optimize * most cases. (Minimal widths will also be used by tables.) ... */
Maybe it is time to 'implement this correctly'. I am not that bothered by the blinking scrollbar, but if there is consencus that this should be fixed I guess it should be fixed... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Indan Zupancic wrote:
Hi,
Things I noticed:
Frames with zero border aren't supported.
Known problem, Dw (actually it is GtkDwScrolledFrame) is not able to draw borderless frames (this was in the README for many releases, but I got tired of repeating it so dropped it after README-11). As I did not want to hack to much around the widget (Sebastian's domain) I did not change this. Yet.
When there is a scrollbar in a frame it has a fat border to the left, making it a little bit ugly, even wider than it already is, and making it look more a part of the right frame because there is no such border at that side (see www.xenon.nl for what I mean, or any other site with similar frames).
Also a widget issue, but it is definitely more visible (and annoying) in framed document.
Reload doesn't reload all the frames. Known issue, but still annoying. :)
Thus far I have not made any special-case exceptions for framed documents wrt. history etc. As there seem to be many requests for this, I think I can not get around this... Should not be hard (just have reload etc. work on document subtrees instead of single documents) but has not been done yet.
Other issues:
When resizing a vertical frame, a horizontal scrollbar is rendered in a blinking way, even when it's not needed. This seems to appear only if a scrollbar will be rendered when the frame doesn't fit, so when you'll never see one it won't blink while resizing either. I guess this is the case with horizontal frames too, but didn't find one to test it with (example url: http://members.ams.chello.nl/wasscher/weer/). Should be easy to fix, I guess initializing the size to 0xffffffff or something instead of 0 at the right place could fix it, if it isn't a GTK issue.
Which it might just be... or not. I've played around with some configurations way back when I started this patch, but have not given it any attention afterwards. I'll see if I can find something to make it look less blinky (maybe hide scrollbars when resizing?).
Also the history seems very broken/buggy with framed webpages. Only thing that worked for me on one page was forward/backward for the main frame, and for most other sites there doesn't seem to be any history for frames at all, even right-clicking gives no forward/backward options (know issue I assume).
The latest patch (version 16) has navigation menus for all frames, in the 'This Frame...' submenu. These work fine AFAIK, if they don't please tell me what breaks where and I'll have a look at it. Individual document history (where 'document' signifies a single display frame/window) should work fine as it is now; adding cascaded reload and possibly some history update for frmae navigation should do the trick I guess?
Another one: Could you please edit your version of capi.c slightly, so that I don't have to make a seperate version of my patch? Just an extra #ifndef HTTPS / #endif somewhere, so it won't affect your code at all.
I'll add it to the next version. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Indan Zupancic wrote:
Random site that doesn't work (thanks google): http://www.public.iastate.edu/~stvoh/homepage.html
"works" with the normal Dillo, but renders nothing with the frames patch (non-standard frames?).
<HTML> <HEAD> <TITLE> <FRAMESET ROWS="... etc. Missing title close tag (</TITLE>). In general Dillo does not try its best to render bad HTML, but missing tag problems are so common that I think this should be fixed. I'll have a look at it when I find some time... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
participants (3)
-
Frank de Lange -
Indan Zupancic -
Melvin Hadasht