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

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > Hi there, > > Do you remember this 4KB memory leak mail-thread? > sorry I read this mail just by now. > At least after the pthread bug interim patch (CVS) it doesn't > leak anymore in my system. And there's this gentle side effect of > Dillo using less than 1/5 memory than before! thank you. :-) Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Feb. 10, 2005

Re: [Dillo-dev]support for video streams

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 February 2005 19:48, Bjoern Brill wrote: > http for which you can provide a working mailcap entry. I hope that this > patch will be merged in the not-too-distant future. this patch is perfect! I also hope, it will make it's way into the CVS! for dillo, there should also be a simpler way to add mime-types at least detected by file extensions... right now I eg. hacked the dpi/file.c to understand video.mp4 as mimetype video/mp4 in File_ext(const char *filename) greets, Mike - -- < When in doubt, THINK! > <----------------------------------------------------------------------> < DI Dr. Michael Kropfberger A-9073 Viktring, Kindergartenstr. 14/6 > < +43(650)6996000 michael _A T_ kropfberger.com http://www.kropfberger.com > <----------------------------------------------------------------------> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCC0SHw6IyDgGSsNIRAhkNAKCux1biazvVk/jwGnj2/oq52bIp0ACeMMTc NN6xvYyYhrbo9XLT1j6yLYs= =9RGu -----END PGP SIGNATURE-----

Feb. 10, 2005

Re: [Dillo-dev]support for video streams

by Bjoern Brill

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

Feb. 9, 2005

Re: [Dillo-dev]support for video streams

by Diego Sáenz

For the protocol part read this two mails: http://article.gmane.org/gmane.comp.web.dillo.devel/2496/match=xproto http://article.gmane.org/gmane.comp.web.dillo.devel/2497/match=xproto DarkSpirit El Wed, 9 Feb 2005 15:25:31 +0100 Michael Kropfberger <michael(a)kropfberger.com> escribio: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi! > > for a multimedia app on linux ipaq, I wanted to enable video links from within > dillo... > > 1st idea: hack up the dpi/file.c so that the file extension .mp4 or .avi is > detected and whenever File_get_file(...) is called, instead of passing the > raw data, an external video player is started with this file name as input > parameter... configuring of the videoplayer path could happen from > within .dillorc > > this is, what I'd imagine to be the quickest solution... > > more complex ideas: > * really make nicer support for mime-types, better even protocol types > (rtsp://), which again calls an external player > > * with a separate dpi, so for remote http:// URLs progressive download via > http is possible > > * even allow "embedded" video output within a rendered html page, so it has to > be like gif,png,jpg support... well, not really interesting on ipaqs, and too > complicated anyways... > > > > what's your thoughts, folks? > > > Mike > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFCCh1bw6IyDgGSsNIRAkI9AJ0bCKJXr67V1SxPT1DpCgrZRYCKcQCfRX1B > rS/y0jHqK3sqUgEJ/vsQ5mM= > =WDsR > -----END PGP SIGNATURE----- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 9, 2005

[Dillo-dev]support for video streams

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi! for a multimedia app on linux ipaq, I wanted to enable video links from within dillo... 1st idea: hack up the dpi/file.c so that the file extension .mp4 or .avi is detected and whenever File_get_file(...) is called, instead of passing the raw data, an external video player is started with this file name as input parameter... configuring of the videoplayer path could happen from within .dillorc this is, what I'd imagine to be the quickest solution... more complex ideas: * really make nicer support for mime-types, better even protocol types (rtsp://), which again calls an external player * with a separate dpi, so for remote http:// URLs progressive download via http is possible * even allow "embedded" video output within a rendered html page, so it has to be like gif,png,jpg support... well, not really interesting on ipaqs, and too complicated anyways... what's your thoughts, folks? Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCCh1bw6IyDgGSsNIRAkI9AJ0bCKJXr67V1SxPT1DpCgrZRYCKcQCfRX1B rS/y0jHqK3sqUgEJ/vsQ5mM= =WDsR -----END PGP SIGNATURE-----

Feb. 9, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Kelson Vibber

Madis Janson wrote: > This is only my opinion, which may be wrong (I am only contributed few > patches to Dillo), but I think the reason for no answer is that strict > standards compliance is one of the goals of the Dillo project and the > w3c html standard discourages the usage of meta tag for refresh. > > http://www.w3.org/TR/html401/struct/global.html#idx-meta_data-2 Actually, that document only discourages using meta refresh for *forwarding*, as there are better, more accessible ways to do it (i.e. 302 Moved and similar responses). It says nothing negative about using a meta http-equiv tag to *refresh* the page. "Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should not use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects." -- Kelson Vibber www.hyperborea.org

Feb. 8, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Madis Janson

On Mon, 31 Jan 2005, Roberto A. Foglietta wrote: > Kelly Price wrote: > > Heya. New here. Glad someone's working on Dillo. Hope it comes > > full-featured like Firefox is with less than half the bloat! > > > > I'm attaching a fixed patch for 0.8.4 that allows meta-http refreshes. > > This is quite common with web chats (including Tag-Board). I've > > test-compiled and ran it, and so far so good. > > > > The next thing we'll need is the frames/iframes code now! > > I'm the authoir of original patch. I developed it for 0.8.4 too > reducing size of patch itself. I tried to talk with dillo author to > evaluete if there was any chances to include it in the main branch but I > didn't received any answer. This is only my opinion, which may be wrong (I am only contributed few patches to Dillo), but I think the reason for no answer is that strict standards compliance is one of the goals of the Dillo project and the w3c html standard discourages the usage of meta tag for refresh. http://www.w3.org/TR/html401/struct/global.html#idx-meta_data-2

Feb. 8, 2005

[Dillo-dev]selection patch (was: Patch review: Frank de Lange patch (20031124))

by Sebastian Geerken

Hi Bastiaan, On Thu, Jan 20, Bastiaan Jacques wrote: > The following patch does does two things in selection.c: > - - make a_Selection_set_dclick_callback replace the callback instead of > returning when the callback was already set. > * This function is called only once in the code (in interface.c); the > callback pointer always points to the same function. So I don't see a > point in merging this first hunk, although it won't do any harm. Thoughts? I'd rather leave it the current way, since changing the callback as in your patch would mean, that the old callback would be silently deactivated. To extend the current functionality, a remove function may be useful (to make deactivation explicit), or even a list of callbacks, so that the functions do not have to be removed (unless they should so). Anyway, there is currently no demand for an extended functionality, so I'd leave it as simple as it is now. > - - Replace three comparison operators (==) with bitwise AND.. > * This only works as expected when either lvalue and rvalue have exactly > one or zero bits set to 1. Although this currently is true, this may > change in the future; thus, I don't think these three hunks should be > merged. This (that only one bit set) will also be true in the future. If contents will be extended to contain multiple types (which is not planned at all), the whole design must be changed anyway (at least, the unions will have to replaced by structs), so grepping over the code is anyway necessary. Until then, your suggestion would only make the code more confusing. Sebastian

Feb. 2, 2005