- Dillo-dev - lists.mailman3.com

Re: patch: url encode, append input

by jcid＠dillo.org

On Tue, Apr 08, 2008 at 09:16:47PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote: > > > a_Url_encode_hex_str() needed to accept a Dstr* because it is not > > > illegal to use url encoding on a file. Maybe a situation that'll > > > never happen, but then again, it's easy to leave off enctype. > > > > In that case the behaviour is not specified. > > > > i.e. (from http://www.ietf.org/rfc/rfc1867.txt) > > > > 5.8 File transfer with ENCTYPE=x-www-form-urlencoded > > > > If a form contains <INPUT TYPE=file> elements but does not contain an > > ENCTYPE in the enclosing <FORM>, the behavior is not specified. It > > is probably inappropriate to attempt to URN-encode large quantities > > of data to servers that don't expect it. > > > > > > > (However, Firefox -- as if it's any authority on anything, but still -- > > > doesn't send file contents for URL encoded forms. It just sends > > > the filename.) > > > > Probably is not a bad idea to follow this lead or investigate > > a bit further on what IE, Safari or Opera do, and then decide. > > > > At least, I'd feel more comfortable with a file-size limit for > > both GET&POST, thus avoiding Dillo to exit because it can't > > allocate enough memory for sending a huge file. > > Ohh... I thought RFC 1867 was just an old version of > RFC 2388 (Returning Values from Forms: multipart/form-data), > so I never looked at it. Yeah, browsing RFC dependencies is confusing sometimes... Jukka Korpela usually has pretty solid advice: http://www.cs.tut.fi/~jkorpela/forms/file.html#rfc The whole page is insightful, the anchor points to: "The status of RFC 1867" > I'd prefer not to send the file at all if we don't have to. After reading the document quickly, I'd also prefer not to send the file. Please let me know your thoughts. -- Cheers Jorge.-

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

Oh wow. Sure, I knew that antialiasing slows things down, but I'd never imagined the difference was so incredibly dramatic. It's now fine with clear_double_buffer(), and the menu I'd mentioned now goes at _full_ _speed_.

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > > > > Jeremy wrote: > > > > > There are no regressions that I can see. It feels just as fast and > > > > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > > > > would be useful if someone with a more low-end box tried it out. > > > > > > > > I wonder who you could be talking about :) > > > > I applied it, but running without double buffering is just not an > > > > option for me. Drawing is just very slow no matter what. > > > > > > Is dillo-fltk useable for you with the patch, but with > > > clear_double_buffer() as in current cvs? > > > If not, what exactly is the problem? > > > > Drawing a page of text takes a couple of seconds, as I've always seen with > > clear_double_buffer(). > > Well, I don't expect it to be faster with my patch, but there should > be less flicker, so you should be able to start reading while the > page is loading. > The same effect would I expect from commenting out > clear_double_buffer(). Or is the drawing itself faster if you > comment out clear_double_buffer()? With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds). If I comment out clear_double_buffer(), it takes no perceived time. > The point of my patch is to make drawing flicker free as with > clear_double_buffer() commented out, but without the memory > overhead. > > What machine do you have? Perhaps I should try to revive an old > laptop of mine... a thinkpad 380XD. It had its tenth birthday in February. I've been really meaning to get something newer for... a year now. (If you think that's bad, I used a Commodore until 1993 -- if you're old enough for that to mean much to you, anyway). > > > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > > > > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html > > > > > > Hm, I see something... And I can click on the "Individual", > > > "Businesses"... images. > > > > Is it slow when you scroll around through the items in the menu > > of forms at the bottom? > > It's certainly usable. However you might have noticed that drawing > antialiased fonts consumes much more CPU than raster fonts. > So you might try fltk2 configured with the --disable-xft option. > I actually like good raster fonts better than antialiased ones, but > that's a matter of taste. It currently must take like a minute to go from one item to the next. Probably more. I'll try --disable-xft.

April 8, 2008

Re: patch: url encode, append input

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote: > > a_Url_encode_hex_str() needed to accept a Dstr* because it is not > > illegal to use url encoding on a file. Maybe a situation that'll > > never happen, but then again, it's easy to leave off enctype. > > In that case the behaviour is not specified. > > i.e. (from http://www.ietf.org/rfc/rfc1867.txt) > > 5.8 File transfer with ENCTYPE=x-www-form-urlencoded > > If a form contains <INPUT TYPE=file> elements but does not contain an > ENCTYPE in the enclosing <FORM>, the behavior is not specified. It > is probably inappropriate to attempt to URN-encode large quantities > of data to servers that don't expect it. > > > > (However, Firefox -- as if it's any authority on anything, but still -- > > doesn't send file contents for URL encoded forms. It just sends > > the filename.) > > Probably is not a bad idea to follow this lead or investigate > a bit further on what IE, Safari or Opera do, and then decide. > > At least, I'd feel more comfortable with a file-size limit for > both GET&POST, thus avoiding Dillo to exit because it can't > allocate enough memory for sending a huge file. Ohh... I thought RFC 1867 was just an old version of RFC 2388 (Returning Values from Forms: multipart/form-data), so I never looked at it. I'd prefer not to send the file at all if we don't have to.

April 8, 2008

Re: patch: urldecode base64 data uri

by jcid＠dillo.org

On Sun, Apr 06, 2008 at 07:01:52PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Apr 06, 2008 at 05:07:30AM +0000, corvid wrote: > > > I took a better look at the RFC and it looks like I am wrong. > > > > > > I naively assumed that since it's been on the acid site for however > > > many years, somebody would have complained if it wasn't right, > > > and I took relatively little care in rfc-checking. > > > > > > On the other hand, I am coming to learn that RFCs are > > > not perfectly perfect things. > > > > > > The relevant RFC text: > > > The appearance of ";base64" means that the data > > > is encoded as base64. Without ";base64", the data (as a sequence of > > > octets) is represented using ASCII encoding for octets inside the > > > range of safe URL characters and using the standard %xx hex encoding > > > of URLs for octets outside that range. > > > > > > http://www.webstandards.org/action/acid2/guide/ says of the square: > > > Also, there is a 64px by 64px red box in the background (represented > > > by the PNG image in the data url, not reprinted in full). The red > > > box is not visible as the background-attachment is set to 'fixed' > > > which puts the red box outside of view. > > > > > > (as opposed to saying that it's supposed to break or something) > > > > Which in what regards to the patch, means? > > > > a) keep > > b) revert > > - To me, a strict reading of the RFC says revert. > > - I see that http://developer.mozilla.org/en/docs/The_data_URL_scheme > gives their base64 example as > "data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D" > > - At http://simonwillison.net/2003/Aug/11/selfContained/ > Simon Proctor claimed that Mozilla didn't like the URL encoding, > and Ian Hickson asserted that it was necessary. > > - Ian Hickson would appear to be the guy who wrote the "data: URI kitchen" > (http://software.hixie.ch/utilities/cgi/data/data) which is apparently > the main datauri-maker that people use, as well as being the guy who wrote > the acid2 test. > > On one hand, this means that dillo will encounter the URL encoding. > > On the other hand, if Hickson has any actual persuasive argument for > his viewpoint, I have not found it. OK, reverted. -- Cheers Jorge.-

April 8, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > > > Jeremy wrote: > > > > There are no regressions that I can see. It feels just as fast and > > > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > > > would be useful if someone with a more low-end box tried it out. > > > > > > I wonder who you could be talking about :) > > > I applied it, but running without double buffering is just not an > > > option for me. Drawing is just very slow no matter what. > > > > Is dillo-fltk useable for you with the patch, but with > > clear_double_buffer() as in current cvs? > > If not, what exactly is the problem? > > Drawing a page of text takes a couple of seconds, as I've always seen with > clear_double_buffer(). Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()? The point of my patch is to make drawing flicker free as with clear_double_buffer() commented out, but without the memory overhead. What machine do you have? Perhaps I should try to revive an old laptop of mine... > > If that sounds wrong, I'll double-check that I applied it correctly. > I had cut and pasted from the mail, and maybe I missed something. > > > > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > > > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html > > > > Hm, I see something... And I can click on the "Individual", > > "Businesses"... images. > > Is it slow when you scroll around through the items in the menu > of forms at the bottom? It's certainly usable. However you might have noticed that drawing antialiased fonts consumes much more CPU than raster fonts. So you might try fltk2 configured with the --disable-xft option. I actually like good raster fonts better than antialiased ones, but that's a matter of taste. Cheers, Johannes

