- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Re: configuration patch

by Andreas Schweitzer

Hi there, On Wed, Apr 02, 2003 at 08:19:56PM +0200, Sebastian Geerken wrote: > On Mon, Mar 31, Jorge Arellano Cid wrote: > > > The location of the system dillorc should NOT be > > > put in config.h according to the GNU docs, instead > > > everything with prefix/sysconfdir and similar stuff > > > should be defined on the command line. Hence, my > > > src/Makefile.am patch. This syntax of ' and " works on > > > a variety of systems (bash, ksh, csh, GNU make) finally. > > > Also, the current toplevel Makefile.am first tries > > > $(DESTDIR)$(sysconfdir) and then falls back on /etc > > > but the code in prefs.c does it the other way round. > > > One of them should probably be reverted. Leaving the above intentionally :-) ... it contains more explanations (by me originally) for the following. > > > And while writing this : the patch supplied on the > > > list will make dillorc be installed ONLY in > > > $(DESTDIR)$(sysconfdir) with no fall-back to /etc > > > but I think $(DESTDIR)$(sysconfdir) will be created > > > if necessary. > > > > I'm not sure of what to do here :(. For now I added Patrice's > > patch that simply adds: > > > > sysconf_DATA = dillorc > > > > in Makefile.am, and it works! That can be done in conjunction with my suggestions for src/Makefile.am (NOT the toplevel Makefile.am) > > The problem is we don't know what directory it gets in. :-) > > > > Currently if it is /usr/local/etc/ or /etc, it works, but if > > someone chooses /opt/weird/etc, it won't be found. Yes, it will be found. See below. > Why not use $(sysconfdir) in the code, as in the attached patch? I'm > not sure about the usage of the quotation marks in src/Makefile.am, > they may cause problems on different environments, perhaps someone has > a better idea. My original patch had something like that. Precisely : AM_CPPFLAGS=-DDILLORC_SYS='"$(sysconfdir)/dillorc"' for src/Makefile.am That way you can use fd = open(DILLORC_SYS, O_RDONLY) in src/prefs.c THIS combination of quotes worked for me :-) on Linux, FreeBSD and OpenBSD. It certainly needs testing - but it did take me a while to get that combo of quotes :-) .... Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

April 2, 2003

Re: [Dillo-dev] Re: configuration patch

by Sebastian Geerken

On Wed, Apr 02, Phil Pennock wrote: > On 2003-04-02 at 20:19 +0200, Sebastian Geerken wrote: > > Why not use $(sysconfdir) in the code, as in the attached patch? > > Uhm, isn't $(sysconfdir) a directory, not a file? > > > diff -pru dillo1/src/prefs.c dillo2/src/prefs.c > > --- dillo1/src/prefs.c Wed Apr 2 19:40:36 2003 > > +++ dillo2/src/prefs.c Wed Apr 2 20:07:10 2003 > > @@ -250,10 +250,9 @@ static gint Prefs_load(void) > > file = a_Misc_prepend_user_home(".dillo/dillorc"); > > fd = open(file, O_RDONLY); > > g_free(file); > > - if (fd < 0 && (fd = open("/etc/dillorc", O_RDONLY)) < 0) > > - if ((fd = open("/usr/local/etc/dillorc", O_RDONLY)) < 0) > > - return FILE_NOT_FOUND; > > - > > + if (fd < 0 && (fd = open(DILLO_SYSCONFDIR, O_RDONLY)) < 0) > > + return FILE_NOT_FOUND; > > + > > fcntl(fd, F_SETFD, FD_CLOEXEC | fcntl(fd, F_GETFD)); > > > > scanner = g_scanner_new(NULL); > > I might be missing something, but your new open() is on a directory > there. Ah, yes, of course. This was just a suggestion, and should be simple to fix. Sebastian

April 2, 2003

Re: [Dillo-dev] Re: configuration patch

by Sebastian Geerken

On Mon, Mar 31, Jorge Arellano Cid wrote: > > The location of the system dillorc should NOT be > > put in config.h according to the GNU docs, instead > > everything with prefix/sysconfdir and similar stuff > > should be defined on the command line. Hence, my > > src/Makefile.am patch. This syntax of ' and " works on > > a variety of systems (bash, ksh, csh, GNU make) finally. > > Also, the current toplevel Makefile.am first tries > > $(DESTDIR)$(sysconfdir) and then falls back on /etc > > but the code in prefs.c does it the other way round. > > One of them should probably be reverted. > > And while writing this : the patch supplied on the > > list will make dillorc be installed ONLY in > > $(DESTDIR)$(sysconfdir) with no fall-back to /etc > > but I think $(DESTDIR)$(sysconfdir) will be created > > if necessary. > > I'm not sure of what to do here :(. For now I added Patrice's > patch that simply adds: > > sysconf_DATA = dillorc > > in Makefile.am, and it works! > > The problem is we don't know what directory it gets in. :-) > > Currently if it is /usr/local/etc/ or /etc, it works, but if > someone chooses /opt/weird/etc, it won't be found. Why not use $(sysconfdir) in the code, as in the attached patch? I'm not sure about the usage of the quotation marks in src/Makefile.am, they may cause problems on different environments, perhaps someone has a better idea. Sebastian

April 2, 2003

