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

Quick question about font_factor in dillorc2

by jcid＠dillo.org

On Mon, Nov 05, 2007 at 12:44:30PM +0000, Jeremy Henty wrote: > On Mon, Nov 05, 2007 at 09:28:25AM -0300, Jorge Arellano Cid wrote: > > On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > > > > Just out of interest, is there any reason why the default dillorc2 > > > sets font_factor to 1.5? > > > > Yes. It slipped out of my dillorc (I'm using a high resolution > > laptop). > > Ah, I wondered if that was it! > > > I think 1.2 is better, but hope the current 1.0 to bring comments! > > I think 1.0 is fine (1280 x 1024 desktop on a 17 inch monitor). It's > a little small, and I might increase font_factor if I started getting > eyestrain or the monitor was poorer quality. On a 1440x900 14 inch LCD, 1.5 is fine for me. It looks like 1.2 is a good default. -- Cheers Jorge.-

Nov. 5, 2007

Re: patch: hiding widgets

by jcid＠dillo.org

On Sun, Nov 04, 2007 at 01:03:51AM +0000, place wrote: > I made this customize() pretty much a copy of the 0.8.x customize(). Commited. > In testing, I saw that playing with the panel_cb a lot makes things crashy > (that is, equally crashy with and without this code). Is that general area > of the UI permanent enough for there to be any point in taking notice of it? The idea was to test on-the-fly resizing. Hoping for FLTK2-savvy guys to come later with some advice on how its done. -- Cheers Jorge.-

Nov. 5, 2007

Quick question about font_factor in dillorc2

by onepoint＠starurchin.org

On Mon, Nov 05, 2007 at 09:28:25AM -0300, Jorge Arellano Cid wrote: > On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > > Just out of interest, is there any reason why the default dillorc2 > > sets font_factor to 1.5? > > Yes. It slipped out of my dillorc (I'm using a high resolution > laptop). Ah, I wondered if that was it! > I think 1.2 is better, but hope the current 1.0 to bring comments! I think 1.0 is fine (1280 x 1024 desktop on a 17 inch monitor). It's a little small, and I might increase font_factor if I started getting eyestrain or the monitor was poorer quality. Regards, Jeremy Henty

Nov. 5, 2007

Quick question about font_factor in dillorc2

by jcid＠dillo.org

On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > Just out of interest, is there any reason why the default dillorc2 > sets font_factor to 1.5? Yes. It slipped out of my dillorc (I'm using a high resolution laptop). :-) > It seems unreasonably large to me, and I > personally much prefer to comment it out. Anyone else have feelings > one way or the other? Now it's set to 1.0. I think 1.2 is better, but hope the current 1.0 to bring comments! ;-) -- Cheers Jorge.-

Nov. 5, 2007

Crashes on OpenBSD

by Christian.Kellermann＠nefkom.net

* Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [071104 14:50]: > Hello, > > as I'm also using a BSD system, I converted the D_DNS_THREADED code > to use the inherently thread-safe getaddrinfo(3) interface that also has > some other advantages (e.g. a predictable ordering of the returned > addresses). Thanks, I will try this. Is you git repo public? Regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Nov. 4, 2007

Re: image loading from menus

by jcid＠dillo.org

Hi, On Sat, Nov 03, 2007 at 11:18:36PM +0000, place wrote: > Jorge wrote: > > After some study and a reimplentation of plain.cc with classes > > (getting rid of its linkblock and hooking a callback for memory > > handling), it looks simpler and better. It looks like the same > > may be done with html.cc. > > I was just wondering how you weigh the options of adding a callback > vs. adding a signal. I had experimented with a destroy signal in > my tree recently. It seemed more consistent to me, although I suspect > the various child widgets were wasting cycles on signal emission code > when they didn't have any receivers... I'd say that for me, the key is simplicity, and elegance. In a sense, accurately captured by this quote: "The key to performance is elegance, not batalions of special cases" -- Jon Bentley and Doug McIlroy In the case of Dillo, I've seen several times the simplicity pay off. When code gets simpler, debugging and improving accelerates. With complexity it stagnates. Elegance helps to keep the design simple and flexible. Having flexibilty in the design, helps to tackle unforeseen problems at the design level, without workarounds, reducing complexity and special cases. -- Cheers Jorge.-

Nov. 4, 2007

Crashes on OpenBSD

by Johannes.Hofmann＠gmx.de

Hello, as I'm also using a BSD system, I converted the D_DNS_THREADED code to use the inherently thread-safe getaddrinfo(3) interface that also has some other advantages (e.g. a predictable ordering of the returned addresses). Jorge, what do you think about this? Are there supported platforms that do not have getaddrinfo? Should we add a compile option for this? Johannes diff --git a/src/dns.c b/src/dns.c --- a/src/dns.c +++ b/src/dns.c @@ -239,58 +239,86 @@ static void Dns_note_hosts(Dlist *list, } } +static void Dns_note_hosts2(Dlist *list, struct addrinfo *res0) +{ + struct addrinfo *res; + DilloHost *dh; + + for (res = res0; res; res = res->ai_next) { + + if (res->ai_family == AF_INET) { + struct sockaddr_in *in_addr; + + if (res->ai_addrlen < sizeof(struct sockaddr_in)) { + continue; + } + + dh = dNew0(DilloHost, 1); + dh->af = AF_INET; + + in_addr = (struct sockaddr_in*) res->ai_addr; + dh->alen = sizeof (struct in_addr); + memcpy(&dh->data[0], &in_addr->sin_addr.s_addr, dh->alen); + + dList_append(list, dh); +#ifdef ENABLE_IPV6 + } else if (res->ai_family == AF_INET6) { + struct sockaddr_in6 *in6_addr; + + if (res->ai_addrlen < sizeof(struct sockaddr_in6)) { + continue; + } + + dh = dNew0(DilloHost, 1); + dh->af = AF_INET6; + + in6_addr = (struct sockaddr_in6*) res->ai_addr; + dh->alen = sizeof (struct in6_addr); + memcpy(&dh->data[0], &in6_addr->sin6_addr.s6_addr, dh->alen); + + dList_append(list, dh); +#endif + } + } +} + #ifdef D_DNS_THREADED /* * Server function (runs on its own thread) */ static void *Dns_server(void *data) { - struct hostent *host; int channel = VOIDP2INT(data); -#ifdef LIBC5 - int h_err; - char buff[1024]; - struct hostent sh; -#endif + struct addrinfo hints, *res0; + int error; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_INET; + hints.ai_socktype = SOCK_STREAM; + Dlist *hosts = dList_new(2); DEBUG_MSG(3, "Dns_server: starting...\n ch: %d host: %s\n", channel, dns_server[channel].hostname); -#ifdef ENABLE_IPV6 - if (ipv6_enabled) { - host = gethostbyname2(dns_server[channel].hostname, AF_INET6); - if (host) { - Dns_note_hosts(hosts, AF_INET6, host); - } - } -#endif - -#ifdef LIBC5 - host = gethostbyname_r(dns_server[channel].hostname, &sh, buff, - sizeof(buff), &h_err); -#else - host = gethostbyname(dns_server[channel].hostname); -#endif - - if (!host) { -#ifdef LIBC5 - dns_server[channel].status = h_err; -#else - dns_server[channel].status = h_errno; - if (h_errno == HOST_NOT_FOUND) + error = getaddrinfo(dns_server[channel].hostname, NULL, &hints, &res0); + + if (error != 0) { + dns_server[channel].status = error; + if (error == EAI_NONAME) MSG("DNS error: HOST_NOT_FOUND\n"); - else if (h_errno == TRY_AGAIN) + else if (error == EAI_AGAIN) MSG("DNS error: TRY_AGAIN\n"); - else if (h_errno == NO_RECOVERY) - MSG("DNS error: NO_RECOVERY\n"); - else if (h_errno == NO_ADDRESS) + else if (error == EAI_NODATA) MSG("DNS error: NO_ADDRESS\n"); -#endif - } else { + else if (h_errno == EAI_FAIL) + MSG("DNS error: NO_RECOVERY\n"); + } else { + Dns_note_hosts2(hosts, res0); dns_server[channel].status = 0; - Dns_note_hosts(hosts, AF_INET, host); - } + freeaddrinfo(res0); + } + if (dList_length(hosts) > 0) { dns_server[channel].status = 0; } else { diff --git a/src/dns.h b/src/dns.h --- a/src/dns.h +++ b/src/dns.h @@ -1,5 +1,7 @@ #ifndef __DNS_H__ #define __DNS_H__ + +#include <netinet/in.h> #include "chain.h" @@ -14,7 +16,7 @@ void a_Dns_freeall(void); void a_Dns_freeall(void); void a_Dns_resolve(const char *hostname, DnsCallback_t cb_func, void *cb_data); -#define DILLO_ADDR_MAX 16 +#define DILLO_ADDR_MAX sizeof(struct in6_addr) typedef struct _DilloHost {

Nov. 4, 2007

PATCH: adds the ' entity

by onepoint＠starurchin.org

Is it dillo's policy to include *only* HTML 4.01 entities. If not, here's a patch to add the ' entity, which appears all over the place despite not being official HTML 4.01. Regards, Jeremy Henty Only in dillo2: CVS Only in dillo2-cur: Makefile Only in dillo2-cur: Makefile.in Only in dillo2-cur: aclocal.m4 Only in dillo2-cur: autom4te.cache Only in dillo2-cur: config.guess Only in dillo2-cur: config.h Only in dillo2-cur: config.log Only in dillo2-cur: config.status Only in dillo2-cur: config.sub Only in dillo2-cur: configure Only in dillo2-cur: d_size.h Only in dillo2-cur: depcomp Only in dillo2-cur/dlib: .deps Only in dillo2/dlib: CVS Only in dillo2-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/dlib: dlib.o Only in dillo2-cur/dlib: libDlib.a Only in dillo2/doc: CVS Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2/dpi: CVS Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpi: bookmarks.dpi Only in dillo2-cur/dpi: bookmarks.o Only in dillo2-cur/dpi: cookies.dpi Only in dillo2-cur/dpi: cookies.o Only in dillo2-cur/dpi: datauri.filter.dpi Only in dillo2-cur/dpi: datauri.o Only in dillo2-cur/dpi: downloads.dpi Only in dillo2-cur/dpi: downloads.o Only in dillo2-cur/dpi: dpiutil.o Only in dillo2-cur/dpi: file.dpi Only in dillo2-cur/dpi: file.o Only in dillo2-cur/dpi: ftp.filter.dpi Only in dillo2-cur/dpi: ftp.o Only in dillo2-cur/dpi: hello.filter.dpi Only in dillo2-cur/dpi: hello.o Only in dillo2-cur/dpi: https.filter.dpi Only in dillo2-cur/dpi: https.o Only in dillo2-cur/dpid: .deps Only in dillo2/dpid: CVS Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpid: dpi.o Only in dillo2-cur/dpid: dpi_service.o Only in dillo2-cur/dpid: dpi_socket_dir.o Only in dillo2-cur/dpid: dpid Only in dillo2-cur/dpid: dpid.o Only in dillo2-cur/dpid: dpid_common.o Only in dillo2-cur/dpid: main.o Only in dillo2-cur/dpid: misc_new.o Only in dillo2-cur/dpip: .deps Only in dillo2/dpip: CVS Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/dpip: dpip.o Only in dillo2-cur/dpip: libDpip.a Only in dillo2-cur: install-sh Only in dillo2-cur: missing Only in dillo2-cur/src: .deps Only in dillo2/src: CVS Only in dillo2-cur/src/IO: .deps Only in dillo2/src/IO: CVS Only in dillo2-cur/src/IO: IO.o Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src/IO: about.o Only in dillo2-cur/src/IO: dpi.o Only in dillo2-cur/src/IO: http.o Only in dillo2-cur/src/IO: iowatch.o Only in dillo2-cur/src/IO: libDiof.a Only in dillo2-cur/src/IO: mime.o Only in dillo2-cur/src/IO: proto.o Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in Only in dillo2-cur/src: bitvec.o Only in dillo2-cur/src: bookmark.o Only in dillo2-cur/src: bw.o Only in dillo2-cur/src: cache.o Only in dillo2-cur/src: capi.o Only in dillo2-cur/src: chain.o Only in dillo2-cur/src: colors.o Only in dillo2-cur/src: cookies.o Only in dillo2-cur/src: dialog.o Only in dillo2-cur/src: dicache.o Only in dillo2-cur/src: dillo-fltk Only in dillo2-cur/src: dillo.o Only in dillo2-cur/src: dir.o Only in dillo2-cur/src: dns.o Only in dillo2-cur/src: dpiapi.o Only in dillo2-cur/src: form.o Only in dillo2-cur/src: gif.o Only in dillo2-cur/src: history.o diff -pru -- dillo2/src/html.cc dillo2-cur/src/html.cc --- dillo2/src/html.cc 2007-11-03 22:16:26.000000000 +0000 +++ dillo2-cur/src/html.cc 2007-11-04 08:44:02.000000000 +0000 @@ -814,7 +814,7 @@ typedef struct { int isocode; } Ent_t; -#define NumEnt 252 +#define NumEnt 253 static const Ent_t Entities[NumEnt] = { {"AElig",0306}, {"Aacute",0301}, {"Acirc",0302}, {"Agrave",0300}, {"Alpha",01621},{"Aring",0305}, {"Atilde",0303}, {"Auml",0304}, @@ -833,7 +833,9 @@ static const Ent_t Entities[NumEnt] = { {"Yacute",0335},{"Yuml",0570}, {"Zeta",01626}, {"aacute",0341}, {"acirc",0342}, {"acute",0264}, {"aelig",0346}, {"agrave",0340}, {"alefsym",020465},{"alpha",01661},{"amp",38}, {"and",021047}, - {"ang",021040}, {"aring",0345}, {"asymp",021110},{"atilde",0343}, + {"ang",021040}, + {"apos",39}, /* not in HTML 4.01 */ + {"aring",0345}, {"asymp",021110},{"atilde",0343}, {"auml",0344}, {"bdquo",020036},{"beta",01662}, {"brvbar",0246}, {"bull",020042},{"cap",021051}, {"ccedil",0347}, {"cedil",0270}, {"cent",0242}, {"chi",01707}, {"circ",01306}, {"clubs",023143}, Only in dillo2-cur/src: html.o Only in dillo2-cur/src: image.o Only in dillo2-cur/src: jpeg.o Only in dillo2-cur/src: klist.o Only in dillo2-cur/src: menu.o Only in dillo2-cur/src: misc.o Only in dillo2-cur/src: nav.o Only in dillo2-cur/src: plain.o Only in dillo2-cur/src: png.o Only in dillo2-cur/src: prefs.o Only in dillo2-cur/src: timeout.o Only in dillo2-cur/src: ui.o Only in dillo2-cur/src: uicmd.o Only in dillo2-cur/src: url.o Only in dillo2-cur/src: web.o Only in dillo2-cur: stamp-h1

Nov. 4, 2007

Quick question about font_factor in dillorc2

by onepoint＠starurchin.org

Just out of interest, is there any reason why the default dillorc2 sets font_factor to 1.5? It seems unreasonably large to me, and I personally much prefer to comment it out. Anyone else have feelings one way or the other? Regards, Jeremy Henty

Nov. 4, 2007

Re: image loading from menus

by place＠gobigwest.com

Jorge wrote: > After some study and a reimplentation of plain.cc with classes > (getting rid of its linkblock and hooking a callback for memory > handling), it looks simpler and better. It looks like the same > may be done with html.cc. I was just wondering how you weigh the options of adding a callback vs. adding a signal. I had experimented with a destroy signal in my tree recently. It seemed more consistent to me, although I suspect the various child widgets were wasting cycles on signal emission code when they didn't have any receivers...

Nov. 4, 2007