April 8, 2008

Re: patch: url encode, append input

by jcid＠dillo.org

Hi, On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote: > a_Url_encode_hex_str() needed to accept a Dstr* because it is not > illegal to use url encoding on a file. Maybe a situation that'll > never happen, but then again, it's easy to leave off enctype. In that case the behaviour is not specified. i.e. (from http://www.ietf.org/rfc/rfc1867.txt) 5.8 File transfer with ENCTYPE=x-www-form-urlencoded If a form contains <INPUT TYPE=file> elements but does not contain an ENCTYPE in the enclosing <FORM>, the behavior is not specified. It is probably inappropriate to attempt to URN-encode large quantities of data to servers that don't expect it. > (However, Firefox -- as if it's any authority on anything, but still -- > doesn't send file contents for URL encoded forms. It just sends > the filename.) Probably is not a bad idea to follow this lead or investigate a bit further on what IE, Safari or Opera do, and then decide. At least, I'd feel more comfortable with a file-size limit for both GET&POST, thus avoiding Dillo to exit because it can't allocate enough memory for sending a huge file. > Html_append_input() becomes a few functions (I'd never felt good > about sending a boundary arg for url encoding anyway). OK. -- Cheers Jorge.-

April 8, 2008

Good news from fltk!

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > > Jeremy wrote: > > > There are no regressions that I can see. It feels just as fast and > > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > > would be useful if someone with a more low-end box tried it out. > > > > I wonder who you could be talking about :) > > I applied it, but running without double buffering is just not an > > option for me. Drawing is just very slow no matter what. > > Is dillo-fltk useable for you with the patch, but with > clear_double_buffer() as in current cvs? > If not, what exactly is the problem? Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer(). If that sounds wrong, I'll double-check that I applied it correctly. I had cut and pasted from the mail, and maybe I missed something. > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html > > Hm, I see something... And I can click on the "Individual", > "Businesses"... images. Is it slow when you scroll around through the items in the menu of forms at the bottom?

April 8, 2008

Good news from fltk!

by jcid＠dillo.org

Hi, On Tue, Apr 08, 2008 at 08:03:04PM +0200, Johannes Hofmann wrote: > On Tue, Apr 08, 2008 at 05:11:58PM +0100, Jeremy Henty wrote: > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > > > Mostly I would be interested whether it still feels fast. And any > > > regressions you observe, of course... > > > > There are no regressions that I can see. It feels just as fast and > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > would be useful if someone with a more low-end box tried it out. > > Yes we should definately test in on some low-end machines. > Remote X11 is also a good test. I can test it on a slow machine, but next week... > > > BTW, do you think double buffering should be a compile time option - > > > as in the patch? As no special includes are needed we might make it > > > a run time option as well. > > > > I don't know enough about the issues to say. Why would someone want > > to disable double buffering? Resource constraints? An unusual X > > server that doesn't support it very well? > > I can only think of debugging. Without double buffering you see > excessive redraws immediately. The problem we had before the patch in current FLTK, was of memory usage on restrained/embedded systems (one buffer per open window IIRC). Although I'm not sure yet, it'd be good to have it as a dillorc option to make faster comparisons. :-) -- Cheers Jorge.-

April 8, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > Jeremy wrote: > > There are no regressions that I can see. It feels just as fast and > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > would be useful if someone with a more low-end box tried it out. > > I wonder who you could be talking about :) > I applied it, but running without double buffering is just not an > option for me. Drawing is just very slow no matter what. Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem? > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html Hm, I see something... And I can click on the "Individual", "Businesses"... images. Cheers, Johannes

April 8, 2008

Good news from fltk!

by corvid＠lavabit.com

Jeremy wrote: > There are no regressions that I can see. It feels just as fast and > somewhat less flickery. Mind you, this is a fairly fast machine, it > would be useful if someone with a more low-end box tried it out. I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what. Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html

April 8, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 05:11:58PM +0100, Jeremy Henty wrote: > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > Mostly I would be interested whether it still feels fast. And any > > regressions you observe, of course... > > There are no regressions that I can see. It feels just as fast and > somewhat less flickery. Mind you, this is a fairly fast machine, it > would be useful if someone with a more low-end box tried it out. Yes we should definately test in on some low-end machines. Remote X11 is also a good test. > > > BTW, do you think double buffering should be a compile time option - > > as in the patch? As no special includes are needed we might make it > > a run time option as well. > > I don't know enough about the issues to say. Why would someone want > to disable double buffering? Resource constraints? An unusual X > server that doesn't support it very well? I can only think of debugging. Without double buffering you see excessive redraws immediately. Regards, Johannes

April 8, 2008

Good news from fltk!

by onepoint＠starurchin.org

On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > Mostly I would be interested whether it still feels fast. And any > regressions you observe, of course... There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out. > BTW, do you think double buffering should be a compile time option - > as in the patch? As no special includes are needed we might make it > a run time option as well. I don't know enough about the issues to say. Why would someone want to disable double buffering? Resource constraints? An unusual X server that doesn't support it very well? Regards, Jeremy Henty

