- Dillo-dev - lists.mailman3.com

[PATCH]: cleanup: comment out DEBUG_MSG in dw2/dw/widget.cc
by onepoint＠starurchin.org Jan. 30, 2008

Jan. 30, 2008

This patch comments out all uses of DEBUG_MSG in widget.cc . The justification is: * Consistency: all other uses of DEBUG_MSG in the DW source are already commented out. * The arguments to DEBUG_MSG use the GTK API, so they would fail to compile if they were ever used. Regards, Jeremy Henty

2 1

Q: "Yes, enough memory!", really?
by onepoint＠starurchin.org Jan. 27, 2008

Jan. 27, 2008

I'm worried about dillo2/src/url.c, line 361: p = str1 = dNew(char, strlen(url_str)); /* Yes, enough memory! */ The code after this line copies url_str to str1 , skipping illegal characters. It seems to me it should allocate one more character for the terminating null character. Does the comment "enough memory" mean that I am missing something, or is it talking about some other issue? Regards, Jeremy Henty

2 2

Work on TABLES
by jcid＠dillo.org Jan. 19, 2008

Jan. 19, 2008

On Sat, Jan 19, 2008 at 07:19:13PM +0000, place wrote: > table.cc is intimidating stuff. > > It works so far, so I don't have much to report, "It works so far" is great news for me, and certainly if it keeps stable better. Good feedback is welcomed! > but I just needed to say > that when I saw per.bak.html, I thought it was going to be something derived > from some article on http://en.wikipedia.org/wiki/Per_Bak instead of being > about, you know, percentages. Percentages is definitely less cool than frozen insulators... -- Cheers Jorge.-

1 0

Re: patch: image.cc typo one-liner
by jcid＠dillo.org Jan. 19, 2008

Jan. 19, 2008

Hi, On Sat, Jan 19, 2008 at 02:47:43AM +0000, place wrote: > It caused stripes along the sides of images with vspace and hspace. > > The line numbers of the patch are off because my image.cc is somewhat > hacked up, but who cares for a one-liner... > > diff -pur dw2/dw/image.cc dw2-cur/dw/image.cc > --- dw2/dw/image.cc 2007-12-24 06:17:14.000000000 +0000 > +++ dw2-cur/dw/image.cc 2008-01-19 02:18:15.000000000 +0000 > @@ -263,7 +263,7 @@ void Image::drawRow (int row) > > buffer->getRowArea (row, &area); > if (area.width && area.height) > - queueDrawArea (area.x + getStyle()->boxOffsetY (), > + queueDrawArea (area.x + getStyle()->boxOffsetX (), > area.y + getStyle()->boxOffsetY (), > area.width, area.height); > } Committed. Now that you're images, would you mind giving a look to these anomalies? http://www.dillo.org/test/img/ 1.- n1 renders a right column with old background (over dialup). 2.- n2 makes space inside the link, not outside, and renders different image size the first time (e.g. when from local harddisk); after back and forward size changes. 3.- n3 is obviously wrong! ;) -- Cheers Jorge.-

2 2

Work on TABLES
by jcid＠dillo.org Jan. 19, 2008

Jan. 19, 2008

Hi there, Good news! It looks like awakening the dragon wasn't a bad idea after all! It took a lot of time and debugging, but now after lots of tests, it seems much better than what we had before. This is not a simple patch, but an algorithms change + bug fixes. Beware that the html documentation is not up-to-date yet though; I prefer to let you test the new code with lots of other cases and to send feedback or bugfixes to the list before adopting the new code. I uploaded a subset of the used test cases to: http://www.dillo.org/test/tables You can start with per1.html, per2.html per3.html & per4.html. Please note that the test is not just rendering the page, but resizing its tables from MIN to MAX. It's interesting to compare what we had before, dillo1 and Firefox (Ill cases follow Firefox's example). So the bottom line is: Test, test, test!!! & send feedback. I'll be back near Jan 30; after enjoying my deserved rest period. ;-) -- Cheers Jorge.- PS: If you want to debug, uncomment table.cc:21 and define dillo_dbg_rendering to 1 in html.cc:64. PS2: I left an exit assert testing d_a and d_w >= 0. If this triggers, please send the URL.

