January 2008 - Dillo-dev - lists.mailman3.com

Various minor patches

by Johannes.Hofmann＠gmx.de

On Tue, Jan 15, 2008 at 12:34:12AM +0100, Thomas-Martin Seck wrote: > * Jorge Arellano Cid (jcid(a)dillo.org) > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > I'd like to know in what sense it looks "promising" to you. > > It can deal with UTF8 now :) But wait, I just noticed that > the window title is not decoded correctly if it contains special > characters, cf <http://www.heise.de/newsticker/meldung/101768> (notice > the "?" in "B?rse"). This is a known problem that only happens with window managers that use the WM_ICON_NAME instead of the _NET_WM_ICON_NAME property. I think this is a fltk bug (try the editor from the fltk/test directory and "save as" with a filename that contains special chars). I had sent a mail to the fltk list, but there seemed to be no consensus about my proposed fix. Johannes > > No seriously, I like to have a fast, graphical, no-frills browser that > allows me to read "non-active" UTF8 content since more and more content > generation systems use it instead of plain ISO8859-1. What I like to see > is frames support and CSS and if this is in the works I will happily > waiting for it to mature -- and I am sure it will, now that a small > but determined community seems to be (re-)forming. > > What I do not really crave for is scripting or support for active > content like Flash or Jave; if all else fails, I can use Opera or FF for > "demanding" sites. > > Unfortunately, I cannot help much with developing the core browser but > offer to maintain the FreeBSD "port" of dillo2 once you consider to > release it and try help with FreeBSD specific build or packaging issues. > Well, as long as it does not break things for others, of course :) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 15, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Jorge Arellano Cid (jcid(a)dillo.org) > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > I'd like to know in what sense it looks "promising" to you. It can deal with UTF8 now :) But wait, I just noticed that the window title is not decoded correctly if it contains special characters, cf <http://www.heise.de/newsticker/meldung/101768> (notice the "?" in "B?rse"). No seriously, I like to have a fast, graphical, no-frills browser that allows me to read "non-active" UTF8 content since more and more content generation systems use it instead of plain ISO8859-1. What I like to see is frames support and CSS and if this is in the works I will happily waiting for it to mature -- and I am sure it will, now that a small but determined community seems to be (re-)forming. What I do not really crave for is scripting or support for active content like Flash or Jave; if all else fails, I can use Opera or FF for "demanding" sites. Unfortunately, I cannot help much with developing the core browser but offer to maintain the FreeBSD "port" of dillo2 once you consider to release it and try help with FreeBSD specific build or packaging issues. Well, as long as it does not break things for others, of course :)

Jan. 15, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Jorge Arellano Cid (jcid(a)dillo.org) > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > 1) detect_libiconv.diff > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > is not in the default linker path, making the build abort. Add > > a simple test to configure.in to check for libiconv's presence > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > OK with the idea but the patch "as is" breaks it for Linux. Please > send a new one. Sorry, I had hoped that the autotools could deal with this somehow and since I only use FreeBSD I could only get to the "works for me" state. What does break on Linux? The intent is to check for libiconv.h in the default include path and for iconv_open in libiconv, assuming that libiconv can be located without adding -L/path/to/libiconv to LDFLAGS explicitly.

Jan. 15, 2008

Various minor patches

by jcid＠dillo.org

Hi, On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > All, > > I am very glad to see that dillo-fltk has now gained some momentum. We too! ;) > While looking at it on FreeBSD (6.2) I came across some minor problems, > patches for which are attached: > > 1) detect_libiconv.diff > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > is not in the default linker path, making the build abort. Add > a simple test to configure.in to check for libiconv's presence > and usability and a substitution for ICONV_LIBS to src/Makefile.am. OK with the idea but the patch "as is" breaks it for Linux. Please send a new one. > > 2) src-colors.h.diff > > I needed to include <stdint.h> or <inttypes.h> in order to have > int32_t properly defined. I decided to wrap this include in a > hopefully portable and correct way by instrumenting config.h. Committed. > 3) src-dns.c.diff > > On current FreeBSD releases, netdb.h does no longer define > EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out > since Oct 2003. It therefore cannot be checked for on a current > FreeBSD release, so test whether we are either compiling on something > other that FreeBSD or if it's a 4.x or older FreeBSD release. Other > BSDs might have similar issues in this regard. Committed, with Johannes' suggestion. > Otherwise dillo-fltk looks really promising -- keep up the good work! I'd like to know in what sense it looks "promising" to you. -- Cheers Jorge.-

Jan. 14, 2008

patch: progressive images

by place＠gobigwest.com

