- Dillo-dev - lists.mailman3.com

Style sheet question (centering and list-style-type)
by furaisanjin＠gmail.com Nov. 5, 2009

Nov. 5, 2009

Hi all. I'm wondering how this web page will be rendered. <HTML> <HEAD> <style></style> <TITLE>test</TITLE> </HEAD> <BODY> <div id="menu"> <ul> <li><a href="http://xxx.xxx.xxx/1">first second</a> </ul> </div> </BODY> </HTML> Recent dillo splits "first" and "second" words above and the first one is aligned on the left. Regards, furaisanjin

2 2

Crashes at bizmakoto.jp
by furaisanjin＠gmail.com Nov. 4, 2009

Nov. 4, 2009

Hi. I don't try all pages but at least there are several pages where dillo keeps crashing. One example is http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace shows something like this. #0 0x28554687 in __vfprintf () from /lib/libc.so.6 #1 0x284e1fe0 in vsnprintf () from /lib/libc.so.6 #2 0x0807a16f in dStr_vsprintfa (ds=0x83cad40, format=0x80fd314 "unexpected closing tag: </%s> -- expected </%s>.\n", argp=0xbfbfe318 "$B!&(B216\017\b") at dlib.c:362 #3 0x08065f94 in DilloHtml::bugMessage (this=0x847f400, format=0x80fd314 "unexpected closing tag: </%s> -- expected </%s>.\n") at html.cc:144 #4 0x0806bed5 in Html_tag_cleanup_at_close (html=0x847f400, new_idx=8) at html.cc:1338 #5 0x0806ce4f in Html_write_raw (html=0x847f400, buf=0x861e000 "\n\n<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\n<html id=\"/bizid/articles/0911/02/news082.html\">\n<head>\n<meta http-equiv=\"Content-Type\" content"..., bufsize=59935, Eof=0) at html.cc:3514 #6 0x0806dca5 in DilloHtml::write (this=0x847f400, Buf=0x0, BufSize=59935, Eof=0) at html.cc:556 #7 0x0806ddbe in Html_callback (Op=0, Client=0x8502380) at html.cc:3673 #8 0x0805b862 in Cache_process_queue (entry=0x8562980) at cache.c:1173 #9 0x0805c41f in Cache_delayed_process_queue_callback () at cache.c:1237 #10 0x080cc874 in fltk::wait () #11 0x080cca19 in fltk::run () #12 0x0804f158 in main (argc=1, argv=0xbfbfe798) at dillo.cc:353 I set YES/NO on w3c_plus_heuristics in dillorc but it didn't help. It seems that new_tag contains something valid but tag looks corrupted or not-initialized. (gdb) p new_tag $1 = {name = 0x80f8ef7 "body", Flags = 30 '\036', EndTag = 79 'O', TagLevel = 1 '\001', open = 0x8069e9c <Html_tag_open_body>, close = 0x8067db0 <Html_tag_close_body>} (gdb) p tag $2 = {name = 0x79000000 <Error reading address 0x79000000: Bad address>, Flags = 16 '\020', EndTag = 0 '\0', TagLevel = 0 '\0', open = 0, close = 0x2f} Regards, furaisanjin

3 7

PATCH: don't force selection of first element in multi-select input.
by dtikhonov＠yahoo.com Nov. 4, 2009

Nov. 4, 2009