2 1

Working on TABLES
by jcid＠dillo.org Jan. 16, 2008

Jan. 16, 2008

Hi there, As you may remember, I dared to awake the sleeping dragon of table apportion algorithms. Frankly, I don't yet know whether it was a good idea after all, but I have hope. It is impresive how complex the geometric combination of cases grows; hopefully some code will be uploaded before Jan 20. In the meanwhile, does anyone want to give a try to imagemaps? Or maybe to implement tabs? This is much simpler than it looks. Basically we can add the tab widgets and to switch the navigation stack and rendered page upon click. As dillo is quick to render this has the advantage of low memory consumption because we don't need to have all the rendered pages in memory! And it opens the possibility of multiple windows with TABS using low resources. -- Cheers Jorge.-

1 0

patch: progressive images
by place＠gobigwest.com Jan. 16, 2008

Jan. 16, 2008

(the ones that start out blurry and grow sharper) - Added code for progressive display of, well, progressive jpegs because I was tired of waiting for full download before display. jpeglib uses the word "scan" for each loop through the scanlines of the image, so I did the same. I'm not sure it's a terribly descriptive term, though, at least to me (not a graphics person). Couldn't think of a better word. - Turned out scaled ones didn't work. (And, incidentally, that was frustrating because it took some time to realize that the breaking ones were scaled ever so slightly.) Added some bit clearing to imgbuf code on the dw side so that scaled buffers would continue to copy from root buffers. - Turned out that if there was more than one copy on a page, only the first copy worked. (dillo uses image decoders on the first one and pulls the scanlines out of Dicache for the rest.) More bit clearing and a scan number to help a_Dicache_callback with its copying. - Discovered that interlaced pngs use progressive display, and that they hadn't been working for scaled or for multiple on a page. - Considered looking into animated gifs, but then my good sense prevailed :)

3 3

patch: the http header Content-Type half of charset conversion
by place＠gobigwest.com Jan. 15, 2008

Jan. 15, 2008

Dug out my old patch and ripped out the meta tag stuff, the charset-setting dialog, etc. This much should be unobjectionable. Had good fun searching for things like dillo ??????? and seeing how many sites using windows-1251 or koi8-r worked now with this much of the code. Maybe half. Greek and Hebrew were somewhat less than half. And my fonts don't have enough coverage to make it fun trying Asian sites. Of course it doesn't matter much when everybody who participates here is a native speaker of some latin-1 language... Note that View Source will not show files as converted because the conversion is up in html.cc and View Source uses the cache.

2 3

Report on fltk-2.0.x-r5990
by onepoint＠starurchin.org Jan. 13, 2008

Jan. 13, 2008

I have been running Dillo on top of the latest daily snapshot (fltk-2.0.x-r5990) and seen no problems. Has anyone else tried this? Maybe we should update the recommended FLTK snapshot? NB: fltk-2.0.x-r5990 is not binary compatible with the current recommended snapshot, so if you upgrade you have to rebuild Dillo (and any other FLTK2 applications) or you will get memory corruption. FYI my system is Linux 2.6.23.12-0 , glibc 2.3.4 , gcc 3.4.3 . Jeremy Henty

3 2

patch: multiple-line http headers (and a free bonus Content-Type msg change)
by place＠gobigwest.com Jan. 12, 2008

Jan. 12, 2008

Finally got around to it. Since it's another one of those things I am probably never going to encounter in the outside world, I tested by sticking whitespace into headers sent by file.c. PS I see that this guy has a rant about how the headers can attain an arbitrary degree of horribleness if you really want to go by the letter of the rfc: http://www.and.org/texts/server-http

2 2