- Dillo-dev - lists.mailman3.com

[Dillo-dev]Re: contrast_visited_color

by opus＠milneweb.com

Jorge Arellano Cid writes: > > A suggestion: http://www.paulgraham.com (any link). > Is it just me or can anybody else get the image and the links to show on this site....using Dillo?? All I get is: "In stores now: Hackers & Painters. New: Great Hackers (Audio) | The Python Paradox. " Nothing else. -- Pete http://milneweb.com http://nomorevirus.com

Aug. 16, 2004

[Dillo-dev]contrast_visited_color

by Jorge Arellano Cid

Hi there, I've been playing with this patch for enough time to start to like its effects. It changes the old 'force_visited_color' dillorc option with 'contrast_visited_color' (featuring a new algorithm). This allows Dillo to choose the visited link color, in such a way that it makes good contrast with the rest of the page. Please update your dillorc with the new option, test it, and say how it works for you. A suggestion: http://www.paulgraham.com (any link). -- Cheers Jorge.-

Aug. 16, 2004

[Dillo-dev]Re: gcc 2.95.4 "compilability" (was: no subject)

by opus＠milneweb.com

Jorge Arellano Cid writes: > The original c99 patch introduced a memory leak, so a fixed > version was commited. > > Yes, we do strive for code compatibility, and this kind of > report is welcomed. > > -- > Cheers > Jorge.- > Thank you for fixing this!! -- Pete http://milneweb.com http://nomorevirus.com

Aug. 15, 2004

Re: [Dillo-dev] gcc 2.95.4 "compilability" (was: no subject)

by Jorge Arellano Cid

On Sun, Aug 15, 2004 at 11:25:59AM +0200, Thomas-Martin Seck wrote: > * David McKee (dmckee(a)jlab.org) > > > The code that is giving you trouble is valid under the new (1999) standard > > for "c", but invalid under the old (1982? ANSI standard, and under the > > original K&R compiler). Versions of gcc from 3.0 on accept c99 syntax, but > > older versions do not. I imagine that Jorge will get around to cleaning it > > up sooner or later. He has fixed this kind of thing in the past. > > As the current mainainer of the dillo FreeBSD port I hope that the code > stays "gcc 2.95 clean" for some time since FreeBSD uses gcc 2.95.4 as > the system compiler on the 4.x series and 4.x is likely to stay around > for quite a while, even after FreeBSD 5 is declared the "STABLE" > development branch. The original c99 patch introduced a memory leak, so a fixed version was commited. Yes, we do strive for code compatibility, and this kind of report is welcomed. -- Cheers Jorge.-

Aug. 15, 2004

Re: [Dillo-dev] gcc 2.95.4 "compilability" (was: no subject)

by Thomas-Martin Seck

* David McKee (dmckee(a)jlab.org) > The code that is giving you trouble is valid under the new (1999) standard > for "c", but invalid under the old (1982? ANSI standard, and under the > original K&R compiler). Versions of gcc from 3.0 on accept c99 syntax, but > older versions do not. I imagine that Jorge will get around to cleaning it > up sooner or later. He has fixed this kind of thing in the past. As the current mainainer of the dillo FreeBSD port I hope that the code stays "gcc 2.95 clean" for some time since FreeBSD uses gcc 2.95.4 as the system compiler on the 4.x series and 4.x is likely to stay around for quite a while, even after FreeBSD 5 is declared the "STABLE" development branch.

Aug. 15, 2004

Re: [Dillo-dev](no subject)

by David McKee

On Sat, 14 Aug 2004, Opus wrote: > On Sat, 14 Aug 2004 19:02:02 -0400 (EDT), David McKee <dmckee(a)jlab.org> wrote: > > Pete, > > This is the problem I reported (and supplied a patch for) under the [snip] > > On Sat, 14 Aug 2004 opus(a)milneweb.com wrote: > > > I am having this issue when I get to 'gmake' doing the CVS build. > > [snip] [snip] > Hey David....thanks. You surely take me for someone that has a clue > what you said means...lol! > > After you said "This is the problem I reported (and supplied a patch > for)" I got lost. I have used CVS for a while now, I am lucky to be > able to get it compiled when things go well. > > Maybe I should skip it now til all is fixed....unless you have a > reasonably 'do-able for me' suggestion. I certainly appreciate your > response though. *;o) Try grabbing the CVS from before the latest patch... man cvs and look for the -D option which lets you set the date spec... BTW- The web access to the CVS archive is the easiest way to learn when that patch was applied. Good luck, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 15, 2004