April 8, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > Attached is a patch that enables double buffering for partial screen > > redraws (this is where the flickering is most annoying). You will > > need at least version r6079 of fltk2 to test. > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > (fixed version). Looks OK so far. Any tests I should run? Mostly I would be interested whether it still feels fast. And any regressions you observe, of course... BTW, do you think double buffering should be a compile time option - as in the patch? As no special includes are needed we might make it a run time option as well. Regards, Johannes

April 8, 2008

Good news from fltk!

by onepoint＠starurchin.org

On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > Attached is a patch that enables double buffering for partial screen > redraws (this is where the flickering is most annoying). You will > need at least version r6079 of fltk2 to test. OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run? Regards, Jeremy Henty

April 8, 2008

Re: patch: escape for display

by jcid＠dillo.org

On Sun, Apr 06, 2008 at 11:08:13PM +0000, corvid wrote: > > I ponder having a: > > > > const char *dStr_printable(dStr *in, int maxlen) > > > > that returns a pointer to an internal static dStr. It has > > the advantage of minimal interface overhead. e.g. > > > > - MSG_WARN(" \"%s\"\n", io->Buf->str); > > + MSG_WARN(" \"%s\"\n", dStr_printable(io->Buf, 2048)); > > > > of course it's not MT-safe, but we don't need it now. > > > > Implementing a MT-safe version is easy, but involves more > > calling overhead: > > > > dStr *dStr_printable(dStr *in, int maxlen) > > > > - MSG_WARN(" \"%s\"\n", io->Buf->str); > > + Dstr *printable = dStr_printable(io->Buf, 2048)); > > + MSG_WARN(" \"%s\"\n", printable->str)); > > + dStr_free(printable, 1); > > > > and disabling the message is not as clean as prepending an "_" > > to the macro. > > > > I'd go with the first alternative. > > Attached. > > I wasn't too sure about representation. Text has \x0D where ^M would > be much less surprising, but \x is easier to read for arbitrary bytes. > > It's funny that I had been calling truncation a bug and now I'm > truncating intentionally, but there is only so much a person > wants to see... Committed. -- Cheers Jorge.-

April 7, 2008

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

by jcid＠dillo.org

Hi, On Sat, Apr 05, 2008 at 11:58:45AM +0200, Johannes Hofmann 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. I checked with a dillo version even as old as 2007-11-23 and the bug is present. So it's not related to the newest anchor patch. It seems somewhere the offset is not being updated. If I load the page from cache, it works! i.e. file:/tmp/44240.html file:/tmp/44240.html#entry-44240 works OK. Using a cgi to simulate network transfer rate (10KB/sec), I can reproduce the bug: http://localhost/cgi-bin/slow.cgi?10000:/tmp/44240.html#entry-44240 That's what I've found so far. -- Cheers Jorge.-

April 6, 2008

Re: patch: dStr_memmem

by jcid＠dillo.org

Hi, Committed with a minor modification: /* * Return a pointer to the first occurrence of needle in haystack. */ char *dStr_memmem(Dstr *haystack, Dstr *needle) { int i; if (needle && haystack) { if (needle->len == 0) return haystack->str; for (i = 0; i <= (haystack->len - needle->len); i++) { - if (!memcmp(haystack->str + i, needle->str, needle->len)) + if (haystack->str[i] == needle->str[0] && + !memcmp(haystack->str + i, needle->str, needle->len)) return haystack->str + i; } } return NULL; } The idea is to avoid a 3 parameters function call per each checked character. Maybe it's even better to implement it without a function call (like dStristr()), but I haven't done any profiling so I'm not sure. It looks like an improvement though. ;-) -- Cheers Jorge.-

April 6, 2008

