- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] dillo-0.8.6-pre(CVS) compile error

by Joerg Sonnenberger

On Mon, Sep 05, 2005 at 02:59:38AM +0200, Diego Sáenz wrote: > Is something that knows about Makefiles and auto* tools interesting in > helpme to fix this? I do not have the knows for it. I think that the > cookies.dpi must not be compiled if cookies are disabled with > "./configure --disable-cookies". The easiest solution is to comment out the target or subdirectory with a variable like ${NO_COOKIES}, which is set to '#' if --disable-cookies is set. That's what automake uses to implement conditional compilation. Joerg

Sept. 5, 2005

Re: [Dillo-dev] dillo-0.8.6-pre(CVS) compile error

by Diego Sáenz

El Sun, 4 Sep 2005 02:01:04 -0700 south park <llmmix(a)gmail.com> escribio: > Hi, > It works if compiled without "--disable-cookies" option. > how to disable cookies in dillo? Dillo disables cookies by default (cookies are configured with the $HOME/.dillo/cookiesrc file), but the code to use cookies is in dillo(in that version in a DilloPlugIn outside dillo, but exec by dillo if cookies enabled) is there. Read doc/Cookies.txt in dillo sources for more information. (the answer continues down) > > 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$ > Is something that knows about Makefiles and auto* tools interesting in helpme to fix this? I do not have the knows for it. I think that the cookies.dpi must not be compiled if cookies are disabled with "./configure --disable-cookies". More about makefiles: Can somebody write a generic makefile for DPIs(DilloPlugins) distributed outside dillo source. It need to install the compiled DPI(DilloPlugIn) in the DPIs system directory when "make install" run as root or install the DPI in the $HOME/.dillo/dpi/ when not and then exec "dpidc register" I think a version of the hello plugin distributed outside dillo can help to the people to write more DPIs. Diego.

Sept. 5, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 08:25:51PM +0100, Jeremy Henty wrote: > On Sun, Sep 04, 2005 at 11:14:38AM -0700, TBlittlefoot wrote: > > On Sun, Sep 04, 2005 at 10:36:57AM -0700, Kelson Vibber wrote: > > > 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. > > Please be tactful about doing this. You don't want to come across as > saying "Your web site breaks in some bizarre web browser you've never > heard of. It's probably because you're incompetent". It's possible > the site designer has no interest in browsers that don't support CSS > and doesn't want to be bothered by people who use them. It's possible > they *know* the coding sucks but are tied to a framework that > generates sucky code and are sick and tired of well-meaning bug > reports that they can do nothing about. It's possible they won't know > what on earth you're talking about. At the very least it would be > considerate to examine the HTML first so you can give some details > rather than a vague "Your web site's broke". Good advice, Jeremy. I'll be polite and much more general: Myself and a lot of other folks are really tired of all the pointless (in terms of substance) and bandwidth-consuming requisites of a lot of websites these days, where the (erroneous) assumption that we all use the latest version of MSIE seems to reign. A lot of us don't even use Windows and have no intention of getting a high-speed connection to the Internet. We don't do sound or java or cookies or plugins or video. On my perfectly functional and RFC-compliant graphical browser, your page displays as mostly blank. It turns out that the printing is white on white... So I use my textmode browser to view it. Have a nice day. No, Bill Gates and his minions do not run my computer, and if you are going to let him run your website, then it is going to look like garbage on my browser and I'll look for another site where the webmaster has thrown off the yoke of the Dark Lord Gates --- Three OS's from corporate kings in their towers of glass, Seven from valley lords where orchards used to grow, Nine from dotcoms doomed to die, One from the Dark Lord Gates on his dark throne In the Land of Redmond where the Shadows lie. One OS to rule them all, one OS to find them, One OS to bring them all and in the darkness bind them, In the Land of Redmond where the Shadows lie. ----------------- :-) Might have gotten a little carried away there! I'm a webmaster, too, Jeremy. I follow the printable standard: What you see with your browser is what you'll see on paper if you print out the webpage. Tom

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 09:17:00PM +0200, Ivo wrote: > On Sunday 04 September 2005 20:13, TBlittlefoot wrote: > > Any important reasons why I _shouldn't_ strip Dillo? > > Only if you have it compiled with debugging symbols and want to run gdb on > it in case of a segfault or something. > > --Ivo > Good. I've had no such problems. The performance of Dillo has been strikingly quick and clean compared to that hog, Moz*. Will run 'strip /usr/local/bin/dillo' as root in the near future. I appreciate your help, Ivo, Tom

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Jeremy Henty

On Sun, Sep 04, 2005 at 11:14:38AM -0700, TBlittlefoot wrote: > On Sun, Sep 04, 2005 at 10:36:57AM -0700, Kelson Vibber wrote: > > 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. Please be tactful about doing this. You don't want to come across as saying "Your web site breaks in some bizarre web browser you've never heard of. It's probably because you're incompetent". It's possible the site designer has no interest in browsers that don't support CSS and doesn't want to be bothered by people who use them. It's possible they *know* the coding sucks but are tied to a framework that generates sucky code and are sick and tired of well-meaning bug reports that they can do nothing about. It's possible they won't know what on earth you're talking about. At the very least it would be considerate to examine the HTML first so you can give some details rather than a vague "Your web site's broke". Cheers, Jeremy Henty (who used to be a webmaster)

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Ivo

On Sunday 04 September 2005 20:13, TBlittlefoot wrote: > Any important reasons why I _shouldn't_ strip Dillo? Only if you have it compiled with debugging symbols and want to run gdb on it in case of a segfault or something. --Ivo

Sept. 4, 2005

Re: [Dillo-dev] Java in Dillo

by Kelson Vibber

On Sunday 04 September 2005 11:14 am, TBlittlefoot wrote: > Good, Kelson. I'll send this thread to the webmaster there. Actually, I haven't looked at this particular site -- I was responding to the general case of sites with black-on-black or white-on-white text. But they're both issues to look at. -- Kelson Vibber www.hyperborea.org

Sept. 4, 2005

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