Re: [Dillo-dev](no subject)

by David McKee

Pete, This is the problem I reported (and supplied a patch for) under the title "c99 coding style...". You can fix it you self by going to the lines where the erros are reported and moving the declarations to the top of their functions. The one in interface.c (the one giving the error below) includes an initiallization that depends on the state of the fuction at line 1350, so you'll have to split it into a declartaion at the top of the function, and an assignment in the current location. The one in url.c can be solved by moving the sanity check at the top of the function below all the declarations. On Sat, 14 Aug 2004 opus(a)milneweb.com wrote: > I am having this issue when I get to 'gmake' doing the CVS build. [snip] > interface.c: In function `Interface_make_search_url': > interface.c:1350: syntax error before `*' > interface.c:1352: `search_url' undeclared (first use in this function) > interface.c:1352: (Each undeclared identifier is reported only once > interface.c:1352: for each function it appears in.) > interface.c:1353: warning: control reaches end of non-void function [snip] > Pete The code that is giving you trouble is valid under the new (1999) standard for "c", but invalid under the old (1982? ANSI standard, and under the original K&R compiler). Versions of gcc from 3.0 on accept c99 syntax, but older versions do not. I imagine that Jorge will get around to cleaning it up sooner or later. He has fixed this kind of thing in the past. Good luck, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 14, 2004

[Dillo-dev](no subject)

by opus＠milneweb.com

I will try to post this again.... I am having this issue when I get to 'gmake' doing the CVS build. [FreeBSD happy.hopto.org 4.10-RELEASE FreeBSD 4.10-RELEASE #0] interface.c: In function `Interface_make_search_url': interface.c:1350: syntax error before `*' interface.c:1352: `search_url' undeclared (first use in this function) interface.c:1352: (Each undeclared identifier is reported only once interface.c:1352: for each function it appears in.) interface.c:1353: warning: control reaches end of non-void function gmake[3]: *** [interface.o] Error 1 gmake[3]: Leaving directory `/usr/home/petie/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/petie/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/petie/dillo' gmake: *** [all] Error 2 -- Pete http://milneweb.com http://nomorevirus.com

Aug. 14, 2004

Re: [Dillo-dev]thread-safe X at fresco

by robert w hall

In article <Pine.LNX.4.60.0406182239380.5841(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > >On Fri, 18 Jun 2004, robert w hall wrote: > >> The thread-safe versions of XFree3.3.3.1 have disappeared from >> linuxsavvy, (and my own attempts too recompile my own have produced >> useable, but not wholly error-free results)... >> >> But I note that vintage.fresco.org still has two earlier thread-safe >> Xlibs, 3.1.2 and 3.2, linked statically. > > I have REENTRANT 3.3.2 libs that work for me. If you want I can >pack them for you to try... > > Cheers > Jorge.- > > Another thing to watch ( clearly I didn't) is not to let ldconfig pick up the 'wrong' version of libpthread - slack 4 has a version which is libc5 compatible and also a version in the glibc1 package linked to libc6 I think. Brings down the whole caboodle with a seg fault if you get the wrong one. >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)lists.auriga.wearlab.de >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- robert w hall

Aug. 13, 2004

[Dillo-dev]dpi preferences suggestion

by David McKee

Folks, I've been thinking a little about my comment the other day to the effect that I prefer more contrast in list views than the new file:// dpi's table mode provided. I wondered if that might be a reasonable candidate for a configurable preference. It's not clear that it is, but it got me thinking about handling preferences in dpi. I suggest that we don't want every dpi implementing it's own preferences scheme. So dpid should handle reading in any preferences for dpis, and pass them to the plugin. The simplest method would be to set environment variables in the new processes execution environment. If we are willing to tolerate having preferences read in only at startup (as with the main program right now) that is the whole of the problem. For reading user preferences from disk we can presumably use the same code that is current employed to get the dillo preferences... Any thoughts? Cheers, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 13, 2004