VERBATIM and TEXTAREA

by Jorge Arellano Cid

Hi there! I just commited a fix for VERBATIM mode in the parser, and some hopefully final improvements to the code handling TEXTAREA initial values. This could be very important for those of you expecting to be able to use dillo with some sites that use the feature: for instance GNU-mailman! Just give it a try! (was BUG#318 and BUG#400). Cheers Jorge.-

April 2, 2003

Re: [Dillo-dev] Remote control reloading

by Eric GAUDET

>> What about implementing some signals dillo would react on. I.e. SIGHUP >> to make dillo reload the page. > > Additional code must be justified by satisfying a user need. I don't think > very many people are going to send signals to Dillo to reload the page -- > they'll just click the Reload button. > No code needs justification. Only the inclusion to release version does. One person thinks he needs this feature that is trivial to implement. Even if it never goes to the main trunk, let's give it a try: it might prove usefull to some people. Or not, who cares? Dillo is great for this because the code is simple enough to understand and experiment with. Good luck trying this kind of stunt with mozilla! The Sylpheed project experimented embedding dillo, and eventually dillo included the feature. Bottom line: I'll always favor experimental contribution that prove useless to sterile discussion about the value of an hypothetical feature. Eric.

April 2, 2003

Re: [Dillo-dev] Remote control reloading

by Chris Palmer

On 2003-03-23 at 17:46 +0100, Christian W. Zuckschwerdt wrote: > What about implementing some signals dillo would react on. I.e. SIGHUP > to make dillo reload the page. Additional code must be justified by satisfying a user need. I don't think very many people are going to send signals to Dillo to reload the page -- they'll just click the Reload button. -- Chris music is what numbers feel like San Francisco, CA

April 1, 2003

Re: [Dillo-dev] Remote control reloading

by Phil Pennock

On 2003-03-23 at 17:46 +0100, Christian W. Zuckschwerdt wrote: > What about implementing some signals dillo would react on. > I.e. SIGHUP to make dillo reload the page. First: I know that I haven't submitted any patches yet, so am not qualified to really say much (my patches are for old versions and all useless, thanks to the sterling work of others, coming up with better solutions -- the best way for it to be ;^) ). I'd still like to point out that whilst this seems like a good idea, using SIGHUP for this is IMnsHO a bad idea. The whole thing with daemons using SIGHUP as a trigger to re-read config is because daemons have no controlling terminal, so can't receive a system-generated SIGHUP. Dillo doesn't detach from a terminal, so can. Whether or not Dillo should actually exit on SIGHUP is another matter. There are two signals reserved for user purposes, SIGUSR1 and SIGUSR2. Why not use those? -Phil

April 1, 2003

Re: [Dillo-dev] Error DNS can't solve (null)

by Joerg Sonnenberger

On Mon, Mar 31, 2003 at 05:17:13PM +0200, Matthias Teege wrote: > Moin, > > I'm running dillo 0.7.0 under FreeBSD and can browse my internal > site without problems. If I try to use dillo with my squid proxy to > access externel sites I get the error message above. > > The logfile og the DNS server logs also strange: > > 2003-03-31 17:16:42.617550500 query 41218 c0a8990a:0f89:34b3 1 . > 2003-03-31 17:16:42.617790500 tx 0 1 . . c0a80015 > 2003-03-31 17:16:42.618661500 stats 41218 146743 1 0 > 2003-03-31 17:16:42.619053500 sent 41218 17 > 2003-03-31 17:16:50.878750500 query 41219 c0a8990a:0f8a:34b5 1 . > 2003-03-31 17:16:50.878988500 tx 0 1 . . c0a80015 > 2003-03-31 17:16:50.879797500 stats 41219 146743 1 0 > 2003-03-31 17:16:50.880180500 sent 41219 17 > > What do I missing? You are using dnscache? If yes, it could not the (DNS) query. Everytime I got this, my routing was misconfigured. Can you access the other network correctly? Joerg > > Many thanks > Matthias > > -- > Matthias Teege -- http://www.mteege.de > make world not war > PGP-Key auf Anfrage

April 1, 2003

Re: [Dillo-dev] Anti-aliasing

by slymer＠slymer.org

On Sun, 30 Mar 2003 16:30:58 +0200 Nicola Girardi <nicola(a)g-n-u.de> wrote: > IMHO, after 2 is fixed (if it's broken at all) this should go > into CVS, because it's a major benefit to have anti-aliased > fonts. Well, IMHO, as I said. Yeah, anti-aliased fonts are something I like about Gecko based browsers. It'd be so cool to have this in dillo, in alpha stage. (I hope it'll be added :) ) -- Registered Linux user #298569 Those who cannot remember the past are condemned to repeat it. -- George Santayana

April 1, 2003

Re: Error DNS can't solve (null)

by Matthias Teege

Jorge Arellano Cid <jcid=s8PdfxpoPdHk1uMJSBkQmQ(a)public.gmane.org> writes: >> access externel sites I get the error message above. > > Please use the latest release. I do so but with the same result. > If your squid uses authentication, dillo will not recognize it > (is not implemented yet, and HTTP 1.1). I didnt use authentication. Bis dann Matthias -- Matthias Teege -- http://www.mteege.de make world not war PGP-Key auf Anfrage

April 1, 2003