On Thu, Mar 30, 2006 at 11:58:17AM -0400, Jorge Arellano Cid wrote: Hi there,
Finally I decided to include a big patch for the MIME type detection and its handling. This is an important change in the way Dillo treats its incoming files (HTTP streams).
Now Dillo uses its detected Content/Type instead of the one sent by the remote server (there's also a bug fix in the detection code).
I confess, I'm with the "no, no, no" crowd.
http://www.software-mirror.com/linuxpackages/Slackware-10.2/ X11/kpacman/kpacman-0.3.3-i486-1ron.tgz
X11/fbpager/fbpager-0.1.4-i486-1awg.tgz is the same, only a bit smaller at 66k.
Try it with dillo <= rc2. It will try to render.
Yes. And it's right to. The content is text/plain, and dillo renders text/plain. After it has rendered, if I want to save it, I can right click and Save page As... and it stores the uncorrupted content. I can then mutter about broken web server admins, but be happy that my client is behaving. (If, for example, it changed the content by "ascii-mode"'ing it before rendering or saving, I'd criticise dillo.) And then I realise that if I want to download something, I should right-click the initial link and Save Link As... and the world is good. Works for all content types, I believe.
I'm a bit surprised nobody complained about this bug before, but I guess with the download support being as crude as it was, it's no wonder only a few people used it. ;-)
I thought the download support was fine. If I wanted to d/l something, right click. Just like in the other graphical browsers I use. (Or copy link location, and paste into a dedicated downloader. Just like in the other browsers I use.) If I wanted to view something, left click. Just like in the other graphical browsers I use. Not much room for confusion, and not much new learning needed. Any chance of a "--unbreak-me" configure option? f -- Francis Daly francis@daoine.org