- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 10:36:57AM -0700, Kelson Vibber wrote: > On Sunday 04 September 2005 4:18 am, Jeremy Henty wrote: > > > On Sun, Sep 04, 2005 at 02:43:03AM -0700, TBlittlefoot wrote: > > > > > Now would you tell me what good black on black or white on > > > white is? > > > > I quite often see web sites that render black on black in > > dillo. I assume they use some standard trick that dillo > > doesn't support. > > If I were to guess, they're probably using HTML for the > background and CSS for the text, or possibly doing something > nonstandard like putting <font color="white"> at the beginning > of the page instead of inside each block element. So the site > is either badly designed (relying on two separate technologies > instead of one for something as critical as readability) or > badly coded (using code that happened to work in Netscape 2 and > IE, but fails in a stricter rendering engine). > Good, Kelson. I'll send this thread to the webmaster there. Tom

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 07:21:13AM -0500, Patrick Shanahan wrote: > * TBlittlefoot <littlefoot8(a)earthlink.net> [09-04-05 06:56]: > > > > While we're chatting, Jeremy, just why is dillo as large as > > it is? (I realize that it is less than 1/10 the size of most > > browsers) I have 1.3M for the executable here. > > > > if you strip the binary, it's much smaller: > -rwxr-xr-x 1 root root 377828 2005-06-19 05:32 /usr/bin/dillo* > No kidding...Good news! Mind giving me a clue as to how one does that? Do you need to re-compile? I don't really know what stripped/un-stripped means. $ file `which dillo` /usr/local/bin/dillo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Okay. I did the obvious and was surprised to find that there is actually a man strip :-) DESCRIPTION GNU strip discards all symbols from object files objfile. The list of object files may include archives. At least one object file must be given. So how do I find that 'one object file' to give? Or does the -s option get around that need? Any important reasons why I _shouldn't_ strip Dillo? Winter _is_ coming...(sorry). Thanks, Patrick, Tom

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Kelson Vibber

On Sunday 04 September 2005 4:18 am, Jeremy Henty wrote: > On Sun, Sep 04, 2005 at 02:43:03AM -0700, TBlittlefoot wrote: > > Now would you tell me what good black on black or white on white is? > > I quite often see web sites that render black on black in dillo. I > assume they use some standard trick that dillo doesn't support. If I were to guess, they're probably using HTML for the background and CSS for the text, or possibly doing something nonstandard like putting <font color="white"> at the beginning of the page instead of inside each block element. So the site is either badly designed (relying on two separate technologies instead of one for something as critical as readability) or badly coded (using code that happened to work in Netscape 2 and IE, but fails in a stricter rendering engine). -- Kelson Vibber www.hyperborea.org

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Patrick Shanahan

* TBlittlefoot <littlefoot8(a)earthlink.net> [09-04-05 06:56]: > > While we're chatting, Jeremy, just why is dillo as large as > it is? (I realize that it is less than 1/10 the size of most > browsers) I have 1.3M for the executable here. > if you strip the binary, it's much smaller: -rwxr-xr-x 1 root root 377828 2005-06-19 05:32 /usr/bin/dillo* -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 12:18:07PM +0100, Jeremy Henty wrote: > On Sun, Sep 04, 2005 at 02:43:03AM -0700, TBlittlefoot wrote: > > > Now would you tell me what good black on black or white on white is? > > I quite often see web sites that render black on black in dillo. I > assume they use some standard trick that dillo doesn't support. I > just switch to links to read such sites, and if that doesn't work I > give up. I've never found such a site that I cared enough about to > bother working out exactly what is going on. So I can't help much > more I'm afraid. > Sure. That's what I've been doing, and it isn't a problem. I just wondered if there was some configuration choice that would easily fix the 'problem'. It sure isn't something the authors should waste any time with, in my estimation. While we're chatting, Jeremy, just why is dillo as large as it is? (I realize that it is less than 1/10 the size of most browsers) I have 1.3M for the executable here. What is it about the current state of the Web (HTML and/or servers) that necessitates this size? W3m is only .7K and does a great job as a textmode browser. Why so much more just to display static images? Big thanks to Jorge and the gang. Great browser. Tom

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Jeremy Henty

