September 2005 - Dillo-dev - lists.mailman3.com

tabs + frames with .deb

by Christian Holland

The dillo patch from http://teki.jpn.ph/pc/software/index-e.shtml fails sometimes. For me under solaris a core a runtime error occures with the following output: ---------------------------- ** WARNING **: no support enc Bus Error (core dumped) ---------------------------- To avoid the error, insert code from line 432-435 a_I18n_convert_raw() before line 455 a_I18n_convert(). So the return value of iconv_open() is checked and if it is not set do the iconv_open() again with defaults like in a_I18n_convert_raw(): gchar *a_I18n_convert( const gchar* from, const gchar* to, const gchar* buf, gint bufsize) { iconv_t it; gchar *outBuf; gint len; if (!buf) return NULL; if (bufsize == 0) return g_strdup(""); g_return_val_if_fail(from && to, g_strndup(buf, bufsize)); it = iconv_open(to, from); if (!it || it==(iconv_t)-1) { /* <========== start of insertion */ it = iconv_open("ASCII", DILLO_CHARSET); } /* =============== end of insertion */ len = (bufsize == -1) ? (gint)strlen(buf) : bufsize; if (len < 0) { MSG("a_I18n_convert: bufsize < 0\n"); return g_strdup(buf); } outBuf = a_I18n_convert_raw(it, buf, len); iconv_close(it); return outBuf; }

Sept. 26, 2005

current no-cache patch?

by Paul Fox

i was surprised when i figured out that the current dillo code doesn't support any sort of "no cache" or "expires" facility. it seems that this was done in 2003, in a patch referenced here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-August/001039.html i tried applying it, and resolving the (many) differences myself, but i seem to have botched it, because now some of my pages don't display at all. :-) is there a more current version of this patch around? i think it's important functionality... paul =--------------------- paul fox, pgf(a)foxharp.boston.ma.us (arlington, ma, where it's 77.5 degrees)

Sept. 22, 2005

Fwd: Re: [Dillo-dev]support for video streams

by Globe Trotter

Hi, Just wondering: is there any plan to merge this? When is the next dillo coming out? What goodies can we expect? Thanks a bundle, all, and best wishes!:-) --- Bjoern Brill <brill(a)fs.math.uni-frankfurt.de> wrote: > From: Bjoern Brill <brill(a)fs.math.uni-frankfurt.de> > To: dillo-dev(a)dillo.org > Subject: Re: [Dillo-dev]support for video streams > Date: Wed, 9 Feb 2005 19:48:48 +0100 (CET) > > > On Wed, 9 Feb 2005, Michael Kropfberger wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > hi! > > > > for a multimedia app on linux ipaq, I wanted to enable video links from > within > > dillo... > > > [...] > > Try the "external viewers" patch by Lars Clausen and Mattthias Franz: > <http://www-fourier.ujf-grenoble.fr/~franz/dillo/>. > It does not (directly) support streaming protocols, but everything over > http for which you can provide a working mailcap entry. I hope that this > patch will be merged in the not-too-distant future. > > > Regards, > > Bjoern > -- > Bj"orn Brill <brill(a)fs.math.uni-frankfurt.de> > Frankfurt am Main, Germany > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

Sept. 22, 2005

Re: [Dillo-dev] JavaScript

by TBlittlefoot

On Mon, Sep 19, 2005 at 10:51:43AM +0200, Bernd Petrovitsch wrote: > On Mon, 2005-09-19 at 01:21 -0700, TBlittlefoot wrote: > [...] > > So what's the big deal about javascripts? > > - No one integrated it. Good. > Actually there is somewhere a free JavaScript > interpreter library so it just need to be "only" integerated. > - JavaScript is a privacy nightmare. I've heard. > > <td><A href ="javascript:void(window.open('/art_bell_cam. > > html','ABCam','nostatus,nomenubar,noresize,width=515,height=435'));"><img src=" > > /images/btn_webcam.gif" border="0"></a> > > </td> > > > > That's the image link and javascript to go to Art Bell's webcam, found > > in the source at www.coasttocoastam.com/index.html > > > > You click on the link with Dillo and get nothing, because Dillo > > doesn't support javascript. > > > > But if you do: > > > > dillo www.coasttocoastam.com/art_bell_cam.html > > > > There it is! A simple end-run around javascript that, it seems > > to me, could be built into Dillo without much problem. > > Provide a patch. My C gets an F. I am, however almost finished with a bash script that produces a history.html file from Dillo's standard out. > > > As for the other eye-candy bullshit done with javascripts, I > > couldn't care less. > > Use <a href="..." target="_blank"> if you need only that feature of > JavaScript. Okay. > > > I don't want non-open-source software on my computer, and it is > > my understanding that java is not open-source. > > - Java has *absolutely* nothing to do with JavaScript. > - "Open source" is such a broad definition, that Java falls under it. > "Java" and you actually probably mean Sun's implementation is for sure > not "free software" (i.e. under the GPL). > Thanks, Bernd, Tom