Re: Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi, my first patch broke test programs in dw2/test/ (as they don't use clear_double_buffer() as dillo-fltk does). Corrected patch attached. Sorry for that, Johannes On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > Hi, > > I stumbled across this post on fltk.bugs: > http://fltk.org/newsgroups.php?s5281+gfltk.bugs+v5290+T0 > > This is great for us, as it allows us to implement efficient double > buffering without X11 specific hacks. > Attached is a patch that enables double buffering for partial screen > redraws (this is where the flickering is most annoying). > You will need at least version r6079 of fltk2 to test. > > Cheers, > Johannes > diff -r 0949076de1d4 configure.in > --- a/configure.in Sat Apr 05 13:33:25 2008 +0200 > +++ b/configure.in Sat Apr 05 16:48:27 2008 +0200 > @@ -21,6 +21,7 @@ AC_ARG_ENABLE(ansi, [ --enable-ansi > AC_ARG_ENABLE(ansi, [ --enable-ansi Try to compile and run with ANSI flags], > , enable_ansi=no) > AC_ARG_ENABLE(rtfl, [ --enable-rtfl Build with rtfl messages], enable_rtfl=yes) > +AC_ARG_ENABLE(doublebuffer, [ --disable-doublebuffer Disable double buffering for drawing], disable_doublebuffer=yes) > > AC_PROG_CXX > AM_PROG_CC_STDC > @@ -61,6 +62,9 @@ if test "x$enable_rtfl" = "xyes" ; then > if test "x$enable_rtfl" = "xyes" ; then > CXXFLAGS="$CXXFLAGS -DDBG_RTFL" > fi > +if test "x$disable_doublebuffer" = "xyes" ; then > + CXXFLAGS="$CXXFLAGS -DNO_DOUBLEBUFFER" > +fi > > dnl ----------------------- > dnl Checks for header files > diff -r 0949076de1d4 dw/fltkviewbase.cc > --- a/dw/fltkviewbase.cc Sat Apr 05 13:33:25 2008 +0200 > +++ b/dw/fltkviewbase.cc Sat Apr 05 16:48:27 2008 +0200 > @@ -38,6 +38,8 @@ namespace dw { > namespace dw { > namespace fltk { > > +::fltk::Image *FltkViewBase::backBuffer; > + > FltkViewBase::FltkViewBase (int x, int y, int w, int h, const char *label): > Group (x, y, w, h, label) > { > @@ -46,13 +48,17 @@ FltkViewBase::FltkViewBase (int x, int y > bgColor = WHITE; > lastDraw = time(0); > drawDelay = 2; /* in seconds */ > +#ifndef NO_DOUBLEBUFFER > + if (!backBuffer) { > + backBuffer = new Image (); > + } > +#endif > } > > FltkViewBase::~FltkViewBase () > { > cancelQueueDraw (); > } > - > > void FltkViewBase::draw () > { > @@ -78,9 +84,27 @@ void FltkViewBase::draw () > > if (!viewRect.empty ()) { > push_clip (viewRect); > +#ifndef NO_DOUBLEBUFFER > + { > + GSave gsave; > + > + backBuffer->setsize (viewRect.w (), viewRect.h ()); > + backBuffer->make_current (); > + translate (-viewRect.x () , -viewRect.y ()); > + > + setcolor (bgColor); > + fillrect (viewRect); > + theLayout->expose (this, rect); > + } > + > + make_current (); > + backBuffer->draw (Rectangle (0, 0, viewRect.w (), viewRect.h ()), > + viewRect); > +#else > setcolor (bgColor); > fillrect (viewRect); > theLayout->expose (this, rect); > +#endif > pop_clip (); > } > } > diff -r 0949076de1d4 dw/fltkviewbase.hh > --- a/dw/fltkviewbase.hh Sat Apr 05 13:33:25 2008 +0200 > +++ b/dw/fltkviewbase.hh Sat Apr 05 16:48:27 2008 +0200 > @@ -2,6 +2,7 @@ > #define __DW_FLTKVIEWBASE_HH__ > > #include <fltk/Group.h> > +#include <fltk/Image.h> > #include <fltk/Scrollbar.h> > > #include "fltkcore.hh" > @@ -15,6 +16,7 @@ private: > private: > int bgColor; > core::Region drawRegion; > + static ::fltk::Image *backBuffer; > > void drawChildWidgets (); >

April 5, 2008

patch: FltkViewport::adjustScrollbarValues()

by Johannes.Hofmann＠gmx.de

On Sat, Apr 05, 2008 at 12:55:00PM -0400, Jorge Arellano Cid wrote: > On Fri, Apr 04, 2008 at 06:58:40PM +0000, corvid wrote: > > You know how the edges of pages like to hide under the scrollbars? > > Yes, I do! > > > This makes them stop doing that. > > Committed. Great, nice fix! Johannes

April 5, 2008

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

by jcid＠dillo.org

On Sat, Apr 05, 2008 at 11:58:45AM +0200, Johannes Hofmann wrote: > > [...] > > jcid@d620:~/C/Dillo/d2/dillo2-cur/src$ ./dillo-fltk /tmp/ > > dillo_dns_init: Here we go! (threaded) > > Enabling cookies as from cookiesrc... > > Nav_open_url: new url='file:/tmp/' > > Nav_open_url: old_url='' idx=-1 > > [file dpi]: dpip_tag={<cmd='open_url' url='file:/tmp/' '>} > > adjustScrollPos: scrollX=0 scrollY=-155 > > ^^^^--- here! > > > > Note: my /tmp is shorter than the viewport. > > > > Please give it a look. > > Funny, I had a similar effect in fltkviewport.cc some time ago. The > problem becomes more obvious, when adding another printf at the > beginning of adjustScrollPos (). Then we get: > > Nav_open_url: new url='file:/tmp/hu' > Nav_open_url: old_url='' idx=-1 > [file dpi]: dpip_tag={<cmd='open_url' url='file:/tmp/hu' '>} > adjustScrollPos: scrollX=0 scrollY=0 > adjustScrollPos: scrollX=0 scrollY=-376 > > So its adjustScrollPos() itself that makes scrollY negative! > The fix is to do the checks the other way round and not to use > "else if" (see attached patch). Good it wasn't a complex side effect. Committed. > 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. I'll check it. > PS: I hope the patch format is ok like this. I'm using mercurial and > the builtin diff may behave a bit differently than standard diff. I like "diff -pru", because of the context, and the explicit stating of the function where the changes happen. Mercurial seems to provide both (as in your attached patch). > Do you prefer inline or attached patches? Attached. -- Cheers Jorge.-

April 5, 2008

patch: FltkViewport::adjustScrollbarValues()

by jcid＠dillo.org

On Fri, Apr 04, 2008 at 06:58:40PM +0000, corvid wrote: > You know how the edges of pages like to hide under the scrollbars? Yes, I do! > This makes them stop doing that. Committed. -- Cheers Jorge.-

April 5, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi, I stumbled across this post on fltk.bugs: http://fltk.org/newsgroups.php?s5281+gfltk.bugs+v5290+T0 This is great for us, as it allows us to implement efficient double buffering without X11 specific hacks. Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test. Cheers, Johannes

April 5, 2008

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

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Apr 03, 2008 at 06:16:03PM -0400, Jorge Arellano Cid wrote: > Hi, > > On Fri, Mar 28, 2008 at 05:08:01PM +0000, Jeremy Henty wrote: > > On Fri, Mar 28, 2008 at 09:57:10AM -0400, Jorge Arellano Cid wrote: > > > > > > On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > > > > > > > If the page contains a meta tag that changes the Content-Type then > > > > Dillo re-opens the URL. This calls Layout::removeWidget(), which > > > > in turn calls Layout::setAnchor(NULL). Ouch! If the URL > > > > contained a fragment then the anchor is lost. Worse, the anchor > > > > doesn't get restored because the URL is flagged as "just > > > > reloading" before it is reopened. The result is that the anchor > > > > mysteriously stops working. > > > > > > > > Commenting out the call to Layout::setAnchor(NULL) in > > > > Layout::removeWidget() fixes the bug and doesn't seem to break > > > > anything else, but I'm not convinced it's the right thing to do. > > > > > > In fact, repush is an after thought, and some parts of nav also > > > need some re-work. The API, IIRC pushing #fragment URLs to the stack > > > has some anomalies too. It'd be good to find/design a single path to > > > handle it (experience shows multiple paths is asking for trouble :). > > > I've looked at it and it seems like deep analysis is required. > > > > Thanks for explaining this. I'll keep running with > > Layout::setAnchor(NULL) commented out for the moment and see how it > > goes. (Still no breakage yet.) I hope to be able to spend time > > looking at this further. If I have any thoughts about a good way to > > do all this I will post them. Unfortunately I have had to devote more > > time to earning a living recently (sigh) so I've spent less time > > looking at Dillo code than I would have liked. > > After a long review of the code, I committed a patch that not only > fixes things in nav.c but in other places which were also involved > in the SEGFAULTs we were getting. Please test it Jeremy. > > Johannes, there's a patch for dw2 too. It involves minor initialization > of scrollX and scrollY, and a printf. If I open dillo with /tmp, a wild > value is got for scrollY: The added initialization is good I think. > > jcid@d620:~/C/Dillo/d2/dillo2-cur/src$ ./dillo-fltk /tmp/ > dillo_dns_init: Here we go! (threaded) > Enabling cookies as from cookiesrc... > Nav_open_url: new url='file:/tmp/' > Nav_open_url: old_url='' idx=-1 > [file dpi]: dpip_tag={<cmd='open_url' url='file:/tmp/' '>} > adjustScrollPos: scrollX=0 scrollY=-155 > ^^^^--- here! > > Note: my /tmp is shorter than the viewport. > > Please give it a look. Funny, I had a similar effect in fltkviewport.cc some time ago. The problem becomes more obvious, when adding another printf at the beginning of adjustScrollPos (). Then we get: Nav_open_url: new url='file:/tmp/hu' Nav_open_url: old_url='' idx=-1 [file dpi]: dpip_tag={<cmd='open_url' url='file:/tmp/hu' '>} adjustScrollPos: scrollX=0 scrollY=0 adjustScrollPos: scrollX=0 scrollY=-376 So its adjustScrollPos() itself that makes scrollY negative! The fix is to do the checks the other way round and not to use "else if" (see attached patch). 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. Cheers, Johannes PS: I hope the patch format is ok like this. I'm using mercurial and the builtin diff may behave a bit differently than standard diff. Do you prefer inline or attached patches?

April 5, 2008

patch: FltkViewport::adjustScrollbarValues()

by corvid＠lavabit.com

You know how the edges of pages like to hide under the scrollbars? This makes them stop doing that.

April 4, 2008

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

by onepoint＠starurchin.org

On Thu, Apr 03, 2008 at 06:16:03PM -0400, Jorge Arellano Cid wrote: > On Fri, Mar 28, 2008 at 05:08:01PM +0000, Jeremy Henty wrote: > > On Fri, Mar 28, 2008 at 09:57:10AM -0400, Jorge Arellano Cid wrote: > > > On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > > > > > > > If the page contains a meta tag that changes the Content-Type > > > > then Dillo re-opens the URL. This calls > > > > Layout::removeWidget(), which in turn calls > > > > Layout::setAnchor(NULL). Ouch! If the URL contained a > > > > fragment then the anchor is lost. Worse, the anchor doesn't > > > > get restored because the URL is flagged as "just reloading" > > > > before it is reopened. The result is that the anchor > > > > mysteriously stops working. > > After a long review of the code, I committed a patch that not only > fixes things in nav.c but in other places which were also involved > in the SEGFAULTs we were getting. Please test it Jeremy. Done. This fixes the anchor-breaking bug that I reported above. No regressions that I can see. Yay! Regards, Jeremy Henty -- If you aren't sure whether you can do this, just try it. The worst thing that can happen is that your computer could explode. -- The GIMP User Manual

April 4, 2008

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

by jcid＠dillo.org

Hi, On Fri, Mar 28, 2008 at 05:08:01PM +0000, Jeremy Henty wrote: > On Fri, Mar 28, 2008 at 09:57:10AM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > > > > > If the page contains a meta tag that changes the Content-Type then > > > Dillo re-opens the URL. This calls Layout::removeWidget(), which > > > in turn calls Layout::setAnchor(NULL). Ouch! If the URL > > > contained a fragment then the anchor is lost. Worse, the anchor > > > doesn't get restored because the URL is flagged as "just > > > reloading" before it is reopened. The result is that the anchor > > > mysteriously stops working. > > > > > > Commenting out the call to Layout::setAnchor(NULL) in > > > Layout::removeWidget() fixes the bug and doesn't seem to break > > > anything else, but I'm not convinced it's the right thing to do. > > > > In fact, repush is an after thought, and some parts of nav also > > need some re-work. The API, IIRC pushing #fragment URLs to the stack > > has some anomalies too. It'd be good to find/design a single path to > > handle it (experience shows multiple paths is asking for trouble :). > > I've looked at it and it seems like deep analysis is required. > > Thanks for explaining this. I'll keep running with > Layout::setAnchor(NULL) commented out for the moment and see how it > goes. (Still no breakage yet.) I hope to be able to spend time > looking at this further. If I have any thoughts about a good way to > do all this I will post them. Unfortunately I have had to devote more > time to earning a living recently (sigh) so I've spent less time > looking at Dillo code than I would have liked. After a long review of the code, I committed a patch that not only fixes things in nav.c but in other places which were also involved in the SEGFAULTs we were getting. Please test it Jeremy. Johannes, there's a patch for dw2 too. It involves minor initialization of scrollX and scrollY, and a printf. If I open dillo with /tmp, a wild value is got for scrollY: jcid@d620:~/C/Dillo/d2/dillo2-cur/src$ ./dillo-fltk /tmp/ dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='file:/tmp/' Nav_open_url: old_url='' idx=-1 [file dpi]: dpip_tag={<cmd='open_url' url='file:/tmp/' '>} adjustScrollPos: scrollX=0 scrollY=-155 ^^^^--- here! Note: my /tmp is shorter than the viewport. Please give it a look. -- Cheers Jorge.-

April 4, 2008

patch names

by jcid＠dillo.org

Hi, Please submit your patches in this format: diff -pru dillo2 dillo2-cur > Patch-Name-Here.dillo2 diff -pru dw2 dw2-cur > Patch-Name-Here.dw2 -- Cheers Jorge.-

April 2, 2008

popup menus

by jcid＠dillo.org

Hi, On Tue, Apr 01, 2008 at 06:46:34PM +0200, Johannes Hofmann wrote: > Hello, > > On Tue, Apr 01, 2008 at 03:41:29AM +0000, corvid wrote: > > I wrote: > > > I wrote: > > > > Does anybody remember whether the add() call was for > > > > some reason that I haven't noticed? > > I don't think it is necessary as long as Group::current() is NULL > (no begin() without end ()). > Otherwise the popup menu would be added to Group::current() - > whatever that is. I may have added it long ago to "make it work". > > > Hmm. > > > On my various (generally quite simple) pages, it works fine with > > > images or tables or lists or whatever. > > > On some pages out in the wider world, though, it gets > > > really confused. > > > I had thought fltk was getting a mouse event and just going > > > up the fltk widget tree to figure out x,y. That is, just > > > Main -> UI. I guess not. > > > > This makes my problem go away: > > > > diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc > > --- dw2/dw/fltkui.cc 2008-02-05 03:14:22.000000000 +0000 > > +++ dw2-cur/dw/fltkui.cc 2008-04-01 03:24:56.000000000 +0000 > > @@ -972,6 +972,7 @@ template <class I> void FltkSelectionRes > > } > > widgetStack->widget->set_item (pos, widgetStack->stack->size ()); > > } > > + widgetStack->stack->getTop()->getTypedValue()->end (); > > } > > } > > > > Jeremy, does that seem all right? > > Yes, that is right! I would go even further and remove all begin() > calls. They are evil - at least if the matching end () is not > immediately following. > In your case the unmatched end () caused the popup menu to become a > child of some Select-widget that happened to be on the page! From some time Johannes has been warning us about begin-end pairs. I agree with him, they bring side effects (just as the above mentioned one), so removing them favouring explicit add() calls is preferred. Unless they cleanly match each other in the same function, without calling other widget-constructing functions in the middle. > I would propose the attached patch to fltkui.cc that replaces all > begin () calls with direct add () calls. Committed. > Then your proposed removal of the ((Group *)bw->ui)->add(pm) calls > (also attached) seems to work fine. It also makes the annoying > redraws when opening a popup menu go away! Committed. -- Cheers Jorge.-

