- Dillo-dev - lists.mailman3.com

Re: patch: Accept-Charset: utf-8,*;q=0.8

by corvid＠lavabit.com

Jorge wrote: > Committed, assuming: > > "Accept-Charset: utf-8,*;q=0.8\r\n" > > means dillo2 leaves the door open to also receive iso-8859-1. Yes. Here's what the RFC says: The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly mentioned.

April 26, 2008

patch: Re: [Dillo-dev] start on image maps (dw-part)

by jcid＠dillo.org

On Tue, Apr 22, 2008 at 04:50:32AM +0000, corvid wrote: > dw: I added motionNotifyImpl() and currLink > > dillo: > - I imagine the setUseMap() in open_img() is probably supposed to be > routed through DilloImage. > - Html_read_coords() was borrowed from 0.8.6 and modified a fair amount. > For one thing, the old code couldn't handle whitespace preceding a comma. > - I didn't really like that dReturn_if_fail so far down in open_area() > since coords is dynamically allocated now, but I left it there. Committed this patch and also scroll_motionNotify.dw2. Shape image-mapped links work so far. Coordinates are not yet being sent. If I missed something, please repost the patch. (I assume this is a work in progress). -- Cheers Jorge.-

April 26, 2008

Re: patch: Accept-Charset: utf-8,*;q=0.8

by jcid＠dillo.org

