- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by robert w hall

In article <Pine.LNX.4.58.0405011313350.1900(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Feedback is very important now, because I want to remove the >"alpha software" label from dillo and name it as stable (beta). > > > Thanks in advance > Jorge.- > > 1) Is this also current cvs? 2) Is anyone else going to test on a playstation-2 - or do I have to boot the kids off the machine on a British (wet!) bank-holiday! -- robert w hall

May 1, 2004

[Dillo-dev]is anyone planning to add SpiderMonkey (JavaScript-C) Engine to Dillo?

by Miernik

Is any work going on to add SpiderMonkey (JavaScript-C) Engine to Dillo? http://www.mozilla.org/js/spidermonkey/ I once saw a post of somebody who planned to do something like that, but heard of no progress later. I would be very interested in such implementation. -- Miernik _________________________ xmpp:miernik@amessage.info ___________________/__ tel: +48888299997 __/ mailto:miernik@ctnet.pl http://www.miernik.ctnet.pl/

May 1, 2004

[Dillo-dev]dillo interface and motif, athena etc

by Riccardo Mottola

Hello. I have never looked at dillo's source code directly, so I am asking some general questions here I have always liked dillo's speed and use of system resources because it brings back the fun of browsing and works on older workstations too, as every browser should. But I never liked dillo's interface too much. I'd like to make it a proper interface, more like other browsers have, taking inspiration for example from Mosaic's bar and bookmarks, from chimera's simplicity, from HotJava cutsomization, etc. Also, I dislike GTK: they are slow and don't work well on 256 color screens. I would use Motif for writing the interface with having an eye on LessTif of course. Motif/Lesstif is extremely fast and works like a charm on my old 20Mhz IBM RS6k witha 256 color card. Also, most free OS users have one of the either installed too, to run stuff like the excellent NEdit. Being able to install dillo on AIX, Solaris, IRIX, HP-UX without having to install an additional toolkit would just be nice. Athena is also present everywhere, but let's say it is a bit primitve. Of course, super-fast :) So I ask: how much of dillo's code is GTK dependent and how difficult would it be to port it to another toolkit? I have quite little experience with toolkits and since I don't know GTK it seems impossible to me alone. One of the nicest things, IMHO, would be a toolkit-independent dillo. Have a look at what the excellet GVIM does or at what amaya does (or, at least, did). Choose your toolkit! I don't know how they structured their code and their graphic drawing, but it would be interesting to investigate. -Riccardo

May 1, 2004

[Dillo-dev]GTK FLTK and other Render

by shuishuila

Hi, dillo-dev， I want to port dillo to set-top box as menu(OSD). But it don't have X11,GTK. How many work need to do if I have to write widget myself? I think it's a pity that dillo combine tightly with glib/gtk, so it is hard to port to X,FrameBuffer,DirectFB etc. If dillo have it's own widget and event handle, it is a excellent broswer for embedded system. Regards, 　　　　　　　　shuishuila 　　　　　　　　shuishuila(a)hotmail.com 　　　　　　　　　　2004-04-30

April 30, 2004

Re: [Dillo-dev]Re: Test for socklen_t in configure.in

by Jorge Arellano Cid