April 2, 2008

popup menus

by Johannes.Hofmann＠gmx.de

On Tue, Apr 01, 2008 at 06:06:38PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Apr 01, 2008 at 03:41:29AM +0000, corvid wrote: > > > I wrote: > > > > I wrote: > > > > > Does anybody remember whether the add() call was for > > > > > some reason that I haven't noticed? > > > > I don't think it is necessary as long as Group::current() is NULL > > (no begin() without end ()). > > Otherwise the popup menu would be added to Group::current() - > > whatever that is. > > I see that Group.h says > > void end() {current_ = (Group*)parent();} > > so I wonder whether there are still enough begins() and end()s > around that some end() is just setting current to Main for us. No, current_ seems to be NULL now and thereby parent_ of the popup widget is NULL too. But that does not seem to do any harm. (gdb) b menu.cc:263 Breakpoint 1 at 0x806b7bb: file menu.cc, line 263. (gdb) r Starting program: /home/hofmann/projects/dillo/plain/dillo2-hg/src/dillo-fltk dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Fontconfig error: "~/.fonts.conf", line 8: junk after document element Nav_open_url: new url='about:splash' [Switching to process 48228, thread 0x28569000] Breakpoint 1, a_Menu_page_popup (bw=0x285a0a00, url=0x28697580, bugs_txt=0x0, prefs_load_images=1) at menu.cc:266 266 if (bugs_txt == NULL) (gdb) p pm $1 = (class fltk::PopupMenu *) 0x286ec500 (gdb) p *pm $2 = {<fltk::Menu> = {<fltk::Group> = {<fltk::Widget> = {<fltk::Rectangle> = {x_ = 0, y_ = 0, w_ = 0, h_ = 0}, _vptr$Widget = 0x8111440, static default_style = 0x8132fa0, static default_glyph = 0x8130954, label_ = 0x8105d8e "&PAGE OPTIONS", image_ = 0x0, flags_ = 262160, style_ = 0x8131f20, callback_ = 0x80b9778 <fltk::Menu::default_callback(fltk::Widget*, void*)>, user_data_ = 0x0, tooltip_ = 0x0, parent_ = 0x0, type_ = 231 '?', damage_ = 128 '\200', layout_damage_ = 128 '\200', when_ = 4 '\004'}, initial_w = 0, initial_h = 0, children_ = 9, focus_index_ = -1, array_ = 0x287f8600, resizable_ = 0x0, resize_align_ = 15, sizes_ = 0x0, static current_ = 0x0}, static default_style = 0x8131ca0, list_ = 0x8131cfc, item_ = 0x0}, static default_style = 0x8131f20} Cheers, Johannes