(the ones that start out blurry and grow sharper) - Added code for progressive display of, well, progressive jpegs because I was tired of waiting for full download before display. jpeglib uses the word "scan" for each loop through the scanlines of the image, so I did the same. I'm not sure it's a terribly descriptive term, though, at least to me (not a graphics person). Couldn't think of a better word. - Turned out scaled ones didn't work. (And, incidentally, that was frustrating because it took some time to realize that the breaking ones were scaled ever so slightly.) Added some bit clearing to imgbuf code on the dw side so that scaled buffers would continue to copy from root buffers. - Turned out that if there was more than one copy on a page, only the first copy worked. (dillo uses image decoders on the first one and pulls the scanlines out of Dicache for the rest.) More bit clearing and a scan number to help a_Dicache_callback with its copying. - Discovered that interlaced pngs use progressive display, and that they hadn't been working for scaled or for multiple on a page. - Considered looking into animated gifs, but then my good sense prevailed :)

Jan. 14, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Johannes Hofmann (Johannes.Hofmann(a)gmx.de) > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > 3) src-dns.c.diff > > > > On current FreeBSD releases, netdb.h does no longer define > > EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out > > since Oct 2003. It therefore cannot be checked for on a current > > FreeBSD release, so test whether we are either compiling on something > > other that FreeBSD or if it's a 4.x or older FreeBSD release. Other > > BSDs might have similar issues in this regard. > > EAI_NODATA still exists on DragonFly. But if it's obsolete we should > generally avoid to use it. Or to be on the safe side do something > like: > > #ifdef EAI_NODATA > ... > #endif Frankly, I do not know why certain constants were obsoleted over the years (in FreeBSD) -- it might be because some RFC/draft says so or ISC/Nominum decided to do so in their implementation which FreeBSD seems to track rather closely. DragonFly probably never felt the need to update this after importing the 4.something userland back in the day? One could make EAI_NODATA equal EAI_NONAME in this case, this is the way it was done in FreeBSD for a few months until 01/2004: <http://www.freebsd.org/cgi/cvsweb.cgi/src/include/netdb.h?rev=1.30;content-…>. This is probably a better approach than the hard coded OS #ifdef I came up with first if one wants to catch this case at all.

Jan. 13, 2008

Various minor patches

by Johannes.Hofmann＠gmx.de

Hello, On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > All, > > I am very glad to see that dillo-fltk has now gained some momentum. > > While looking at it on FreeBSD (6.2) I came across some minor problems, > patches for which are attached: > > 1) detect_libiconv.diff > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > is not in the default linker path, making the build abort. Add > a simple test to configure.in to check for libiconv's presence > and usability and a substitution for ICONV_LIBS to src/Makefile.am. Very nice! The same problem exists on DragonFly... > > 2) src-colors.h.diff > > I needed to include <stdint.h> or <inttypes.h> in order to have > int32_t properly defined. I decided to wrap this include in a > hopefully portable and correct way by instrumenting config.h. > > 3) src-dns.c.diff > > On current FreeBSD releases, netdb.h does no longer define > EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out > since Oct 2003. It therefore cannot be checked for on a current > FreeBSD release, so test whether we are either compiling on something > other that FreeBSD or if it's a 4.x or older FreeBSD release. Other > BSDs might have similar issues in this regard. EAI_NODATA still exists on DragonFly. But if it's obsolete we should generally avoid to use it. Or to be on the safe side do something like: #ifdef EAI_NODATA ... #endif Regards, Johannes > > Otherwise dillo-fltk looks really promising -- keep up the good work! > > Best regards, > -- > Thomas-Martin Seck > current dillo and FLTK port maintainer on FreeBSD Content-Description: detect_libiconv.diff > --- dillo2/configure.in Fri Oct 19 17:39:27 2007 > +++ dillo2-cur/configure.in Sun Jan 13 15:46:18 2008 > @@ -300,6 +300,18 @@ > AC_DEFINE([ENABLE_SSL], [], [Enable SSL support]) > fi > > +dnl ---------------------- > +dnl Test for libiconv > +dnl ---------------------- > +AC_CHECK_HEADER(iconv.h, iconv_ok=yes, iconv_ok=no) > +if test "x$iconv_ok" = "xyes"; then > + AC_CHECK_LIB(iconv, iconv_open, iconv_ok=yes, iconv_ok=no) > +fi > +if test "x$iconv_ok" = "xyes"; then > + LIBICONV_LIBS="-liconv" > +else > + AC_ERROR(libiconv must be installed!) > +fi > > dnl ---------------------- > dnl Test for POSIX threads > @@ -465,6 +477,7 @@ > AC_SUBST(LIBFLTK_CXXFLAGS) > AC_SUBST(LIBFLTK_CFLAGS) > AC_SUBST(LIBFLTK_LIBS) > +AC_SUBST(LIBICONV_LIBS) > AC_SUBST(datadir) > AC_SUBST(src doc) > > --- dillo2/src/Makefile.am Tue Nov 13 14:56:43 2007 > +++ dillo2-cur/src/Makefile.am Sun Jan 13 15:04:17 2008 > @@ -14,7 +14,7 @@ > ../../dw-testbed/dw/libDw-fltk.a \ > ../../dw-testbed/dw/libDw-core.a \ > ../../dw-testbed/lout/liblout.a \ > - @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ > + @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ @LIBICONV_LIBS@ > > dillo_fltk_SOURCES = \ > dillo.cc \ Content-Description: src-colors.h.diff > --- dillo2/src/colors.h Sun Oct 7 00:36:34 2007 > +++ dillo2-cur/src/colors.h Sun Jan 13 15:49:28 2008 > @@ -1,6 +1,15 @@ > #ifndef __COLORS_H__ > #define __COLORS_H__ > > +#include "config.h" > +#ifdef HAVE_INTTYPES_H > +#include <inttypes.h> > +#else > +#ifdef HAVE_STDINT_H > +#include <stdint.h> > +#endif > +#endif > + > #ifdef __cplusplus > extern "C" { > #endif /* __cplusplus */ Content-Description: src-dns.c.diff > --- dillo2/src/dns.c Mon Nov 5 21:25:16 2007 > +++ dillo2-cur/src/dns.c Sun Jan 13 16:48:07 2008 > @@ -289,8 +289,12 @@ static void *Dns_server(void *data) > MSG("DNS error: HOST_NOT_FOUND\n"); > else if (error == EAI_AGAIN) > MSG("DNS error: TRY_AGAIN\n"); > + /* The EAI_NODATA definition is marked as obsoleted in FreeBSD's netdb.h > + * and is #if 0'ed in releases starting with 5.2: */ > +#if !defined __FreeBSD__ || __FreeBSD__ <= 4 > else if (error == EAI_NODATA) > MSG("DNS error: NO_ADDRESS\n"); > +#endif > else if (h_errno == EAI_FAIL) > MSG("DNS error: NO_RECOVERY\n"); > } else { > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 13, 2008

