- Dillo-dev - lists.mailman3.com

[patch]: remove redundant #include in fltkflatview.cc
by onepoint＠starurchin.org April 30, 2008

April 30, 2008

A small cleanup: the "#include <fltk/damage.h>" in fltkflatview.cc is unnecessary. Regards, Jeremy Henty

2 1

[patch] fix table destructor
by Johannes.Hofmann＠gmx.de April 30, 2008

April 30, 2008

Hi, with memleaks in the news lately.... Here comes another one. Cheers, Johannes

2 1

patch: fltkimgbuf memleak
by corvid＠lavabit.com April 29, 2008

April 29, 2008

You should see a significant decrease in memory used.

3 2

Cheering some recent improvements in table layout
by onepoint＠starurchin.org April 29, 2008

April 29, 2008

Just to say that I'm seeing much better table rendering now. I have a page with a large two-column table. For a while recently this rendered very strangely in Dillo: it appeared with the two columns at opposite sides of the page, then the second column would move over to the left, one item at a time, to sit next to the first. But now the table immediately appears with both columns in the right place. I don't know what caused the strange realignment behaviour but I'm glad it's gone. Regards, Jeremy Henty

2 1

[patch] phrase search - take 2
by Johannes.Hofmann＠gmx.de April 29, 2008

April 29, 2008

Hi, here comes my second attempt on phrase search. As already described, I changed CharIterator back to not return \0s. Instead blanks are inserted when the space flag is set. This way CharIterator always returns a smooth stream of chars whether for normal html- or pre-text. Then there was a bug in DeepIterator::prev() that took me some time to find. I also adjusted charsEqual() to treat all space-chars equally. Finally I had to add a check in CharIterator::highlight() to avoid a crash when searching for the last word in pre-text with a blank appended. Cheers, Johannes

2 1

dillo seems to close file descriptors twice
by Johannes.Hofmann＠gmx.de April 29, 2008

April 29, 2008

Hi, I just noticed, that dillo seems to close file descriptors twice via IO_close_fd, which causes problems when other threads run in parallel for name server queries. Here are the two call stacks via which IO_close_fd is called for each fd: (gdb) b IO_close_fd Breakpoint 1 at 0x8070781: file IO.c, line 137. (gdb) r dillo.org Starting program: /home/hofmann/projects/dillo/plain/dillo2-hg/src/dillo-fltk dillo.org dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='http://dillo.org' Dns_server [0]: dillo.org is 0x28559680 Connecting to 134.102.206.165 Nav_open_url: new url='http://www.dillo.org/' Breakpoint 1, IO_close_fd (io=0x28550a00, CloseCode=2) at IO.c:137 137 fprintf(stderr,"====> begin IO close (%d)\n", io->FD); Current language: auto; currently c (gdb) bt #0 IO_close_fd (io=0x28550a00, CloseCode=2) at IO.c:137 #1 0x0807094e in a_IO_ccc (Op=4, Branch=1, Dir=2, Info=0x285509e0, Data1=0x0, Data2=0x0) at IO.c:392 #2 0x0805633e in a_Chain_bcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:98 #3 0x0806ea14 in a_Http_ccc (Op=4, Branch=1, Dir=2, Info=0x2854df60, Data1=0x0, Data2=0x0) at http.c:522 #4 0x0805633e in a_Chain_bcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:98 #5 0x0805a514 in a_Capi_ccc (Op=4, Branch=1, Dir=2, Info=0x2854df40, Data1=0x0, Data2=0x0) at capi.c:491 #6 0x0805a39c in a_Capi_ccc (Op=4, Branch=2, Dir=1, Info=0x285509a0, Data1=0x0, Data2=0x0) at capi.c:601 #7 0x0805630a in a_Chain_fcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:86 #8 0x0806ffd1 in a_Dpi_ccc (Op=4, Branch=2, Dir=1, Info=0x28550bc0, Data1=0x0, Data2=0x0) at dpi.c:671 #9 0x0805630a in a_Chain_fcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:86 #10 0x08070891 in a_IO_ccc (Op=4, Branch=2, Dir=1, Info=0x28550c00, Data1=0x28550c20, Data2=0x0) at IO.c :410 #11 0x08070b64 in IO_callback (fd=<value optimized out>, io=0x28550c20) at IO.c:201 #12 0x08070beb in IO_fd_read_cb (fd=7, data=0x2) at IO.c:277 #13 0x080bcfe5 in fltk::wait () #14 0x080bd195 in fltk::run () #15 0x0804eadb in main (argc=0, argv=0x0) at dillo.cc:110 (gdb) c Continuing. ====> begin IO close (7) Breakpoint 1, IO_close_fd (io=0x28550c20, CloseCode=2) at IO.c:137 137 fprintf(stderr,"====> begin IO close (%d)\n", io->FD); (gdb) bt #0 IO_close_fd (io=0x28550c20, CloseCode=2) at IO.c:137 #1 0x0807089e in a_IO_ccc (Op=4, Branch=2, Dir=1, Info=0x28550c00, Data1=0x28550c20, Data2=0x0) at IO.c:411 #2 0x08070b64 in IO_callback (fd=<value optimized out>, io=0x28550c20) at IO.c:201 #3 0x08070beb in IO_fd_read_cb (fd=7, data=0x2) at IO.c:277 #4 0x080bcfe5 in fltk::wait () #5 0x080bd195 in fltk::run () #6 0x0804eadb in main (argc=0, argv=0x0) at dillo.cc:110 (gdb) c Continuing. ====> begin IO close (7) A line like fprintf(stderr,"====> begin IO close (%d)\n", io->FD); at the beginning of IO_close_fd() also shows the problem. Cheers, Johannes

