September 2005 - Dillo-dev - lists.mailman3.com

dillo and xhtml

by Wim De Smet

Hi, in keeping with the latest and greatest, I was playing around with xhtml. Now the standard seems to be that xhtml should be send es application/xhtml+xml in the first place (there's a note about it somewhere). Or, if that is not possible, application/xml, text/xml, etc. Never as text/html (because this mimetype is not registered for this content). However, dillo doesn't recognize this mimetype and always tries to save an application/xhtml+xml file, though it can always be rendered as html. The current workaround for dillo and other browsers is just send text/html but since standards compliance is very important for dillo I would suggest treating application/xhtml+xml as though it was text/html for the time being. (or at least until the CSS support is complete). Thoughts? Ideas? Wim

Sept. 7, 2005

Funding activities

by Jorge Arellano Cid

Hi there, After coming back from LSM 2005, I've devoted 100% of my time to the funding effort. I know I said that most probably after the LSM a FLTK-based prototype would be online, but at that time we were _very_ advanced to get the core team to work full time on dillo. It failed almost at signing the contracts. I was waiting for this to happen to tell the list the good news. BTW, most of the new dpi stuff (not yet uploaded) was a work for this company. I see no point in spending my last $$ in developing just to tell you a have to leave in a couple of months, so funding has acquired the first priority. For those of you that are curious, the donations link has raised EUR 500 in all its lifespan (2 years or less IIRC). Almost surely, the next release will be GTK-based, and I'll code only when I find a timespan in my fund-related activities. The FLTK port went great while we were working on full steam with Sebastian in Germany, now it's stalled. If funding succeeds, we'll be able to work on it again, and you'll surely enjoy the new Dillo much more than the current one! -- Cheers Jorge.-

Sept. 6, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Tue, Sep 06, 2005 at 11:03:26PM +0200, Alexander Becher wrote: > TBlittlefoot schrieb: > [black text on black background] > >I just wondered if there was some configuration choice that would > >easily fix the 'problem'. > > force_my_colors=YES > Perfect! Thanks for your help, Alexander, Tom

Sept. 6, 2005

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 04:53:27AM -0700, TBlittlefoot wrote: <snip> > While we're chatting, Jeremy, just why is dillo as large as > it is? (I realize that it is less than 1/10 the size of most > browsers) I have 1.3M for the executable here. > > What is it about the current state of the Web (HTML and/or > servers) that necessitates this size? > > W3m is only .7K and does a great job as a textmode browser. > Why so much more just to display static images? > Correction. That's .7M. It is actually bigger than Dillo stripped! Tom

Sept. 6, 2005

Re: [Dillo-dev] Java in Dillo

by Alexander Becher

TBlittlefoot schrieb: [black text on black background] >I just wondered if there was some configuration choice that would >easily fix the 'problem'. force_my_colors=YES HTH Alexander -- PGP key available Port Payé / Entgelt bezahlt / Postage Paid: http://www.hashcash.org/

Sept. 6, 2005

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

by Jorge Arellano Cid

Hi, On Mon, Sep 05, 2005 at 02:59:38AM +0200, Diego Sáenz wrote: > 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. Although 'cookiesrc' is enough to control cookies, the compile option "--disable-cookies" was introduced because it served to reduce dillo's binary size for embedded environments (cookie support code is not small). Even now that most of that code was moved into an external plugin, it still saves some remaining cookie-code inside dillo. A patch for the problem is in the CVS now. Please test it. Note: the cookies.dpi is still compiled when cookies are disabled with "--disable-cookies" (near 5KB that can be safely ignored or deleted because it will never run). I don't feel like complicating the autotools* stuff to make the cookies.dpi not to compile ;-). Ah, I also added a message to remind cookies were disabled at compile time. > 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" There's a script in the tarball: install-dpi-local. More or less it does what you want. -- Cheers Jorge.-

Sept. 5, 2005

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