- Dillo-dev - lists.mailman3.com

We have competition!

by corvid＠lavabit.com

Jeremy wrote: > Hv3 is also supposed to support Javascript through SEE, but the SEE > site is not responding right now so I can't try it out (and comments > suggest that getting it into a source build is broken). Maybe SEE > would be a way to support JavaScript in Dillo? Justus wrote a bit about SEE and others: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005065.html

Jan. 2, 2009

We have competition!

by onepoint＠starurchin.org

Linux Weekly News covers Hv3, a Tcl-based lightweight browser. http://lwn.net/Articles/311823/ They refer to Dillo as "perhaps the best known minimalist browser"! It's worth reading the comments to see what people want to see in a lightweight browser and what they don't miss if it's not there. They certainly appreciate the speed. Hv3 claims to support CSS, but I'm not seeing it: Slashdot and the BBC look almost exactly the same as they do in Dillo. Mind you, I'm running it from the latest CVS and getting plagued with Tcl errors too, so maybe it's just temporarily broken. Hv3 is also supposed to support Javascript through SEE, but the SEE site is not responding right now so I can't try it out (and comments suggest that getting it into a source build is broken). Maybe SEE would be a way to support JavaScript in Dillo? Amyway, it looks like 2009 will be an exciting year for Dillo. Jeremy

Jan. 1, 2009

[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