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

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

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(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 26, 2003

Re: [Dillo-dev] patched dillo via Arch

by Frank de Lange

Paul Pelzl wrote: >I wouldn't mind setting up a patches list, but only if there is demand >for it. Is patch discussion creating too much traffic on the wearlab >mailing list? If not, then it seems like keeping patch discussion on >the list would give the patches more exposure. > >Anyone else have an opinion? > >Paul > > > I think that patch traffic belongs on this list, as it is quite often relevant for all of Dillo (patched or unpatched). It also keeps the patches in sight for users/developers of unpatched Dillo, which should generate exposure. If/when the patches really take on a life of theirselves it is time to move, but that time has not arrived as far as I'm concerned. Good initiative btw, the Archive. 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." ]

Nov. 26, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

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(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 25, 2003

patched dillo via Arch

by Paul Pelzl

If anyone on the list is using GNU Arch, you can obtain: Dillo CVS + Frank's tab/frame/kbnav/etc. patch v16 + Indan's HTTPS patch v2 + my toggle-force-my-colors patch integrated into branch dillo--tabframe-pelzl--16.0 . The archive is: pelzlpj(a)eecs.umich.edu--2003 ftp://pelzlpj.dyndns.org/pub/paul/tla/2003 If you find this useful, please send me a private email. If no one cares, I won't bother to announce this archive in the future. Paul

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Indan Zupancic

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

Nov. 25, 2003

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter

by Andreas Schweitzer

Hi > > I suppose you're getting tired of hearing about my ancient Redhat > > system, but my gcc doesn't believe in -Wno-unused-parameters, preferning Same on FreeBSD which also still uses 2.95. I think there are lots of systems that still use gcc2.95 > If you add a simple way to test whether gcc accepts the warning > option, in configure.in, it'd be ok. Attached is a patch wich does just that. However, it assumes that the -Wno-unused-parameters appeared with version 3 of gcc. A quick google search seems to confirm that this option was introduced with gcc 3.0 - can anybody with gcc 3.0 confirm that ? The patch also fixes some problems with detection of /usr/local in the default path. This patch works on a FreeBSD 4.8 system (gcc 2.95) and a Suse 8.2 system (gcc3.2). Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Indan Zupancic

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

Nov. 25, 2003

kbnav bugs anyone?

by Frank de Lange

Hi'all, I just noticed that kbnav does not do the right thing when tabbing out of a mouse-selected form field. Instead of going to the next field, it starts at the first form field/button on the page. I'll resolve this for the next patch. If anyone has any other problems with kbnav (or tabs or frames, but that is another patch...) let me know. I'd like to resolve problems in the current feature set before adding anything new... 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." ]

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

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(a)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,

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

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(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 25, 2003