3 3

Since we've been talking about name clashes, what about "assert"
by onepoint＠starurchin.org April 27, 2008

April 27, 2008

Because lout::misc defines an inline assert function, including dw/core.hh fails if you've already included anything that defines the standard assert macro (such the C++ iostream stuff). You can work around it by including dw/core.hh first, but that feels pretty fragile as it depends on nothing subsequently using the standard assert. What's the best fix? (Example appended.) Regards, Jeremy Henty For example: #include <ios> #include <dw/core.hh> yields (with GCC 3.4.3): In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, from ./../Source/current/dw2/dw/core.hh:39, from dw_assert.cc:9: ./../Source/current/dw2/dw/../lout/misc.hh:36:55: macro "assert" passed 3 arguments, but takes just 1 In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, from ./../Source/current/dw2/dw/core.hh:39, from dw_assert.cc:9: ./../Source/current/dw2/dw/../lout/misc.hh:37: error: invalid function declaration ./../Source/current/dw2/dw/../lout/misc.hh:185:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh:198:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh:213:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T* lout::misc::SimpleVector<T>::getRef(int)': ./../Source/current/dw2/dw/../lout/misc.hh:184: error: `assert' undeclared (first use this function) ./../Source/current/dw2/dw/../lout/misc.hh:184: error: (Each undeclared identifier is reported only once for each function it appears in.) ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T lout::misc::SimpleVector<T>::get(int)': ./../Source/current/dw2/dw/../lout/misc.hh:197: error: `assert' undeclared (first use this function) ./../Source/current/dw2/dw/../lout/misc.hh: In member function `void lout::misc::SimpleVector<T>::set(int, T)': ./../Source/current/dw2/dw/../lout/misc.hh:212: error: `assert' undeclared (first use this function) make[1]: *** [dw_assert-dw_assert.o] Error 1

2 2

Re: patch: various IN_*s
by jcid＠dillo.org April 27, 2008

April 27, 2008

Hi, On Sun, Apr 27, 2008 at 02:15:37PM +0000, corvid wrote: > - disallow <button> or <input> inside <button>. > Nested buttons and image inputs inside buttons don't come out right, > and they aren't legal anyway. OK. > - disallow <input> inside <select>. > As I mentioned before, </select> does not like that, and it isn't legal. ok. > - disallow <isindex> inside <form>. > It's legal (%block goes inside form, and isindex is a %block), > but it splits a form into pieces, given dillo's current implementation. > Firefox handles it as a form within a form, but I don't want to add > complexity, and I know you don't want to add complexity :) ok. Committed. -- Cheers Jorge.-

1 0

"View Page source" scrolling problem
by 4winter＠informatik.uni-hamburg.de April 27, 2008

April 27, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey folks :) I found another bug / feature... I use a trackstick with mouse wheel emulation. This allows me to scroll text by pressing the middle button and moving the stick. Someone in the xorg input layer maps this to buttons 4 - 7 (up, down, left, right). Problem is that it is impossible to just scroll up. You end up being off by some degree and you get a event for left and right every now and then (confirmed using xev). Unfortunately this kills the scrolling in the view page source window: http://teythoon.cryptobitch.de/stuff/scroll-problem.ogg It would also be nice to be able to scroll left/right with buttons 6 and 7. Since there are mouses that have special navigation buttons (most likely also being number 6 and 7) it would be nice to be able to configure the mapping (firefox does this) for these buttons. That would make trackstick users happy and also those of us that are stuck with a mouse with those navigation buttons (I have access to one of those and the buttons are located at the left side so that you can press them with your thumb [not a very left-handed friendly design]. To make a long story short you just end up pressing them by accident the moment you filled out some huge form...). But then again, some people might find them useful. 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 iD8DBQFIE+EdoPmwNWhsaZYRArv+AJ0ZO6hR5Caw/eaHXtnwWv9RFEgETACfYn6v FcJ5rxwibEXoAK5ZLtmTNEs= =t0nP -----END PGP SIGNATURE-----

1 0

[PATCH]: lout::misc::min
by onepoint＠starurchin.org April 27, 2008

April 27, 2008

I mean, this *has* to be a typo, right? Jeremy Henty

2 3