April 1, 2008

popup menus

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 01, 2008 at 03:41:29AM +0000, corvid wrote: > > I wrote: > > > I wrote: > > > > Does anybody remember whether the add() call was for > > > > some reason that I haven't noticed? > > I don't think it is necessary as long as Group::current() is NULL > (no begin() without end ()). > Otherwise the popup menu would be added to Group::current() - > whatever that is. I see that Group.h says void end() {current_ = (Group*)parent();} so I wonder whether there are still enough begins() and end()s around that some end() is just setting current to Main for us.

April 1, 2008

popup menus

by Johannes.Hofmann＠gmx.de

Hello, On Tue, Apr 01, 2008 at 03:41:29AM +0000, corvid wrote: > I wrote: > > I wrote: > > > Does anybody remember whether the add() call was for > > > some reason that I haven't noticed? I don't think it is necessary as long as Group::current() is NULL (no begin() without end ()). Otherwise the popup menu would be added to Group::current() - whatever that is. > > > > Hmm. > > On my various (generally quite simple) pages, it works fine with > > images or tables or lists or whatever. > > On some pages out in the wider world, though, it gets > > really confused. > > I had thought fltk was getting a mouse event and just going > > up the fltk widget tree to figure out x,y. That is, just > > Main -> UI. I guess not. > > This makes my problem go away: > > diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc > --- dw2/dw/fltkui.cc 2008-02-05 03:14:22.000000000 +0000 > +++ dw2-cur/dw/fltkui.cc 2008-04-01 03:24:56.000000000 +0000 > @@ -972,6 +972,7 @@ template <class I> void FltkSelectionRes > } > widgetStack->widget->set_item (pos, widgetStack->stack->size ()); > } > + widgetStack->stack->getTop()->getTypedValue()->end (); > } > } > > Jeremy, does that seem all right? Yes, that is right! I would go even further and remove all begin() calls. They are evil - at least if the matching end () is not immediately following. In your case the unmatched end () caused the popup menu to become a child of some Select-widget that happened to be on the page! I would propose the attached patch to fltkui.cc that replaces all begin () calls with direct add () calls. Then your proposed removal of the ((Group *)bw->ui)->add(pm) calls (also attached) seems to work fine. It also makes the annoying redraws when opening a popup menu go away! Thanks for your work on this, Johannes > This is yet another case of me not knowing the code at all. > It sure takes a lot of code to construct a web browser... > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 1, 2008

popup menus

by corvid＠lavabit.com

I wrote: > I wrote: > > Does anybody remember whether the add() call was for > > some reason that I haven't noticed? > > Hmm. > On my various (generally quite simple) pages, it works fine with > images or tables or lists or whatever. > On some pages out in the wider world, though, it gets > really confused. > I had thought fltk was getting a mouse event and just going > up the fltk widget tree to figure out x,y. That is, just > Main -> UI. I guess not. This makes my problem go away: diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2/dw/fltkui.cc 2008-02-05 03:14:22.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2008-04-01 03:24:56.000000000 +0000 @@ -972,6 +972,7 @@ template <class I> void FltkSelectionRes } widgetStack->widget->set_item (pos, widgetStack->stack->size ()); } + widgetStack->stack->getTop()->getTypedValue()->end (); } } Jeremy, does that seem all right? This is yet another case of me not knowing the code at all. It sure takes a lot of code to construct a web browser...

April 1, 2008

popup menus

by corvid＠lavabit.com

I wrote: > Does anybody remember whether the add() call was for > some reason that I haven't noticed? Hmm. On my various (generally quite simple) pages, it works fine with images or tables or lists or whatever. On some pages out in the wider world, though, it gets really confused. I had thought fltk was getting a mouse event and just going up the fltk widget tree to figure out x,y. That is, just Main -> UI. I guess not.

April 1, 2008

(place->corvid) popup menus

by corvid＠lavabit.com

Got back to looking at why popup menus are offset by the height of the control panel, and // Make the popup a child of the calling UI object ((Group *)bw->ui)->add(pm); caught my eye. I thought perhaps if I made them children of Main instead, they would work. But first I tried commenting it out completely -- and now everything seems to work fine. The popups even remember the previous item chosen, which would allow the removal of click-to-load for images. Does anybody remember whether the add() call was for some reason that I haven't noticed? (Jorge cleared the moderation bit for me, so I think you will get this mail!)

March 31, 2008