On Sun, Sep 04, 2005 at 02:43:03AM -0700, TBlittlefoot wrote: > Now would you tell me what good black on black or white on white is? I quite often see web sites that render black on black in dillo. I assume they use some standard trick that dillo doesn't support. I just switch to links to read such sites, and if that doesn't work I give up. I've never found such a site that I cared enough about to bother working out exactly what is going on. So I can't help much more I'm afraid. Cheers, Jeremy Henty

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 09:58:47AM +0100, Jeremy Henty wrote: > On Sat, Sep 03, 2005 at 11:35:20PM -0700, TBlittlefoot wrote: > > > http://www.lifeaftertheoilcrash.net/ > > > > ... w3m displays all the text and Dillo doesn't. > > Actually Dillo *does*, but the text is black on black. Scroll down to > the bottom half of the page and drag the mouse around. You'll see the > paragraphs appear (in white on white). > > I'm not sure why the text has been pushed halfway down the page. > There's an enormous empty image "tp.gif" filling the top half of the > page, but when I download it separately the image is tiny (1x1 pixel > I'd guess). Looks like there's some layout and size munging. > > Cheers, > > Jeremy Henty > Thanks, Jeremy. I found it. Now would you tell me what good black on black or white on white is? It may as well not be there, right? Tom

Sept. 4, 2005

dillo-0.8.6-pre(CVS) compile error

by south park

Hi, It works if compiled without "--disable-cookies" option. how to disable cookies in dillo? XXX@debian:~/download$ cd dillo XXX@debian:~/download/dillo$ ./configure --disable-cookies ... XXX@debian:~/download/dillo$ make make all-recursive make[1]: Entering directory `/home/XXX/download/dillo' Making all in doc make[2]: Entering directory `/home/XXX/download/dillo/doc' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/XXX/download/dillo/doc' Making all in src make[2]: Entering directory `/home/XXX/download/dillo/src' Making all in IO make[3]: Entering directory `/home/XXX/download/dillo/src/IO' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/XXX/download/dillo/src/IO' make[3]: Entering directory `/home/XXX/download/dillo/src' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/XXX/download/dillo/src' make[2]: Leaving directory `/home/XXX/download/dillo/src' Making all in dpid make[2]: Entering directory `/home/XXX/download/dillo/dpid' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/XXX/download/dillo/dpid' Making all in dpi make[2]: Entering directory `/home/XXX/download/dillo/dpi' gcc -I/usr/include/glib-1.2 -I/usr/lib/glib/include -g -O2 -DDISABLE_COOKIES -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -L/usr/local/lib -o cookies.dpi cookies.o dpiutil.o -L/usr/lib -lglib /usr/lib/crt1.o: In function `_start': ../sysdeps/i386/elf/start.S:115: undefined reference to `main' collect2: ld returned 1 exit status make[2]: *** [cookies.dpi] Error 1 make[2]: Leaving directory `/home/XXX/download/dillo/dpi' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/XXX/download/dillo' make: *** [all-recursive-am] Error 2 XXX@debian:~/download/dillo$

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Jeremy Henty

On Sat, Sep 03, 2005 at 11:35:20PM -0700, TBlittlefoot wrote: > http://www.lifeaftertheoilcrash.net/ > > ... w3m displays all the text and Dillo doesn't. Actually Dillo *does*, but the text is black on black. Scroll down to the bottom half of the page and drag the mouse around. You'll see the paragraphs appear (in white on white). I'm not sure why the text has been pushed halfway down the page. There's an enormous empty image "tp.gif" filling the top half of the page, but when I download it separately the image is tiny (1x1 pixel I'd guess). Looks like there's some layout and size munging. Cheers, Jeremy Henty

Sept. 4, 2005

Re: Want to use dillo with TOR

by south park