Hi all, Great job on dillo! Below is a patch that prevents the browser from selecting the first element of a multi-select input. Thanks, - Dmitri. --- a/src/form.cc Mon Nov 02 13:41:37 2009 -0300 +++ b/src/form.cc Tue Nov 03 12:57:02 2009 -0500 @@ -767,8 +767,8 @@ void Html_tag_close_select(DilloHtml *ht DilloHtmlInput *input = Html_get_current_input(html); DilloHtmlSelect *select = input->select; - // BUG(?): should not do this for MULTI selections - select->ensureSelection (); + if (DILLO_HTML_INPUT_SEL_LIST != input->type) + select->ensureSelection (); SelectionResource *res = (SelectionResource*)input->embed->getResource(); select->addOptionsTo (res);

2 2

Cleanups for Html_tag_cleanup_at_close()
by onepoint＠starurchin.org Nov. 2, 2009

Nov. 2, 2009

Congratulations on the big DPI reworking! Meanwhile I'd like to submit some cleanups for Html_tag_cleanup_at_close(), whose logic is currently pretty opaque. The first is a resubmit (it seems to have vanished into the ether when last posted). These should have no effect on behaviour, they just make it more clear what is going on. Regards, Jeremy Henty

2 2

arbitrary keysyms in keysrc
by corvid＠lavabit.com Nov. 1, 2009

Nov. 1, 2009

Jorge wrote: > On Sat, Oct 31, 2009 at 11:39:15PM +0000, corvid wrote: > > > > What would you think of allowing arbitrary keysyms > > to be specified in keysrc using their hex values? > > What's the gain? Being able to use a hex code from xev? > (to me it's an obscure representation, but easy to find OTOH) I finally got a newer computer, and it has some buttons that fltk has no idea about (e.g., a picture of a rectangle and arrow that X thinks of as XF86Next), and it would be nice to be able to use them.

1 0

patch: jpegs and cmyk color space
by corvid＠lavabit.com Nov. 1, 2009

Nov. 1, 2009

Here's one page that links to some CMYK jpgs and pretty much fits with what I've been able to learn: http://code.google.com/p/chromium/issues/detail?id=21659 Everything I find on the web about this shows roughly the same amount of uncertainty.

1 0

arbitrary keysyms in keysrc
by corvid＠lavabit.com Nov. 1, 2009

Nov. 1, 2009

What would you think of allowing arbitrary keysyms to be specified in keysrc using their hex values?

1 0

Latest whitespace handling patches
by jcid＠dillo.org Oct. 29, 2009

Oct. 29, 2009

Hi, The latest cleanups and whitespace handling patches have come like a fresh breeze removing unnecessary code. They're good for better code clarity. One of the few regressions I've noticed is extra underlining of links (the space before the first word's letter). As in: http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 BTW, I'm close to commiting the DPIP changes. Hopefully near this month's end. -- Cheers Jorge.-

2 5

Re: NULL for default tag close?
by jcid＠dillo.org Oct. 27, 2009

Oct. 27, 2009

On Tue, Oct 27, 2009 at 05:09:37PM +0000, corvid wrote: > Would it be all right if I changed the default_close()s to NULL? > I think it makes Tags[] easier to read, I'd prefer it as is for the same reason! :-) > and testing for NULL would > mean less time calling an empty function anyway... I'd be surprised if the gain is more than 0.1%. BTW, today in one part of the DPIP code I found that avoiding thousands of read() calls made no noticeable difference. With write() it was a different story though. Most probably gcc optimizes out empty functions too. -- Cheers Jorge.-

1 0

Re: link signal emission from layout?
by corvid＠lavabit.com Oct. 25, 2009

Oct. 25, 2009

Jorge wrote: > On Sat, Oct 24, 2009 at 03:48:55PM +0000, corvid wrote: > > I never liked all of the connectSignals() for all of the > > textblocks and images and whatever else in html.cc. > > Why not? So much signal connection for the listitems and the tablecells and everything, and all redundant, since it's all going back to the same receiver in html. > > Would you have any opinion about moving the > > (perhaps increasingly-inaccurately-named) > > link signal emission to layout? > > Could be. > > > I was just playing with the idea, and, at least after > > a moment's test :) , it seemed to be working. > > And, as a bonus, it lets me pop up menus when > > pressing button 3 below the bottom of page content. > > I miss this feature. Also being able to popup a menu over > a bare image would be a plus. Random thought: it would nice if there were a mechanism to change the size of images. > > (I left the event emitter alone for the moment, but I > > think the only thing using it right now is plain.cc. > > If so, it would be nice to rip that out in any case, > > even if plain doesn't have "links" exactly...) > > I don't know why it's currently done in html.cc, maybe it's > just grouping by required functionality, maybe not. If the new > approach is simpler and provides the same and more as you > pointed, id say: +1. It's simpler for src/, but the ickiness is preserved for dw/, since what was excised from Widget gets implanted into Layout. > BTW, please move this thread to dillo-dev.

1 0