December 2008 - Dillo-dev - lists.mailman3.com

[patch]: refactor Auth_parse_auth_basic()

by onepoint＠starurchin.org

This patch implements a previous suggestion to break up Auth_parse_auth_basic() into smaller functions and eliminate gotos. Please comment. Jeremy Henty

Dec. 29, 2008

patch: Accept-Language header

by furaisanjin＠gmail.com

Hi, I like this patch because google works better for none English with accept language header. Regards, furaisanjin

Dec. 29, 2008

patch: Accept-Language header

by corvid＠lavabit.com

For people who don't want to always get language-of-place-where-I'm-physically-located.

Dec. 29, 2008

Re: CSS loading part#2

by jcid＠dillo.org

On Sun, Dec 28, 2008 at 05:30:07PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Dec 25, 2008 at 10:43:06AM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > Here I'm attaching the second part of the CSS loading patch. > > > > This one is coherent and works better :-). Please commit after > > > > some testing. > > > > > > > > Note: images are still truncated sometimes, but AFAIS this is a > > > > problem in the dicache, not in CSS loading. I hope to fix this > > > > soon. > > > > > > Well, in fact, images were always truncated when the repush > > > caught them still rendering. > > > > > > I've been working on this for days and yes, it's a problem in > > > the dicache. Unfortunately the cache/dicache/image-decode/image > > > code is so entangled that it needs a rewrite. Quite surprising it > > > works stable "as is". > > > > BTW, what about removing the dicache altogether? Or is anyone using > > use_dicache=YES ? > > fltk-era dillo always behaved like use_dicache=NO, and I took out the > pref some months ago. I wanted to rip out the dicache at one point, > but ran into the entanglement mentioned above. A simple ripping-out > didn't look like it was going to work because something needed to > associate URLs with imgbufs and so on... Exactly. The dicache serves as a link between the image decoder and the image widget. It also provides versioned images. I have progressed a lot and the new code works quite well in my tree. After some assorted testing, there's still a segfault that I want to chase before showing the code. The rest of it works OK. (i.e. CSS with no half images). -- Cheers Jorge.-

Dec. 29, 2008

remove generate_submit pref?

by jcid＠dillo.org

On Fri, Dec 26, 2008 at 05:05:30AM +0000, Jeremy Henty wrote: > On Fri, Dec 26, 2008 at 02:44:52AM +0000, corvid wrote: > > Any objections to getting rid of it? > > No. IIRC that was a code path that got in the way of refactoring > form.cc when I last looked at it, so I wouldn't be surprised if the > code was improved by losing it. A long time ago it served as a workaround for simple javascript-dependent submit buttons. It seems like it's of not much use anymore. AFAIS, we can get rid of it. -- Cheers Jorge.-

Dec. 29, 2008

[patch]: fix dialog callback

by onepoint＠starurchin.org

Dialog_user_password_cb() should not use VOIDP2INT, because the (void *) argument was originally an (int *), not an int or long. This bug makes the dialog always call its callback even when the user presses the Cancel button. As a result it is futile to cancel the Basic Authentication dialog: the page reloads and the dialog pops up again. Patch attached. Jeremy Henty

Dec. 28, 2008

Re: CSS loading part#2

by corvid＠lavabit.com

Johannes wrote: > On Thu, Dec 25, 2008 at 10:43:06AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > Here I'm attaching the second part of the CSS loading patch. > > > This one is coherent and works better :-). Please commit after > > > some testing. > > > > > > Note: images are still truncated sometimes, but AFAIS this is a > > > problem in the dicache, not in CSS loading. I hope to fix this > > > soon. > > > > Well, in fact, images were always truncated when the repush > > caught them still rendering. > > > > I've been working on this for days and yes, it's a problem in > > the dicache. Unfortunately the cache/dicache/image-decode/image > > code is so entangled that it needs a rewrite. Quite surprising it > > works stable "as is". > > BTW, what about removing the dicache altogether? Or is anyone using > use_dicache=YES ? fltk-era dillo always behaved like use_dicache=NO, and I took out the pref some months ago. I wanted to rip out the dicache at one point, but ran into the entanglement mentioned above. A simple ripping-out didn't look like it was going to work because something needed to associate URLs with imgbufs and so on...