Hi, Sorry, I just realized that a "pre" tarball is required to test the socklen_t detection (else it depends on the local machine's installed auto* tools). I'm preparing it, stay tuned. Cheers Jorge.-

April 30, 2004

Re: [Dillo-dev]Re: Test for socklen_t in configure.in

by Johannes Hofmann

Hi, works fine here on a pretty current DragonFly BSD machine. Relevant lines from config.log: configure:3666: checking for socklen_t configure:3692: gcc -c -g -O2 -I/usr/local/include conftest.c >&5 configure:3695: $? = 0 configure:3698: test -s conftest.o configure:3701: $? = 0 configure:3754: result: socklen_t <snip> ac_cv_prog_make_make_set=yes ac_cv_socklen_t=socklen_t ac_cv_target= Cheers, Johannes On Fri, Apr 30, 2004 at 08:30:37AM -0400, Jorge Arellano Cid wrote: > > > On Wed, 28 Apr 2004, Jorge Arellano Cid wrote: > > > > > Hi there, > > > > Our configure.in is in need of a test for socklen_t. I thought > > this one could be a good one: > > > > dnl ------------------- > > dnl Check for socklen_t > > dnl ------------------- > > dnl > > [...] > > > but my autoheader complains... > > > > Can someone please complete the patch, I'm currently chasing a > > segfault bug I found... > > > Fixed, and commited. It only requires testing, specially on non > GNU/Linux environments, specially the *BSD ones. > > Please tell me how it works. > > Cheers > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 30, 2004

[Dillo-dev]Re: Test for socklen_t in configure.in

by Jorge Arellano Cid

On Wed, 28 Apr 2004, Jorge Arellano Cid wrote: > > Hi there, > > Our configure.in is in need of a test for socklen_t. I thought > this one could be a good one: > > dnl ------------------- > dnl Check for socklen_t > dnl ------------------- > dnl > [...] > but my autoheader complains... > > Can someone please complete the patch, I'm currently chasing a > segfault bug I found... Fixed, and commited. It only requires testing, specially on non GNU/Linux environments, specially the *BSD ones. Please tell me how it works. Cheers Jorge.-

April 30, 2004

[Dillo-dev]Test for socklen_t in configure.in

by Jorge Arellano Cid

Hi there, Our configure.in is in need of a test for socklen_t. I thought this one could be a good one: dnl ------------------- dnl Check for socklen_t dnl ------------------- dnl AC_MSG_CHECKING(for socklen_t) AC_TRY_COMPILE([#include <sys/types.h> #include <sys/socket.h> socklen_t x; ], [], [AC_MSG_RESULT(yes)], [ AC_TRY_COMPILE([#include <sys/types.h> #include <sys/socket.h> int accept(int, struct sockaddr *, size_t *); ], [], [ AC_MSG_RESULT(size_t) AC_DEFINE(socklen_t, size_t)], [ AC_MSG_RESULT(int) AC_DEFINE(socklen_t, int)])]) but my autoheader complains... Can someone please complete the patch, I'm currently chasing a segfault bug I found... TIA Jorge.-

April 28, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Jorge Arellano Cid

Hi Francis, First of all, thanks for your research and well backed answer. Here I go: On Tue, 27 Apr 2004, Francis Daly wrote: > On Mon, Apr 26, 2004 at 07:48:11PM -0400, Jorge Arellano Cid wrote: > > On Thu, 22 Apr 2004, Jens Arm wrote: > > > > > Please test our current CVS hardly, and tell us how it did. > > > > > > Directories like > > > > > > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ > > > > > > or others are not rendered correctly > > > > Yes. This is a complex problem. > > > > Apache (the web server), generates bad HTML for directory > > listings (at least 1.3.x series): > > > > <PRE> is an inline container excluding: > > > > {IMG, OBJECT, APPLET, BIG, SMALL, SUB, SUP, FONT, BASEFONT} > > > > Also, it can't hold block elements (e.g. HR). > > > > > > So there's a bug in having <HR> inside <PRE> and one bug per > > directory entry because <PRE> can't contain <IMG>. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9307 and <q from above URL> Yes, it's a known issue. In 2.0 and later, tables can be enabled by configuration. 1.3 will stick with the <pre> stuff, also because of backwards compat, sorry. <q> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13351 suggest that > the apache developers know, and it's not going to change in the 1.3 > series. Well, they know the bad HTML issue and made a tables version for the directory listing (that was also faulty but that as of the bug entry should be corrected now). > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10880 suggests that > the default won't change in the 2.0 series, <q from above URL> Item 1 has been fixed in 2.1 and is proposed for backport. Item 2 ... ehm? what standard? html? agreed. ;-) As said you can use IndexOptions to fix that issues. For backwards compat we should stick with the current defaults. Item 3 doesn't appear in the current tree so I'm assuming it fixed already. </q> The backwards compatibility is a point that was easy to foresee. Although the developer above doesn't seem to be much concerned about the standards, and this surprises me. A simple solution woud be to replace: -<HR> +</PRE><HR><PRE> and replece the <IMG> tag with its alt text, and make _that_ the default in apache. They could provide an option to produce the old directory listing, and thus, leave the responsibility of deciding whether to serve bad HTML to every webmaster, but the default should be valid HTML (IMHO). In brief, the webmaster would have: - Good HTML by default (no images) based on <PRE> - The option to serve bad HTML with images based on <PRE> - The option to serve good HTML with images based on <TABLE> > > > After analizing the produced HTML for directory listings, I > > found that isolating the <HR> outside <PRE> is a trivial fix that > > helps keeping the block element outside. > > > > That is: > > > > - <HR> > > + </PRE><HR><PRE> > > > > Very simple. It would allow for violations of the type "inline > > container with excluded inline element within" (instead of > > "inline container with a block inside"). > > > > Does anyone know an apache developer? It seems that sending the > > patch through bugzilla could take years to be noticed... > > It can be a bit hit and miss. If one of the core team is directly > interested and not otherwise engaged, they can get things done quickly. I got a bit discouraged to make the patch and submit it because it's a toilsome work that I don't know will have a warm reception ;) If you feel like doing it, please go ahead, but I'd suggest first to contact one of the developers and explain the idea before making a patch. It's reasonable, unless they have to support some scripts that rely on the directory listing source being served exactly the old way... > > Their most recent attempt not to lose patches seems to be described in > http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108012889313136&w=2 > which suggests that bugzilla may be being watched closely. This is good news. But the whole issue is more a "backwards compatibilty" problem than "valid HTML". This is better to be asked in advance. > > > OTOH, I don't like very much breaking our policies with code to > > handle bad HTML, and yes I know this is the most used web server. > > Maybe a dillorc option to enable a workaround for apache could do > > it, but I'd really like to talk with one of the developers. > > > > Comments? > > As others have said, any future change to apache won't change current > servers for years to come. Sigh, I suppose this is right. Even under the pressure of a security-fix release... > So rendering it usefully, if not ideally, would be prudent. And a big > black mark in the bug meter is in order, too. > > Correctness vs usefulness... Yes Francis, I think the same as you, but I'd appreciate if someone asks them if serving good HTML without the images for the directory listing is a good default (providing the alternatives described above). For those that read this far: the CVS contains the patch I made for this issue. Cheers Jorge.-

April 28, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Pete

On Tue, Apr 27, 2004 at 04:11:19PM +0100, Francis Daly wrote: > > > I may be missing something with this. What I think I am reading is > > that this is an Apache issue as far as why the page isnt rendering > > well. I am running Thttp for a server. I copied the source and stuck > > it on my server. It then will not render well with Dillo either. > > The fact is that the html is invalid, and therefore renders funny. > Saving the html and serving it from another web server, or fetching it > from a file, won't change that it is invalid. > > The reason it is an apache problem is that the html is generated by > apache, not that it is served by apache. > Ok, that is what I was thinking but wasnt sure. Seeing all these webservers serve up the html incorrectly, do you make them correct the issue or do you have Dillo also 'render incorrectly'? I know there are a lot of sites that are not rendered correctly with Dillo. Whether these issues would be the reason or not I am not educated enough to know. Thanks for the explination though. -- Pete http://milneweb.com http://nomorevirus.com

April 27, 2004