Jorge wrote:

On Thu, Oct 18, 2007 at 10:56:39PM +0000, place wrote:

...

...

The fact of the linkblock not being freed in current code (see warning from compiling html.cc) is just because I haven't found the clean & proper place to hook Html_lb_free() (to widget destruction probably). IIRC there was a ...connect_after() hook in GTK that worked ok after deletion of the object (which I haven't yet found an analog in FLTK2).

So I should regard "linkblock" as "the bag of event handling stuff"? Okay.

It's a bag for links, form data etc...

I've longed to get rid of it several times, but I don't see a much cleaner approach. This may be the time, or maybe not.

For instance, if the linkblock data is put inside the html struct, and the whole turned into a class, it would look much cleaner. It would also be clearer in the case of plain text (it also receives the signal for page menu), and having a separate linkblock or receiver for it seems odd.

OTOH, the data that now belongs to the html-struct is freed when parsing finishes, and it would remain inside the class, which is a bit untidy, but if we make this part a pointer inside the shiny new class, it could go NULL at freeing time. This looks cleaner.

Indeed.

...

I now have new code for image signals. In an effort not to add an extra argument to the signals (which seemed hacky -- either an image_vs_link sort of argument, or an image_number sort of argument), I ended up making a vector of image receivers, one per image. I can't decide whether that is bad or reasonably sensible. If a better solution is obvious to you, please let me know.

Not obvious, but I think of the case of pages with hundreds or thousands of images (e.g.):

http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/A...

Memory consumption for this vector may grow too much. A single int value working as an index to the proper URL/data from within a single image signal receiver looks cleaner (from a distance :-)

All right.

...

So the image menu works, an ugly little button toggles image loading, and click-to-load works, though I don't have any placeholder image.

More than enough for a start!

And an opportunity for people who say "I'd love to help dillo, but don't know how to write code" to make a little tiny button... I was going to try having a single patch for all of that, but it was already teetering on the edge between small-enough and too-much. I think I'll try to pull out the menu and the button to send you first, since they're harmless, and then the rest after I redo it.

...

(if only forms worked well enough to perform search queries, I just about wouldn't need my old dillo around anymore!)

I know what you mean. Given that, plus the scrolling bug, search text inside pages and anchors, it'd looks very sexy to me!

...

BTW, not that it really matters at present, but I discovered that in Html_write_raw(), you can get token_start to be greater than bufsize. Go through the verbatim part at the top until token_start = buf_index = bufsize, then have the isspace() test right below it be true. It looks like this is why my iconv buffer code crashed often on me.

Thanks for the report, I'll look at it when I find some time.

BTW, this duscussion is more than worth to have in dillo-dev. Can I take it there?

*cc:s dillo-dev, resists urge to trim quotes*