Sorry, i felt so dumb. I read the friendly manual, and now i am using privoxy with tor. On 8/18/05, Martin Evald <radiant(a)gnarf.org> wrote: > south park wrote on Thu, Aug 18, 2005 at 03:08:18AM -0700: > > Hi! > > > is it possible to enable SOCKS5 in dillo? > > You should be able to run Dillo behind Proxychains. ( > http://proxychains.sourceforge.net/ ) > > Take a look at it! > > /Martin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 4, 2005

Java in Dillo

by TBlittlefoot

Greetings, Could anyone tell me why this page is readable with W3m but not with Dillo 0.8.0? http://www.lifeaftertheoilcrash.net/ A no-java warning appears in both browsers, but w3m displays all the text and Dillo doesn't. Thanks. Great browser. I was happy to dump mozilla for it and don't do java or cookies or plugins. Tom

Sept. 4, 2005

Re: [Dillo-dev] external browser req

by taeb

On Fri, Sep 02, 2005 at 01:51:19PM -0400, Todd Slater wrote: > On Fri, Sep 02, 2005 at 06:46:55PM +0200, Ivo wrote: > > > > I thought Todd Slater meant something like Konqueror does. Konqueror has a > > whole list of open in mozilla, open in galeaon, open in opera (depending on > > what you have installed on your system) under the file menu. It will spawn > > a new browser and open the current page in it. Sometimes that's supposed to > > be handy if a certain page doesn't render correctly. > > That's exactly it Ivo. I have Dillo set as my default browser so I > don't have to wait half an hour for Firefox to open when I click a > link in other apps, but sometimes I need to use FF anyway. > > There is a patch for this out there, but I think you can only > configure one alternate browser. And I can never remember how to apply > the patch, or where I left it, so I spend some time figuring that out. > > I thought enough people might find it useful to include it by default. > > Todd > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev If we're voting, count me in favor. It sounds like a very handy feature, and I'd probably switch my default browser to dillo too. I try to use it for just about everything now. tony

Sept. 2, 2005

Re: [Dillo-dev] tabs + frames with .deb

by Tito

On Friday 02 September 2005 12:22, Caleb Duggan wrote: > ive installed dillo using apt-get(in ubuntu).......is there any way to get > tabs and frames support without compiling the source? > Look at: http://teki.jpn.ph/pc/software/index-e.shtml Improvements * Support for frames and tabbed browsing * Anti-aliasing and scaled fonts through Xft support * Changed to use UTF-8 for internal processing * Multi byte char selection support * Support for character entity references like &#xnnnn; * Automatic charset recognition support * Change font setting code for i18n * Gettextize * GUI tool for configuration * Text Search in status bar (configurable) * gzip compression transmission support * SSL support * BASIC authorization support * Referer support * User-Agent is configurable * Meta-refresh support (off by default) * And more changes... But I think you have to compile it from source. You could also try: Debian dpkg http://debian.fam.cx/index.php?uploader#content_1_3 Ciao, Tito

Sept. 2, 2005

Re: [Dillo-dev] external browser req

by Todd Slater

On Fri, Sep 02, 2005 at 06:46:55PM +0200, Ivo wrote: > On Friday 02 September 2005 14:38, Daniel C. Bastos wrote: > > On Fri, 2 Sep 2005 11:22:29 -0400, > > > > Todd Slater <dontodd(a)columbus.rr.com> 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.'' > > I thought Todd Slater meant something like Konqueror does. Konqueror has a > whole list of open in mozilla, open in galeaon, open in opera (depending on > what you have installed on your system) under the file menu. It will spawn > a new browser and open the current page in it. Sometimes that's supposed to > be handy if a certain page doesn't render correctly. That's exactly it Ivo. I have Dillo set as my default browser so I don't have to wait half an hour for Firefox to open when I click a link in other apps, but sometimes I need to use FF anyway. There is a patch for this out there, but I think you can only configure one alternate browser. And I can never remember how to apply the patch, or where I left it, so I spend some time figuring that out. I thought enough people might find it useful to include it by default. Todd

Sept. 2, 2005

Re: [Dillo-dev] external browser req

by Ivo

On Friday 02 September 2005 14:38, Daniel C. Bastos wrote: > On Fri, 2 Sep 2005 11:22:29 -0400, > > Todd Slater <dontodd(a)columbus.rr.com> 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.'' I thought Todd Slater meant something like Konqueror does. Konqueror has a whole list of open in mozilla, open in galeaon, open in opera (depending on what you have installed on your system) under the file menu. It will spawn a new browser and open the current page in it. Sometimes that's supposed to be handy if a certain page doesn't render correctly. --Ivo

Sept. 2, 2005

external browser req

by Todd Slater

Any chance of getting that "open in external browser" integrated with Dillo? Thanks, Todd

Sept. 2, 2005

Re: [Dillo-dev] tabs + frames with .deb

by Riccardo Mottola

Caleb Duggan wrote: > > ive installed dillo using apt-get(in ubuntu).......is there any way to get > tabs and frames support without compiling the source? no. -R

Sept. 2, 2005

Re: [Dillo-dev] external browser req

by Daniel C. Bastos

On Fri, 2 Sep 2005 11:22:29 -0400, Todd Slater <dontodd(a)columbus.rr.com> 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.''

Sept. 2, 2005

tabs + frames with .deb

by Caleb Duggan

ive installed dillo using apt-get(in ubuntu).......is there any way to get tabs and frames support without compiling the source? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Sept. 2, 2005

Re: [Dillo-dev] dillo + proxy?

by Alexander Becher

Patrick Shanahan schrieb: >* Caleb Duggan <caleb.duggan(a)gmail.com> [09-01-05 09:18]: >> how do i give dillo a proxy? i cant find anything on how to give it a >> proxy from google searches or on the dillo website. Ive also tried looking >> for config files to put it in but can't find anything >> > >grep /etc/dillorc > >or, examine the dillorc included in the tar-ball. dillo will also regard the environment variable http_proxy. Not no_proxy, though, but I have a patch for that. I'm waiting for FLTK dillo to submit it. Regards Alexander -- PGP key available Port Payé / Entgelt bezahlt / Postage Paid: http://www.hashcash.org/

Sept. 1, 2005

Re: [Dillo-dev] dillo + proxy?

by Patrick Shanahan

* Caleb Duggan <caleb.duggan(a)gmail.com> [09-01-05 09:18]: > how do i give dillo a proxy? i cant find anything on how to give it a > proxy from google searches or on the dillo website. Ive also tried looking > for config files to put it in but can't find anything > grep /etc/dillorc or, examine the dillorc included in the tar-ball. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery

Sept. 1, 2005

dillo + proxy?

by Caleb Duggan

how do i give dillo a proxy? i cant find anything on how to give it a proxy from google searches or on the dillo website. Ive also tried looking for config files to put it in but can't find anything -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Sept. 1, 2005

Re: [Dillo-dev] Want to use dillo with TOR

by Martin Evald

south park wrote on Thu, Aug 18, 2005 at 03:08:18AM -0700: Hi! > is it possible to enable SOCKS5 in dillo? You should be able to run Dillo behind Proxychains. ( http://proxychains.sourceforge.net/ ) Take a look at it! /Martin

Aug. 18, 2005

Want to use dillo with TOR

by south park

Hi, First of all, thanks to all who developed dillo. I am using dillo everyday, sometime, using mozilla(you know). i have a question, how to use dillo with tor? http://tor.eff.org i can use tor with gaim, it just easy because gaim supports SOCKS5. is it possible to enable SOCKS5 in dillo? --

Aug. 18, 2005

Re: [Dillo-dev] exact meaning of "Handling of configuration data"

by Jorge Arellano Cid

On Tue, Aug 09, 2005 at 02:32:59AM +0200, Diego Sáenz wrote: > Hi, in the current plans page(http://www.dillo.org/Plans.html) there is a medium priority task named: > - Handling of configuration data. > > By some comments in the list have some idea of the meaning of this, but what > is exact meaning of "handling of configuration data"? Basically it's the idea of handling the "rc" files for dillo, cookies, file, etc. in a uniform way from a config dpi. -- Cheers Jorge.-

Aug. 10, 2005

Re: [Dillo-dev] Dillo mailing list <dillo-dev@lists.auriga.wearlab.de>

by Jorge Arellano Cid

On Wed, Aug 10, 2005 at 08:10:23PM +0100, Jeremy Henty wrote: > > Jorge Arellano Cid wrote: > > > After a more in depth review, the patch for the cookies dpi was > > uploaded to the CVS. It has some minor modifications and it's > > ready for testing! > > Works great for me! (Linux 2.4.31-0 i586 unknown.) Good! Note: if you want to make it less verbose, just "#define DEBUG_LEVEL 8" in src/cookies.c. -- Cheers Jorge.-

Aug. 10, 2005

Dillo mailing list <dillo-dev@lists.auriga.wearlab.de>

by Jeremy Henty

Jorge Arellano Cid wrote: > After a more in depth review, the patch for the cookies dpi was > uploaded to the CVS. It has some minor modifications and it's > ready for testing! Works great for me! (Linux 2.4.31-0 i586 unknown.) Cheers, Jeremy

Aug. 10, 2005

exact meaning of "Handling of configuration data"

by Diego Sáenz

Hi, in the current plans page(http://www.dillo.org/Plans.html) there is a medium priority task named: - Handling of configuration data. By some comments in the list have some idea of the meaning of this, but what is exact meaning of "handling of configuration data"? Diego.

Aug. 9, 2005

Re: [Dillo-dev] Search feature for the mailing list

by Jorgen Viksell

Hi, fre 2005-08-05 klockan 15:45 -0400 skrev Jorge Arellano Cid: > The mailing list "search" page is consistently working bad. > Would you mind trying to find out a program that does this job > given the archives as input. I'll have a look at some options (including namazu mentioned by higuita). Browsed around some on the server and found that the list archives are located on it, so it should be quite easy... Will probably be done by wednesday! Cheers, Jörgen

Aug. 6, 2005

Re: [Dillo-dev] Search feature for the mailing list

by higuita

On Fri, 5 Aug 2005 15:45:24 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Would you mind trying to find out a program that does this job > given the archives as input. i use namazu for local search and works well... isnt build for many users searchs at same time, but the mailing list is so small compared with all my files that shouldnt be a problem... it doesnt need any SQL database, so its light and easy to setup higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Aug. 5, 2005

Re: [Dillo-dev] cookies dpi patch is on CVS now

by Diego Sáenz

El Fri, 5 Aug 2005 14:00:16 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi there, > > After a more in depth review, the patch for the cookies dpi was > uploaded to the CVS. It has some minor modifications and it's > ready for testing! > Then other thing to mark as in cvs in the current plans page. Thanks for the modifications, specially for MSG/_MSG and english corrections :P > Cookies now hare handled by a dpi (dillo plugin), so there's no > more restriction of only one instance of Dillo having cookies > enabled. Every single dillo sees cookies.dpi as the "cookies > server" so there's no problem, and dillo's core gets smaller. > > After 'make", remember to "dpidc stop" and to 'make install' to > get the cookies dpi installed. > > If you find some bugs, please report back here to Diego or me. > > Diego: I'll try to catch up with the thread about the MIME dpi. > As Matthias Franz pointed out, I'm interested on it. The main > point is to make it use the dpi/dpip framework instead of a > custom approach. --More on this soon. I think that the way to register dpis and the mime that each dpi understand is needed before that. If dillo use mailcap then it will have a lot of configuration done, but dillo need to support dpis for mime too so they work with dillo better. I am open to change mi opinion with a better solution, of course. > > I'm also working on a new dpip library, so it may be merged in > the future (don't worry, that's my work and it makes things > easier, not harder). Porting the cookies dpi to it should be no > more than one day, and I have already every other dpi working on > it on a custom tree... I await it. > > > -- > Cheers > Jorge.- > Diego Sáenz / Darkspirit

Aug. 5, 2005

Search feature for the mailing list

by Jorge Arellano Cid

Hi Jörgen, The mailing list "search" page is consistently working bad. Would you mind trying to find out a program that does this job given the archives as input. (the archives are available from: http://lists.auriga.wearlab.de/pipermail/dillo-dev/) I'd like to haveit running on site, otherwise it gets very hard for non-subscribed people to search the mailing list for some information. TIA. -- Cheers Jorge.-

Aug. 5, 2005

cookies dpi patch is on CVS now

by Jorge Arellano Cid

Hi there, After a more in depth review, the patch for the cookies dpi was uploaded to the CVS. It has some minor modifications and it's ready for testing! Cookies now hare handled by a dpi (dillo plugin), so there's no more restriction of only one instance of Dillo having cookies enabled. Every single dillo sees cookies.dpi as the "cookies server" so there's no problem, and dillo's core gets smaller. After 'make", remember to "dpidc stop" and to 'make install' to get the cookies dpi installed. If you find some bugs, please report back here to Diego or me. Diego: I'll try to catch up with the thread about the MIME dpi. As Matthias Franz pointed out, I'm interested on it. The main point is to make it use the dpi/dpip framework instead of a custom approach. --More on this soon. I'm also working on a new dpip library, so it may be merged in the future (don't worry, that's my work and it makes things easier, not harder). Porting the cookies dpi to it should be no more than one day, and I have already every other dpi working on it on a custom tree... -- Cheers Jorge.-

Aug. 5, 2005

News after LSM 2005

by Jorge Arellano Cid

Hi there! It's being some time since coming back from France, but I'm catching up. There's a new link for "LSM 2005", and there's a video URL for those interested. Ah, Philippe De Swert, made a Debian package for x86 with dillo-0.8.5. It is available from the downloads page. Please let the Debian guys know so they can get it, and try it, tell them to report back here in case the package needs some polishing. It's being a lot of work with these conferences. I'll report here more news when we sort out what to do in the near future. The FLTK2-based prototype is not ready yet for CVS and this is one of the things we're deciding on with Sebastian. Diego: please check and send me the cookies patch to upload it to the CVS (and to merge with the prototype). The server was down several days because it was hacked. Now it's working normally again, reinstalled on another machine. This probably explains why it was so hard to get in touch with it. :-) -- Cheers Jorge.-

Aug. 2, 2005

Re: [Dillo-dev]Meta-refresh warning

by Alexander Becher

Glyn Kennington schrieb: >> -r only refresh >> -rr redirect too > >I'll get to work on that. I'm not sure if "-rr" breaks certain coding >standards, it being neither a "short" (only one character) nor "long" >(starting with two dashes) option, but that's not especially important >(to me) right now. How about "-R" for "redirect too"? Also, dillo's error message when parsing the command line is not very helpful: |$ dillo -help |Error in command line options. Maybe at some time I'll look into making this more specific. >> but I think that dillo could not complain about refresh because they >> are HTML-standard compliant and it is the reason because meta-refresh >> was been invented. So if we would stay on the standards we have to >> accept it even if we don't like it. > >It's dubious whether it's standard HTML, actually. The spec says that >the "http-equiv" must be valid HTTP, effectively passing the buck to the >HTTP spec. And as the HTTP spec is in a fairly unreadable RFC format, >I'm still uncertain about all this... Actually, as I read it, the META-refresh is not an HTTP header at all. At least it does not occur anywhere in the HTTP spec. The HTML 4.0 spec says: 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. <META http-equiv="refresh" content="3,http://www.acme.com/intro.html"> The content is a number specifying the delay in seconds, followed by the URI to load when the time is up. [...] However, since some user agents do not support this mechanism, [...] Regards Alexander -- PGP key available Port Payé / Entgelt bezahlt / Postage Paid: http://www.hashcash.org/

July 13, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Glyn Kennington wrote: > Roberto A. Foglietta wrote: > > -r only refresh > > -rr redirect too > > I'll get to work on that. OK, here's one very poorly tested diff. Apply it after applying the main "refresh" patch. It should work against current CVS, nothing else tried. It's a bit of a hack, but no more so than your own patch ;-) I'll leave the timelimit part until I've thought about it a bit more. Glyn

July 12, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Roberto A. Foglietta wrote: > Glyn Kennington ha scritto: > >Rather than changing the first to be "refresh only, no redirect", could > >I suggest some kind of choice between the following three? > > > >1: no refresh > >2: refreshes allowed, redirects not > >3: refreshes + redirects permitted > > > >[...] > > that sounds good: > > -r only refresh > -rr redirect too I'll get to work on that. I'm not sure if "-rr" breaks certain coding standards, it being neither a "short" (only one character) nor "long" (starting with two dashes) option, but that's not especially important (to me) right now. > but I think that dillo could not complain about refresh because they > are HTML-standard compliant and it is the reason because meta-refresh > was been invented. So if we would stay on the standards we have to > accept it even if we don't like it. It's dubious whether it's standard HTML, actually. The spec says that the "http-equiv" must be valid HTTP, effectively passing the buck to the HTTP spec. And as the HTTP spec is in a fairly unreadable RFC format, I'm still uncertain about all this... Glyn

July 12, 2005

Re: [Dillo-dev]Meta-refresh warning

by Roberto A. Foglietta

Glyn Kennington ha scritto: > Roberto A. Foglietta wrote: > >> http://www.roberto.foglietta.name/pub/dillo/ >> >> It able to refresh AND redirect, but only if -r option is specified in >>command line. May be you can modify it to refresh ALWAYS and use -r >>option ONLY for redirect when time is more than the specified offset >> >> -r <seconds> > > > The more I think about how I'd go about hacking this functionality in, > the more questions it brings up... > > As well as a time boundary, I think it would probably be best to include > another option to specify which refreshes to honour. At the moment it's > a simple choice between > > 1 (default): no refresh > 2 (with -r): all refreshes permitted > > Rather than changing the first to be "refresh only, no redirect", could > I suggest some kind of choice between the following three? > > 1: no refresh > 2: refreshes allowed, redirects not > 3: refreshes + redirects permitted > > And then we get into the murky area of limiting the times for these. > Could/should it be a different value for refreshes and for redirects? > What to do if the page requests a shorter timeout than allowed: ignore > it altogether, or handle after the minimum timeout has elapsed? > > Is that too many command-line options? Would an entry (or several) in > dillorc be more suitable? > that sounds good: -r only refresh -rr redirect too but I think that dillo could not complain about refresh because they are HTML-standard compliant and it is the reason because meta-refresh was been invented. So if we would stay on the standards we have to accept it even if we don't like it. The reason because I decided not to include the option in dillorc is beacuse -r -rr could be an alias which the user could setup in his/her shellrc while dillorc could be modified acrivating the option by distribution without knowledge of end-users. In this last case safe behaviure of dillo would be overloaded out of our/end-user control. Warning on refresh are very boring and fails completely in automated systems like embedded while warning on redirect could be much more acceptable for end users. So I think my patch was not so much usefull if dillo was HTML-stadard compliant but because my refresh needs we could discover (and sombody else) fix a very evil memory leak bug in pthread library. 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

July 11, 2005

[Dillo-dev][PATCH] use an alternative rcfile from command line

by Tito

Hi to all, this little patch adds a command line option ( -R --rcfile) to specify an alternative rcfile from the command line. This is useful if you are calling dillo from scripts or other applications and you need to enable/disable some options for a particular task. The patch is against dillo 8.5. Please apply if you think it is ok to do so and the patch fits in the dillo philisophy. Ciao, Tito

July 10, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Roberto A. Foglietta wrote: > http://www.roberto.foglietta.name/pub/dillo/ > > It able to refresh AND redirect, but only if -r option is specified in > command line. May be you can modify it to refresh ALWAYS and use -r > option ONLY for redirect when time is more than the specified offset > > -r <seconds> The more I think about how I'd go about hacking this functionality in, the more questions it brings up... As well as a time boundary, I think it would probably be best to include another option to specify which refreshes to honour. At the moment it's a simple choice between 1 (default): no refresh 2 (with -r): all refreshes permitted Rather than changing the first to be "refresh only, no redirect", could I suggest some kind of choice between the following three? 1: no refresh 2: refreshes allowed, redirects not 3: refreshes + redirects permitted And then we get into the murky area of limiting the times for these. Could/should it be a different value for refreshes and for redirects? What to do if the page requests a shorter timeout than allowed: ignore it altogether, or handle after the minimum timeout has elapsed? Is that too many command-line options? Would an entry (or several) in dillorc be more suitable? Glyn

July 9, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Glyn Kennington wrote: > I can write the necessary trivial patch to insert such a check if people > agree that it's The Right Thing, but I thought I'd better check that > I've interpreted the spec properly (and am reading the right bit of it) > before I do so. Well, as nobody's tried to put me right on this, here's some patches (taken against current CVS, and they can be applied to 0.8.5): First, the "safe" patch. This removes the reference to the spec's "explicit recommendation" if it's a simple refresh with no redirection. A warning is still generated. Second, the "controversial" patch ;-). This removes the warning altogether when the refresh doesn't involve redirection. Glyn

July 9, 2005

Re: [Dillo-dev]viewing non-web files

by Michael Kropfberger

-----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-----

July 6, 2005

Re: [Dillo-dev]viewing non-web files

by Matthias Franz

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

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Diego Sáenz

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(a)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

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Michael Kropfberger

-----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-----

July 5, 2005

Re: [Dillo-dev]Meta-refresh warning

by Roberto A. Foglietta

Glyn Kennington wrote: > While using dillo to check some pages for AnyBrowser-friendliness, I've > encountered the warning inserted whenever a <meta http-equiv="refresh" > ...> tag is used. I interpreted this as meaning that the HTML I'd > written was in some way wrong, and I should find another way to achieve > the same effect. > > The warning says: > > This page uses the NON-STANDARD meta refresh tag. The HTML 4.01 > SPEC\n" " (sec 7.4.4) recommends explicitly to avoid it. > > I checked that part of the HTML spec to see exactly what it said, and > whether it suggested any better alternatives. However, all that section > has to say about the use of "refresh" is: > > ( http://www.w3.org/TR/html401/struct/global.html#h-7.4.4 ) > > 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. > > My understanding of that paragraph is that it's only recommending > against redirection, in which the refresh tag specifies that a different > page should be loaded after the timeout. It might additionally mean > that it's only discouraged for "instant" (ie. delay=0) redirection. > > OTOH, refreshing the same page (which is what I'm trying to do with the > page that I'm writing) should be OK. In this case, shouldn't dillo only > complain if the "content" part of the tag contains a "URL=" (even if it > won't handle the refresh without the aid of the meta-refresh patch)? > > I can write the necessary trivial patch to insert such a check if people > agree that it's The Right Thing, but I thought I'd better check that > I've interpreted the spec properly (and am reading the right bit of it) > before I do so. > May be you can modify my patch, as far I know it works with 0.8.5 http://www.roberto.foglietta.name/pub/dillo/ It able to refresh AND redirect, but only if -r option is specified in command line. May be you can modify it to refresh ALWAYS and use -r option ONLY for redirect when time is more than the specified offset -r <seconds> 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

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Diego Sáenz

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(a)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(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Matthias Franz

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

July 4, 2005

[Dillo-dev]viewing non-web files, thanks, etc

by Daniel C. Bastos

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

July 4, 2005

Re: [Dillo-dev]cookies dpi over https and dpi framework

by Diego Sáenz

Hello, i have found that the problem was in https dpi. Under some circunstances, self signed certificate and formated in some way, the https dpi died. I send a patch to fix it. The patch is for dillo 0.8.5 but surely it works in previous versions, only touches dpi/https.c, it works with or without cookies.dpi patch, whitout cokies.dpi patch only the first dillo have cookies. I send a this mail with cc to the list to make it,the new(and the fix), public so the people can test it ASAP. Diego Sáenz/DarkSpirit. 8<--------------------CUT HERE------------------>8 diff -pru dillo-0.8.5-DIRTY/dpi/https.c dillo-0.8.5-WORK/dpi/https.c --- dillo-0.8.5-DIRTY/dpi/https.c 2005-07-03 23:25:06.000000000 +0200 +++ dillo-0.8.5-WORK/dpi/https.c 2005-07-03 23:29:23.000000000 +0200 @@ -331,6 +331,7 @@ static int handle_certificate_problem(SS int retval = -1; long st; char buf[4096]; + char * cn, * cn_end; X509 * remote_cert; @@ -363,12 +364,16 @@ static int handle_certificate_problem(SS case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: /*Either self signed and untrusted*/ /*Extract CN from certificate name information*/ - strncpy(buf, (strstr(remote_cert->name, "/CN=") + 4), - (size_t)(strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - - strstr(remote_cert->name, "/CN=")- 4)); + cn = strstr(remote_cert->name, "/CN=") + 4; + if (cn == NULL) break; + + if ((cn_end = strstr(cn, "/")) == NULL ) cn_end = cn + strlen(cn); + + strncpy(buf, cn, (size_t) (cn_end - cn)); + /*Add terminating NULL*/ - buf[strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - - strstr(remote_cert->name, "/CN=")- 3] = 0; + buf[cn_end - cn] = 0; + sock_handler_printf(sh, 1, "<dpi cmd='dialog' msg='%s%s' alt1='%s' alt2='%s' alt3='%s'>", "The remote certificate is self-signed and untrusted.\n" 8<----------------------CUT HERE------------------------>8 El Tue, 28 Jun 2005 00:13:24 +0200 Jorgen Viksell <jviksell(a)dillo.org> escribio: > OK, now it's up at: > https://www.dillo.org/~jviksell/test.php > http://www.dillo.org/~jviksell/test.php > > It sends four secure cookies and four unsecure. > > Cheers, > Jörgen

July 3, 2005