Dec. 28, 2008

experimental patch: image error status as alt text

by corvid＠lavabit.com

Johannes wrote: > That reminds me of a related issue. Display of alt text works fine > if width or height of an image is unspecified, but looks weird e.g. > with images that have width=1. > Any idea how to handle that? Should we ignore width/height in case > we are showing the alt text? Perhaps. I'm wondering whether it might distort pages too much, though. And related to _that_, we have the matter of dillo not preserving aspect for images with one dimension specified.

Dec. 28, 2008

Re: CSS loading part#2

by Johannes.Hofmann＠gmx.de

On Thu, Dec 25, 2008 at 10:43:06AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Here I'm attaching the second part of the CSS loading patch. > > This one is coherent and works better :-). Please commit after > > some testing. > > > > Note: images are still truncated sometimes, but AFAIS this is a > > problem in the dicache, not in CSS loading. I hope to fix this > > soon. > > Well, in fact, images were always truncated when the repush > caught them still rendering. > > I've been working on this for days and yes, it's a problem in > the dicache. Unfortunately the cache/dicache/image-decode/image > code is so entangled that it needs a rewrite. Quite surprising it > works stable "as is". BTW, what about removing the dicache altogether? Or is anyone using use_dicache=YES ? > > The idea is to try to devise a single path of execution that > allows handling each image request (repeated or not) as a simple > cache client. It's more complex than it sounds! > > The good news is that after you merge the latest cleanups in > dillo main, the attached patch will more or less make it work as > desired. There'll be some added unstability, and the underlying > mess ;), but it should be a good basis to keep improving CSS > while I work in the image process stream. With the patch below I get frequent crashes like that: Program received signal SIGSEGV, Segmentation fault. a_Image_imgbuf_unref (v_imgbuf=0x0) at image.cc:214 214 ((Imgbuf*)v_imgbuf)->unref(); (gdb) bt #0 a_Image_imgbuf_unref (v_imgbuf=0x0) at image.cc:214 #1 0x0805c63e in Dicache_remove (Url=<value optimized out>, version=<value optimized out>) at dicache.c:190 #2 0x0805a486 in a_Cache_stop_client (Key=63) at cache.c:1268 #3 0x080542fb in a_Bw_stop_clients (bw=0x2860f2c0, flags=3) at bw.c:188 #4 0x08059b4b in Nav_open_url (bw=0x2860f2c0, url=0x2866b1c0, offset=0) at nav.c:231 #5 0x08059e23 in Nav_repush (bw=0x2860f2c0) at nav.c:366 #6 0x08059e46 in Nav_repush_callback (data=0x2860f2c0) at nav.c:373 #7 0x080c3c1d in fltk::wait () #8 0x080c3cad in fltk::run () #9 0x0804f1a0 in main (argc=1, argv=0x4) at dillo.cc:334 (gdb) Cheers, Johannes

Dec. 28, 2008

experimental patch: image error status as alt text

by Johannes.Hofmann＠gmx.de

On Mon, Dec 22, 2008 at 01:19:07AM +0000, corvid wrote: > You know how for image redirections and 404s, nothing at all happens? > User's mind: "I didn't get the image. Dillo must be broken." > > (or the address can't resolve, or content-type doesn't match...) > > So I tried making something recently that shows, > e.g., [404] as the alt text. In this form it's > probably wrong in a design sense because cache > probably isn't allowed to call image, but maybe > it'll prompt some discussion... That reminds me of a related issue. Display of alt text works fine if width or height of an image is unspecified, but looks weird e.g. with images that have width=1. Any idea how to handle that? Should we ignore width/height in case we are showing the alt text? Cheers, Johannes

Dec. 28, 2008