From the BLFS project: [theoldfellow@gmail.com: Dillo - going, going....]

by onepoint＠starurchin.org

The Beyond Linux From Scratch project is removing Dillo Classic because they don't want to list unsupported GTK1 applications (in fact they are looking to ditch GTK1 completely). They seem pretty keen on Dillo-FLTK though! Jeremy Henty ----- Forwarded message from TheOldFellow <theoldfellow(a)gmail.com> ----- From: TheOldFellow <theoldfellow(a)gmail.com> To: blfs-dev(a)linuxfromscratch.org Subject: Dillo - going, going.... Date: Mon, 31 Mar 2008 11:14:42 +0100 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.1 Well no one screamed that it was their favourite web browser, so I'll comment it out of the book later today. As an aside, I built Dillo2, still very alpha, with FLTK2, in Beta. The result is quite good. Lightning fast, and some nice features as a browser to build first and read BLFS with while you build the GTK2 and Firefox ziggurat. I'll put a wiki page together for it later too. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page ----- End forwarded message -----

March 31, 2008

[patch] scroll cleanup

by jcid＠dillo.org

On Sun, Mar 30, 2008 at 09:24:20PM +0000, place wrote: > Johannes wrote: > > I hope I have not reintroduced the widget scrolling bug place has > > just fixed. Can you verify this? > > It works! Committed. -- Cheers Jorge.-

March 31, 2008

[patch] scroll cleanup

by place＠gobigwest.com

Johannes wrote: > I hope I have not reintroduced the widget scrolling bug place has > just fixed. Can you verify this? It works!

March 30, 2008

[patch] scroll cleanup

by Johannes.Hofmann＠gmx.de

Hello, as promised here comes my attempt to cleanup the scrolling code a bit. scrollTo () is now the real method and scroll () is just a helper. I think that is more natural than the other way round. I also moved the call to updateCanvasWidgets () out of the draw () method again as I think draw () should not modify things if possible. I hope I have not reintroduced the widget scrolling bug place has just fixed. Can you verify this? Cheers, Johannes

March 30, 2008

Re: patch: Cookies_parse_one()

by jcid＠dillo.org

On Thu, Mar 27, 2008 at 05:27:18PM +0000, place wrote: > I had to turn on cookies to try something, and the very first cookie I > saw threw the dpi into an infinite loop. > "TRK%5FLastLoginID=; expires=Fri, 27-Mar-2009 04:00:00 GMT; path=/" > > Instead of returning immediately on error, it eats its broken cookie up now. > And I added some dFree(attr)s. Good, thanks for the fixes; it's much simpler to debug functions that have a single return point. Committed. > > Oh, and the "catched" in Cookies_parse_string() should be "caught". > Should've put that in the patch, but I forgot. Committed. -- Cheers Jorge.-

March 29, 2008

Re: a_Url_cmp()

by jcid＠dillo.org

On Sat, Mar 29, 2008 at 04:25:42AM +0000, place wrote: > 1. I happened to run into a preexisting bug in a_Url_cmp(). > > I hooked up the dialog code as the others had done for https, and the > first URL I tried was a redirect that goes > http://something -> https://something. The urls are identical except for > the scheme. It broke because a_Url_cmp() has > > (st = URL_STR_FIELD_I_CMP(A->scheme, B->scheme) == 0))) > instead of > (st = URL_STR_FIELD_I_CMP(A->scheme, B->scheme)) == 0)) Committed. > 2. The mail I tried to send some days back from my new account(*) also > happened to be about a_Url_cmp(). When I was playing with file inputs, > I generated the URL file:///something, with file:/something already in > cache. Cache did not find it because the authority of one was NULL and > the authority of the other was "". URL_STR_FIELD_I_CMP thinks those are > different things. Which is possible. Knowing how weird the URL spec gets, > the code might reflect a genuine difference, but sounds more like an error. Yes, current URL handling follows the spec. The problem is that the rest of dillo is using URLs like file:/something freely, when they should be file:///something. It should be easy to switch the file server dpi to generate "file:///"-prefixed URLS, and the input location to also normalize file:/ prefixed ones. But, if they appear in an external html page, it may be better to make the URL code normalize it (or check what other browsers do). > That I should run into these two issues at the very same time that I'm > trying to change a_Url_cmp() for url->data is a strange coincidence. Peer reviewing is always an asset. > > * And it receives list mail just fine. Andreas seemed to think that > as long as I'm subscribed, I shouldn't have any moderation problems. > Strange. Out of my control, anyway. I gave a look at the list settings. Please let me know your new email address to find whether I can do something to enable it. BTW, with the new patch for "missing widgets", when I first went to http://lists.auriga.wearlab.de/cgi-bin/mailman/admin/dillo-dev the Password input widget was missing! (it worked the next tries). -- Cheers Jorge.-

March 29, 2008

patch: widget scrolling

by jcid＠dillo.org

On Fri, Mar 28, 2008 at 08:56:36PM +0000, place wrote: > > > Johannes, are there any unintended consequences to this fix? > > > > Your patch seems correct, but I'd like to cleanup the scrolling code > > a bit more. Anyway, I have no objections to commit this for now. > > Cool. Thanks! Committed. -- Cheers Jorge.-

March 29, 2008

patch: URL data as a Dstr

by jcid＠dillo.org

Hi, On Wed, Mar 26, 2008 at 05:15:49PM +0000, place wrote: > This is part one in a series for file inputs. > Parts two and three are written. Parts four and five > are contemplated. Maybe a part six if I feel like it. > Part three is the one that makes it at least appear to > work, though I'll need help in testing at that point. Committed with some changes: capi.c: made it test using flags for both POST & GET. url.c : made a_Url_set_data's second parameter a Dstr**. url.c, dlib.c: changed Url_dstr_cmp for Dstr_cmp. changed the implementation too. dlib.c: made dStr_sized_new allocate sz+1 bytes (to avoid a realloc). Please check them, because I've done little testing. > HTTPS note: > If https does remain a dpi, somebody will have to decide what they want > to do with Capi_dpi_build_cmd() if http_query can contain NULLs. OK. -- Cheers Jorge.-

March 29, 2008

patch: widget scrolling

by place＠gobigwest.com

> > Johannes, are there any unintended consequences to this fix? > > Your patch seems correct, but I'd like to cleanup the scrolling code > a bit more. Anyway, I have no objections to commit this for now. Cool. Thanks!

March 28, 2008

patch: widget scrolling

by Johannes.Hofmann＠gmx.de