Sept. 19, 2005

Re: [Dillo-dev] JavaScript

by Bernd Petrovitsch

On Mon, 2005-09-19 at 01:21 -0700, TBlittlefoot wrote: [...] > So what's the big deal about javascripts? - No one integrated it. Actually there is somewhere a free JavaScript interpreter library so it just need to be "only" integerated. - JavaScript is a privacy nightmare. > <td><A href ="javascript:void(window.open('/art_bell_cam. > html','ABCam','nostatus,nomenubar,noresize,width=515,height=435'));"><img src=" > /images/btn_webcam.gif" border="0"></a> > </td> > > That's the image link and javascript to go to Art Bell's webcam, found > in the source at www.coasttocoastam.com/index.html > > You click on the link with Dillo and get nothing, because Dillo > doesn't support javascript. > > But if you do: > > dillo www.coasttocoastam.com/art_bell_cam.html > > There it is! A simple end-run around javascript that, it seems > to me, could be built into Dillo without much problem. Provide a patch. > As for the other eye-candy bullshit done with javascripts, I > couldn't care less. Use <a href="..." target="_blank"> if you need only that feature of JavaScript. > I don't want non-open-source software on my computer, and it is > my understanding that java is not open-source. - Java has *absolutely* nothing to do with JavaScript. - "Open source" is such a broad definition, that Java falls under it. "Java" and you actually probably mean Sun's implementation is for sure not "free software" (i.e. under the GPL). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services

Sept. 19, 2005

JavaScript

by TBlittlefoot

Hello again, So what's the big deal about javascripts? <td><A href ="javascript:void(window.open('/art_bell_cam. html','ABCam','nostatus,nomenubar,noresize,width=515,height=435'));"><img src=" /images/btn_webcam.gif" border="0"></a> </td> That's the image link and javascript to go to Art Bell's webcam, found in the source at www.coasttocoastam.com/index.html You click on the link with Dillo and get nothing, because Dillo doesn't support javascript. But if you do: dillo www.coasttocoastam.com/art_bell_cam.html There it is! A simple end-run around javascript that, it seems to me, could be built into Dillo without much problem. As for the other eye-candy bullshit done with javascripts, I couldn't care less. I don't want non-open-source software on my computer, and it is my understanding that java is not open-source. Tom

Sept. 19, 2005

Re: [Dillo-dev] external browser req

by Scott Scriven

* Daniel C. Bastos <dbastos(a)math.utoledo.edu> wrote: > > Any chance of getting that "open in external browser" > > integrated with Dillo? > > Open in external program, you mean? There are patches for that. > More than one person has written patches to make such thing > work. I have written one to get it working, but it was a quick > big hack. > > Look in the archive of the list. Subject ``viewing non-web > files.'' Both would be useful. Sometimes it's nice to open an URL (current, or the one under the pointer) in a different program. Other times it's useful to load the current page content in a program (like gvim, for example). The former would pass an URL directly to a program, while the latter passes the path of a temp file. Either would be useful for both the current page and as an option in the right-click menu for links: Current page: - send current URL to program (firefox, or similar) - save current page and open in program (gvim or similar) Right click a link and then... - send URL to program (firefox, mplayer, whatever) - download its content, and open it in program (xv, gvim, ...) The thing I do most often is "copy link location" or "copy image location". But that wouldn't be as necessary if dillo could send the URL/file to a program for me. OTOH, just adding a keybinding for those "copy location" functions might be even better, to eliminate a lot of clicking and mousing. (hover the mouse over a link or image, press a key, and its URL goes into the clipboard) -- Scott

Sept. 16, 2005

Re: [Dillo-dev] Java in Dillo

by Scott Scriven

* Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > If I were to guess, they're probably using HTML for the > > background and CSS for the text, ... > > Yes, that's the main cause (invisible text is also used to spam > google, but the user seldom notices :). I see this almost every day, since so many sites are built badly. Usually, I inform the webmaster of the problem, but this is like moving a beach one grain of sand at a time. I think I preferred the old behavior of dillo, when selecting text would highlight it with fixed colors instead of inverting the colors. > Unfortunately "force_my_colors" will make every page in that > Dillo render in the same colors. I'm thinking of adding a > togle button to let the user do this on the fly. I had to deal with this color problem back in VGA / DOS days. What worked for me was to set the text to either black or white, depending on which had more contrast to the background color. Basically, something like this: text = white if background is brighter than 50% grey: text = black It was sometimes ugly, but always readable. Something like that could be used to automatically make text visible... either all the time, or at least when selecting text with the mouse. (inverting the colors is nice, when the background isn't grey and the text has sufficient contrast, but auto-selecting the colors would be more reliable) Or you could get fancy and invoke it only when the background and text are too similar (say, less than 25% different). But I realize that's the sort of messy kludge dillo tries to avoid. Anyway, it'd be nice if dillo handled invisible text better. Ideally, detect it and log a bug, but override to make the page readable. Or, as you said, add a button to toggle between user colors and page colors. This would be like the user mode versus author mode in opera (which is useful). -- Scott

Sept. 16, 2005

Re: [Dillo-dev] dillo and xhtml

by Kelly Price

On 9/11/05, Wim De Smet <kromagg(a)gmail.com> wrote: > I will not try arguing the point. While I believe that there is a very > good reason to want to do this from a user perspective (eg. you can > migrate to xhtml now and not 10 years from now) I also understand > there are plenty reasons not to. You probably have a much clearer > point of view on this. Though the article you linked lacked one reason > to use xhtml, namely it's really clean to write. :-) > While it may be, if you try to integrate it into other technologies such as Javascript, the article points out you have a headache and a half waiting to happen. I've read it. The service I oversee is sticking with HTML 4.01. > I've been thinking about UA parsing to determine doctype but I've > always considered UA parsing pure evil so will probably not do that. > Have I completely missed it or is there indeed no standard way for a > webserver/site to determine browser capabilities? > Other than what the web browser asks for in terms of MIME types, not really. -- Kelly "STrRedWolf" Price http://strredwolf.furrynet.com

Sept. 11, 2005

Re: [Dillo-dev] dillo and xhtml

by Wim De Smet

On 9/9/05, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi Wim, > > On Wed, Sep 07, 2005 at 05:17:13PM +0200, Wim De Smet wrote: > > Hi, > > > > in keeping with the latest and greatest, I was playing around with > > xhtml. Now the standard seems to be that xhtml should be send es > > application/xhtml+xml in the first place (there's a note about it > > somewhere). Or, if that is not possible, application/xml, text/xml, > > etc. Never as text/html (because this mimetype is not registered for > > this content). > > I really wish things were that simple! :-) > > Just to get the idea, you can start here: > > http://www.hixie.ch/advocacy/xhtml > > (the URLs inside are more than worth a read too!) > > > > > However, dillo doesn't recognize this mimetype and always tries to > > save an application/xhtml+xml file, though it can always be rendered > > as html. The current workaround for dillo and other browsers is just > > send text/html but since standards compliance is very important for > > dillo I would suggest treating application/xhtml+xml as though it was > > text/html for the time being. (or at least until the CSS support is > > complete). > > > > Thoughts? Ideas? > > Yes, the above-mentioned links. > > To save you the agony of understanding it all, I'd say: > > * It's incredibly easy to allow Dillo to treat xhtml as html, > but it's against the xhtml standard spirit (well, if something > of its point still remains. :-) > > * I prefer not to allow the official Dillo to do this out of > the box until at least some validation tailored to xhtml is > in place. Remember, the UA is expected to do validation. The > bug meter does this, but with the HTML4.01 spec in mind. It > would require an XHTML mode. > > Given the current priorities, that day seems far away. Now, > having an rc option like "treat_xhtml_as_tag_soup", could do the > trick in the meanwhile, but only if someone goes through the > above-mentioned links and convinces me that's there's no point in > not having it. :-) > I will not try arguing the point. While I believe that there is a very good reason to want to do this from a user perspective (eg. you can migrate to xhtml now and not 10 years from now) I also understand there are plenty reasons not to. You probably have a much clearer point of view on this. Though the article you linked lacked one reason to use xhtml, namely it's really clean to write. :-) I've been thinking about UA parsing to determine doctype but I've always considered UA parsing pure evil so will probably not do that. Have I completely missed it or is there indeed no standard way for a webserver/site to determine browser capabilities? greets, wim

Sept. 11, 2005