- Dillo-dev - lists.mailman3.com

We have competition!
by onepoint＠starurchin.org Jan. 2, 2009

Jan. 2, 2009

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

4 4

patch: Accept-Language header
by corvid＠lavabit.com Dec. 29, 2008

Dec. 29, 2008

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

2 1

Re: CSS loading part#2
by jcid＠dillo.org Dec. 29, 2008

Dec. 29, 2008

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". 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. -- Cheers Jorge.- _... o_.-"` `\ .--. _ `'-._.-'""-; _ .' \`_\_ {_.-a"a-} _ / \ _/ .-' '. {c-._o_.){\|` | (@`-._ / \{ ^ } \\ _/ `~\ '-._ /'. } \} .-. |>:< '-.__/ '._,} \_/ / ()) | >:< `'---. ____'-.|(`"` \ >:< \\_\\_\ | ; \ \\-{}-\/ \ \ '._\\' /) '. /( `-._ _____ _ _____ __.'\ \ / \ / \ / \ \ \ jgs _.'/^\'._.'/^\'._.'/^\'.__) \ ,==' `---` '---' '---' ) `"""""""""""""""""""""""""""""""`

3 3

remove generate_submit pref?
by corvid＠lavabit.com Dec. 29, 2008

Dec. 29, 2008

Any objections to getting rid of it? dillorc: # Some forms lack a submit button, and dillo can generate a custom one # internally. Unfortunately there's no guarantee for it to work. :( # (my experience is that forms that lack a submit rely on Javascript) #generate_submit=NO

3 2

experimental patch: image error status as alt text
by corvid＠lavabit.com Dec. 28, 2008

Dec. 28, 2008

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... (and maybe it'd be better to pull the status out of the header whenever needed rather than adding more junk to the cache entry.)

2 2

gmail access
by furaisanjin＠gmail.com Dec. 23, 2008

Dec. 23, 2008

Hi all. Now I figure out the way to access gmail but I realize that isn't sophisticated. Anyway what I have modified dillo after all is add "force reload link" feature. This is the step to access gmail 1. Goto gmail.com and login in. 2. You will see meta redirect page so just force reload the link on meta redirect link. However you won't go anywhere yet. 3. Goto mail.google.com/mail, then you find link to simple HTML page. If some of you are interested the patch, I will post. Regards, furaisanjin

1 1

Re: Dillo-dev Digest, Vol 40, Issue 22
by daniel.victoria＠gmail.com Dec. 23, 2008

Dec. 23, 2008

Regarding Gmail access... I'm certanly interested in a patch Thanks Daniel On Tue, Dec 23, 2008 at 9:00 AM, <dillo-dev-request(a)dillo.org> wrote: > Send Dillo-dev mailing list submissions to > dillo-dev(a)dillo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > or, via email, send a message with subject or body 'help' to > dillo-dev-request(a)dillo.org > > You can reach the person managing the list at > dillo-dev-owner(a)dillo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dillo-dev digest..." > > > Today's Topics: > > 1. gmail access (furaisanjin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Dec 2008 09:28:14 +0900 > From: furaisanjin <furaisanjin(a)gmail.com> > Subject: [Dillo-dev] gmail access > To: Dillo-dev(a)dillo.org > Message-ID: > <144aa14b0812221628v71c176b2vf504b5bfe663e5b9(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all. > > Now I figure out the way to access gmail but I realize that isn't sophisticated. > > Anyway what I have modified dillo after all is add "force reload link" feature. > > This is the step to access gmail > 1. Goto gmail.com and login in. > 2. You will see meta redirect page so just force reload the link on > meta redirect link. However you won't go anywhere yet. > 3. Goto mail.google.com/mail, then you find link to simple HTML page. > > If some of you are interested the patch, I will post. > > Regards, > furaisanjin > > > > ------------------------------ > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > End of Dillo-dev Digest, Vol 40, Issue 22 > ***************************************** >

1 0

a little ad blocker
by corvid＠lavabit.com Dec. 22, 2008

Dec. 22, 2008

If you would like one just to play with, well then: http://www.dillo.org/test/adblocker.patch (Blocking * pretty much suffices for me, so I might as well put it there as-is before I become dangerously bored with it.)

1 0

HTTP/1.1 side effect
by jcid＠dillo.org Dec. 21, 2008

Dec. 21, 2008

Hi, @corvid: while debugging the CSS loading patch, I noticed that sometimes dillo doesn't get the close after transfer event. This is needed to trigger the CSS parser with a full sheet. For instance, go to http://localhost:631/ (CUPS interface), and the progress bar will not get inactive after the page is got. Now, if you switch http.c to HTTP/1.0 queries, it will work as expected. Is there something missing, or a way to hook this? -- Cheers Jorge.-

2 1

[patch]: Basic Authentication
by onepoint＠starurchin.org Dec. 21, 2008

Dec. 21, 2008

OK, here it is. Please comment. Some observations: When the cache parses the HTTP header we just attach any authentication headers to the cache entry. Nothing else happens until we process the clients. Just before iterating over the clients we check if all the data is in. If it is then we do any necessary authentication. Opening the authentication dialog runs the FLTK event loop, which means that incoming data can call the cache again, triggering CCC warnings. We work around it by deferring the dialog to a timeout so that the cache finishes iterating over the clients before the dialog appears. This is annoying but I don't see a better way at the moment. The authentication dialog does not know which browser window opened the URL so it can't call a_Nav_reload(). Instead I implemented a_Nav_reload_url(). There's an interesting case when the server demands authentication for a realm that we have already authenticated ourselves to. It could be that we didn't send authentication because we didn't know the path was in the realm, or it could be that the authentication we sent was wrong. This requires the code to deduce what it did last time it saw this URL and rely on what it will do the next time. It works, but it feels fragile to me. I would prefer the URL to explicitly record authentication attempts so that the code doesn't have to second-guess itself. Thoughts? I implemented a full token-value list parser as per the RFC. Maybe this is overkill for Basic authentication, but it will be necessary for Digest authentication. Yes, it has gotos; I began by setting flags but decided that gotos were actually cleaner. Maybe it should be rewritten in state-machine style? If the user opens several pages in a realm in a very short time then it is conceivable that multiple authentication dialogs for the same realm could pop up (just like the https DPI sometimes does with certificate dialogs). I don't address this at the moment because I think it won't be a problem in practice. If it needs fixing then we will have to monitor the list of currently open dialogs to avoid duplicates. Regards, Jeremy Henty

4 8