- Dillo-dev - lists.mailman3.com

dillo-fltk on x86_64

by jcid＠dillo.org

Hi Justus, > It's hard to get anything past you guys... revised patches are attached. :-) No, you just had bad luck. 64bit is a complex matter that looks simple. BTW, I'm quite happy that a few patches made dillo2 run on 64bit. On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey@all :) > > I ran into some issues compiling dillo. I solved / worked around them, > patches are attached. Here are my findings and my interpretations (let > me know in case I am way off somewhere): > > dw2 > === > gcc-4.2 on linux/x86_64 complained about two casts in lout/object.cc: > > 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. After reviewing the thread, and a head scratching phase, I committed the following code. please test it: +/* For some unknown reason, this doesn't compile on some 64bit platforms: + * + * if (sizeof (int) == sizeof (void*)) + * return (int)value; + * else + * return ((int*)value)[0] ^ ((int*)value)[1]; + */ +#if SIZEOF_VOID_P == 4 + return (int)value; +#else + return ((int*)value)[0] ^ ((int*)value)[1]; +#endif > dillo2 > ====== > There was another complaint by gcc: > > dialog.cc:249: error: cast from ???void*??? to ???int??? loses precision > > A parameter of type void* for a callback is used to carry a small > integer (most likely the number of the button pressed or something). I > solved this one by first casting to long and then to int. I saw this > somewhere on the net, don't know if this is too hacky. Committed as: + choice5_answer = VOIDP2INT(number); > dillo2/dpi > ========== > downloads.cc failed to compile since gcc couldn't find the fltk includes > (I chose not to install them to /usr/local/lib), so I poked around in > dpi/Makefile.am and managed to include LIBFLTK_CXXFLAGS into cxxflags > (/me is an automake n00b). Yeah, auto* is not simple. Does it work for you with a: +downloads_dpi_CXXFLAGS = @LIBFLTK_CXXFLAGS@ instead? (CVS has this tentative patch). > > With my three patches applied dillo compiles and runs fine, however I > had to create ~/.dillo and manually start dpid. Did I miss something here? No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! (as we all run dillo1 before, ~/.dillo was there :-) dpid didn't start because it most probably wasn't in your path. With regard to a missing SSL, yes, it'd be good not to try to compile https the. Patches are welcomed! :-) -- Cheers Jorge.-

April 26, 2008

[patch] phrase search

by Johannes.Hofmann＠gmx.de

On Sat, Apr 26, 2008 at 01:10:46PM -0400, Jorge Arellano Cid wrote: > 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. Ah yes. I totally forgot about PRE. In normal text spaces are encoded using the "space" flag in Content. In PRE there is a separate Content object for each space. I think I will revert my change to CharIterator and make prev() work as next() originally did (i.e. not return any '\0'). Instead CharIterator will generate a ' ' if the space flag is set in a Content object. This way CharIterator will always create a stream of chars (no '\0's) with words in normal text separated by blanks. Then phrase search should work for PRE sections too. And it should even be possible to search for something like three blanks in a row within PRE sections. Patch will follow... Cheers, Johannes

April 26, 2008

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

by corvid＠lavabit.com

Johannes wrote: > What about deleting coords earlier? I think they are no longer > needed once the shape has been constructed. attached.

April 26, 2008

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

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 10:46:26AM +0100, Jeremy Henty wrote: > 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. Committed! -- Cheers Jorge.-

April 26, 2008

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

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 04:56:45PM +0000, corvid wrote: > 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. OK. -- Cheers Jorge.-

April 26, 2008

patch: /* todo: don't create things if button type is unknown */

by jcid＠dillo.org

Hi, Committed. -- Cheers Jorge.-

April 26, 2008

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

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 05:26:58PM +0000, corvid wrote: > Jorge wrote: > > 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). > > What's not working exactly? We didn't do ISMAP yet, if that's what > you're saying... Yes, ISMAP. -- Cheers Jorge.-

April 26, 2008

Re: the last patch that I sent you BREAKS isindex.

by corvid＠lavabit.com

Jorge wrote: > On Thu, Apr 17, 2008 at 06:17:04AM +0000, corvid wrote: > > I shouldn't have moved isindex's connectActivate to close_form. > > If you wish, I can make a new version. > > Yes, please. I just wanted to let people on the list know that that patch wasn't sent to the list, so this isn't about anything that you might have applied to your tree. > > By the way, I found that the top of open_input needs > > if (html->InFlags & IN_SELECT) { > > MSG_HTML("INPUT inside SELECT\n"); > > return; > > } > > Otherwise, if another input sneaks in there, close_select will crash. > > Please include it in the patch. I'm planning to make a patch that contains a few IN_* tests that are needed here and there...

April 26, 2008

Re: the last patch that I sent you BREAKS isindex.

by jcid＠dillo.org

On Thu, Apr 17, 2008 at 06:17:04AM +0000, corvid wrote: > I shouldn't have moved isindex's connectActivate to close_form. > If you wish, I can make a new version. Yes, please. > > By the way, I found that the top of open_input needs > if (html->InFlags & IN_SELECT) { > MSG_HTML("INPUT inside SELECT\n"); > return; > } > Otherwise, if another input sneaks in there, close_select will crash. Please include it in the patch. -- Cheers Jorge.-

April 26, 2008

[patch] introduce lout namespace (was: namespace problem)

by jcid＠dillo.org

On Thu, Apr 24, 2008 at 09:18:30PM +0200, Johannes Hofmann wrote: > Hi, > > while trying to implement a fix to the namespace problem I came to > the conclusion that the easiest and least intrusive way is to keep > the existing namespaces in the lout directory and just wrap them in > another namespace "lout". > This fixes the name collision with signal. Committed. BTW, now the documentation should mention this "lout" namespace. ;-) -- Cheers Jorge.-

April 26, 2008