- Dillo-dev - lists.mailman3.com

[patch]: dillo2 configure.in update for latest GNU m4

by jcid＠dillo.org

On Sat, May 10, 2008 at 08:37:36AM +0100, Jeremy Henty wrote: > On Sat, May 10, 2008 at 07:45:27AM +0100, Jeremy Henty wrote: > > > ... "AC_SUBST(src doc)" complains that "src doc" is not a valid > > shell tag. ... Anyway, replacing "AC_SUBST(src doc)" with > > "AC_SUBST(src)" and "AC_SUBST(doc)" seems to fix things. Patch > > attached. > > On second thoughts, it appears that "AC_SUBST(src doc)" does nothing > because the *.in files don't contain "@src doc@", "@src@" or "@doc@" > anywhere. Maybe we should just delete it. Here's an alternative > patch that does that. Committed. -- Cheers Jorge.-

May 10, 2008

should zlib be required?

by joerg.sonnenberger＠web.de

On Sat, May 10, 2008 at 12:17:37PM +0000, corvid wrote: > Should zlib be required? Given many sites allow compression for HTML pages, it is useful to have around anyway. I would just make it a requirement. Joerg

May 10, 2008

should zlib be required?

by corvid＠lavabit.com

Should zlib be required? I notice that testing for zlib is currently just a part of deciding whether to enable png. I either need to make configure.in require it, or make zlib optional with some ifdefs. As for which, though, I don't have much of an opinion.

May 10, 2008

[patch]: dillo2 configure.in update for latest GNU m4

by onepoint＠starurchin.org

On Sat, May 10, 2008 at 07:45:27AM +0100, Jeremy Henty wrote: > ... "AC_SUBST(src doc)" complains that "src doc" is not a valid > shell tag. ... Anyway, replacing "AC_SUBST(src doc)" with > "AC_SUBST(src)" and "AC_SUBST(doc)" seems to fix things. Patch > attached. On second thoughts, it appears that "AC_SUBST(src doc)" does nothing because the *.in files don't contain "@src doc@", "@src@" or "@doc@" anywhere. Maybe we should just delete it. Here's an alternative patch that does that. Jeremy Henty

May 10, 2008

[patch]: dillo2 configure.in update for latest GNU m4

by onepoint＠starurchin.org

I just updated my auto* tools including GNU m4 and the dillo2 build broke because "AC_SUBST(src doc)" complains that "src doc" is not a valid shell tag. I guess that the macro used to split at spaces and iterate over the result whereas the new version no longer does so. Anyway, replacing "AC_SUBST(src doc)" with "AC_SUBST(src)" and "AC_SUBST(doc)" seems to fix things. Patch attached. Please comment. Jeremy Henty

May 10, 2008

does RGBA work for you?

by corvid＠lavabit.com

