- Dillo-dev - lists.mailman3.com

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

Re: [Dillo-dev] Funding activities

by Matthias Franz

Hi Jorge, it's sad to hear that funding-problems threaten Dillo's development so much! Could MIT's "100$ laptop" initiative (http://laptop.media.mit.edu/) be a possible sponsor? On Tue, Sep 06, 2005 at 06:18:25PM -0400, Jorge Arellano Cid wrote: > Almost surely, the next release will be GTK-based, To what extent are you interested in new patches? I have the feeling that many people have been waiting for the FLTK-based version instead of submitting/developing new patches. All the best, -- Matthias Franz

Sept. 11, 2005

Re: [Dillo-dev] Optional Image Downloading/HTML2txt Conversion

by TBlittlefoot

On Fri, Sep 09, 2005 at 09:58:25PM -0400, Jorge Arellano Cid wrote: > On Fri, Sep 09, 2005 at 12:56:11PM -0700, TBlittlefoot wrote: > > On Fri, Sep 09, 2005 at 09:52:44AM -0400, Jorge Arellano Cid wrote: > > > On Wed, Sep 07, 2005 at 09:14:45PM -0700, TBlittlefoot wrote: > > > > > > > > It would be nice if downloading images was optional, > > > > but I've been reading through the docs and haven't > > > > found a way. > > > > > > > > Perhaps a configuration item in dillorc that would tell Dillo to > > > > first download just the HTML source, render the text, and then, > > > > if you chose to reload it, bring down the images too....?? > > > > > > Having a no-images dillo is easy. Having a good UI for doing > > > images on demand is not that simple... > > > > > > > If Dillo could do that, and be used to convert HTML to plain > > > > text, I could ditch w3m! > > > > > > Html2text is a different thing. Dillo doesn't render to a plain > > > text canvas. It uses graphic objects (widgets). > > > i.e. you'll have to keep w3m or similar for this task. > > > > > > > > > > What if there was a text/image toggle that caused Dillo to > > just bring down the source without the image/sound files > > (which wget does by default, right?) then parse the text tags, > > like <p>,<i>,<h[1-5]>,<b>,<hr> and so forth, displaying the > > results. Then, saving the page as displayed would be the way > > Dillo did html2txt conversion? > > That's exactly the problem: "saving the page as displayed". You'd know better than I. Liking the modular approach, Perhaps one of the > > > The rationale for this is to speed up 'surfing' for the 45% of us > > that have dialup connections. Takes a long time to bring down the > > image/sound files for a page that turns out to be worthless for > > our current purposes. > > Do you have an example of Dillo downloading sounds? Errrr...No. I just assumed. The only sounds my box makes are the whirring of the fan, the grinding or whining of the disks, and a beep when I hit a wrong key. Glad to hear it. (so to speak :-) > > > > > I'll see if I can come up with a shell script that uses wget > > to bring down the source and does an adequate job of formatting > > the text therein. > > > > Thanks for the response and the great browser, Jorge, > > :-) I'll see you that smile and raise you one. :-) :-) Tom

Sept. 10, 2005