Various minor patches

by tmseck-lists＠netcologne.de

All, I am very glad to see that dillo-fltk has now gained some momentum. While looking at it on FreeBSD (6.2) I came across some minor problems, patches for which are attached: 1) detect_libiconv.diff src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am. 2) src-colors.h.diff I needed to include <stdint.h> or <inttypes.h> in order to have int32_t properly defined. I decided to wrap this include in a hopefully portable and correct way by instrumenting config.h. 3) src-dns.c.diff On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard. Otherwise dillo-fltk looks really promising -- keep up the good work! Best regards, -- Thomas-Martin Seck current dillo and FLTK port maintainer on FreeBSD

Jan. 13, 2008

patch: the http header Content-Type half of charset conversion

by place＠gobigwest.com

Jorge wrote: > How did you make the search? I managed to get a few windows-125[2-3] > but nothing else. URLs, or a dummies guide to searching is appreciated. ;) I wonder whether "???????" came through. I was careful to send the msg as UTF-8, but I neglected to check the copy that came back via the list to see whether anything munged it up along the way. The third hit on the first page via google gives me a koi8-r page for a charset patch to 0.6.6. http://www.google.com/search?q=dillo+%D0%B1%D1%80%D0%B0%D1%83%D0%B7%D0%B5%D… I just stumbled upon the fact that google itself is a decent source. www.google.cn is GB2312 (google, working to crush dissent and make information disappear. Big money is the only morality, after all.) www.google.gr is ISO-8859-7, www.google.lt is windows-1257 Took me a while this time to find any Hebrew. pc.co.il is windows-1255. Displayed left-to-right, but it's a start. > Actually, to me, it looks like the cache is a good place to make the > conversion (instead of html). That way text, html and view source would > work in a similar way: I think you're right. When I started it, I had the idea that cache was going to be "pure" and not know about what it was sending to clients, but, yeah, it does need to know. > Maybe the most important part now is to try to get HTML's meta charset > working, and only after that to choose where to place the code. Putting aside my earlier concerns about javascript since it's not like javascript support is imminent, let's see... http says it's charset A. cache.c translates A->utf8. meta says it's charset B. html.cc translates utf8->A followed by B->utf8, except that won't work because the utf8 that html.cc received is probably full of UFFFD characters and things. badly-written pages displaying text and making buttons and tooltips and so on by the time the meta tag is reached.

Jan. 13, 2008

Report on fltk-2.0.x-r5990

by jcid＠dillo.org

On Wed, Jan 09, 2008 at 08:15:40AM +0000, Jeremy Henty wrote: > > I have been running Dillo on top of the latest daily snapshot > (fltk-2.0.x-r5990) and seen no problems. Has anyone else tried this? > Maybe we should update the recommended FLTK snapshot? > > NB: fltk-2.0.x-r5990 is not binary compatible with the current > recommended snapshot, so if you upgrade you have to rebuild Dillo (and > any other FLTK2 applications) or you will get memory corruption. Yes, diff -pru fltk-2.0.x-r5975 fltk-2.0.x-r5990 |grep -v ^Only|less shows only a few lines changed. Unless I overlooked another change it looks safe to upgrade. -- Cheers Jorge.-

Jan. 13, 2008