Johannes wrote: > On Fri, May 09, 2008 at 02:23:09PM +0000, corvid wrote: > > (I'd seen that there was talk on the fltk forums recently about RGBA and images > > ending up with the wrong dimensions, but that's not my problem.) > > > > If you uncomment RGBA in test/dw_images_scaled.cc, does dragging the window > > around cause part of it to turn pinkish? > > (I'll attach a diff, even though it's not exactly difficult.) > > No, seems to work fine here. The rgab stuff in test/image from the > fltk tarball also seems to work. > I have xft enabled in my fltk build. Perhaps that makes a > difference? I have xft back on (I'd grown too accustomed to antialiasing to do without it). I'd forgotten about fltk/test. Nothing seems to be misbehaving there. Hmm. Maybe digging through the test source will enlighten me. I can hope, anyway...

May 9, 2008

does RGBA work for you?

by Johannes.Hofmann＠gmx.de

On Fri, May 09, 2008 at 02:23:09PM +0000, corvid wrote: > (I'd seen that there was talk on the fltk forums recently about RGBA and images > ending up with the wrong dimensions, but that's not my problem.) > > If you uncomment RGBA in test/dw_images_scaled.cc, does dragging the window > around cause part of it to turn pinkish? > (I'll attach a diff, even though it's not exactly difficult.) No, seems to work fine here. The rgab stuff in test/image from the fltk tarball also seems to work. I have xft enabled in my fltk build. Perhaps that makes a difference? Cheers, Johannes

May 9, 2008

does RGBA work for you?

by corvid＠lavabit.com

(I'd seen that there was talk on the fltk forums recently about RGBA and images ending up with the wrong dimensions, but that's not my problem.) If you uncomment RGBA in test/dw_images_scaled.cc, does dragging the window around cause part of it to turn pinkish? (I'll attach a diff, even though it's not exactly difficult.) I had started by hacking up the dillo side to send RGBA, and it worked fairly well in general for images where every pixel is either completely opaque or completely transparent. Gradients didn't seem to work too well, and often these pink/red regions were showing up. So far it seems as if the value of green relative to the value of alpha is what can make it particularly lose its mind, but that's probably wrong. You know how first impressions are... I followed it down to fltk/src/x11/Image.cxx, by which point it had been transformed to ARGB which looked about right to me. Then there's lots of xrender and transforms and things I don't know anything about. I tried some setcolor and fillrect in FltkImgbuf::draw(), but it didn't seem to matter, so I guess that's not my problem... If the question is "Why bother?", dillo2/src/png.c currently just mixes in whatever the background color is the first time we see an image on the page.

May 9, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by corvid＠lavabit.com

Jorge wrote: > > [Johannes wrote:] > > I noticed one regression with the new anchor code: > > The "Continue Reading Older Posts" link on www.boingboing.net > > (e.g. http://www.boingboing.net/2008/04/03/#entry-44240) no longer > > scrolls to the right position. > > There were mixed issues here. > > I just committed a patch that modifies/fixes anchor handling > with repush (on the last weeks anchors didn't work for me even > inside the bookmarks page). > > Now it works, and more like Firefox. This is, now reloading a > page with fragment, scrolls to the fragment position, but going > back and forward remembers the last user-scrolled position; quite > comfortable. > > The page you mention, works OK when it's a local file, but not > from the network. This looks like a bug hiding in the offset > calculation or scroll adjustment while the page loads images. > > In brief: with the patch the situation improves a lot, and > there's still a bug to fix. Things seem flaky now with redirection. Here's what happens if I 1 type in dillo.org 2 type in minix3.org $ dillo dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='about:blank' Nav_open_url: new url='http://dillo.org' Dns_server [0]: dillo.org is 0x8171648 Connecting to 134.102.206.165 Nav_open_url: new url='http://www.dillo.org/' Dns_server [0]: www.dillo.org is 0x8194228 Connecting to 134.102.206.165 META Content-Type changes charset to: iso-8859-1 Nav_open_url: new url='http://www.dillo.org/' META Content-Type gave charset as: iso-8859-1 a_Nav_expect_done: repush! Nav_open_url: new url='http://minix3.org' Dns_server [0]: minix3.org is 0x8147220 Connecting to 130.37.20.20 Nav_open_url: new url='http://www.minix3.org/' Dns_server [0]: www.minix3.org is 0x8198090 Connecting to 130.37.20.20 a_Nav_expect_done: e2ereload! META Content-Type changes charset to: iso-8859-1 Nav_open_url: new url='http://www.dillo.org/' META Content-Type gave charset as: iso-8859-1 a_Nav_expect_done: repush! I did not press Back.

May 8, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by jcid＠dillo.org

Hi, > [Johannes wrote:] > I noticed one regression with the new anchor code: > The "Continue Reading Older Posts" link on www.boingboing.net > (e.g. http://www.boingboing.net/2008/04/03/#entry-44240) no longer > scrolls to the right position. There were mixed issues here. I just committed a patch that modifies/fixes anchor handling with repush (on the last weeks anchors didn't work for me even inside the bookmarks page). Now it works, and more like Firefox. This is, now reloading a page with fragment, scrolls to the fragment position, but going back and forward remembers the last user-scrolled position; quite comfortable. The page you mention, works OK when it's a local file, but not from the network. This looks like a bug hiding in the offset calculation or scroll adjustment while the page loads images. In brief: with the patch the situation improves a lot, and there's still a bug to fix. -- Cheers Jorge.-

May 8, 2008