- Dillo-dev - lists.mailman3.com

tabs, https, ...

by taj＠www.linux.org.uk

I've been following the dillo mail list for a while getting a feel for what is up; Good things! With the external patches, I'd be willing to toss in a cvs server that mirrors the base dillo and has modified branches for various interests or even one merged branch. The intent would be to just keep a seperate single repository for external work which dillo could merge portions that fit it's philosophy. The offer would include www,cvs,ftp and shell access for developers that post their nontrivial patches to the official mail-list. -- Trent Jarvi taj(a)www.linux.org.uk

Nov. 17, 2003

Re: [Dillo-dev] gushort for port instead of guint

by Indan Zupancic

> What about the port in DilloUrl then? A port is always a unsigned short, can store it as an int if you want, but doesn't make much sense. I only looked at Dillo's IO code, so didn't notice the one in DilloUrl. It's really not very important, but in the case of SocketData it at least makes the structure smaller, DilloUrl stays the same size. Greetings, Indan

Nov. 16, 2003

Re: [Dillo-dev] HTTPS Patch

by Mike Eriksen

Thank you, Indan! This works great! I hope you will consider to match your HTTPS patch against Franks frames/tab patch once in a while. It makes life so much easier for amatuers like myself. If you guys manage to get the branching to work, this will of course be solved this way. A short note to people trying to compile on Red Hat 9.0: Add: EXPORT CPPFLAGS=-I/usr/kerberos/include in front of "./configure" (and don't forget to to change the zcat lines from "...patch" to "...patch.gz" as pointed out elsewhere) Mike On Fri, 14 Nov 2003, Indan Zupancic wrote: > Hello, > > I made a version of my https patch which works with Frank's tabs patch, > version 14 I think, there was one silly reject. I also made a simple > (unfinished) script to get a patched Dillo version from CVS, edit it for > your needs: > > ------- script ------- > #!/bin/sh > > CFLAGS="-O2 -s -pipe" > > mkdir Dillo-patched > cd Dillo-patched > echo "Getting Dillo source..." > cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co -D > "11/10/03" dillo > > echo "Getting patches..." > wget "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" > wget "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" > cd dillo > > echo "Applying tabs patch..." > zcat ../dillo-20031110-tabs.patch | patch -p1 > echo "Applying https patch..." > zcat ../dillo-20031110-https.patch | patch -p1 > > ./autogen.sh > echo "Running configure..." > CFLAGS=$CFLAGS ./configure > > #echo "Compiling patched Dillo..." > #make > #echo "Install patched Dillo?" > #su > #make install > #exit > #cd ../../ > #rm -rf Dillo-patched > ------- end script ------- > > Greetings, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 16, 2003

Re: [Dillo-dev] gushort for port instead of guint

by Stephan Goetter

Am Sat, Nov 15, 2003 at 07:09:43PM +0100 schrieb Indan Zupancic und sprach: > Hello, > > Just a tiny cleanup, ports are always shorts, so no need to make it an > int. It also makes the structure SocketData 4 bytes smaller because of > less padding. > > diff -purN orig/src/IO/http.c https/src/IO/http.c > --- orig/src/IO/http.c 2003-11-11 22:15:39.000000000 +0100 > +++ https/src/IO/http.c 2003-11-15 18:26:01.000000000 +0100 > @@ -58,7 +58,7 @@ G_STMT_START { > typedef struct { > gint SockFD; > const DilloUrl *Url; /* reference to original URL */ > - guint port; /* need a separate port in order to support > PROXY */ > + gushort port; /* need a separate port in order to support > PROXY */ > gboolean use_proxy; /* indicates whether to use proxy or not */ > DilloWeb *web; /* reference to client's web structure */ > GSList *addr_list; /* Holds the DNS answer */ > What about the port in DilloUrl then? Stephan

Nov. 16, 2003

gushort for port instead of guint

by Indan Zupancic

Hello, Just a tiny cleanup, ports are always shorts, so no need to make it an int. It also makes the structure SocketData 4 bytes smaller because of less padding. Greetings, Indan diff -purN orig/src/IO/http.c https/src/IO/http.c --- orig/src/IO/http.c 2003-11-11 22:15:39.000000000 +0100 +++ https/src/IO/http.c 2003-11-15 18:26:01.000000000 +0100 @@ -58,7 +58,7 @@ G_STMT_START { typedef struct { gint SockFD; const DilloUrl *Url; /* reference to original URL */ - guint port; /* need a separate port in order to support PROXY */ + gushort port; /* need a separate port in order to support PROXY */ gboolean use_proxy; /* indicates whether to use proxy or not */ DilloWeb *web; /* reference to client's web structure */ GSList *addr_list; /* Holds the DNS answer */

Nov. 15, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> Should that be: > zcat ../dillo-20031110-tabs.patch.gz | patch -p1 Oops, yes, of course. As I said, edit it for your needs. ;) Seems like I copied the wrong (untested) version, I mean, I tested the thing and it worked, so didn't expect that I would send the not working version, silly me. Well, jet another reason to not send emails too hasty. Thanks for pointing it out. Indan

Nov. 15, 2003

Re: [Dillo-dev] HTTPS Patch

by Johann Koenig

On Friday November 14 at 03:35pm Indan Zupancic <indan(a)nul.nu> wrote: > echo "Getting patches..." > wget > "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" > wget > "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" cd > dillo > > echo "Applying tabs patch..." > zcat ../dillo-20031110-tabs.patch | patch -p1 > echo "Applying https patch..." > zcat ../dillo-20031110-https.patch | patch -p1 Should that be: zcat ../dillo-20031110-tabs.patch.gz | patch -p1 ^^^^^ -- -johann koenig Today is Pungenday, the 26th day of The Aftermath in the YOLD 3169 My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp

Nov. 15, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Hello, I made a version of my https patch which works with Frank's tabs patch, version 14 I think, there was one silly reject. I also made a simple (unfinished) script to get a patched Dillo version from CVS, edit it for your needs: ------- script ------- #!/bin/sh CFLAGS="-O2 -s -pipe" mkdir Dillo-patched cd Dillo-patched echo "Getting Dillo source..." cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co -D "11/10/03" dillo echo "Getting patches..." wget "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" wget "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" cd dillo echo "Applying tabs patch..." zcat ../dillo-20031110-tabs.patch | patch -p1 echo "Applying https patch..." zcat ../dillo-20031110-https.patch | patch -p1 ./autogen.sh echo "Running configure..." CFLAGS=$CFLAGS ./configure #echo "Compiling patched Dillo..." #make #echo "Install patched Dillo?" #su #make install #exit #cd ../../ #rm -rf Dillo-patched ------- end script ------- Greetings, Indan

Nov. 14, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Hello, I looked a bit more into it, and found several revision systems, one of them Subversion. The most important part is how good the program is in merging branches, because that's the most work. Normal diff can't handle it very well, CVS makes it only easier to fix it manually from what I saw of it, so that is what the main advantages of Subversion and Arch should be, easy merging. After reading some docs it seems that Arch is harder to setup and handle, but probably better, and Subversion much easier to use, but not really distributed. Several sites said that Bitkeeper is the best, only it has a not too nice license and isn't open source. I think it's time to find other patch makers, and see how far we can come with plain diffs and CVS first. Using Arch would probably make it easier to handle multiple branches, but may also scare away potential patch makers (meaning that they probably will use diffs and that someone else must apply them to an Arch branch). Subversion has the advantage that it resembles CVS much more, so it's easier to start with. Greetings, Indan ------------------------------------------------------------------ HTTPS patch: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz ------------------------------------------------------------------

Nov. 14, 2003

Re: [Dillo-dev] HTTPS Patch

by Paul Pelzl

Subversion is certainly "a compelling replacement for CVS" (to use the words of the SVN developers), but it lacks proper support for distributed repositories. I think this feature is ideal for Free software projects, as it makes it easy for developers to make contributions without having to worry about who has write access at a central repository. Paul On Fri, Nov 14, 2003 at 08:14:45AM +0100, Lars Segerlund wrote: > How about considering subversion ? ( www.tigris.org ). > > I have been using it at work for about a year with really good results. It can really do branches and such, also handles directories in a sane way. > > / regards, LArs Segerlund. > > On Thu, 13 Nov 2003 02:46:56 +0100 (CET) > "Indan Zupancic" <indan(a)nul.nu> wrote: > > > > I've made some scripts which create a temporary copy of the dillo CVS > > > dir and the patched dir, remove all unwanted crud from the patched dir, > > > do the diff and generate some statistics. I can send them if you want. > > > > Hm, a script, didn't thought about that. No need to send them though, can > > make my own if I need any. > > > > > Of course this still leaves the issues with patch makers constantly > > > being out of sync with eachother, and each patch being broken by updates > > > to CVS shortly after the patch was posted. More on that later... > > > > What about making a seperate Dillo repository, but instead of using CVS > > that is too centralized and can't handle branches very well (or so I > > heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > > thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > > easier to manage all the patches, with one branch for each "patch" (one > > branch for https, one for tab+frames, etc). The hardest part should be to > > keep our main branch in sync with Dillo's CVS. > > > > Greetings, > > > > Indan > > > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev(a)lists.auriga.wearlab.de > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 14, 2003

Re: [Dillo-dev] HTTPS Patch

by Lars Segerlund

How about considering subversion ? ( www.tigris.org ). I have been using it at work for about a year with really good results. It can really do branches and such, also handles directories in a sane way. / regards, LArs Segerlund. On Thu, 13 Nov 2003 02:46:56 +0100 (CET) "Indan Zupancic" <indan(a)nul.nu> wrote: > > I've made some scripts which create a temporary copy of the dillo CVS > > dir and the patched dir, remove all unwanted crud from the patched dir, > > do the diff and generate some statistics. I can send them if you want. > > Hm, a script, didn't thought about that. No need to send them though, can > make my own if I need any. > > > Of course this still leaves the issues with patch makers constantly > > being out of sync with eachother, and each patch being broken by updates > > to CVS shortly after the patch was posted. More on that later... > > What about making a seperate Dillo repository, but instead of using CVS > that is too centralized and can't handle branches very well (or so I > heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > easier to manage all the patches, with one branch for each "patch" (one > branch for https, one for tab+frames, etc). The hardest part should be to > keep our main branch in sync with Dillo's CVS. > > Greetings, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 14, 2003

Re: [Dillo-dev] Cross Compiling for arm

by Donald McKnight

Same issue it located everything fine except for the X11R6 Headers, I corrected this but I get some errors on the make and they are below: dw_table.c: In function `Dw_table_construct_last_iterator': dw_table.c:649: warning: `child' might be used uninitialized in this function In file included from /opt/arm-linux/include/jpeglib.h:28, from jpeg.c:29: /opt/arm-linux/include/jconfig.h:12: warning: `HAVE_STDLIB_H' redefined ../config.h:38: warning: this is the location of the previous definition /opt/arm-linux/bin/ld: warning: cannot find entry symbol _start; defaulting to 00013c64 /opt/arm-linux/bin/ld: warning: cannot find entry symbol _start; defaulting to 000099b4 Strange this is when I launch it on arm it doesnt give any errors it just sits there and never opens unless I kill it Im lost at this point Thanks for the feed back Donald ----- Original Message ----- From: "Jorge Arellano Cid" <jcid(a)dillo.org> To: "Donald McKnight" <donald.mcknight(a)sbcglobal.net> Cc: "Dillo mailing list" <dillo-dev(a)lists.auriga.wearlab.de> Sent: Thursday, November 13, 2003 1:09 PM Subject: Re: [Dillo-dev] Cross Compiling for arm > > > On Thu, 13 Nov 2003, Donald McKnight wrote: > > > Hello, > > I recently downloaded 0.7.3 to cross compile on the gmate yopy > 3700. with my first attempt I noticed the configure script > grabbed all of my local variables such as /usr/local/lib instead > of /opt/arm-linux/lib. This gave me libgtk.so cannot read > symbols. I went though the configure and manually set the > environment variables and was able to successfully compile dillo, > however when I transfer the binary to arm it does not launch it > just hangs. I have cross-compiled several apps using the same > cross-compiler on my system. I am using slackware 9.1 kernel > 2.4.22, but I don't think the version should matter. Has anyone > ran into this before? > > > Hmmm, I've not been cross compiling dillo, but there's this > portion of code in configure.in: > > dnl -------------------------------------- > dnl Check whether to add /usr/local or not > dnl (this is somewhat a religious problem) > dnl -------------------------------------- > dnl > if test ! "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include'`"; then > CPPFLAGS="$CPPFLAGS -I/usr/local/include" > LDFLAGS="$LDFLAGS -L/usr/local/lib" > fi > > > Please comment it out, re-run autogen and see what happens. > > If you can't find the answer here, maybe the guys at familiar > may hint you better. > > > HTH > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 13, 2003

Re: [Dillo-dev] Cross Compiling for arm

by Jorge Arellano Cid

On Thu, 13 Nov 2003, Donald McKnight wrote: > Hello, > I recently downloaded 0.7.3 to cross compile on the gmate yopy 3700. with my first attempt I noticed the configure script grabbed all of my local variables such as /usr/local/lib instead of /opt/arm-linux/lib. This gave me libgtk.so cannot read symbols. I went though the configure and manually set the environment variables and was able to successfully compile dillo, however when I transfer the binary to arm it does not launch it just hangs. I have cross-compiled several apps using the same cross-compiler on my system. I am using slackware 9.1 kernel 2.4.22, but I don't think the version should matter. Has anyone ran into this before? Hmmm, I've not been cross compiling dillo, but there's this portion of code in configure.in: dnl -------------------------------------- dnl Check whether to add /usr/local or not dnl (this is somewhat a religious problem) dnl -------------------------------------- dnl if test ! "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include'`"; then CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" fi Please comment it out, re-run autogen and see what happens. If you can't find the answer here, maybe the guys at familiar may hint you better. HTH Jorge.-

Nov. 13, 2003

Cross Compiling for arm

by Donald McKnight

Hello, I recently downloaded 0.7.3 to cross compile on the gmate yopy 3700. with my first attempt I noticed the configure script grabbed all of my local variables such as /usr/local/lib instead of /opt/arm-linux/lib. This gave me libgtk.so cannot read symbols. I went though the configure and manually set the environment variables and was able to successfully compile dillo, however when I transfer the binary to arm it does not launch it just hangs. I have cross-compiled several apps using the same cross-compiler on my system. I am using slackware 9.1 kernel 2.4.22, but I don't think the version should matter. Has anyone ran into this before? Thanks Donald McKnight

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

On Thu, Nov 13, 2003 at 04:40:35PM +0100, Stephan Goetter wrote: > Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach: > > > I think something like Arch or Subversion, with an accompanying Wiki for > > > developers and users to converse (and converge) is a good idea. > > > > I'm starting to doubt the whole idea, how nice it may be: Are there any > > other active patch makers out there except us? > > I'm working on JavaScript support for dillo using the SpiderMonkey > C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ At some point I was thinking (or rather fanatsising :-) ...) about using http://www.bbassett.net/njs/ as a Javascript Interpreter. (That was when I first understood plugins and played with them.) > The patch is not yet stable/clean enough to post it here and it lacks > a lot. Currently I try to clean it up and get the focus set on google. Google uses Javascript ? > I know most people here have low-end machines and there is probably no > interest in JavaScript support in the main branch. IMHO it could be useful to have an extremely light implementation. Only the OnClick, OnSUbmit things. I read on the specs etc., understood only a portion and probably remember only a tiny fraction now :-). But I remember, that it may make sense to only implement a handful of Javascriopt things (as you see, I even forgot the terminology), It may still be compaitible with dillo's design goals. I was mainly thinking of the sites that use Javascript to pop up new windows on clicking some links - which could just as easily be implemented in HTML. I.e. the ones that don't know the difference between Javascript and HTML. Also, the OnSUbmit thing seems to be useful for checking form values before submissions. However, all in all, I use dillo because it does NOT support Javascript and let the browser invade my desktop :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Stephan Goetter

Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach: > > I think something like Arch or Subversion, with an accompanying Wiki for > > developers and users to converse (and converge) is a good idea. > > I'm starting to doubt the whole idea, how nice it may be: Are there any > other active patch makers out there except us? I'm working on JavaScript support for dillo using the SpiderMonkey C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ Code as part of the html-file can already be executed. <script>...</script>, window.*(), window.status, location, history, href="javascript:.." do work. The patch is not yet stable/clean enough to post it here and it lacks a lot. Currently I try to clean it up and get the focus set on google. I thought about a patch on top of Frank's patch as I'm using this every day but this wouldn't make things easier. I know most people here have low-end machines and there is probably no interest in JavaScript support in the main branch. Greets, Stephan

Nov. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [11-13-03 03:25]: > > Those of you who want to keep the conditional compilation options for > tabs and frameset support in the tab/frame patch, speak up now. If I > do not get any serious requests in this direction I will remove the > conditional compilation options in the next patch (any day now...) > and you'll all be stuck with tabs and frames. But... that might be > the reason you applied the patch in the first place, so... Drop the conditional compilation and provide new-window/tab option in the rc file. tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Paul Pelzl

On Thu, Nov 13, 2003 at 02:46:56AM +0100, Indan Zupancic wrote: > What about making a seperate Dillo repository, but instead of using CVS > that is too centralized and can't handle branches very well (or so I > heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > easier to manage all the patches, with one branch for each "patch" (one > branch for https, one for tab+frames, etc). The hardest part should be to > keep our main branch in sync with Dillo's CVS. The best way to handle that with Arch is to have a "CVS gateway" branch that contains only unmodified CVS sources. Other branches (https, tab/frame, etc.) would be tags ("continuations") of the CVS gateway, which would make it relatively easy to merge in patches from CVS. Of course, the "merge in" is where work is sometimes involved, but I don't know of any general solution to that problem. Paul

Nov. 13, 2003

Re: [Dillo-dev] [RFC] keywords

by Paul Pelzl

On Thu, Nov 13, 2003 at 12:51:06PM +0100, Frank de Lange wrote: > in the location bar, which is interpreted as "search for something or > other" through this keyword definition in the dillorc: > > s:http://www.google.com/search?q= > > You can define as many as these as you want. The format is > > keywords = "<keyword>:<url> <keyword>:<url> ..." I think this is an elegant way to handle it. The most immediate benefit I see is that I can (probably) set up keywords for multiple search sites (teoma, turbo10, alltheweb, etc.). > [ and on the subject of preferences... I know what Havoc et al say, but > I do not always agree... In many cases choice is a good thing, as > long as it is not mandatory to choose. Define sane defaults for those > who can not or do not want to choose, but keep things flexible for > those who want to change those defaults. TIMTOWTDI ] I could not agree more. Paul

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

On Thu, Nov 13, 2003 at 09:50:29AM +0100, Thorben Thuermer wrote: > On Thu, 13 Nov 2003 07:59:50 +0100 > Frank de Lange <frank(a)unternet.org> wrote: > > Indan Zupancic wrote: > > > > >What about making a seperate Dillo repository, but instead of using CVS > > >that is too centralized and can't handle branches very well (or so I > > >heard), <snip> > erm... or http://auriga.wearlab.de/ ? ;) Or while at it, use indeed the branch mechanism. In the documentation it does not look that much different from current diff-ing. Furthermore, CVS can be configured (with add-ons) to allow certain comittors only comit into certain branches. This is handled via comittinfo and cvs_acls. cvs_acls is a perl script that is at least in the source tar ball of cvs in the contrib section. Most installations of cvs keep it somewhere ( .../share/.../cvs/.../contrib/ ) If ypu should not have a local copy, check http://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in where it is documented in detail how to restrict users to branches. That way, Jorge and Sebastian keep control over the main branch as it is right now, but dedicated branchers could have their repository in the same place. And users simply need to check out these experimental branches. The branchesr only need to marge from current regularly. Of course, I don't know how wearlab has organized their CVS setup and if that would be acceptable. Also, I hope that Jorge or Sebastian read that far down in the thread ;-) ... Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Frank de Lange

Indan Zupancic wrote: > Hello, > > If it will stay a patch always, then you can remove it without problems. I > think you should treat the code as if it is offical, so use only > conditions where you would normally do, otherwise you may need to add them > back later if it's merges with Dillo's code. So the question is, should > Dillo have always tabs and/or frames support? Point is, Sebastian (of Dw fame) has stated that he does not like the conditional compilation options as it complicates code maintenance (which is true). My standpoint was that not everyone liked or needed the extended functionality or (more importantly) could spare the memory for it. I have asked several times on the list whether these options should stay or go, but have not gotten a clear 'stay' response. So, I intend to remove the options since there does not seem to be a need for them. On tab/window preferences, there already is a preference to open new windows in tabs (tab_instead_of_window=YES). I will add an option to ignore the _blank target for those who do not like their browser to open new windows or tabs at random (check the archives for some examples of people complaining about this). Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Frank de Lange

Indan Zupancic wrote: >>I think something like Arch or Subversion, with an accompanying Wiki for >>developers and users to converse (and converge) is a good idea. > > > I'm starting to doubt the whole idea, how nice it may be: Are there any > other active patch makers out there except us? If there are, they're hiding in the woodwork. However, this is partly caused by the current way patches are handled. Dillo is not the most patch-friendly project I know of. > If not, then is it worth > all the trouble? For me it's very easy to keep my https patch in sync with > your tabs+frames patch, I'll just sync with CVS when you have a new > version, and then attach your version number to the filename, so that it's > clear which patches are compatible with eachother. Of course doing the > same with other patches won't be as easy, because they may conflict, > something that's unlikely with the https patch and frames+tabs patch. But that means you are dependent on my quirky release schedule... Something you might not like. There can be weeks, but also days between paches. And I do not always keep up to date with the CVS version du jour. But no, I do not know if it is worth the trouble to set up an Arch/Subversion server for this. Unless... > What are the advantages of being a GNU project? Exposure, mindshare. 'Everybody knows GNU'. Continuity of maintenance, sort of. Hosting at Savannah (also open to non-GNU projects). No Arch yet, but that might change... Anyway, it is not ours to decide for Dillo to apply to become a GNU project. Jorge, have you thought about this possibility? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] [RFC] external Dillo splash screen

by Indan Zupancic

Hello, No, you misunderstood me Arnold, but that way you also brought new ideas. :) What I meant was that splash_url= or splash_url="" would mean that there is no splash screen at all, while commenting the setting out will give you the default splash screen. This also means it's very easy to get the default back, something both Frank and I overlooked. Show_splash may be more intiutive, but it is so only when it is mentioned in dillorc. One comment above splash_url to tell the user to set it to "" for no splash screen is as easy then. What about a compromis; splash=[NO | url] or something like that? Default is the path to the default splash screen, NO and "" ("" means strlen=0, so splash= is the same) disable it. Also don't forget that whatever option you give, it's much better than the official Dillo that loads it's splash screen ALWAYS, even when you start it with "dillo some_file". Greetings, Indan

Nov. 13, 2003

[RFC] keywords

by Frank de Lange

While we're talking preferences anyway... I have another addition to the range: keywords. In my current version you can type "s something or other" in the location bar, which is interpreted as "search for something or other" through this keyword definition in the dillorc: s:http://www.google.com/search?q= You can define as many as these as you want. The format is keywords = "<keyword>:<url> <keyword>:<url> ..." The end result of a successful keyword match consists of the url for the keyword, followed by an escaped copy of anything that followed the keyword. The above example for "s" looks like this: http://www.google.com/search?q=something%20or%20other This adds next to nothing to the size of Dillo by the way. Any strong sentiments against this functionality? [ and on the subject of preferences... I know what Havoc et al say, but I do not always agree... In many cases choice is a good thing, as long as it is not mandatory to choose. Define sane defaults for those who can not or do not want to choose, but keep things flexible for those who want to change those defaults. TIMTOWTDI ] Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Indan Zupancic

Hello, If it will stay a patch always, then you can remove it without problems. I think you should treat the code as if it is offical, so use only conditions where you would normally do, otherwise you may need to add them back later if it's merges with Dillo's code. So the question is, should Dillo have always tabs and/or frames support? Always frame support makes more sense that always tabs support in my opinion, but just an option in dillorc to enable/disable them is probably enough, both runtime and compile time options may be overkill. The choice should be new windows or new tabs, there is not much more annoying than a new window when the browser supports tabs, the user also can't know if the link will change the current page or pop up a new one. Greetings, Indan

Nov. 13, 2003

Re: [Dillo-dev] [RFC] external Dillo splash screen

by Frank de Lange

Arnold wrote: > Frank: > I'm not sure that I understand your point. > > It would seem that Indan's solution eliminates the need an additional preference setting and still provides fallback to the internal default splash url when splash_url is not explicitly specified as nil, by taking advantage of > non-mandatory nature of .dillorc prefs. True, I had not thought about that aspect. The splash will only be 'completely' gone if someone removes it from the defaults in prefs.c. My point is that Dillo uses 'show_...' for all user interface elements, so for consistency I have added a show_splash. It would be possible to do without it, though. Point taken :-) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> I think something like Arch or Subversion, with an accompanying Wiki for > developers and users to converse (and converge) is a good idea. I'm starting to doubt the whole idea, how nice it may be: Are there any other active patch makers out there except us? If not, then is it worth all the trouble? For me it's very easy to keep my https patch in sync with your tabs+frames patch, I'll just sync with CVS when you have a new version, and then attach your version number to the filename, so that it's clear which patches are compatible with eachother. Of course doing the same with other patches won't be as easy, because they may conflict, something that's unlikely with the https patch and frames+tabs patch. > BTW, I also double as a software evaluator for the GNU project (Even > though I've not done many evaluations lately for lack of time), and > would be more than happy to get Dillo listed as a GNU project. What are the advantages of being a GNU project? Greetings, Indan

Nov. 13, 2003

Re: [Dillo-dev] [RFC] external Dillo splash screen

by Arnold

Frank: I'm not sure that I understand your point. It would seem that Indan's solution eliminates the need an additional preference setting and still provides fallback to the internal default splash url when splash_url is not explicitly specified as nil, by taking advantage of non-mandatory nature of .dillorc prefs. Why would dillo not revert to an internal default splash_url value when not explicitly specified in .dillorc as nil or a value? In other words, when the override of the splash_url to nil (ie. "splash_url=" ) was deleted or commented out, why would dillo not use its own internal hard-coded default? Thanks for your great work to continue to improve dillo! Arnold On Thu, 13 Nov 2003 07:49:56 +0100 Frank de Lange <frank(a)unternet.org> wrote: > Indan Zupancic wrote: > > >Hello, > > > >Inspired by my idea, or something you were thinking about before? Just > >curious (everyone that takes a look at about.c should get the idea IMHO). > > > Both. I looked at the file before and felt slightly uneasy. Then you > mentioned it, I thought 'what the heck let's try it', and 5 minutes > later it worked. > > >Don't add unnecessary parameters like show_splash, just use splash_url="" > >for no splash screen. > > > Hm, that would make it hard for people who have (or for whom someone > has) disabled the splash to get it back, as they have to know the url. A > simple YES/NO is better and not very intrusive. Be aware of the fact > that the prefs have sane defaults, they are not mandatory. Having > 'show_splash=NO' in a preference file (or a checkbox in a preference > screen/page if you prefer) is easier and more intuitive than setting an > URL to an empty string. > > Cheers//Frank >

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Thorben Thuermer

On Thu, 13 Nov 2003 07:59:50 +0100 Frank de Lange <frank(a)unternet.org> wrote: > Indan Zupancic wrote: > > >What about making a seperate Dillo repository, but instead of using CVS > >that is too centralized and can't handle branches very well (or so I > >heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > >thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > >easier to manage all the patches, with one branch for each "patch" (one > >branch for https, one for tab+frames, etc). The hardest part should be to > >keep our main branch in sync with Dillo's CVS. > > > I think something like Arch or Subversion, with an accompanying Wiki for > developers and users to converse (and converge) is a good idea. As I do > not yet have a server here in Sweden (damn broadband which is not here, > but everywhere else...) I can not host this, someone with the resources > and time care to chime in? > > Of course there is always Savannah (http://savannah.gnu.org) > Sourceforge, etc. erm... or http://auriga.wearlab.de/ ? ;) > Cheers//Frank Greetings, Thorben

Nov. 13, 2003

[RFC] Last call... remove conditional compilation from tab/fram patch?

by Frank de Lange

Hi'all, Those of you who want to keep the conditional compilation options for tabs and frameset support in the tab/frame patch, speak up now. If I do not get any serious requests in this direction I will remove the conditional compilation options in the next patch (any day now...) and you'll all be stuck with tabs and frames. But... that might be the reason you applied the patch in the first place, so... BTW, the selection issue with the tab/frame patch is solved, I just forgot to set the owner for the selection. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Frank de Lange

Indan Zupancic wrote: >What about making a seperate Dillo repository, but instead of using CVS >that is too centralized and can't handle branches very well (or so I >heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, >thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much >easier to manage all the patches, with one branch for each "patch" (one >branch for https, one for tab+frames, etc). The hardest part should be to >keep our main branch in sync with Dillo's CVS. > > I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea. As I do not yet have a server here in Sweden (damn broadband which is not here, but everywhere else...) I can not host this, someone with the resources and time care to chime in? Of course there is always Savannah (http://savannah.gnu.org) Sourceforge, etc. BTW, I also double as a software evaluator for the GNU project (Even though I've not done many evaluations lately for lack of time), and would be more than happy to get Dillo listed as a GNU project. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] [RFC] external Dillo splash screen

by Frank de Lange

Indan Zupancic wrote: >Hello, > >Inspired by my idea, or something you were thinking about before? Just >curious (everyone that takes a look at about.c should get the idea IMHO). > Both. I looked at the file before and felt slightly uneasy. Then you mentioned it, I thought 'what the heck let's try it', and 5 minutes later it worked. >Don't add unnecessary parameters like show_splash, just use splash_url="" >for no splash screen. > Hm, that would make it hard for people who have (or for whom someone has) disabled the splash to get it back, as they have to know the url. A simple YES/NO is better and not very intrusive. Be aware of the fact that the prefs have sane defaults, they are not mandatory. Having 'show_splash=NO' in a preference file (or a checkbox in a preference screen/page if you prefer) is easier and more intuitive than setting an URL to an empty string. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> I've made some scripts which create a temporary copy of the dillo CVS > dir and the patched dir, remove all unwanted crud from the patched dir, > do the diff and generate some statistics. I can send them if you want. Hm, a script, didn't thought about that. No need to send them though, can make my own if I need any. > Of course this still leaves the issues with patch makers constantly > being out of sync with eachother, and each patch being broken by updates > to CVS shortly after the patch was posted. More on that later... What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS. Greetings, Indan

Nov. 13, 2003

Re: [Dillo-dev] Re: [RFC] Quo Vadis Dillo

by higuita

On Wed, 12 Nov 2003 12:18:40 -0500, Eythan Weg <weg(a)indiscrete.org> wrote: > Frank de Lange writes: > > Make a form which feeds two urls to a frameset page like that. Presto, > > two documents side by side. > Yes, but... inconvenient and besides it blends the > user with the page designer. Consider, perhaps, yes, but dont forget that dillo is suppose to be light and fast... if we start adding this kind of small things that most users will not use, we will start getting mozilla size 8) 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

Nov. 13, 2003

Re: [Dillo-dev] [RFC] external Dillo splash screen

by Indan Zupancic

Hello, Inspired by my idea, or something you were thinking about before? Just curious (everyone that takes a look at about.c should get the idea IMHO). > I've also added a new pref 'show_splash', which - you guessed it - can be > used to suppress the splash screen. Set it to NO, and Dillo will come up > with a blank window instead. Don't add unnecessary parameters like show_splash, just use splash_url="" for no splash screen. Greetings, Indan

Nov. 13, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Ken Wolcott

On Wednesday 12 November 2003 14:57, Thorben Thuermer wrote: > On Wed, 12 Nov 2003 14:18:38 -0600 > > Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > > Hi Thorben; > > > > If my proxy server refuses to resolve requests coming from the dillo > > web browser, it doesn't make any sense for it not to refuse requests from > > the mozilla web browser. The proxy settings are identical. One of them > > exists in the ~/.dillorc and the other exists in the mozilla advanced > > proxy setting preferences. So, it looks to me like dillo doesn't like my > > ~/.dillorc and isn't telling me that there's a problem. Mozilla works > > fine, dillo doesn't, the proxy settings are the same. > > it's not a problem of your proxy not liking dillo's requests: > > **** > > > > as long as your dillo tries to dns resolve the host of the url you > > > enter, it is for some reason NOT using a proxy at all. > > **** > > - your dillo does not use any proxy setting. > > - i do not know why. > > it's probably something simple... > > maybe try something like: > $ mv .dillo/dillorc .dillo/dillorc.bak > $ echo http_proxy=http://localhost:12345/ >.dillo/dillorc > ^^^^^^^^^^^^^^ > $ dillo http://www.google.com/ > Enabling cookies as from cookiesrc... > Connecting to 127.0.0.1 > > ... just read Victor's reply while writing this... > > but then what was > > > I noticed that the chatter from dillo no longer > > complained about a missing .dillorc > > about? > > > Ken > > Thorben > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Hi Thorben; Problem solved. The problem was that I incorrectly thought that the rc file should be ~/.dillorc instead of ~/.dillo/dillrc. Thanks, Ken

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environmen t?

by Ken Wolcott

On Wednesday 12 November 2003 15:08, Stephen Lewis wrote: > On Wed, Nov 12, 2003 at 09:57:39PM +0100, Thorben Thuermer wrote: > > ... just read Victor's reply while writing this... > > > > but then what was > > > > > I noticed that the chatter from dillo no longer > > > complained about a missing .dillorc > > > > about? > > I think you'll find that was a misinterpretation of > > Dillo: error reading /home/<user>/.dillo: No such file or directory > > Which gets created, so the next time you run dillo it doesn't > complain. Exactly what happened to me, now that I think about it. Thanks, Ken

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Stephen Lewis

On Wed, Nov 12, 2003 at 09:57:39PM +0100, Thorben Thuermer wrote: > > ... just read Victor's reply while writing this... > > but then what was > > I noticed that the chatter from dillo no longer > > complained about a missing .dillorc > about? I think you'll find that was a misinterpretation of Dillo: error reading /home/<user>/.dillo: No such file or directory Which gets created, so the next time you run dillo it doesn't complain. -- Stephen Lewis

Nov. 12, 2003

[RFC] external Dillo splash screen

by Frank de Lange

Hi'all, I've removed the Dillo splash screen from src/IO/about.c, and added a new preference 'splash_url' (currently set to '/usr/lib/dillo/dillo.html' by default, this can change). The contents of that file are identical to the current splash screen. I've also added a new pref 'show_splash', which - you guessed it - can be used to suppress the splash screen. Set it to NO, and Dillo will come up with a blank window instead. Dillo is now ca. 11 KB smaller than before. The splash screen loads just as fast. The splash screen can be distributed with Dillo just like the dpi's are. Should it be missing, all that'll happen is that Dillo will complain about not finding the file. No breakage... Seems like an improvement to me. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Thorben Thuermer

On Wed, 12 Nov 2003 14:18:38 -0600 Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > > Hi Thorben; > > If my proxy server refuses to resolve requests coming from the dillo web > browser, it doesn't make any sense for it not to refuse requests from the > mozilla web browser. The proxy settings are identical. One of them exists > in the ~/.dillorc and the other exists in the mozilla advanced proxy setting > preferences. So, it looks to me like dillo doesn't like my ~/.dillorc and > isn't telling me that there's a problem. Mozilla works fine, dillo doesn't, > the proxy settings are the same. it's not a problem of your proxy not liking dillo's requests: **** > > as long as your dillo tries to dns resolve the host of the url you enter, > > it is for some reason NOT using a proxy at all. **** - your dillo does not use any proxy setting. - i do not know why. it's probably something simple... maybe try something like: $ mv .dillo/dillorc .dillo/dillorc.bak $ echo http_proxy=http://localhost:12345/ >.dillo/dillorc ^^^^^^^^^^^^^^ $ dillo http://www.google.com/ Enabling cookies as from cookiesrc... Connecting to 127.0.0.1 ... just read Victor's reply while writing this... but then what was > I noticed that the chatter from dillo no longer > complained about a missing .dillorc about? > Ken Thorben

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environmen t?

by Ken Wolcott

Hi Stephen; That was **EXACTLY** the problem! I moved ~/.dillorc to be ~/.dillo/dillorc...Works fine now! Thanks, Ken On Wednesday 12 November 2003 14:35, Stephen Lewis wrote: > On Wed, Nov 12, 2003 at 02:18:38PM -0600, Ken Wolcott wrote: > > Hi Thorben; > > > > If my proxy server refuses to resolve requests coming from the dillo > > web > > > browser, it doesn't make any sense for it not to refuse requests from > > the > > > mozilla web browser. The proxy settings are identical. One of them > > exists > > > in the ~/.dillorc and the other exists in the mozilla advanced proxy > > setting > > > preferences. So, it looks to me like dillo doesn't like my ~/.dillorc > > and > > > isn't telling me that there's a problem. Mozilla works fine, dillo > > doesn't, > > > the proxy settings are the same. > > Hi, I think I just noticed the root of your problem. > > You're using a ~/.dillorc file. What dillo actually wants is a > ~/.dillo/dillorc file, I don't think it is using the file at > ~/.dillorc at all :) > > Another method is to set the "http_proxy" environment variable, > which many console progams like wget tend to honour > > Hope that helps.

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Victor Sahlstedt

On Wed, 12 Nov 2003 14:18:38 -0600 Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > [...] The proxy settings are identical. One of > them exists in the ~/.dillorc and the other exists in the mozilla > advanced proxy setting preferences. So, it looks to me like dillo > doesn't like my ~/.dillorc and isn't telling me that there's a > problem. Mozilla works fine, dillo doesn't, the proxy settings are > the same. Well, the dillorc provided in the Dillo-tarball should recide in ~/.dillo/ - i.e. the path should be ~/.dillo/dillorc and NOT ~/.dillorc - Victor

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Kelson Vibber

At 12:18 PM 11/12/2003, Ken Wolcott wrote: > If my proxy server refuses to resolve requests coming from the dillo web >browser, it doesn't make any sense for it not to refuse requests from the >mozilla web browser. The proxy settings are identical. One of them exists >in the ~/.dillorc and the other exists in the mozilla advanced proxy setting >preferences. So, it looks to me like dillo doesn't like my ~/.dillorc and >isn't telling me that there's a problem. Mozilla works fine, dillo doesn't, >the proxy settings are the same. The impression I get from the earlier posts is not that your proxy server is not resolving requests from Dillo, but that Dillo is not sending requests to the proxy server. As Thorben stated: > Dillo does not support those either, it needs the actual address and port > of the proxy. So if you use the IP address or a name listed in /etc/hosts, it sounds like it should work. (I've never used a proxy with Dillo, I'm just basing this on what I've read today.) Kelson Vibber www.hyperborea.org

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Ken Wolcott

On Wednesday 12 November 2003 13:53, Thorben Thuermer wrote: > On Wed, 12 Nov 2003 13:43:34 -0600 > > Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > > Hi Thorben; > > > > Thank you for your response. > > > > Yes, I didn't make myself very clear unfortunately, and I realized that > > some time after having sent the email msg. > > > > I did a diff of the supplied dillorc and my ~/.dillorc. The only line > > that differed was the extra line (copied http_proxy) that I had enabled > > with the correct URL for the proxy. What I provided in the email was the > > line that diff'd after it had been "sanitized". > > > > I had an "Automatic proxy configuration URL" set up for mozilla > > originally which is different than a "Manual proxy configuration" > > (http://ip:port) syntax. I decided to change the way the proxy was > > configured in mozilla to the form needed by dillo. It works fine. > > Dillo does not support those either, it needs the actual address and port > of the proxy. > as long as your dillo tries to dns resolve the host of the url you enter, > it is for some reason NOT using a proxy at all. > > > Are you saying that dillo under a proxy expects the proxy server to do > > all dns resolution? If that's the case, then why is galeon, mozilla, > > konquorer, netscape and opera working correctly under the proxy where > > dillo does not? I'm using the same proxy for all the web browsers I just > > mentioned. > > sorry, but: THIS IS HOW PROXY SERVERS WORK! > > the browsr forwards the proxy the request > "get me http://www.dillo.org/" > (to be exact: GET http://www.dillo.org/ HTTP/1.0") > and the proxy returns the page/image/resource, or a error. > > > Thanks, > > Ken > > greetings, > Thorben Hi Thorben; If my proxy server refuses to resolve requests coming from the dillo web browser, it doesn't make any sense for it not to refuse requests from the mozilla web browser. The proxy settings are identical. One of them exists in the ~/.dillorc and the other exists in the mozilla advanced proxy setting preferences. So, it looks to me like dillo doesn't like my ~/.dillorc and isn't telling me that there's a problem. Mozilla works fine, dillo doesn't, the proxy settings are the same. Ken

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Thorben Thuermer

On Wed, 12 Nov 2003 13:43:34 -0600 Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > Hi Thorben; > > Thank you for your response. > > Yes, I didn't make myself very clear unfortunately, and I realized that some > time after having sent the email msg. > > I did a diff of the supplied dillorc and my ~/.dillorc. The only line that > differed was the extra line (copied http_proxy) that I had enabled with the > correct URL for the proxy. What I provided in the email was the line that > diff'd after it had been "sanitized". > > I had an "Automatic proxy configuration URL" set up for mozilla originally > which is different than a "Manual proxy configuration" (http://ip:port) > syntax. I decided to change the way the proxy was configured in mozilla to > the form needed by dillo. It works fine. Dillo does not support those either, it needs the actual address and port of the proxy. as long as your dillo tries to dns resolve the host of the url you enter, it is for some reason NOT using a proxy at all. > Are you saying that dillo under a proxy expects the proxy server to do all > dns resolution? If that's the case, then why is galeon, mozilla, konquorer, > netscape and opera working correctly under the proxy where dillo does not? > I'm using the same proxy for all the web browsers I just mentioned. sorry, but: THIS IS HOW PROXY SERVERS WORK! the browsr forwards the proxy the request "get me http://www.dillo.org/" (to be exact: GET http://www.dillo.org/ HTTP/1.0") and the proxy returns the page/image/resource, or a error. > Thanks, > Ken greetings, Thorben

Nov. 12, 2003

Re: [Dillo-dev] Re: [RFC] Quo Vadis Dillo

by Thorben Thuermer

On Wed, 12 Nov 2003 10:36:34 -0500 Eythan Weg <weg(a)indiscrete.org> wrote: > > How about horizontal/vertical split of a tab. One > use for it is being able to compare side by side > different parts of the same document. at the point where you find that you also want you text editor side-by-side with dillo to edit your page and consider integrating one with dillo, you should notice that this is probably the wrong level to solve the problem at... such things seem less like a feature to add into a specific application, (ands to be repeated in each new application!) but ask for a more more general system, for example a windowmanager feature. <offtopic><plug> a windowmanager that implements such features is ion: http://modeemi.cs.tut.fi/~tuomov/ion/ while it's different managment models probably take time to get used to, it's perfect for such tasks. i made screenshots of a split dillo example: http://users.auriga.wearlab.de/~r00t/sidebyside-1.png http://users.auriga.wearlab.de/~r00t/sidebyside-2.png </plug></offtopic> > Eythan Greetings, Thorben

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Ken Wolcott

Hi Thorben; Thank you for your response. Yes, I didn't make myself very clear unfortunately, and I realized that some time after having sent the email msg. I did a diff of the supplied dillorc and my ~/.dillorc. The only line that differed was the extra line (copied http_proxy) that I had enabled with the correct URL for the proxy. What I provided in the email was the line that diff'd after it had been "sanitized". I had an "Automatic proxy configuration URL" set up for mozilla originally which is different than a "Manual proxy configuration" (http://ip:port) syntax. I decided to change the way the proxy was configured in mozilla to the form needed by dillo. It works fine. Are you saying that dillo under a proxy expects the proxy server to do all dns resolution? If that's the case, then why is galeon, mozilla, konquorer, netscape and opera working correctly under the proxy where dillo does not? I'm using the same proxy for all the web browsers I just mentioned. Thanks, Ken On Wednesday 12 November 2003 13:08, Thorben Thuermer wrote: > On Wed, 12 Nov 2003 10:53:45 -0600 > > Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > > Hi; > > > > Dillo looks interesting. However I can't go anywhere with it as I am > > under a proxy environment. I saw that the default dillorc has a > > commented-out section for http_proxy. I copied the default dillorc to be > > my ~/.dillorc and started dillo again. > > you DID uncomment the http_proxy line and edit it to insert YOUR proxy's > address? > > (using a local wwwoffle proxy on my notebook) > $ grep -i proxy .dillo/dillorc > # Set the proxy information for http > http_proxy=http://localhost:8080/ > no_proxy = "wl localhost" > > note that plain dillo does currently NOT support proxy authentication. > > >I noticed that the chatter from dillo no longer > > complained about a missing .dillorc, yet I am still unable to go to any > > URL. The message on the web browser was: "Error: Dns: can't resolve > > http://linuxtoday.com". I get the same basic error message when trying > > to go to www.perl.com or http://www.perl.com. I am able to go to these > > web sites using other web browsers such as mozilla, galeon, opera, > > netscape and konqueror. Each one of those I had to set a proxy > > preference. Perhaps my proxy setting has incorrect syntax? Enclosed is > > the chatter from dillo and the .dillorc (proxy setting has obviously been > > sanitized). > > > > Thanks, > > Ken > > > > prompt> dillo > > Nav_open_url: Url=>http://linuxtoday.com/< > > Dns_server [0]: linuxtoday.com is (nil) > > when using a proxy, dillo would never try to resolve the DNS > of the URL you entered, but only connect to the proxy host: > > $ dillo > Enabling cookies as from cookiesrc... > Connecting to 127.0.0.1 > > Greetings, > Thorben > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 12, 2003

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environment?

by Thorben Thuermer

On Wed, 12 Nov 2003 10:53:45 -0600 Ken Wolcott <ken.wolcott(a)med.ge.com> wrote: > Hi; > > Dillo looks interesting. However I can't go anywhere with it as I am under > a proxy environment. I saw that the default dillorc has a commented-out > section for http_proxy. I copied the default dillorc to be my ~/.dillorc and > started dillo again. you DID uncomment the http_proxy line and edit it to insert YOUR proxy's address? (using a local wwwoffle proxy on my notebook) $ grep -i proxy .dillo/dillorc # Set the proxy information for http http_proxy=http://localhost:8080/ no_proxy = "wl localhost" note that plain dillo does currently NOT support proxy authentication. >I noticed that the chatter from dillo no longer > complained about a missing .dillorc, yet I am still unable to go to any URL. > The message on the web browser was: "Error: Dns: can't resolve > http://linuxtoday.com". I get the same basic error message when trying to go > to www.perl.com or http://www.perl.com. I am able to go to these web sites > using other web browsers such as mozilla, galeon, opera, netscape and > konqueror. Each one of those I had to set a proxy preference. Perhaps my > proxy setting has incorrect syntax? Enclosed is the chatter from dillo and > the .dillorc (proxy setting has obviously been sanitized). > > Thanks, > Ken > prompt> dillo > Nav_open_url: Url=>http://linuxtoday.com/< > Dns_server [0]: linuxtoday.com is (nil) when using a proxy, dillo would never try to resolve the DNS of the URL you entered, but only connect to the proxy host: $ dillo Enabling cookies as from cookiesrc... Connecting to 127.0.0.1 Greetings, Thorben

Nov. 12, 2003

Re: [RFC] Quo Vadis Dillo

by Eythan Weg

Frank de Lange writes: > Eythan Weg wrote: > >>How about horizontal/vertical split of a tab. One >>use for it is being able to compare side by side >> different parts of the same document. >> > No, that sounds like something which can easily be achieved using a > frameset. No need for special code in Dillo for that... > > <frameset cols="*,*"> > <frame src="doc1.html"> > <frame src="doc2.html"> > </frameset> > > Make a form which feeds two urls to a frameset page like that. Presto, > two documents side by side. > Yes, but... inconvenient and besides it blends the user with the page designer. Consider, perhaps, an implementation of your suggestion done on the fly. For now I prefer to open a second dillo's window when such a need arises. > Cheers//Frank Sincerely, Eythan

Nov. 12, 2003

dillo won't resolve URLs under a proxy environment?

by Ken Wolcott

Hi; Dillo looks interesting. However I can't go anywhere with it as I am under a proxy environment. I saw that the default dillorc has a commented-out section for http_proxy. I copied the default dillorc to be my ~/.dillorc and started dillo again. I noticed that the chatter from dillo no longer complained about a missing .dillorc, yet I am still unable to go to any URL. The message on the web browser was: "Error: Dns: can't resolve http://linuxtoday.com". I get the same basic error message when trying to go to www.perl.com or http://www.perl.com. I am able to go to these web sites using other web browsers such as mozilla, galeon, opera, netscape and konqueror. Each one of those I had to set a proxy preference. Perhaps my proxy setting has incorrect syntax? Enclosed is the chatter from dillo and the .dillorc (proxy setting has obviously been sanitized). Thanks, Ken **************snip********************** prompt> cat /etc/redhat-release Red Hat Linux release 8.0 (Psyche) prompt> which dillo dillo is /usr/bin/dillo ptompt> dillo --version Dillo 0.7.3 /msa3530> prompt> dillo Setting locale to C... dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://linuxtoday.com/< Dns_server [0]: linuxtoday.com is (nil) Dillo: normal exit! /prompt> **************snip********************** **************snip********************** http_proxy=http://my_ip:my_port/ **************snip**********************

Nov. 12, 2003