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

[patch] phrase search

by jcid＠dillo.org

Hi, Committed. On Tue, Apr 22, 2008 at 06:12:55PM +0200, Johannes Hofmann wrote: > Hi, > > attached is a patch that make phrase search work. I'm not 100% sure > about the CharIterator::prev() change. CharIterator::next() returned > \0 between words, prev() didn't. So something was wrong. > I decided to go with current next() behaviour and made prev() return > \0 as word separator too. It looks reasonable. BTW, while working on fixing the parsing of " " (a not yet committed work), I found that it's not clear how non-breaking whitespace is handled/represented. Currently we have a parser/dw mix that tries to render it "right" for HTML. The idea is to decide how to render inside the HTML parser and to use dw for that. Now there's some HTML logic built in dw, which would be good not to have (an idea we talked with Sebastian long ago). For instance dillo1 handles NBSP better in some cases and worse in others than dillo2. I think it'll have to wait until I find some time to dig into it... > Also the current implementation only works if one enters exactly one > blank between words in the search dialog. Should we collapse multiple > blanks into one automatically? As a workaround, I don't see why not. BTW, the phrase search doesn't work with text wrapped by the PRE element. This probably is related to a whole sentence/line stored as a single dw word. -- Cheers Jorge.-

April 26, 2008

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