On Fri, Mar 28, 2008 at 05:14:48PM +0000, place wrote: > I've had lots of trouble with widgets disappearing because my > machine is too slow to keep up. But today I had the good fortune > to happen to stumble upon updateCanvasWidgets()... Excellent that you have found this bug. I had seen this problem once using dillo via remote X11 but could not reproduce it at home. > > Johannes, are there any unintended consequences to this fix? > Your patch seems correct, but I'd like to cleanup the scrolling code a bit more. Anyway, I have no objections to commit this for now. Cheers, Johannes > diff -pur dw2/dw/fltkviewport.cc dw2-cur/dw/fltkviewport.cc > --- dw2/dw/fltkviewport.cc 2008-02-29 18:26:27.000000000 +0000 > +++ dw2-cur/dw/fltkviewport.cc 2008-03-28 16:55:57.000000000 +0000 > @@ -186,6 +186,7 @@ void FltkViewport::draw () > > if (d & DAMAGE_SCROLL) { > set_damage (DAMAGE_SCROLL); > + updateCanvasWidgets (scrollDX, scrollDY); > scrollrect(cr, -scrollDX, -scrollDY, draw_area, this); > d &= ~DAMAGE_SCROLL; > set_damage (d); > @@ -377,7 +378,6 @@ void FltkViewport::scroll (int dx, int d > > adjustScrollbarValues (); > redraw (DAMAGE_SCROLL); > - updateCanvasWidgets (oldScrollX, oldScrollY); > theLayout->scrollPosChanged (this, scrollX, scrollY); > } > > @@ -400,16 +400,16 @@ void FltkViewport::setViewportSize (int > vscrollbar->hide (); > } > > -void FltkViewport::updateCanvasWidgets (int oldScrollX, int oldScrollY) > +void FltkViewport::updateCanvasWidgets (int dx, int dy) > { > for(Iterator <TypedPointer < ::fltk::Widget> > it > = canvasWidgets->iterator (); > it.hasNext (); ) { > ::fltk::Widget *widget = it.getNext()->getTypedValue (); > - if (oldScrollX != scrollX) > - widget->x (widget->x () - scrollX + oldScrollX); > - if (oldScrollY != scrollY) > - widget->y (widget->y () - scrollY + oldScrollY); > + if (dx) > + widget->x (widget->x () - dx); > + if (dy) > + widget->y (widget->y () - dy); > } > } > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 28, 2008

patch: widget scrolling

by place＠gobigwest.com

I've had lots of trouble with widgets disappearing because my machine is too slow to keep up. But today I had the good fortune to happen to stumble upon updateCanvasWidgets()... Johannes, are there any unintended consequences to this fix?

March 28, 2008

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

by onepoint＠starurchin.org

On Fri, Mar 28, 2008 at 09:57:10AM -0400, Jorge Arellano Cid wrote: > > On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > > > If the page contains a meta tag that changes the Content-Type then > > Dillo re-opens the URL. This calls Layout::removeWidget(), which > > in turn calls Layout::setAnchor(NULL). Ouch! If the URL > > contained a fragment then the anchor is lost. Worse, the anchor > > doesn't get restored because the URL is flagged as "just > > reloading" before it is reopened. The result is that the anchor > > mysteriously stops working. > > > > Commenting out the call to Layout::setAnchor(NULL) in > > Layout::removeWidget() fixes the bug and doesn't seem to break > > anything else, but I'm not convinced it's the right thing to do. > > In fact, repush is an after thought, and some parts of nav also > need some re-work. The API, IIRC pushing #fragment URLs to the stack > has some anomalies too. It'd be good to find/design a single path to > handle it (experience shows multiple paths is asking for trouble :). > I've looked at it and it seems like deep analysis is required. Thanks for explaining this. I'll keep running with Layout::setAnchor(NULL) commented out for the moment and see how it goes. (Still no breakage yet.) I hope to be able to spend time looking at this further. If I have any thoughts about a good way to do all this I will post them. Unfortunately I have had to devote more time to earning a living recently (sigh) so I've spent less time looking at Dillo code than I would have liked. Regards, Jeremy Henty

March 28, 2008

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

by jcid＠dillo.org

Hi Jeremy, On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > OK, I've figured out the problem and (as usual) my first thoughts were > completely wrong. I'm not sure what the fix is, though. > > If the page contains a meta tag that changes the Content-Type then > Dillo re-opens the URL. This calls Layout::removeWidget(), which in > turn calls Layout::setAnchor(NULL). Ouch! If the URL contained a > fragment then the anchor is lost. Worse, the anchor doesn't get > restored because the URL is flagged as "just reloading" before it is > reopened. The result is that the anchor mysteriously stops working. > > Commenting out the call to Layout::setAnchor(NULL) in > Layout::removeWidget() fixes the bug and doesn't seem to break > anything else, but I'm not convinced it's the right thing to do. If > it's not then I don't know what is: I already tried tweaking things so > that the reload goes down the same code path as the initial load, but > that just caused crashes everywhere. > > I'd really like to fix this as it regularly breaks pages for me, but I > don't know the code well enough to sure I've got it right. Thanks for all the information. In fact, repush is an after thought, and some parts of nav also need some re-work. The API, IIRC pushing #fragment URLs to the stack has some anomalies too. It'd be good to find/design a single path to handle it (experience shows multiple paths is asking for trouble :). I've looked at it and it seems like deep analysis is required. I'm reviewing a few patches now. I'll work on it again when I find some time. -- Cheers Jorge.-

March 28, 2008

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

by onepoint＠starurchin.org

OK, I've figured out the problem and (as usual) my first thoughts were completely wrong. I'm not sure what the fix is, though. If the page contains a meta tag that changes the Content-Type then Dillo re-opens the URL. This calls Layout::removeWidget(), which in turn calls Layout::setAnchor(NULL). Ouch! If the URL contained a fragment then the anchor is lost. Worse, the anchor doesn't get restored because the URL is flagged as "just reloading" before it is reopened. The result is that the anchor mysteriously stops working. Commenting out the call to Layout::setAnchor(NULL) in Layout::removeWidget() fixes the bug and doesn't seem to break anything else, but I'm not convinced it's the right thing to do. If it's not then I don't know what is: I already tried tweaking things so that the reload goes down the same code path as the initial load, but that just caused crashes everywhere. I'd really like to fix this as it regularly breaks pages for me, but I don't know the code well enough to sure I've got it right. Jeremy Henty

March 26, 2008

ComplexButton crashing

by place＠gobigwest.com

Johannes wrote: > Ahh, now I understand. layout is a new layout specific to the > button. It is created in ComplexButton::init (). > So the purpose of ComplexButton is to create buttons that can have arbitrary > HTML rendered on them. > > I wonder if we really need to duplicate the button code from fltk > for this. > > For now I think your fix is good. Perhaps we can make the whole > stuff simpler in the future. > > Did you already manage to add an dw::Image to a ComplexButton? Yes. The two problems that remained were: Small images were only visible when the control panel was not visible. The recurring problem of dw's idea of offsets being different than that of fltk. And big images were usually (but not always -- some timing thing) offset inside their buttons by an amount that seemed to depend on the size of the alt text.

March 26, 2008