[Dillo-dev]viewing non-web files, thanks, etc
I'm a dillo user, not a developer, but I sat down one day to write a quick patch to get dillo to let me quickly view PDF files because I read lots of them from the web. So I wrote a program called quick and then I wrote a patch to get dillo to call quick when it's a file that quick can open. I'm happy with the benefit, but this is not a patch for dillo, it's just a hack to get me happy (I didn't use glib, for example.) I wanted to drop you guys this message to tell you guys that there's one user who would like such feature in dillo and I should perhaps ask you guys how you would build such feature in dillo if you were to sit down today and do it. Who knows? I could do it myself, if it won't be too complicated. I also wanted to say thanks. I think the software is great. http://math.utoledo.edu/~dbastos/files/patch/patch_dillo_cache.c http://math.utoledo.edu/~dbastos/files/quick-0.1.tar.gz
On Mon, Jul 04, 2005 at 07:53:40AM +0000, Daniel C. Bastos wrote:
quick patch to get dillo to let me quickly view PDF files [...] I wanted to drop you guys this message to tell you guys that there's one user who would like such feature in dillo
Hi Daniel, I've written such a patch, see my posting http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002278.html The patch is for Dillo 0.8.4, but it also works for 0.8.5. Well - almost. Apparently, the src/Makefile is wrong. The file external.c is not compiled, and external.o is not used for linking dillo. It's easy to change this by hand, but I haven't had time yet to fix the patch. Maybe it's related to the new version 1.9 of automake (which I haven't installed). Maybe someone could step in and fix the patch? Thanks in advance, -- Matthias Franz
Daniel, Matthias. Why not to cordinate effors? What about a group to bring this feature to "official" dillo? I am not a core developer and i unknown what core developers can think that is needed to include such feature, but i can imagine one: Add the minimal code to dillo. This can be done with a dpi, a filter dpi can be enough, like xproto for example. Dillo only needs to include a pair of lines to send a dpi command. To write a dpi is easy, i can help if it is needed. Some personal opinions more, but less important ones. That dpi must support mailcap because every linux distro and unix flavour have it configured by default and some user too. It must use file if unknown the mime type, but must use the mime type of the http headers if possible. It needs to be configurable by the user, to display html pages to ask the user if there are multiple acctions posible, available to call other DPIs to manage some mime types, but all this can be add later when basic funcionality is done. Diego Sáenz / DarkSpirit El Mon, 4 Jul 2005 19:55:48 +0200 Matthias Franz <matthias.franz@ujf-grenoble.fr> escribio:
On Mon, Jul 04, 2005 at 07:53:40AM +0000, Daniel C. Bastos wrote:
quick patch to get dillo to let me quickly view PDF files [...] I wanted to drop you guys this message to tell you guys that there's one user who would like such feature in dillo
Hi Daniel,
I've written such a patch, see my posting http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002278.html
The patch is for Dillo 0.8.4, but it also works for 0.8.5. Well - almost. Apparently, the src/Makefile is wrong. The file external.c is not compiled, and external.o is not used for linking dillo. It's easy to change this by hand, but I haven't had time yet to fix the patch. Maybe it's related to the new version 1.9 of automake (which I haven't installed).
Maybe someone could step in and fix the patch? Thanks in advance, -- Matthias Franz
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
That dpi must support mailcap because every linux distro and unix flavour have it configured by default and some user too. It must use file if unknown the mime type, but must use the mime type of the http headers if possible. It needs to be configurable by the user, to display html pages to ask the user if there are multiple acctions posible, available to call other DPIs to manage some mime types, but all this can be add later when basic funcionality is done.
I'm also voting for having external mime support directly in dillo. if there is a coordinated work is done, there is one prob with the avail external patch: even when passed though the file.dpi (eg. file://myacro.pdf) a new temp file is created and the external mime-viewer is called on this. there are several problems: 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs 2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise just my 2 cents, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCymEUw6IyDgGSsNIRAr56AJ475U6rGOKGlxPrWaY5MhNm1EL9kwCeLrj7 iq1ZMcHP/feMV6ugh2kyrBM= =V1RP -----END PGP SIGNATURE-----
1) use a tmp directory /tmp/dillo-zxqw34/file_with_original_name_and.ext 2) The temp file is not needed for local files(file://). About memory and performance: If the mime support is in dillo the size of the code is in memory all the time, substracting memory size to the program launched to view the file and other programs. If it is a filter DPI it only uses mem before launch the program. It can use exec to not use mem after launch the program or other ways. More about avoid temp files for local files Dillo send a dpi command to the DPI with a url of the file. For example: <dpi command='open_file?' url='protocol://path/file.ext' content-type='if dillo know it'> The DPI pass the /path/file.ext to program if the file is local or download it and pass the /tmp/dillo-zxqw34/file.ext file to the program. The mime DPI can, and surely need to, do protocol handling too. Diego Sáenz / Darkspirit El Tue, 5 Jul 2005 12:29:37 +0200 Michael Kropfberger <michael@kropfberger.com> escribio: ...
I'm also voting for having external mime support directly in dillo. if there is a coordinated work is done, there is one prob with the avail external patch: even when passed though the file.dpi (eg. file://myacro.pdf) a new temp file is created and the external mime-viewer is called on this. there are several problems: 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs 2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise
just my 2 cents,
Mike
On Tue, Jul 05, 2005 at 03:30:12AM +0200, Diego Sáenz wrote:
Why not to cordinate effors? What about a group to bring this feature to "official" dillo?
This is a good idea. I'm quite busy with my job, but I could contribute to such a project. As far as I know, Jorge would like to have an external viewer dpi in Dillo. Jorge: Correct me if this is wrong
That dpi must support mailcap
already in the patch
It must use file if unknown the mime type,
Currently the mime type is guessed in a_Misc_get_content_type_from_data (not part of the patch). I've added some more guesses in file.c.
but must use the mime type of the http headers if possible.
done On Tue, Jul 05, 2005 at 12:29:37PM +0200, Michael Kropfberger wrote:
1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs
If an external program needs a certain extension, it can set the "nametemplate" field as defined in RFC 1524. Example: application/pdf; /usr/bin/xpdf '%s'; \ test=test -n "$DISPLAY; nametemplate=%s.pdf The current patch implements this.
2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise
This might indeed be a problem. (Note: I'm away for the next couple of days.) All the best, -- Matthias Franz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 05 July 2005 19:55, Matthias Franz wrote:
On Tue, Jul 05, 2005 at 12:29:37PM +0200, Michael Kropfberger wrote:
1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs
If an external program needs a certain extension, it can set the "nametemplate" field as defined in RFC 1524. Example:
application/pdf; /usr/bin/xpdf '%s'; \ test=test -n "$DISPLAY; nametemplate=%s.pdf
THANKS for this hint!!! works great!
2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise
This might indeed be a problem.
right now, I've written an ugly patch to directly override all dillo intelligence and pass a fixed extension (.mp4) to a video player... this is the only way to make it usable to play video off a SD-card... greets, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCy6hkw6IyDgGSsNIRAnfvAJ4gfeHNO96MVda6fh6+1Gp/NcPJwwCgi0YQ vTyPiSDH6J74EEJxMR/fmyA= =cgDY -----END PGP SIGNATURE-----
participants (4)
-
Daniel C. Bastos -
Diego Sáenz -
Matthias Franz -
Michael Kropfberger