On Thu, Apr 17, 2008 at 04:57:48PM +0000, corvid wrote: > It is good for dillo to state its preference for UTF-8 > over ISO-8859-1. > > Also, the RFC says that not mentioning '*' puts dillo > in theoretical danger of receiving 406 Not Acceptable. > Committed, assuming: "Accept-Charset: utf-8,*;q=0.8\r\n" means dillo2 leaves the door open to also receive iso-8859-1. -- Cheers Jorge.- > --- dillo2/src/IO/http.c 2008-04-11 19:48:51.000000000 +0000 > +++ dillo2-cur/src/IO/http.c 2008-04-17 16:17:17.000000000 +0000 > @@ -236,7 +236,7 @@ Dstr *a_Http_make_query_str(const DilloU > query, > "POST %s HTTP/1.1\r\n" > "Connection: close\r\n" > - "Accept-Charset: utf-8, iso-8859-1\r\n" > + "Accept-Charset: utf-8,*;q=0.8\r\n" > "Accept-Encoding: gzip\r\n" > "Host: %s%s\r\n" > "%s" > @@ -258,7 +258,7 @@ Dstr *a_Http_make_query_str(const DilloU > "GET %s HTTP/1.1\r\n" > "%s" > "Connection: close\r\n" > - "Accept-Charset: utf-8, iso-8859-1\r\n" > + "Accept-Charset: utf-8,*;q=0.8\r\n" > "Accept-Encoding: gzip\r\n" > "Host: %s%s\r\n" > "%s"

April 26, 2008

patch: image loading on demand for complex button

by jcid＠dillo.org

Hi, Committed. I also changed Html_add_new_linkimage() to take a DilloUrl** parameter, to show it keeps the url. -- Cheers Jorge.-

April 26, 2008

Docs question: dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE

by onepoint＠starurchin.org

On Sat, Apr 26, 2008 at 10:31:51AM +0200, Johannes Hofmann wrote: > On Sat, Apr 26, 2008 at 09:27:01AM +0100, Jeremy Henty wrote: > > > > The description of > > dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE > > does not make sense. Should "The user may not the only selected > > item." read "The user may unselect the only selected item."? > > I guess so. Maybe the comment was copied from > SELECTION_EXACTLY_ONE_BY_USER and "unselect" was deleted instead of > "not"? That's my guess too. If someone comfirms this I'll make a patch. Regards, Jeremy Henty

April 26, 2008

Docs question: dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE

by Johannes.Hofmann＠gmx.de

On Sat, Apr 26, 2008 at 09:27:01AM +0100, Jeremy Henty wrote: > > The description of > dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE does > not make sense. Should "The user may not the only selected item." > read "The user may unselect the only selected item."? I guess so. Maybe the comment was copied from SELECTION_EXACTLY_ONE_BY_USER and "unselect" was deleted instead of "not"? Regards, Johannes

April 26, 2008

Docs question: dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE

by onepoint＠starurchin.org

The description of dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE does not make sense. Should "The user may not the only selected item." read "The user may unselect the only selected item."? Regards, Jeremy Henty

April 26, 2008

dillo-fltk on x86_64

by jcid＠dillo.org

On Fri, Apr 25, 2008 at 04:38:09PM +0200, Johannes Hofmann wrote: > On Fri, Apr 25, 2008 at 10:54:26AM +0200, Justus Winter wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Johannes Hofmann wrote: > > > object.cc:118: error: cast from ?void*? to ?int? loses precision > > > > > > I felt it was nonsense to check the size of void* at runtime and used > > > the preprocessor to choose which instruction to use based on the value > > > of SIZEOF_VOID_P. > > > > > >> I think the idea is that the compiler will optimize out unnecessary > > >> branches. And indeed the assembly code looks like this here: > > > > Ah, I see. But surely I can't be the only one having problems with this > > code? > > > > $ gcc -v > > Using built-in specs. > > Target: x86_64-linux-gnu > > Configured with: ../src/configure -v > > - --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > > - --enable-shared --with-system-zlib --libexecdir=/usr/lib > > - --without-included-gettext --enable-threads=posix --enable-nls > > - --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 > > - --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > > - --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu > > - --host=x86_64-linux-gnu --target=x86_64-linux-gnu > > Thread model: posix > > gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) > > $ uname -a > > Linux thinkbox 2.6.24-15-generic #1 SMP Mon Apr 7 16:37:53 UTC 2008 > > x86_64 GNU/Linux > > > > And I would guess my compiler bails out at parsing the code and building > > an syntax tree way before it has a chance to optimize out any branches. > > Maybe your compiler is more permissive, either because it's a different > > version or you're on a different architecture where sizeof(int) == > > sizeof(void*) so there isn't any "loss of precision"? > > You seem to be the first one to try to compile dillo2 with 64bit. > So yes, we need to fix that compilation problem. It's just that > currently there is hardly any conditional compilation in dw-testbed > and it would be nice to keep it that way. > Do you think you can fix the problem without any preprocessor > conditionals? Perhaps with some sort of cast as in the callback case. Yes, that's right. Doesn't dlib's VOIDP2INT() work in this case? -- Cheers Jorge.- PS: Sorry for the lack of presence lately. I've been fully busy.

April 25, 2008

dillo-fltk on x86_64

by Johannes.Hofmann＠gmx.de

On Fri, Apr 25, 2008 at 08:13:45PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It's hard to get anything past you guys... revised patches are attached. > > By the way, if you still think there's something wrong with them, please > adjust them accordingly (like checking the return value of snprintf, > reducing the size of buf (a 64 byte long char buffer should be enough > for the hexadecimal representation of 244 bit wide pointers plus '0x' > and the final 0, right? :) ). > > Cheers, > Justus > - -- > gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIEh9ZoPmwNWhsaZYRAj50AJ9QWcxALBx1fuLIqEBAbNKsGn5PogCbBRRV > QjvTVKQJnI1yzOamX2KwOy8= > =TVic > -----END PGP SIGNATURE----- > diff -pru dillo2/src/dialog.cc dillo2-cur/src/dialog.cc > --- dillo2/src/dialog.cc 2008-04-11 14:51:24.000000000 +0200 > +++ dillo2-cur/src/dialog.cc 2008-04-24 00:19:39.000000000 +0200 > @@ -11,6 +11,7 @@ > > // UI dialogs > > +#include <inttypes.h> > #include <math.h> // for rint() > > #include <fltk/events.h> // for the unfortunate (temporary?) event key testing > @@ -246,7 +247,7 @@ static int choice5_answer; > > void choice5_cb(Widget *button, void *number) > { > - choice5_answer = (int)number; > + choice5_answer = (intptr_t)number; > _MSG("choice5_cb: %d\n", choice5_answer); > button->window()->make_exec_return(true); > } > diff -pru dw2/lout/object.cc dw2-cur/lout/object.cc > --- dw2/lout/object.cc 2007-10-26 14:17:43.000000000 +0200 > +++ dw2-cur/lout/object.cc 2008-04-25 19:01:34.000000000 +0200 > @@ -22,6 +22,7 @@ > > #include "object.hh" > #include <stdio.h> > +#include <inttypes.h> > > namespace object { > > @@ -114,28 +115,13 @@ bool Pointer::equals(Object *other) > > int Pointer::hashValue() > { > - if(sizeof (int) == sizeof (void*)) > - return (int)value; > - else if (2 * sizeof (int) == sizeof (void*)) > - return ((int*)value)[0] ^ ((int*)value)[1]; > - else { > - // unhandled case > - misc::assertNotReached (); > - return 0; > - } > + return (intptr_t)value; > } The xor-stuff in the 64bit case ensures a equal distribution of hash values. I'm not sure a simple cast to int is enough on all systems (well, it probabely is..). intptr_t v = (intptr_t) value; return (int) v ^ (v >> (sizeof int * 8)); for the 64bit case would be a more conservative fix - if it compiles :-) > > void Pointer::intoStringBuffer(misc::StringBuffer *sb) > { > char buf[64]; > - if(sizeof (int) == sizeof (void*)) > - sprintf(buf, "0x%x", (int)value); > - else if (sizeof (long) == sizeof (void*)) > - sprintf(buf, "0x%lx", (long)value); > - else { > - // unhandled case > - misc::assertNotReached (); > - } > + snprintf(buf, sizeof(buf), "0x%p", value); > sb->append(buf); > } Nice simplification! Johannes

April 25, 2008

dillo-fltk on x86_64

by joerg.sonnenberger＠web.de

On Fri, Apr 25, 2008 at 08:13:45PM +0200, Justus Winter wrote: > By the way, if you still think there's something wrong with them, please > adjust them accordingly (like checking the return value of snprintf, > reducing the size of buf (a 64 byte long char buffer should be enough > for the hexadecimal representation of 244 bit wide pointers plus '0x' > and the final 0, right? :) ). I am just a bystander myself :-) "%p" really is enough (includes 0x). snprintf because it doesn't match static scans for potentially unsafe functions. Joerg

April 25, 2008