- Dillo-dev - lists.mailman3.com

[patch]: remove redundant #include in fltkflatview.cc

by onepoint＠starurchin.org

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

April 29, 2008

dillo seems to close file descriptors twice

by joerg.sonnenberger＠web.de

On Tue, Apr 29, 2008 at 04:54:20PM +0200, Johannes Hofmann wrote: > The signal is delivered as dillo writes to a socket that has been > closed by the remote side. I rather wonder, why this does not happen > on Linux. Just set it to SIG_IGN. Joerg

April 29, 2008

FIXED: [PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by onepoint＠starurchin.org

D'oh! "||" where I should have used "|"! What a n00b! Here's the fixed patch. (And this time I have tested by running all the executables in dw/test/ .) Regards, Jeremy Henty

April 29, 2008

dillo seems to close file descriptors twice

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Apr 29, 2008 at 10:40:18AM -0400, Jorge Arellano Cid wrote: > On Tue, Apr 22, 2008 at 08:27:39PM +0200, Johannes Hofmann wrote: > > 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: > > OK, I committed a commented patch for this. Please test it. Yes, the double close problem is gone with this patch. > I'd be also interested to know whether this fixes the SIGPIPE > problems you saw in your OS. > > I remember removing the ignore SIGPIPE code because it didn't > happen anymore in GNU/Linux. It'd be good to know where it comes > from. The SIGPIPE problem is still there: Program received signal SIGPIPE, Broken pipe. 0x283e1050 in write () from /usr/lib/libc.so.6 (gdb) bt #0 0x283e1050 in write () from /usr/lib/libc.so.6 #1 0x28297f2c in write () from /usr/lib/libpthread.so.0 #2 0x080712a2 in IO_callback (fd=<value optimized out>, io=0x282a18c0) at IO.c:226 #3 0x080713f7 in IO_fd_write_cb (fd=7, data=0x1) at IO.c:303 #4 0x080bd4b9 in fltk::wait () #5 0x080bd669 in fltk::run () #6 0x0804eadb in main (argc=Cannot access memory at address 0x0) at dillo.cc:110 The signal is delivered as dillo writes to a socket that has been closed by the remote side. I rather wonder, why this does not happen on Linux. I found this on the topic: http://www.developerweb.net/forum/showthread.php?t=2953 Cheers, Johannes

April 29, 2008

dillo seems to close file descriptors twice

by jcid＠dillo.org

On Tue, Apr 22, 2008 at 08:27:39PM +0200, Johannes Hofmann wrote: > 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: OK, I committed a commented patch for this. Please test it. I'd be also interested to know whether this fixes the SIGPIPE problems you saw in your OS. I remember removing the ignore SIGPIPE code because it didn't happen anymore in GNU/Linux. It'd be good to know where it comes from. -- Cheers Jorge.-

April 29, 2008

[patch] fix table destructor

by Johannes.Hofmann＠gmx.de

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

April 29, 2008

patch: fltkimgbuf memleak

by Johannes.Hofmann＠gmx.de

On Tue, Apr 29, 2008 at 01:24:49AM +0000, corvid wrote: > You should see a significant decrease in memory used. Wow, indeed! > > diff -pur dw2/dw/fltkimgbuf.cc dw2-cur/dw/fltkimgbuf.cc > --- dw2/dw/fltkimgbuf.cc 2008-01-16 02:57:23.000000000 +0000 > +++ dw2-cur/dw/fltkimgbuf.cc 2008-04-29 00:40:04.000000000 +0000 > @@ -119,11 +119,10 @@ FltkImgbuf::~FltkImgbuf () > //else > // printf("FltkImgbuf[root %p]: deleted\n", this); > > - if (!isRoot()) { > + if (!isRoot()) > root->detachScaledBuf (this); > - delete rawdata; > - } > > + delete rawdata; > delete copiedRows; > > if (scaledBuffers) > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 29, 2008

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > On Sun, Apr 27, 2008 at 05:33:33AM +0200, Justus Winter wrote: >> Somewhat related I would suggest to get rid of the location dialog (ctrl >> + l). As far as I can see it has offers nothing more than entering the >> address directly into the url bar, so whats the point? Make ctrl + l a >> shortcut that moves the cursor to the url bar instead. > > On the other hand the dialogs allow to use dillo without panel > (Ctrl-Space). That's a nice feature, indeed. What about getting rid of the dialog box and just showing the panel on demand in "without panel" mode? >> Flickering... there was a thread about fltk and double buffer >> something... there is no flickering when scrolling a page on my machine >> (there are some artifacts in the scrollbar, it looks like it is jumping >> around a little or changing its size) but if I move the whole window it >> flickers a lot. > > Both are fltk bugs I think. I also see this with fltk test > applications if I add clear_double_buffer(). > We should submit bug reports for that. If you have a small patch ready that introduces this behavior into one of their test programs I nominate you for this task :) >> And one more obscure bug I just noticed while playing around with the >> scrollbar: When I switch from one virtual desktop (my window manager is >> e17) to another with a dillo window on it and try to scroll the page it >> doesn't work. Most of the time it selects text on the page (it didn't >> when I recorded the movie, typical...). The problem goes away if I move >> or resize the window so I would guess that it has something to do with >> window coordinates / dimensions not being correct. I compiled dillo with >> fltk2 revision 6101. >> >> http://teythoon.cryptobitch.de/stuff/virtual-desktops.ogg > > I don't see this with dwm. Can you try whether fltk test > applications show this behaviour too? http://teythoon.cryptobitch.de/stuff/virtual-desktops-fltk2-problem.ogg You are right, this seems to be a fltk2 bug. I will file a bug report for this problem. 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 iD8DBQFIFyr6oPmwNWhsaZYRArM/AJ44W5nWh1xekGLtM1RrfmC9ujW3eACfTVbx OlU9NERtkjeQqraFwc96M2c= =pMct -----END PGP SIGNATURE-----

April 29, 2008

DO NOT: [PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by onepoint＠starurchin.org

D'oh! > This patch makes FltkWidgetView::allocateFltkWidget mark the FLTK > widget's layout as damaged. This fixes > dw::fltk::ui::FltkListResource (which is necessary to implement > MULTIPLE SELECT inputs in forms). And it also makes TextResources crash. Augh! Let me try and figure this out. Regards, Jeremy Henty

April 29, 2008

[PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by onepoint＠starurchin.org

This patch makes FltkWidgetView::allocateFltkWidget mark the FLTK widget's layout as damaged. This fixes dw::fltk::ui::FltkListResource (which is necessary to implement MULTIPLE SELECT inputs in forms). Currently a dw::fltk::ui::FltkListResource widget fails to display itself. (You can run test/dw-resource-test to see this). This is because the resource's fltk::MultiBrowser widget is created with a tiny size and later reallocated to the correct size. The viewport calls layout() each time, but this doesn't call widget->layout() unless the widget's layout is damaged. Unfortunately the layout is marked as damaged when the widget is created but *not* after it is resized, so MultiBrowser::layout() gets called when the widget is tiny, but not when it is the right size. Alas, MultiBrowser::draw() uses size information that was cached by MultiBrowser::layout() , so it behaves as though the widget is still tiny, concludes that none of the Items are visible and doesn't draw anything. This bug potentially bites all widgets, it's just sheer luck that only MultiBrowser is visibly affected. Other widgets are either simple enough to survive their layout() being called when they were a different size, or else smart enough to mark *themselves* as damaged so that the viewport calls their layout() at the right time. Regards, Jeremy Henty

April 29, 2008