Import original dillo.org website into old/

38 files changed, 81865 insertions, 0 deletions

diff --git a/old/oldmail/199912.txt b/old/oldmail/199912.txt
new file mode 100644
index 0000000..3e029d0
--- /dev/null
+++ b/old/oldmail/199912.txt
@@ -0,0 +1,2015 @@
+[Dillo-dev]Home page (ASCII version)
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-31 13:27
+
+==============================================================================
+Here's the new home page:
+==============================================================================
+
+
+The Dillo Web Browser
+_________________________________________________________________
+
+Welcome to Dillo project!
+
+What's Dillo?
+
+Dillo is a web browser project based upon gzilla-0.2.2 and
+Armadillo-0.3.10.
+It aims to be a multiplataform browser alternative that's stable,
+developer-friendly, usable, fast, and extensible (Dillo is a free-SW
+project in the terms of the GNU public license).
+_________________________________________________________________
+
+Fast links:
+
+* Achieved goals
+* Naming&Coding design
+* Bug-track engine
+* Authors
+_________________________________________________________________
+
+News:
+
+Dec 30, 1999
+
+Updated the web site, wrote new patching directions, updated the
+bug-track engine, incorporated several patches, and currently planning
+a new tarball release.
+
+Dec 18, 1999
+
+Naming&Coding, Stage 2, is finished, completely!!!
+_________________________________________________________________
+
+Current goals 
+
+Our primary concerns by now are (Dec 30, 1999):
+* Fix and stabilize Dillo to be at least as stable as gzilla-0.2.2,
+but faster. (this is our main and first goal by now)
+* Fix the rendering bugs that affect GIF and JPG files (Those that
+were working good in gzilla-0.2.2).
+* Document Dillo internals within the source (every function).
+
+Future Goals (these may change in the future)
+* Make '#' anchors work. (The rendering part of it) Currently those
+anchors leave you at page's top
+* Incorporate the FTP plugin (I tested it, it works but I just need
+to put it there)
+* Define a simple plugin API (stdout based)
+* Begin designning a dynamic loadable plugin scheme
+* Fix and improve rendering
+* Begin working on TABLE support!
+
+That's enough work for now!
+_________________________________________________________________
+
+Developer info
+
+Brief Program Overview
+
+Dillo is a browser purely written in C; that helps to make it very
+fast and produces a smaller binary file than what would be achieved
+with C++. The trade off is that inheritance gets more complex cause it
+must be implemented with C code. That's a bit scary at the very
+beginning, but is not as bad at it seems.
+
+Dillo internals are not of a simple nature. A Web browser is an
+inherently complex application. Just think of every thing that needs
+to be coordinated to get the job done. And at the very same time!
+
+Dillo's main libraries are gtk+ (gimp tool kit) for widgets and glib
+for almost everything else (as memory management). So, if you happen
+to be developing new code, please try to find what glib has to offer
+you, amd use it. Needless to say, you must use g_malloc, g_free,
+g_realloc and friends.
+
+Dillo's SW-techniques include threads, callbacks, signal driven IO
+(input/output), a bytesink abstraction layer and an IO engine that
+cares file descriptor activity (including sockets). Ah, there's also a
+widget abstraction layer that serves as an internal ADT (abstract data
+type) to gtk+; It's called Dillo widget (Dw_ within function names).
+
+I'll try to document those later. Please be patient.
+
+Now you know what you'll face when digging inside the code.
+
+Patching
+
+Patching is very welcome. Specially if the patched bug comes from the
+bug-track engine. But beware, only high quality patches will be
+accepted.
+Dillo is following an evolving software-model where every new version
+of it, should be better than the former; there's no place for unstable
+releases!
+
+So, if you want to submit a patch, please make sure:
+
+It passes a 30 minutes stress test
+A stress test is a testing situation where you put the newly
+implemented routines under heavy workload (more than what's
+expected under normal circumstances).
+
+It passes your own custom testing functions
+An alternative to the former point. If the stress test is hard
+to implement, or the new functionality is better covered with
+this kind of test, chose this way!
+
+It follows Dillo's Naming&Coding design
+Every patch must strictly follow our coding standar. Just to
+keep our code clean, and to simplify the patch-reviewing task.
+
+It fixes the problem and doesn't cover the symptoms.
+Sometimes the problem itself lies in a deeper layer; take your
+time, investigate and fix it the right way.
+
+You submit your patches following a "one bug, one patch" scheme.
+Don't submit a huge monolithic patch that fixes several things.
+Split it into smaller patches, one for each bug.
+
+You strive for clean code, not for hacks.
+Although it's very cool to write fancy solutions, they are
+harder to understand and to maintain; please avoid them.
+
+You let others know what you're doing
+Don't do silent patching; use the bug-track engine, make a bug
+report and update your progress regularly. Ask for help if you
+need it.
+
+Contributing
+
+If you're planning to contribute and stay with the project as part of
+the development staff, please subscribe to the mailing list, and email
+me your expertise areas and interests; keep reviewing the bug-track
+engine and the Web site, participate, and have fun!
+
+The bug-track engine
+
+It explains it's purpose by itself, go and take a look at it at:
+
+http://academico.inf.utfsm.cl:81/~jcid/Dillo/Dbugtrack.html
+
+USE IT!
+
+
+========================================================================
+
+Jorge.- 
+
+
+
+[Dillo-dev]Server is down
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-31 13:12
+
+Hello there,
+
+
+I had just finished updating the website, the bug-track
+engine, the patching process directives and several other things,
+and when trying to commit them, I noticed that the Web server was
+turned down... But it was worst, the whole university net was
+turned down, on purpose, without a notice nor a warning: they
+turned it off just like that...
+
+I cant express how ashamed I feel; all I can say is that I
+know people there that had helped us a lot (with servers, advice
+and the like) and this 'decision' was on someone else's hands...
+I thank God for having this mailing list running on another
+machine (I was offered a mailing list...), and to have a
+communication channel with you.
+
+As I wrote before, they didn't warn anyone, so I don't know
+when it will be up; maybe January 3... If this is not the case,
+I'll start moving the site to so....net and start working
+from there.
+
+Please receive my apologies, and let's try to coordinate the
+project with the mailing list these days.
+
+BTW, I was trying to make a new tarball release before Y2K,
+and now it will have to wait; personally I'll use this time to
+continue digging deep to the roots of the image rendering bug.
+
+
+sincerely
+Jorge.- 
+
+
+
+[Dillo-dev]bug #23
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-30 13:49
+
+With regard to bug #23, I sent this lines to Luca:
+
+
+-----------------------------------------------------------------
+With regard to your ideas request for the preferences menu, I
+have several, but most of them are not implemented yet, so you'll
+have to think of it, as a module that will be heavily changing
+over time.
+
+* User selected preferences must be saved to a file
+'preferences.rc' (readable config) inside .dillo/ directory.
+* Actually, there's code inside the new tarball that
+implements a gentle background-alternative to WHITE. (I always
+thought it must be in the preferences menu :)
+* The new progress bar code lets choices on fonts and colors
+(to be considered in the near future).
+
+Not yet implemented, but desirable:
+
+* Text font (and size) preference
+* Load images (YES/NO) Def: YES
+* Use decompressed image cache (YES/NO) Def: YES
+* Save preferences on exit (YES/NO) Def: NO
+* Save preferences functionality
+
+
+I know this is mostly 'vaporware' and probably will be easier
+to handle and implement in the future; you choose!
+-----------------------------------------------------------------
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]News (lots)
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-24 01:48
+
+Hi!
+
+
+Although I haven't wrote much to the list, my work has been
+divided into several areas; some quite interesting!
+
+Let's start:
+
+* There are several changes and patches already integrated to
+the code; current changelog looks like this:
+
+
+dillo-0.0.4.tar.gz
+
+- Added more comments to the source
+- Removed dw_test
+- Implemented rendering for <OL> </OL> tags
+- Implemented background colors
+- Changed some ADTs to glib
+- Added PNG image format support
+- Fixed a compilation crash that affected RedHat 6.1 systems
+
+
+* I still have some (very interesting) patches in my queue and
+when they make their way into the code, you'll notice the BIG
+difference. (Luca made neat changes to the UI and he also
+implemented the 'View source' functionallity among others! You'll
+find that detailed in the final Changelog.)
+
+* I've been patching too. Most of it can be tracked at the
+engine.
+
+* There're still more patches to include!!!
+
+* The Web server was behaving erratically so I had to get to
+it (lots of time). Now it's working better and I hope that to
+last. If you experience problems with it, please let me know.
+
+* I've been to the University were I studied, and they granted
+me access to several machines (that's why I had the chance to
+test with redhat 6.1 among others). Several things are happening,
+and all I can tell you by now is: cross your fingers! Excellent
+news could spring from that.
+
+* While testing dillo on Redhat 6.1 (glibc2) I found critical
+races (problems). That's good and bad: good cause now I know the
+obscure cause of some erratic behavior, and bad, cause it's not
+simple.
+
+* What else? I continued testing, and compared gzilla-0.2.2
+select-based IO (polling) routines against SIGIO (introduced by
+Randall Maas into armadillo), and ... guess what?
+
+I'll have to design a more detailed test cause, with that
+kernel, the former method was significatively faster than the new
+one! The test was as simple as averaging a few page loads from an
+specific address (freshmeat) with both browsers, gzilla-0.2.2 and
+dillo-0.0.3. 
+
+Once again, that's good and bad :)
+
+Good: 
++ If the test is right (I mean, it remains TRUE most of
+the time), we'll end up with a browser that's faster than what we
+actually have (by changing the IO engine).
++ The internal implementation is very much simpler with
+the former method, and that leads to code thats much easier to
+understand and maintain.
+
+Bad:
++ (think about it...)
+
+* I also focused my efforts on project security concerns.
+There'll be new plans, most of them introduced next year... BTW,
+please bear in mind that current project status is not secret,
+but private (I know this is a complicated area to discuss, but
+please think about how many browser projects you knew, and after
+that, focus on what we have here...)
+
+* CVS stuff: I want to start working with it. Just to keep
+track of project history, and to keep a detailed Changelog of it.
+I'm curently designing a patching submition scheme to help us
+keep it clear and useful (not the highest priority though).
+
+
+Finally, I want to thank everyone here, just as accurately as
+my english allows me, for the excellent spirit this project has
+shown in this first month of work.
+Let's keep it that way!
+
+I also hope it not to be too late, to wish you an excellent
+Christmas, and a joyfull new year celebration!
+
+
+sincerely
+Jorge.- 
+
+
+
+[Dillo-dev]News
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-21 23:42
+
+Hi there!
+
+
+The work here has been up to full capacity!
+
+* The patch that removes gzw_test is applied (thanks Sammy)
+* The Background feature patch also made its way into the code!
+(thanks James and Luca)
+* Luca sent me some patches more that I'll start working on...
+* I have also been working out the code and made some fixes.
+
+
+
+I know the Web server is working awfully slow. I'll try to get
+to that machine tomorrow and see what's happenning. Please be patient.
+
+
+best regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]remove test gzw ?
+
+From: Rota Luca <drake@fr...> - 1999-12-21 20:00
+
+On Mon, 20 Dec 1999, nightstalker wrote:
+
+> should i get rid of the 'test gzw' feature or not ?
+
+Yes!
+Well, I think so :)
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]remove test gzw ?
+
+From: nightstalker <nstalkie@tv...> - 1999-12-20 19:25
+
+i was just cleaning up some stuff from commands.c .. and i was wondering
+..
+
+should i get rid of the 'test gzw' feature or not ?
+
+sammy.
+
+ps: answer as soon as you can please :) 
+
+
+
+Re: [Dillo-dev]how to use ddd or gdb with dillo
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-20 00:27
+
+Sammy,
+
+> how can i use ddd or gdb with dillo ? i think it had to do with
+> uncommenting two lines ?
+
+You can debug it without any changes using local files but, if
+you need to debug it, using the dns stuff, then go to 'dns.c',
+line 42, and comment it out. That's all!
+
+
+Thanks for commiting yourself to fix some bugs.
+
+
+Sincerely
+Jorge.- 
+
+
+
+[Dillo-dev]how to use ddd or gdb with dillo
+
+From: nightstalker <nstalkie@tv...> - 1999-12-19 22:28
+
+how can i use ddd or gdb with dillo ? i think it had to do with
+uncommenting two lines ?
+
+sammy. 
+
+
+
+[Dillo-dev]announce dillo to the public ?
+
+From: nightstalker <nstalkie@tv...> - 1999-12-19 22:18
+
+hi all,
+
+
+i think this is a time when we can announce the project to the public
+...
+(for example via freshmeat)
+
+now that the name changing / indenting has ended, i think we have a good
+
+basis for further development ! the name change actually worked,
+something
+we never achieved with gzilla/armadillo :)
+
+sammy. 
+
+
+
+[Dillo-dev]Update
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-18 22:23
+
+Hello everyone!
+
+I updated the website once more. Visit it thoroughly!
+BTW: The bug-track engine has new load :)
+
+Good luck!
+Jorge.- 
+
+
+
+[Dillo-dev]Another tarball release!!!
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-18 18:37
+
+Hi!
+
+dillo-0.0.3.tar.gz is ready at the web site!
+(following patches must be against this version)
+
+It features several improvements; read them in the ChangeLog
+inside the tarball. This will be our code base for bug fixing.
+
+Finally, our house is clean and we can start removing bugs from
+Dillo. I'll flood the bug-track engine soon...
+
+
+Jorge.-
+
+
+Pd: I'm very happy to be at this point; as fast as we did. 
+
+
+
+Re: [Dillo-dev]Stage two
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-18 10:30
+
+Daniel,
+
+> I'll do it. I think I have more access time to computers from now on.
+> Perhaps (holds breath) I might even have Linux up and running...
+
+well, I already did it but...
+
+> Just give me the details and what you want me to do.
+
+Would you mind making some changes in the future? i.e. I send
+you the ASCII with the contents and you email me back the html
+pages?
+
+> Jorge Arellano Cid escribió:
+> ...
+
+¡Con acento y todo!
+Felicitaciones.
+
+
+Gracias
+Jorge.- 
+
+
+
+[Dillo-dev]**** Stage 2 ****
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-18 01:46
+
+Hi there!
+
+It seems that Luca has done 90% of the Stage 2 work with a
+couple of nice scripts!!!
+
+I run them and found minor problems that I want to polish
+before releasing a new tarball!!!
+
+The good new is that you won't have to do anything, stage 2 is
+almost complete!
+
+Some files didn't pass the object files test, so I'll check
+those tomorrow, fix a couple more things and voila, new tarball.
+From then and on we'll focus on BUG fixing.
+
+These ARE good news!
+
+Thank you very much Luca.
+
+Jorge.- 
+
+
+
+[Dillo-dev]*** Stage 2 ***
+
+From: Jorge Arellano Cid <jcid@in...> - 1999-12-18 01:25
+
+Hi there!
+
+It seems that Luca has done 90% of the Stage 2 work with a
+couple of nice scripts!!!
+
+I run them and found minor problems that I want to polish
+before releasing a new tarball!!!
+
+The good new is that you won't have to do anything, stage 2 is
+almost complete!
+
+Some files didn't pass the object files test, so I'll check
+those tomorrow, fix a couple more things and voila, new tarball.
+From then and on we'll focus on BUG fixing.
+
+These ARE good news!
+
+Thank you very much Luca.
+
+Jorge.-
+
+
+Pd: This message comes from another server cause mailtag is down. 
+
+
+
+Re: [Dillo-dev]Stage two
+
+From: Daniel Moore <ant@so...> - 1999-12-17 21:30
+
+I'll do it. I think I have more access time to computers from now on.
+Perhaps (holds breath) I might even have Linux up and running...
+
+Just give me the details and what you want me to do.
+
+Cheers,
+Daniel.
+
+Jorge Arellano Cid escribió:
+
+> Hi!
+>
+> Good news are:
+>
+> * I'm planning to release the new tarball today.
+> * Luca has plenty of patches
+> * The tarball has many many changes (you'll see)
+> * I have stage two directives written
+> (just need to put them on the web site)
+>
+> Bad news are:
+>
+> * Jarrod has no time now to arrange the web site.
+> * I'll have to do that (delay root...)
+>
+> Jorge.-
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]Updated web site
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-17 20:37
+
+Hello!
+
+Finally, the new Web site is up and running.
+Go take a look at it; several things changed.
+
+I wrote a bit of everything there :)
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]New tarball release
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-17 17:42
+
+Hi!
+
+Is official now, there's a new tarball: dillo-0.0.2.tar.gz
+Grab it from the site!
+
+Luca tested it and it works fine...
+(dillo-0.0.2.tar.gz is exactly the same as d2.tar.gz)
+
+enjoy
+Jorge.-
+
+
+Pd: Feedback? 
+
+
+
+Re: [Dillo-dev]New tarball test oportunity :)
+
+From: Rota Luca <drake@fr...> - 1999-12-17 16:42
+
+On Fri, 17 Dec 1999, Jorge Arellano Cid wrote:
+
+> I really hate a tarball that doesn't compile, so the first one
+> to answer this mail, will be replied with the alfa tarball URL,
+> and I'll wait online for him to reply me the results. OK?
+
+d2.tar.gz compile fine and work fine on my box.
+I get only a pair of warning (but they're in the previous tarball, too).
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]tarball alpha test
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-17 14:26
+
+Hi!
+
+
+Well, I waited online, but nothing happened..
+The alpha tarball is name d2.tar.gz.
+I'll check your answers ASAP; got to go out now....
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]New tarball test oportunity :)
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-17 13:00
+
+Hi!
+
+I just finished the new tarball. We're only one step aside
+from dillo-0.0.2 release: the alfa test.
+
+I really hate a tarball that doesn't compile, so the first one
+to answer this mail, will be replied with the alfa tarball URL,
+and I'll wait online for him to reply me the results. OK?
+
+(Yes, I tested it thoroughly here, but it always seems to run
+perfect on the packager's machine...)
+
+I'll be right here!
+(updating the web site)
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Stage two
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-17 10:23
+
+Hi!
+
+
+Good news are:
+
+* I'm planning to release the new tarball today.
+* Luca has plenty of patches
+* The tarball has many many changes (you'll see)
+* I have stage two directives written
+(just need to put them on the web site)
+
+Bad news are:
+
+* Jarrod has no time now to arrange the web site.
+* I'll have to do that (delay root...)
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Stage two
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-16 00:08
+
+Hi!
+
+
+Jarrod is arranging the web site now, and I'm setting the
+framework to start with stage two; I have to finish the tarball
+too... I hope it to be ready in a couple of days.
+
+James: I was talking about the patch that you described
+writing:
+"All this patch does is fix the bug where hitting reload before
+loading any pages crashes the browser. It also adds some
+consistency to initialization of dillo objects."
+
+
+Sammy: I referred the patch that:
+"changes: bookmarks add shortcut is now <ctrl+d>
+changed gzilla menu to file menu (heh)
+changed help - gzilla home and gzilla manual to
+dillo home/manual :)
+reindented source
+made the name changes for the functions : a_Menu_
+etc ..."
+
+if you have an actualized version of it, GOOD! :-)
+
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]News
+
+From: nightstalker <nstalkie@tv...> - 1999-12-15 17:46
+
+Jorge Arellano Cid wrote:
+
+> Hello everyone!
+>
+
+hi :)
+
+>
+> The big menu patch from sammy (45 Kb) will remain queued until
+> stage two completes. I hope stage two effort not to take more
+> than one week.
+>
+
+be careful when applying that .. it also has a .h file that is changed
+.. (because one of the
+a_Menu things should be dumped from .h and changed to Menu... )
+
+anyways, the patch is so big cause i also did reindenting in that one.
+i didn't make a lot of changes to the code .. 
+
+
+
+[Dillo-dev]News
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-15 12:14
+
+Hello everyone!
+
+
+Today I'm very happy and maybe in a couple of weeks I'll have
+very good news for the project (even more)... Hold on, if it
+happens, I tell you!
+
+Now I have some work to do but, after that, I'll go to the Web
+site console and make some updating there; the stage one of the
+naming&coding effort is about to finish, and now is time to set
+a framework for stage two.
+
+I'd be very happy to have a Web site maintainer (or
+volunteer), someone that I could send ASCII text with the Web
+site contents, and from whom I can get back the HTML (well,
+there's some site arranging and design work involved). That way
+it would be much easier for me to keep fresh contents there...
+But if you're able to do patching or BUX fixing work, I'd
+rather prefer you to work on those areas!
+
+Stage two will be cleanning time (discussed on the list) and
+time for fixing (improving and wiping) all those rough edges you
+had taken notes on, while working out the sources.
+
+For instance, when facing the IO module, I found an incredible
+mess there! It was so impressive that I decided to block every
+single source with my name at the progress-track-monitor, just to
+work it out heavily; you'll see what I did in the next Dillo
+tarball.
+
+The same happened when a got to the URL module; but this time
+it didn't take me by surprise. BTW I was led there by a BUG! (one
+more). And it was cloaked with some fancy stuff! There were
+function definitions within the header files (__inline__); that
+makes them invisible to a debugger...
+
+So I decided to rearrange the whole thing. Once I was ready
+with that, bug hunting was a pleasure! Thanks to you all!!!
+
+I'll try to release the tarball for stage two as soon as
+possible. It'll include several improvements, as the ones I
+described before, plus some compile time warnings fixes, updated
+automake stuff, some other bugs fixed, indented code,
+more documentation within the source, some patching I have queued
+(from James).
+
+The big menu patch from sammy (45 Kb) will remain queued until
+stage two completes. I hope stage two effort not to take more
+than one week. 
+
+
+After stage two succeeds, I'll try to start working with the
+CVS repository (don't worry, you'll always have a tarball
+alternative).
+
+
+Best regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]#ifdef USE_GZW
+
+From: <jamesm@gt...> - 1999-12-14 22:18
+
+We should definitely get rid of these #ifdefs. They were probably
+useful when the gzw module was under development, but now it simply
+adds more bytes to the source tree.
+
+-James McCollough 
+
+
+
+Re: [Dillo-dev]#ifdef USE_GZW
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-14 22:13
+
+Hello!
+
+
+On Tue, 14 Dec 1999, Rota Luca wrote:
+
+> 
+> Hi,
+> 
+> I notice that in some files (gzilla{html,plain,web}) there is often the
+> code:
+> 
+> #ifdef USE_GZW
+> gzw_function();
+> #else
+> gtk_function();
+> #endif
+> 
+> Maybe, we could keep the gzw version only, to make the code more readable.
+> What do you think about it?
+
+I think just as you and Sammy, let's wipe that at the second stage!
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]#ifdef USE_GZW
+
+From: nightstalker <nstalkie@tv...> - 1999-12-14 19:00
+
+Rota Luca wrote:
+
+> Hi,
+>
+> I notice that in some files (gzilla{html,plain,web}) there is often the
+> code:
+>
+> #ifdef USE_GZW
+> gzw_function();
+> #else
+> gtk_function();
+> #endif
+>
+> Maybe, we could keep the gzw version only, to make the code more readable.
+> What do you think about it?
+>
+> Ciao,
+> Luca
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+yep, i think we should keep only one of those ... it makes the source more
+readable,
+and we don't have to support old stuff we won't use anymore :)
+
+i found this too in some files (this had to do with supporting gtk 1.1)
+
+sammy. 
+
+
+
+[Dillo-dev]#ifdef USE_GZW
+
+From: Rota Luca <drake@fr...> - 1999-12-14 18:12
+
+Hi,
+
+I notice that in some files (gzilla{html,plain,web}) there is often the
+code:
+
+#ifdef USE_GZW
+gzw_function();
+#else
+gtk_function();
+#endif
+
+Maybe, we could keep the gzw version only, to make the code more readable.
+What do you think about it?
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]I am in doubt what to do!
+
+From: Rota Luca <drake@fr...> - 1999-12-12 21:44
+
+On Sat, 11 Dec 1999, Jorge Arellano Cid wrote:
+
+> > 1. a_gtk_Dw_view_new
+> > 2. a_Dw_gtk_view_new
+> > 3. a_Dw_view_new
+> > Which do you want?
+
+> Number 2.
+
+OK!! I like it, too.
+
+> Pd: Haven't seen your vote on braces placement yet!
+
+I prefer:
+
+if( x == y ) 
+{
+x++;
+y--; 
+} 
+else 
+{
+x--;
+y++;
+}
+
+But it's not so important for me :).
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]Re: reindenting
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-12 13:06
+
+Hi,
+
+Thank you very much for answering Jarrod's email Sammy.
+I'll just add a bit to it...
+
+
+> > Jarrod
+> Sammy
+Me
+
+
+> > I've got a little (Very little) experience in
+> > C++, but let me tell you what I would like to see..
+> > could someone do some sort of heavy commenting on the
+> > code? 
+
+Have you been there?
+The code is commented, not heavily, but up to a good amount
+IMHO. Comments aim to unveil the algorithms, or the internals,
+not to explain every single detail...
+
+Why?
+
+Because programming expertise is an scarce resource, and
+solid programming expertise is even more rare, so when a project
+happens to count with one of those star-developers, the trade off
+is to sacrifice documentation for highly-valued SW.
+I'm not putting this to black or white, please don't get me
+wrong; it IS a trade off.
+
+
+
+> > Or at least do a cflow with a quick
+> > description? I understand C a bit, but I need to see
+> > some type of roadmap, and "read the archives" is a bit
+> > too vague..
+
+I'd very much like to see a quick description too, so I tried
+to put such an introduction at the web site. I know it was
+appreciated cause I can feel a strong collaborative spirit within
+this project, and I'm very delighted with that; the efforts this
+guys are putting in are not unnoticed by me, the work is tough
+and their commitment has been generous to the bone.
+
+Have you wondered why the naming&coding change effort is
+taking place?
+
+Please, be fair on us and don't blame we put you to "read the
+archives".
+
+
+> > I know it seems like a lot, but if I'm
+> > ever going to help on the coding end (or if any one
+> > else is, for that matter) we kinda need to know what's
+> > going on..
+> 
+> you are right ! Dillo is a BIG program and you need to see
+> some kind of flow in the source. i don't know a lot about
+> the internals of Dillo yet too :(. 
+
+Knowing the whole functionning of Dillo is hard even for a
+core developer. And maybe I'm the one that has been more
+thoroughly to the code at this point, so I designed the
+naming&coding style, layer abstractions, changing algorithm,
+progress tracker and I'm also doing the patch integration task...
+
+Once we succeed with this, it will be *very* much easier for
+everyone to step into the code and to find out what's going on
+there, and then, based on individual specific-areas expertise
+we'll get to document it.
+
+But that will be after bug chasing, cause that's the highest
+priority (stability), and with the extra knowledge gained from
+that stage, the documentation will be more clean, accurate and
+pertinent.
+
+
+> i was thinking about
+> making some kind of overview that lists every module and
+> every function together with what it is supposed to do/does)
+> this way we can also try to avoid reimplementing thins like
+> lists etc ... and: if you find a bug in a function, you can easily
+> lookup which functions performs a similar task to see if the
+> bug is there too ...
+
+Sammy is right, that's the idea. 
+(although it needs polishing work)
+
+
+
+Ok, that's what I needed to say about that. Please don't get
+distracted with this and let's continue working on the naming
+effort. We still have a lot of work to do finishing the first
+stage.
+
+Whe we get to the second stage (remember the notes I asked
+you to take when reviewing the modules), and those new changes
+are integrated, it will be celebration time!
+
+It took a long time to write this answer, and I have plenty
+of patches waiting at my queue, but I thought this information
+about near-future-plans, would be very useful to us all.
+
+
+OK, now I'll get back to work those patches in...
+
+
+Sincerely
+Jorge.-
+
+
+Pd:
+
+> i always use braces, even for one line of code ...
+
+OK Sammy, you convinced me, I'll try to add the braces.
+
+
+Pd2:
+
+> > Also.. one other odd thing.. Dillo does not like
+> > glibc2.1 systems. I recall there being some sorta
+> > manual fix for gzilla, and I know it'd work on my
+> > system.. but I can't recall WHAT that fix was. It
+> > involved (If I recall correctly) something with the
+> > LDL. Anyone manage to save that?
+
+Please let us know what compile time errors you got.
+I know it works ok with glibc2 systems but extra info is
+welcomed.
+
+> i don't know about this one ...something i wanted to add :
+> i tried out the new tarball today (dillo-0.0.1) and it
+> compiled fine again on my system (with the 0.0.0 i had to
+> type make inside the src/ dir .. make would fail in the
+> dillo-0.0.0 dir (due to a configure it did). i'm happy this is
+> fixed :)
+
+I made the autoheader, autoconf, automake stuff again, I hope
+that was the fixing root :-) 
+
+
+
+[Dillo-dev]extended cvs explanation
+
+From: <jamesm@gt...> - 1999-12-11 20:41
+
+Here's an outline as to how to use dillo's CVS repository:
+
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+Anonymous CVS Access
+
+This project's SourceForge CVS repository can be checked out through
+anonymous (pserver) CVS with the following instruction set. When prompted
+for a password for anonymous, simply press the Enter key.
+
+set the environment variable CVSROOT to :pserver:anonymous@cv...:/cvsroot/dillo
+
+then execute:
+
+$ cvs login
+$ cvs checkout dillo
+
+this will create a directory in the current directory called dillo with
+a duplicate of the source in the repository.
+
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+Developer CVS Access via SSH 
+
+***NOTE: this is only for Jorge right now
+
+Only project developers can access the CVS tree via this method. SSH1
+must be installed on your client machine. Substitute username with the 
+proper values. Enter your site password when prompted.
+
+set the environment variable CVS_RSH to ssh and the CVSROOT variable to
+username@cv...:/cvsroot/dillo
+
+first, execute:
+$ cvs checkout dillo
+
+to have a copy in sync with the CVS server. the apply your patches to
+your local 'dillo' directory that was created with the checkout
+command. Once you are comfortable with the changes, and they have
+been tested, update the repository to reflect your changes with this
+command:
+
+$ cvs commit dillo
+
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+Browse the CVS Tree 
+
+Browsing the CVS tree gives you a great view into the current status of
+this project's code. You may also view the complete histories of any
+file in the repository.
+* http://cvs.so....net/cgi-bin/cvsweb.cgi?cvsroot=dillo 
+
+
+
+Re: [Dillo-dev]Re: reindenting
+
+From: nightstalker <nstalkie@tv...> - 1999-12-11 17:31
+
+Jarrod Henry wrote:
+
+> Granted, I am VERY new to C. In fact I doubt I could
+> understand coding at all on this project, I'm just
+> trying to help in whatever meager ways I can. I've
+
+you can help in a lot of ways ! for example the name changing
+we are doing at the moment. you don't need a lot of c
+experience to do that. Some bugs will also be somewhat
+easy stuff to do (for example the menu changes i did once, and
+the UI things).
+
+anyways: your c knowledge will improve :) (if you don't give
+up too soon :)) an advice : be sure you understand pointers
+very well ! it's one of the more important things in c and also
+THE trickiest thing :) many bugs result from having NULL pointers
+or from not calling free when using malloc etc ...
+
+
+>
+> not really been able to work much at all outside the
+> very initial website frontpage due to finals at
+> school. I've got a little (Very little) experience in
+> C++, but let me tell you what I would like to see..
+> could someone do some sort of heavy commenting on the
+> code? Or at least do a cflow with a quick
+> description? I understand C a bit, but I need to see
+> some type of roadmap, and "read the archives" is a bit
+> too vague.. I know it seems like a lot, but if I'm
+> ever going to help on the coding end (or if any one
+> else is, for that matter) we kinda need to know what's
+> going on..
+
+you are right ! Dillo is a BIG program and you need to see
+some kind of flow in the source. i don't know a lot about
+the internals of Dillo yet too :(. i was thinking about
+making some kind of overview that lists every module and
+every function together with what it is supposed to do/does)
+this way we can also try to avoid reimplementing thins like
+lists etc ... and: if you find a bug in a function, you can easily
+lookup which functions performs a similar task to see if the
+bug is there too ...
+
+one of the better ways to learn something about the code is
+reading doc/bytesink.txt or something like that. it explains
+what a bytesink is and how it is used in gzilla/Dillo. it also
+explains what happens when between the time you enter an url
+and when dillo displays your html page.
+i think we need more docs like this (btw: this doc needs
+updating when the name change is done)
+
+another way to find out something is by stepping through it with
+a debugger (for example ddd, a nice frontend for gdb)
+
+
+
+> --- nightstalker <nstalkie@tv...> wrote:
+> > > I really don't like this format:
+> > >
+> > > > if( blah == blahblah )
+> > > > {
+> > > > hello();
+> > > > }
+>
+
+btw: i didn't write this :)) it was a reply to a message i sent where
+i said the opposite :)
+
+>
+> I like this. One statement per line. The ultimate
+> reason I like this format is because the {'s are
+> matched. I know a lot of editors will source
+> highlight around the mismatched braces/parens, but
+> this makes the code readable without using those
+> editors. Just MHO. I mean, we can use indent *.[ch]
+> if we really wanna set it up our own ways :)
+>
+
+i like this form better too :) the number of lines of the code
+go up, but i think this is more readable than the other form.
+btw: this way of indenting is called BSD-style indenting i
+believe.
+
+
+>
+> > > > if( blah == blahblah ) {
+> > > > hello();
+> > > > }
+>
+> I don't. First off, it's bad form :) It's a single
+> line of code following a test. That means you don't
+> need the braces. But that's just my compsci
+> instructor speaking through me. The bad part about
+> this code is that the braces aren't matched up. Throw
+> another function around that , and it gets really hard
+> to read. Ex:
+>
+
+i always use braces, even for one line of code .. i'll try to explain
+why ...
+when you want to add something, sometimes a guy will not pay
+attention and just add it :) then you get something like : (using
+my preferred indenting :)
+
+if( blah == blahblah )
+hello();
+hello2();
+
+i also do it because it just looks better in my opinion :)
+
+
+>
+> void somefunc(int count, float& average)
+> {
+> if (count <= 200) {
+> printf("Count is less than or equal to 200");
+> average+=count;
+> }
+> return;
+> }
+>
+> My problem with this is on a glance over, it doesn't
+> look like the decision was exited correctly. Or it
+> could appear unclear that the average+= line is part
+> of the true case. Or a variety of other things. The
+> purpose (as this beginner) sees to indenting is to
+> make the code readable. Lining up the braces and
+> parens help to isolate blocks on quick run-throughs.
+> I already have a ton of work to do once I get free of
+> school this semester to learn the ins and outs of
+> Dillo.
+>
+
+code like that is the reason why we want to re-indent :)
+
+
+>
+> Also.. one other odd thing.. Dillo does not like
+> glibc2.1 systems. I recall there being some sorta
+> manual fix for gzilla, and I know it'd work on my
+> system.. but I can't recall WHAT that fix was. It
+> involved (If I recall correctly) something with the
+> LDL. Anyone manage to save that?
+>
+
+i don't know about this one ...something i wanted to add :
+i tried out the new tarball today (dillo-0.0.1) and it
+compiled fine again on my system (with the 0.0.0 i had to
+type make inside the src/ dir .. make would fail in the
+dillo-0.0.0 dir (due to a configure it did). i'm happy this is
+fixed :)
+
+
+>
+> Jarrod
+> 
+
+
+
+Re: [Dillo-dev]Re: reindenting
+
+From: Jarrod Henry <magnwa@ya...> - 1999-12-11 17:03
+
+Granted, I am VERY new to C. In fact I doubt I could
+understand coding at all on this project, I'm just
+trying to help in whatever meager ways I can. I've
+not really been able to work much at all outside the
+very initial website frontpage due to finals at
+school. I've got a little (Very little) experience in
+C++, but let me tell you what I would like to see..
+could someone do some sort of heavy commenting on the
+code? Or at least do a cflow with a quick
+description? I understand C a bit, but I need to see
+some type of roadmap, and "read the archives" is a bit
+too vague.. I know it seems like a lot, but if I'm
+ever going to help on the coding end (or if any one
+else is, for that matter) we kinda need to know what's
+going on..
+
+
+Now..
+
+--- nightstalker <nstalkie@tv...> wrote:
+> > I really don't like this format:
+> >
+> > > if( blah == blahblah )
+> > > {
+> > > hello();
+> > > }
+
+I like this. One statement per line. The ultimate
+reason I like this format is because the {'s are
+matched. I know a lot of editors will source
+highlight around the mismatched braces/parens, but
+this makes the code readable without using those
+editors. Just MHO. I mean, we can use indent *.[ch]
+if we really wanna set it up our own ways :)
+
+> > > if( blah == blahblah ) {
+> > > hello();
+> > > }
+
+I don't. First off, it's bad form :) It's a single
+line of code following a test. That means you don't
+need the braces. But that's just my compsci
+instructor speaking through me. The bad part about
+this code is that the braces aren't matched up. Throw
+another function around that , and it gets really hard
+to read. Ex:
+
+void somefunc(int count, float& average)
+{
+if (count <= 200) { 
+printf("Count is less than or equal to 200");
+average+=count;
+}
+return;
+} 
+
+My problem with this is on a glance over, it doesn't
+look like the decision was exited correctly. Or it
+could appear unclear that the average+= line is part
+of the true case. Or a variety of other things. The
+purpose (as this beginner) sees to indenting is to
+make the code readable. Lining up the braces and
+parens help to isolate blocks on quick run-throughs. 
+I already have a ton of work to do once I get free of
+school this semester to learn the ins and outs of
+Dillo. 
+
+Also.. one other odd thing.. Dillo does not like
+glibc2.1 systems. I recall there being some sorta
+manual fix for gzilla, and I know it'd work on my
+system.. but I can't recall WHAT that fix was. It
+involved (If I recall correctly) something with the
+LDL. Anyone manage to save that?
+
+Jarrod
+
+__________________________________________________
+Do You Yahoo!?
+Thousands of Stores. Millions of Products. All in one place.
+Yahoo! Shopping: http://shopping.yahoo.com 
+
+
+
+Re: [Dillo-dev]Re: reindenting
+
+From: nightstalker <nstalkie@tv...> - 1999-12-11 16:45
+
+Jorge Arellano Cid wrote:
+
+> Hello,
+>
+> I really don't like this format:
+>
+> > if( blah == blahblah )
+> > {
+> > hello();
+> > }
+>
+> I prefer this method:
+>
+> > if( blah == blahblah ) {
+> > hello();
+> > }
+>
+> That's my argument.
+> -James McCollough
+>
+> Me too!
+> -Jorge Arellano Cid
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO :)
+
+sammy.
+
+ps: i'll learn to live with it :) 
+
+
+
+Re: [Dillo-dev]I am in doubt what to do!
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-11 11:41
+
+Luca,
+
+Good to see you posting here!
+(I was very worried about the list failing to reach it's
+susbscribers) 
+
+
+> Hello World,
+> 
+> I have to patch gtkgzwview.c but I don't know what to do.
+> 
+> I thought, from gtk_gzw_view_new to:
+> 1. a_gtk_Dw_view_new
+> 2. a_Dw_gtk_view_new
+> 3. a_Dw_view_new
+> 
+> Which do you want?
+
+Number 2.
+
+Why?
+Cause as a wrote before, when asked the same, (I don't remember
+where; blesses to the list), I see Dillo Widget as a whole
+module. So, from #2 it would be clear that the module is Dillo
+Widget, that the functionality is view_new and that it's gtk
+based. Finally I should name the source 'dillogtkview.c' later...
+
+
+
+Jorge.-
+
+
+Pd: Haven't seen your vote on braces placement yet! 
+
+
+
+[Dillo-dev]I am in doubt what to do!
+
+From: Rota Luca <drake@fr...> - 1999-12-11 10:44
+
+Hello World,
+
+I have to patch gtkgzwview.c but I don't know what to do.
+
+I thought, from gtk_gzw_view_new to:
+1. a_gtk_Dw_view_new
+2. a_Dw_gtk_view_new
+3. a_Dw_view_new
+
+Which do you want?
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]Re: reindenting
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-10 10:37
+
+Hello,
+
+I really don't like this format:
+
+> if( blah == blahblah )
+> {
+> hello();
+> }
+
+I prefer this method:
+
+> if( blah == blahblah ) {
+> hello();
+> }
+
+to quote from the CodingStyle document in the linux kernel
+documentation:
+
+Chapter 2: Placing Braces
+
+The other issue that always comes up in C styling is the placement of
+braces. Unlike the indent size, there are few technical reasons to
+choose one placement strategy over the other, but the preferred way, as
+shown to us by the prophets Kernighan and Ritchie, is to put the opening
+brace last on the line, and put the closing brace first, thusly:
+
+if (x is true) {
+we do y
+}
+
+However, there is one special case, namely functions: they have the
+opening brace at the beginning of the next line, thus:
+
+int function(int x)
+{
+body of function
+}
+
+Heretic people all over the world have claimed that this inconsistency
+is ... well ... inconsistent, but all right-thinking people know that
+(a) K&R are _right_ and (b) K&R are right. Besides, functions are
+special anyway (you can't nest them in C). 
+
+Note that the closing brace is empty on a line of its own, _except_ in
+the cases where it is followed by a continuation of the same statement,
+ie a "while" in a do-statement or an "else" in an if-statement, like
+this:
+
+do {
+body of do-loop
+} while (condition);
+
+and
+
+if (x == y) {
+..
+} else if (x > y) {
+...
+} else {
+....
+}
+
+Rationale: K&R. 
+
+Also, note that this brace-placement also minimizes the number of empty
+(or almost empty) lines, without any loss of readability. Thus, as the
+supply of new-lines on your screen is not a renewable resource (think
+25-line terminal screens here), you have more empty lines to put
+comments on. 
+
+(end quote)
+
+That's my argument.
+-James McCollough
+
+Me too!
+-Jorge Arellano Cid 
+
+
+
+[Dillo-dev]CVS information
+
+From: <jamesm@gt...> - 1999-12-10 02:18
+
+Here's a brief explanation of CVS, as well as links to additional
+information.
+
+CVS is a beautiful thing. It allows a set of developers to work on a
+single set of sources, and allows users to get daily updates to the
+source. Generally you have anonymous read access set up, so anyone can
+get the sources, and you also have write access for a select few who
+can make changes.
+
+quoted from the cvs man page:
+
+CVS is a version control system, which allows you to keep
+old versions of files (usually source code), keep a log of
+who, when, and why changes occurred, etc., like RCS or
+SCCS. Unlike the simpler systems, CVS does not just oper-
+ate on one file at a time or one directory at a time, but
+operates on hierarchical collections of directories con-
+sisting of version controlled files. CVS helps to manage
+releases and to control the concurrent editing of source
+files among multiple authors. CVS allows triggers to
+enable/log/control various operations and works well over
+a wide area network.
+
+cvs keeps a single copy of the master sources. This copy
+is called the source ``repository''; it contains all the
+information to permit extracting previous software
+releases at any time based on either a symbolic revision
+tag, or a date in the past.
+
+links:
+
+the homepage of cyclic software, makers of CVS:
+http://www.cyclic.com
+
+a page with links to documentation and other tools:
+http://www.loria.fr/~molli/cvs-index.html 
+
+
+
+[Dillo-dev]Reindenting
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-10 02:13
+
+Hi!
+
+
+I don't know why, but my former message got to the list
+incomplete... 
+
+I'm polling you on the '{', '}' placement as ilustrated in the
+former msg. 
+Everyone in the name change has a vote!
+
+Vote here, to the list.
+
+
+Jorge.-
+
+
+Pd: I don't know if you're receiving this messages, so please
+acknowledge it to my by email. Subject: dillo-dev OK 
+
+
+
+[Dillo-dev]Re: reindenting
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-10 02:01
+
+On Thu, 9 Dec 1999, nightstalker wrote:
+
+> What's the way you are going to use for the re-indenting ? (i know it's
+> a topic of it's own but .. :)
+> 
+> i prefer :
+> 
+> if( blah == blahblah )
+> {
+> hello();
+> }
+> 
+> i hate:
+> 
+> if( blah == blahblah ) {
+> hello();
+> }
+> 
+> :))
+> 
+> if you decide to re-indent the source like the second style, i'll live
+> with it :) i was just a bit curious :))
+> 
+> 
+> 
+> 
+
+
+
+[Dillo-dev]Halfway advanced tarball
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-09 23:29
+
+Hello!
+
+I'm just uploading the "new" tarball to the website. It has
+every single patch I received integrated & tested; chances are
+you'll like it very much.
+
+The effort is not completed though...
+
+With this second half of the naming process, let's start it
+over again, i.e. unpack the new tarball, ./configure; make,
+create the obj/ dir, copy the objects there, strip them and start
+the patching process.
+
+Please do it by module, don't concatenate patches.
+And if your patch needs to modify one of the sources within
+the src/ subdirectories (IO, MIME, URL or Cache), attach the
+patches for those as normal patch files, one patch, one source.
+Just issue a normal 'diff -bu' on them.
+
+
+Enjoy!
+Jorge.-
+
+
+Pd:
+http://academico.inf.utfsm.cl:81/~jcid/Dillo/dillo-0.0.1.tar.gz 
+
+
+
+[Dillo-dev]Patching news
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-09 19:23
+
+Hi,
+
+For those of you that're still praying, relax, I succeeded
+with every single patch (thanks above).
+
+Now I'm cleanning my source tree and when finished, I'll put
+it at the website so we can continue working from it. That'll be
+very soon (give me 4 hours). I'll announce it here, OK?
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Patching hell!
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-09 12:11
+
+Hello everyone!
+
+Currently I have a patching hell here!!!
+
+...but Don't worry, I can handle that; the fact that matters
+is that I *do* dislike it very much.
+
+Please: stop sending me patches for now. I'll try to integrate
+the ones I have now (Sammy's & James') and will put out an
+intermediate level source tarball to continue from.
+
+Please don't send me a huge integrated radioactive patch :-)
+That's really hard to manage. Send me "per module" patches.
+
+I'm currently struggling a 55 Kb. patch....
+
+
+Well, I feel the need to thank everyone collaborating with
+this effort, cause I've been there and I know how hard it is, and
+what a tough work it requires.
+
+I've had the pleasure of a short debugging session with the
+halfway-completed-tarball and it really pays off. You'll
+experience that soon, when I slay the big dragon in!
+
+We're cleanning the house, and it really looks&feels better
+although not completed yet; wait until I show you the identated
+version after the patching effort succeeds! That will be
+Champaigne time!!!
+
+
+Jorge.-
+
+
+Pd: Sammy, I'm putting my best efforts on it. 
+
+
+
+[Dillo-dev]CVS up
+
+From: <jamesm@gt...> - 1999-12-09 01:52
+
+hello,
+
+A CVS repository for dillo is up, consisting of the dillo-0.0.0
+release. to have anonymous read access, set your CVSROOT environment
+variable to:
+
+pserver:anonymous@cv...:/cvsroot/dillo
+
+and do a 'cvs login'. at the password prompt, simply hit enter.
+
+to checkout, do a 'cvs checkout dillo'.
+
+to obtain write access, please contact either jorge or me for details.
+
+-James McCollough
+
+P.S. if cvs.dillo.so....net doesn't resolve, use
+cvs1.so....net:/cvsroot/dillo 
+
+
+
+[Dillo-dev]name change within subdirectories
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-09 01:47
+
+Hi,
+
+I've been told that the progress monitor doesn't work with
+subdirectories...
+But it does!
+Just submit the file name, not including the directory and
+that'll do it. I've put an example there.
+
+(if I'm wrong, let me know)
+Jorge.- 
+
+
+
+[Dillo-dev]Patching hint
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-08 20:53
+
+Hi,
+
+I just managed to integrate gzwimage.c patch (by Luca) in a
+secure way. I mean, with identical object files. Here's what I
+found: g_print() and g_return_if_fail() integrate a function name
+to the object file (as a way of being able to provide that info
+at run time), and that's why the object files differ.
+
+A simple way of avoiding this object file incongruencies, is
+to change those functions, commenting them out in the original
+file (unpatched), making the object for it (save it stripped to
+obj/) and do the naming change process as usual. You'd eventually
+end up with identical object files. If that's true, submit the
+original patch to me with a note about that.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Naming&coding, hints and News
+
+From: Jorge Arellano Cid <jcid@ma...> - 1999-12-08 14:56
+
+Hello World!
+
+This is my first message to the list. We have a mailing list!!!
+Thanks James, your work has saved me precious time that I put to
+the patching effort.
+
+I'm very happy cause now you'll get more informed about project
+activities and related stuff. (I told James to add the "crew" to
+the list but, if you're feeling spammed, please let him know and
+to remove you (you can do that yourself too))
+
+
+============
+News & Hints
+============
+
+------------------------------------------------
+
+As the patches began to flow to my email account (keep sending
+them to me, not to the list), I noticed that sometimes the patch
+fails, even though it was done right, that's why I changed the
+diff format to 'unified'. It works better for me.
+
+Edit your 'mkpatch' script an before the last line you'll find:
+
+diff -b patch/ ./ > ptch
+
+change it to:
+
+diff -bu patch/ ./ > ptch
+
+that's all (or if you hesitate, download the new version from
+the web site).
+
+That'll make things simpler on the patching side ;)
+
+------------------------------------------------
+
+If you compile and get undefined references to renamed
+functions, that's just cause you forgot to erase the stripped
+object file.
+
+------------------------------------------------
+
+If you get to the progress-tracker and see the word 'DONE', it
+means I already succeeded integrating it to the new tarball.
+
+------------------------------------------------
+
+James as ked me what to do with structs, here's a quote:
+
+> for structs, does the 'a_' prefix show up at all?
+
+That's a good idea!
+
+I haven't included that things (neither the gzilla named
+structs and vars), and I think that it was good not doing it.
+Why?
+Because the current naming process is complex enough to scare
+our developers, and that kind of extra work would narrow our
+scope of collaborating people working on it.
+
+But that is to be accomplished on a second stage, and frankly I
+haven't thought of the struct-naming based on scope; that's why I
+found your idea good.
+
+Yes, probably that will be the future naming convention for it.
+I do like it that way.
+
+I.E. Exported structs prefixed with 'a_' and internal ones
+named freely, but declared static!
+
+Perfect.
+Don't do it now though, let it happen at the second stage.
+
+
+> Would GzillaImgSink struct become ImgSink or a_ImgSink?
+
+As long as it is exported, and following the former directives,
+it would be renamed 'a_ImgSink'.
+
+But, let's think of another exported struct, that's named
+simply 'mystery', then it should become 'a_Imgsink_mystery' just
+to show where it came from. Nice!!!
+
+
+------------------------------------------------
+
+Please remember that the naming effort is concurrent and very
+very fragile. We need to make it exactly as the 'manual' says. As
+a matter of fact, I put the manual on a VC an actually use it
+when making the changes!!!
+
+------------------------------------------------
+
+Luca: I tried to integrate your gzwimage.c patch, but the
+object files differ. I went thorough the patch itself, and found
+nothing suspicious :(, I tried from a clean source, but failed
+again so, would you mind sending me a new version? (using the new
+mkpatch); otherwise it will have to wait every other single patch
+to get in :(
+
+------------------------------------------------
+
+thankful
+Jorge.-
+
+
+
+
+Pd: Does anyone know what LOL means? :) 
+
+
diff --git a/old/oldmail/200001.txt b/old/oldmail/200001.txt
new file mode 100644
index 0000000..5bfcee1
--- /dev/null
+++ b/old/oldmail/200001.txt
@@ -0,0 +1,313 @@
+[Dillo-dev]News!
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-01-13 14:41
+
+HI there!
+
+Time for good news!:
+
+* Finally, I made the arrangements to keep working full-time on Dillo
+project (At least for some months). I think that will significatively help
+the whole project, specially at this critical fixing-redesignning stage.
+
+* Updated the web site
+
+* Fixed several things inside the code (including severe memory leaks).
+
+
+Currently I'm heavily changing the dicache, imgsink and Image modules
+(code, algorithms and ADTs). Please focus on bug fixing, and expect big
+changes in the next release!
+
+I'll try to devote all my time to this task; please excuse me if I 
+procrastinate other subjects...
+
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Memory Leak
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-01-07 15:09
+
+Luca,
+(& everyone)
+
+> Hi,
+> 
+> I'm testing Dillo and I don't like what I see. I've changed malloc in
+> g_malloc, free in g_free and realloc in g_realloc in all the source tree.
+> I've recompiled my glib with mem_profile enabled, at the end of main()
+> I've added g_mem_profile() just before the return.
+
+Nice!
+Did you just run a script to change them?
+(please send it to me)
+
+> 
+> Test:
+> Run Dillo and then press <CTRL-X> (to close Dillo): 
+> 143 Kb allocated
+> 35 Kb freed
+> 108 Kb in use :(
+> 
+> Run Dillo, open http://www.polito.it, open http://www.gzilla.com (here I got
+> GLib-WARNING **: freeing previously freed memory :( ), open segfault.org,
+> <CTRL-X>:
+> 2.8 Mb allocated
+> 1.8 Mb freed
+> 1 Mb in use :(
+> 
+> Run Dillo, open http://www.polito.it, open Dillo Home Page, open http://www.gzilla.com, 
+> <CTRL-X> (this time I have't got the GLib warning):
+> 1.9 Mb
+> 1 Mb
+> 0.9 Mb in use 
+> 
+> Maybe we'd solve this bug to stabilize Dillo, too.
+
+Of course.
+
+Some time ago, Daniel (Roberts) posted a very similar report to gzilla
+mailing list (he worked with 'leaky' or similar), the fact that matters is
+that Dillo doesn't deallocate the memory it uses before exiting; it leaves
+all the cleanning work to the OS.
+Specially significative is the DIC (decompressed image cache), wich I'm
+extensively working now; It allocates memory for every single image Dillo
+loads (uncompressed allocation).
+There're also other resources (I remember five lists of allocated stuff)
+that don't get deallocated when finishing...
+
+I think it would be very interesting to write the deallocating functions
+(as a_Dicache_free_all for instance), call them before exiting and
+make a review of what happens then.
+
+Personally, I've worked enough those modules, up to be deeply convinced,
+that such a test is required. I can even try to write some of those
+deallocating functions quickly.
+
+Actually, I've worked the code a lot, and would like to standarize it to
+g_malloc and friends (as you did), integrate your latest patch, write
+the deallocating functions, and make a new release to work with.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Memory Leak
+
+From: Luca Rota <drake@fr...> - 2000-01-06 15:35
+
+Hi,
+
+I'm testing Dillo and I don't like what I see. I've changed malloc in
+g_malloc, free in g_free and realloc in g_realloc in all the source tree.
+I've recompiled my glib with mem_profile enabled, at the end of main()
+I've added g_mem_profile() just before the return.
+
+Test:
+Run Dillo and then press <CTRL-X> (to close Dillo): 
+143 Kb allocated
+35 Kb freed
+108 Kb in use :(
+
+Run Dillo, open http://www.polito.it, open http://www.gzilla.com (here I got
+GLib-WARNING **: freeing previously freed memory :( ), open segfault.org,
+<CTRL-X>:
+2.8 Mb allocated
+1.8 Mb freed
+1 Mb in use :(
+
+Run Dillo, open http://www.polito.it, open Dillo Home Page, open http://www.gzilla.com, 
+<CTRL-X> (this time I have't got the GLib warning):
+1.9 Mb
+1 Mb
+0.9 Mb in use 
+
+Maybe we'd solve this bug to stabilize Dillo, too.
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]New release
+
+From: Jorge Arellano Cid <jcid@ma...> - 2000-01-05 23:45
+
+Sammy,
+
+
+> What is the library for the png routines ? i get undefined references
+> from png.c :)
+
+Sorry, it seems I'll have to include a check within the
+autoconf stuff...
+
+
+The PNG support requires libpng-1.0.5 or better
+(available at http://www.cdrom.com/pub/png/) 
+
+... it also requires zlib-1.1.3 or better
+(available http://www.cdrom.com/pub/infozip/zlib/)
+
+but if you're running Redhat, you'd better grab the rpms.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]New release
+
+From: <jamesm@gt...> - 2000-01-05 23:21
+
+its libpng, and it can be downloaded from ftp.cdrom.com or
+metalab.unc.edu, or just about any big ftp site. I also had to add -lz
+to the makefile to link with zlib (That's probably your problem).
+
+-James McCollough 
+
+
+
+Re: [Dillo-dev]New release
+
+From: nightstalker <nstalkie@tv...> - 2000-01-05 22:05
+
+What is the library for the png routines ? i get undefined references
+from png.c :)
+
+sammy 
+
+
+
+[Dillo-dev]New release
+
+From: Jorge Arellano Cid <jcid@ma...> - 2000-01-05 01:02
+
+Hi!
+
+
+Finally dillo-0.0.4 is finished, and ready for download. It
+includes several changes, bug fixes and improvements; some things
+didn't make it into the tarball due to stability concerns, but I
+hope to polish them enough to add them in the next release.
+Anyway you'll find plenty of changes in the Changelog.
+
+I hope you enjoy this release.
+
+Caveat: The background color support is not yet completed and
+if you happen to browse a page with BLACK background, you'll not
+see the text! -- Luca is currently working on this.
+
+
+Jorge.-
+
+
+Pd: James, tomorrow I'll send you a detailed answer in regard to
+the progress bar code; I liked it very much and I think we're a
+few touches away from a first class meter! 
+
+
+
+Re: [Dillo-dev]What's about i18n (internationalization)?
+
+From: Jorge Arellano Cid <jcid@ma...> - 2000-01-04 14:00
+
+Luca,
+(and everyone!)
+
+> Hi,
+> in this days I've tried to add i18n to Dillo. I'm using gettext package.
+> I've added the po/ and intl/ into source tree, modified the configure.in and
+> added the necessary code to dillo.c and menu.c thus I've tried to translate
+> some menu items in Italian (it works !).
+> 
+> So my question is: Are we interested in i18n?
+
+Of course it's a desirable feature, but I'd rather prefer we
+focus on bug fixing now; I've been deeply digging the sources
+these days and I'm somewhat scared on what I've found.
+
+Please don't get me wrong, I do like those new features, what
+I'm trying to do is to finish the stabilization process, and end
+up with a rock-solid browser that's easy to understand and to
+extend. BTW: when adding the PNG decoding routines, Geoff used a
+very similar aproach to what he saw with GIF and JPG. But the
+underlying mechanism was broken, so he was not able to know in
+advance that it wasn't his code's fault when some images were not
+rendering... I've experienced that several times before, and it's
+incredibly discouraging to start trying to find were the bug is
+(or whether your fault or not), in a very big code base that you
+don't know, that's undocumented and sometimes misleadingly
+commented...
+
+I don't want our developers to experience that painful coding
+facts, and that's why I prefer to stabilize, clean and fix what
+we have now, and after that, to focus on what we'd like to add or
+improve. As a matter of fact, I've found several more bugs while
+working the code and I'll introduce them into the bug track ASAP.
+
+Please don't be deceived by a pretty face, Dillo _IS_ very
+BUGGED now, we haven't reached the safe extensibilty milestone
+yet. You have been warned...
+
+
+------
+
+Luca:
+In regard to 'text', 'link', 'vlink' and 'alink', they are
+highly required now (cause bgcolor will be included in the next
+release). Please make a feature-fault entry at the bug-track and
+keep up the good job!
+
+
+sincerely
+Jorge.-
+
+
+Pd: I'll try to release dillo-0.0.4 today. 
+
+
+
+[Dillo-dev]What's about i18n (internationalization)?
+
+From: Luca Rota <drake@fr...> - 2000-01-03 14:50
+
+Hi,
+in this days I've tried to add i18n to Dillo. I'm using gettext package.
+I've added the po/ and intl/ into source tree, modified the configure.in and
+added the necessary code to dillo.c and menu.c thus I've tried to translate
+some menu items in Italian (it works !).
+
+So my question is: Are we interested in i18n?
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]Site is UP!!!
+
+From: Jorge Arellano Cid <jcid@ma...> - 2000-01-02 00:59
+
+Hi everyone!
+2000 year greetings to you!
+
+Quick Good News:
+
+- Our site is working again!!!
+(Go & check it please :)
+
+- Internet is working OK (No big Y2K problems here)
+
+- dillo-0.0.4 will be great!
+
+
+
+Jorge.- 
+
+
diff --git a/old/oldmail/200002.txt b/old/oldmail/200002.txt
new file mode 100644
index 0000000..20eee44
--- /dev/null
+++ b/old/oldmail/200002.txt
@@ -0,0 +1,295 @@
+Re: [Dillo-dev]New release & documentation
+
+From: nightstalker <nstaaalkie@tv...> - 2000-02-09 23:53
+
+jcid@ma... wrote:
+
+> Sammy,
+>
+> Glad to see you again!
+>
+
+Glad to be back too :) (although work is keeping me busy)
+
+>
+> > can anyone from the mailing list give me the url to the webpage?
+>
+> Yes! :)
+>
+> > i reinstalled my system but i forgot to copy my netscape
+> > bookmarks :)
+>
+> Deja vu (Did I spelled it right?)
+>
+> Ok Sammy, we're at:
+>
+> http://academico.inf.utfsm.cl:81/~jcid/Dillo/project.html
+>
+> and you'd surely want to download:
+>
+> http://academico.inf.utfsm.cl:81/~jcid/Dillo/dillo-0.0.5.tar.gz
+>
+> enjoy!
+>
+> Jorge.-
+>
+> Pd: Feedback welcome
+>
+
+it compiled like a breeze over here (running slackware 7 with newest
+version of glib &
+gtk )
+ran very well too .. allthough a bug that i fixed back when dillo was
+gzilla is back :)
+(as your first action : select bookmarks -> add bookmark ...
+'segmentation fault' )
+i'll see if i can fix it again (it shouldn't be so hard)
+
+i still notice that sometimes dillo starts taking a lot of cpu power (it
+doesn't appear to be
+doing anything though). I've noticed this with other versions of dillo
+too.
+
+congratulations on fixing the image code .. i could now surf to
+http://www.tuxedo.org/~esr/ and
+see all jpgs and png's :) 
+
+
+
+Re: [Dillo-dev]New release & documentation
+
+From: <jcid@ma...> - 2000-02-08 14:47
+
+Sammy,
+
+Glad to see you again!
+
+> can anyone from the mailing list give me the url to the webpage?
+
+Yes! :)
+
+> i reinstalled my system but i forgot to copy my netscape
+> bookmarks :)
+
+Deja vu (Did I spelled it right?)
+
+Ok Sammy, we're at:
+
+http://academico.inf.utfsm.cl:81/~jcid/Dillo/project.html
+
+and you'd surely want to download:
+
+http://academico.inf.utfsm.cl:81/~jcid/Dillo/dillo-0.0.5.tar.gz
+
+enjoy!
+
+
+Jorge.-
+
+
+Pd: Feedback welcome 
+
+
+
+Re: [Dillo-dev]New release & documentation
+
+From: nightstalker <nstalkie@tv...> - 2000-02-06 15:56
+
+hi,
+
+can anyone from the mailing list give me the url to the webpage ?
+i reinstalled my system but i forgot to copy my netscape
+bookmarks :)
+
+sammy 
+
+
+
+[Dillo-dev]New release & documentation
+
+From: Jorge Arellano Cid <jcid@ma...> - 2000-02-04 02:59
+
+Hi!
+
+Fresh news for you:
+
++ Just released dillo-0.0.5.tar.gz (DL. from website)
++ There're several improvements (read the Changelog)
++ Made minor updates to the web site
++ Wrote some documentation (attached with this mail)
+
+
+Well, before you download the source, let me tell you that
+this release features a couple of progress bars, but *don't
+expect them to work*, that will be fixed later. The problem is
+that they were developed while I was changing the image fetching
+routines... When I finish that, they'll get right.
+
+The second thing you should be aware of, is that although
+rendering is significatively improved, stability is very fragile.
+No, that's not due to rendering, but to socket abort handling. As
+a matter of fact, Dillo-0.0.5 is very stable on local networks.
+
+Needless to say, I'll focus on finishing the image fetching
+stuff, write some more docs, and then get to the sockets part.
+
+Finally, here I quote the notes I took while reviewing Dillo
+widget code, they are to be completed, corrected and improved.
+They were useful for me, so let's share them! 
+
+
+Sicerely
+Jorge.-
+
+
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+
+------------
+DILLO WIDGET
+------------
+
+------
+Resize
+------
+
+Widget resizing and repainting can be initiated by
+Dw_gtk_view_request_resize and Dw_gtk_view_request_paint
+functions. The resizing process is carried by an idle function
+(Dw_gtk_view_idle_func) that's launched upon request.
+
+Using an idle function to do it ensures good performance,
+as long as the resizing stuff gets done when the browser is not
+doing anything else.
+
+To start the resizing, a_Dw_request_parent_resize must be
+called, but beware, this routine is not a straightforward
+invocation of the widget method. Rather, it uses a resize flag
+mechanism; if the widget's resize flag was already set, nothing
+happens but, if not, the flag is set and the request_resize
+method on the widget parent is called.
+The actual resize is done later, by an idle function that
+discriminates upon those flags.
+The resize flag is cleared later by a_Dw_size_nego_y.
+
+The horizontal and vertical size methods are a_Dw_size_nego_x
+and a_Dw_size_nego_y. They call the appropriate widget-class
+method. For instance: if you call a_Dw_size_nego_x(wdg) and wdg
+is of type DwPage, then Dw_page_size_nego_x will be called.
+
+a_Dw_size_nego_x is called with the widget and requested width
+as parameters. a_Dw_size_nego_y is called with the widget and,
+width & height inside an allocation structure (that's why
+size_nego_x method isn't implemented sometimes). Anyway, the size
+negotiation sequence calls a_Dw_size_nego_x first, and after that
+it calls a_Dw_size_nego_y. If size_nego_x is NULL, there's no
+problem, but size_nego_y must be defined.
+
+
+Some vars:
+
+y_ascent = image height
+y_descent = 0 (for images)
+x_size = gdk_string_width(gdkfont, text) | widget width
+
+
+-------
+Repaint
+-------
+
+Dw_gtk_view_request_paint gets called whenever a child widget
+needs a repaint (generally issued as the request_paint method of
+the container class). The repaint rectangle is added to the
+request repaint region, and an idle process is started to repaint
+it if necessary (Dw_gtk_view_idle_func).
+
+The interesting fact is that Dw_gtk_view_idle_func performs
+both, resizing and repainting.
+
+
+------------------
+Rewrap (new stuff)
+------------------
+
+The rewrap stuff is not completely designed yet. What I
+implemented is a workaround that's somewhere between a hack and a
+clean patch; Yes, it's a tradeoff that lets the browser handle
+image resizes, and is tuned enough to be very fast.
+
+The rewrap function is set in Dw_page_request_resize as an
+idle function; that way, a single rewrap is done, instead of one
+per image resize. Even more, if the image is cached, there's no
+rewrap call cause the image size is already known.
+
+How is it done?
+a_Dw_image_size function requests a parent resize. When the
+resize-request reaches the top class, resize methods are called;
+that way, Dw_page_request_resize is run (at its turn). Inside
+Dw_page_request_resize, the page's rewrap-request-flag is set and
+an idle rewrap is launched.
+
+
+----------- O ----------- 
+
+
+
+Re: [Dillo-dev]Progress
+
+From: Luca Rota <drake@fr...> - 2000-02-01 21:20
+
+On Mon, 31 Jan 2000, Jorge Arellano Cid wrote:
+
+> Hi!
+> Is there anybody out there? :-)
+
+I'm always here. :)
+
+> Tomorrow will be testing time, and you can expect a new release
+> soon (maybe three or four days, gimme' some feedback).
+
+I'll wait ;)
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]Progress
+
+From: Jorge Arellano Cid <jcid@ma...> - 2000-02-01 01:37
+
+Hi!
+Is there anybody out there? :-)
+
+
+Well, finally the image rendering bug is fixed; that made a big
+change in Dillo (and a lot of work and changes in the inside).
+Tomorrow will be testing time, and you can expect a new release
+soon (maybe three or four days, gimme' some feedback).
+
+
+Current changelog looks like this:
+
+- * Added progress bars (to be improved)
+Patch: James McCollough, Jorge Arellano Cid
+- * Rearranged, changed and commented the decompressed image cache code
+* Fixed autoconf stuff to include zlib
+* Added memory deallocating functions to cache, dicache, socket, http & dns
+* Fixed memory leaks in jpeg.c, png.c and gif.c
+* Made several changes in dw_page.c
+* Made several "standarizing" changes all over the code.
+* Introduced ist.hsource
+* Fixed image rendering (Fixed algorithms and data structures)
+Patches: Jorge Arellano Cid <jcid@ma...>
+- * Added support for extand inkcolors inside <BODY> tags
+* Standarized all memory management to glib functions
+* Fixed the plugin API to work again (forked)
+* Removed a warning (remove not implemented for Dw_view and Dw_scroller)
+* Solved the page-without-title bug in bookmarks.
+Patches: Luca Rota <drake@fr...>
+
+
+
+Best regards
+Jorge.- 
+
+
diff --git a/old/oldmail/200003.txt b/old/oldmail/200003.txt
new file mode 100644
index 0000000..57b7fbf
--- /dev/null
+++ b/old/oldmail/200003.txt
@@ -0,0 +1,200 @@
+[Dillo-dev]Developer release
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-03-30 22:50
+
+Hi everyone!
+
+Today dillo-0.1.0.tar.gz is ready for download. It will be our
+first public developer release!
+
+When James finish setting it to on the sourceforge ftp server,
+I'll add a download link to the home page, announce it to the gtk
+devel mailing list, and it will be public!
+
+Comments are welcomed.
+
+
+Jorge.-
+
+
+Pd: Haven't got any feedback on the former release yet :-| 
+
+
+
+[Dillo-dev]Activity
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-03-15 16:16
+
+Hi,
+
+Has anyone downloaded dillo-0.0.6?
+(Haven't received a single comment yet...)
+
+Jorge.- 
+
+
+
+[Dillo-dev]New release
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-03-09 17:58
+
+Hi!
+
+Finally, dillo-0.0.6.tar.gz is out!
+Several bug fixes, feature additions and docs had been added.
+Please check it carefully and send me comments about the documentation.
+
+Beware:
+- The Image progress bar is not working properly, it needs further
+work.
+- Sometimes the IP transfer blocks the browser. I'm working on that...
+- Sometimes images are rendered as a white rectangle. Any clues?
+
+
+Finally, Luca added preferences that are to be set using a
+readable config file. I included a sample one within the tarball
+(dillorc). Copy it to your .dillo/ directory and adjust to your taste!
+
+Ah, I also updated the web site. Check it out!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Lots of news!
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-03-03 19:03
+
+Hi guys!
+
+Although mailing list activity had been dead, my email box has
+showed some traffic. A lot of things are happening now, and I wish
+to share the with all of you.
+
+dillo-0.0.6 is almost ready for release (less than a week more) and
+I want dillo-0.0.7 to be our first developer's release; Let's work 
+toward that goal!
+
+I've been working ironing some bugs (check the bug track) and writing
+DOCUMENTATION!!! All that stuff will be inside the next tarball in the
+doc/ dir. Please check it carefully and send me some feedback about it.
+What did you like? What you want extended? --things like that.
+If you feel confident enough to send me your extensions, please do so.
+
+The other part (the one that has taken most of my time) is the table and
+frames extensions to dillo parser. There were several alternatives, among
+them I found:
+
+1.- gtk-xmhtml
+2.- xml (Entity engine)
+3.- xhtml
+4.- gtkhtml
+5.- mMosaic source code
+
+The main point was to find a HTML-rendering library or some code
+that can be adapted to dillo.
+
+Briefly:
+
+1.- Is deprecated. (Dead, as Miguel de Icaza told me)
+
+2.- This is very interesting and consists on writing a new HTML parser
+but having all the rendering done by the Entity engine. Entity is a new
+project by Ian Main (he also worked in gzilla a long time ago). Entity is
+an XML parsing engine, written in C that can be used to develop apps.
+specified as XML with functionality implemented in another language.
+(Interesting, but I need more time to evaluate it. --Spent three and a
+half hours on IRC with Ian talking about it...)
+If you want to investigate, go to:
+http://entity.evilplan.org
+
+3.- XHTML is a family of current and future document types and modules
+that reproduce, subset and extend HTML 4. XHTML family doc. types are XML
+based, and ultimately are designed to work in conjunction with XML-based
+user agents.
+What does it means? That if we implement an XHTML parser, we should
+be able to handle that, some more and, with some little magic, HTML 4.0
+
+4.- gtkhtml is the html library that will superseed gtk-xmhtml in the
+gnome project. I tryed to try it :) as Miguel suggested, but id depended
+on several other gnome-libs (gnome-xml, glibwww, gnome-print, gtkhtml...)
+I gave up. It was impressively big, and the meaning of having a light
+weight browser is absolutely lost.
+
+5.- mMosaic claims to support TABLES and one level of frames. Maybe
+we can look there. (Zero research :( )
+
+Well, it seems we'll continue extending dillo widget to support tables
+and frames until we found a better way to do the job.
+
+Opinions&suggestions are welcome.
+
+
+------
+
+Sammy,
+
+I included all your patches in dillo-0.0.6
+
+> it compiled like a breeze over here (running slackware 7 with newest
+> version of glib & gtk)
+
+Good! (I plan to install Slk 7 soon)
+
+> i still notice that sometimes dillo starts taking a lot of cpu power
+> (it doesn't appear to be doing anything though). I've noticed this with 
+> other versions of dillo too.
+
+This worries me from time to time. I've never been able to reproduce
+the bug, and the only thing I can think of, is a surviving thread (maybe
+the scheduling one) from a KILL signal. Pleas check it.
+'ps aux | grep dillo'
+When you first run dillo, there should be one process. After the first
+DNS query, there should be 2. And from then and on, those two threads
+remain but when resolving a query, one more thread per query is
+temporarily added.
+
+> congratulations on fixing the image code .. i could now surf to
+> http://www.tuxedo.org/~esr/ and
+> see all jpgs and png's :)
+
+Thanks a lot.
+
+Finally: Are you working on the reload button?
+
+------
+
+James:
+
+I've been working the progress bars code. Finally moved them to the
+upper part and at least the text one is working reasonably well. I have
+to put further work with the image one though.
+I hope to improve those a bit before releasin dillo-0.0.6.
+
+Ah, I need my sourceforge account to have admin permissions!
+Currently it recognizes me as a user (No uploads, FTP, HTML site...)
+
+If you're stuck with bug #5, you'll find some good info in the docs I
+wrote (wait next release or send me an email request)
+
+
+-----
+
+Luca,
+
+I hope to have answered some of your questions with the first part
+of this book :)
+
+> What's about gtk-app-devel-list@re... (gtk mailing list) and the
+> so....net' news?
+
+The suggestions you gave to my gtk-oriented-announce-place request, seem
+OK to me. Lets keep it that way, unless a better one pops-up. 
+
+
+
+Sincerely
+Jorge.- 
+
+
diff --git a/old/oldmail/200004.txt b/old/oldmail/200004.txt
new file mode 100644
index 0000000..ba80bfb
--- /dev/null
+++ b/old/oldmail/200004.txt
@@ -0,0 +1,906 @@
+Re: [Dillo-dev]Sourceforge
+
+From: Jorge Arellano Cid <jcid@hu...> - 2000-04-24 19:15
+
+Hello World!
+
+
+First, I'd really appreciate feedback on my ematic.com email address,
+but I still don't know if it is world reachable.
+(If you can't deliver there, use jcid@ma... instead).
+
+
+On Sun, 23 Apr 2000 bigdaddy@ll... wrote:
+
+> I noticed that dillo is only using about 30% of all the sourceforge
+> resources that it could.
+
+Excellent, if you feel like updating it...
+
+> I.E. - The there is no webpage at http://dillo.so....net
+
+I wish it to be a mirror rather than a URL redirection.
+I'll keep the bug track engine and the primary site in the new server
+(dillo.inf.utfsm.cl) and use sourceforge to handle heavy network traffic
+(downloads and home page).
+
+> The ftp on sourceforge is very outdated.
+
+Update it, no problem (please delete the old tarball)
+
+> The CVS hasn't been updated in a while
+
+Not first priority. If updated, it would work as a checkout only.
+
+
+> I think it might be a good idea to update the sourceforge stuff. It might
+> help to bring more developers into the project.
+
+Thanks, please contact James and ask him the SW permissions to do that.
+It would be nice to announce the project in sourceforge news too...
+Please remember that this is a DEVELOPER's release. Not for USERS.
+
+> Switching over to sourceforge's bugtracking might not be a bad idea, but
+> since we already have an engine for that (though last time I checked it
+> wasn't working) it is not a high priority.
+
+The bug-track is healthy and working, check it at:
+
+http://dillo.inf.utfsm.cl/
+
+(it is was designed for this project, so we'll keep it)
+
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Sourceforge
+
+From: <bigdaddy@ll...> - 2000-04-24 01:45
+
+I noticed that dillo is only using about 30% of all the sourceforge
+resources that it could.
+I.E. - The there is no webpage at http://dillo.so....net
+The ftp on sourceforge is very outdated.
+The CVS hasn't been updated in a while
+So on, and so forth.
+I think it might be a good idea to update the sourceforge stuff. It might
+help to bring more developers into the project.
+At a minimum- make a re-direct on the dillo.so....net page to the
+real homepage, and update the ftp tarball. 
+Switching over to sourceforge's bugtracking might not be a bad idea, but
+since we already have an engine for that (though last time I checked it
+wasn't working) it is not a high priority.
+
+Does anybody else have any thoughts?
+
+-Mark
+
+"You can't get a blue screen on a black and white monitor." 
+
+
+
+Re: [Dillo-dev]ematic.com
+
+From: <bigdaddy@ll...> - 2000-04-22 21:28
+
+If this gets to you, then no ;-)
+
+-Mark
+
+"You can't get a blue screen on a black and white monitor."
+
+On Fri, 21 Apr 2000, Jorge Arellano Cid wrote:
+
+> 
+> Hi,
+> 
+> Has anyone experienced trouble sending mail to jcid@em...?
+> 
+> 
+> Jorge.-
+> 
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]ematic.com
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-21 18:19
+
+Hi,
+
+Has anyone experienced trouble sending mail to jcid@em...?
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]New server
+
+From: Jorge Arellano Cid <jcid@hu...> - 2000-04-20 14:25
+
+Hi!
+
+
+Just finished moving the web site!
+
+Take a look at: http://dillo.inf.utfsm.cl/
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Progress
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-20 01:44
+
+Hello crew!
+
+The new server is almost set; just need to recompile the CGIs
+and it will be ready!
+
+The cache rewrite is in progress, I just finished writing a
+whole new IO engine; the cache will be based on it, and the rest
+of Dillo will use the cache API.
+
+Please remember that after that's done, and the CPU hogging
+problem is fixed, we'll make a freshmeat announce!
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Current tarball
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-13 03:30
+
+Hi!
+
+
+You can get the latest tarball at
+
+http://academico.inf.utfsm.cl:81/~jcid/Dillo/d010a7.tgz
+
+(This is not a release yet; just some patches and progress trying
+to overcome the CPU-hogging bug)
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]CPU Hogging
+
+From: <greslin@li...> - 2000-04-12 13:34
+
+On Wed, Apr 12, 2000 at 09:12:28AM -0400, Jorge Arellano Cid wrote:
+> 
+> Ps: If you want to get a tarball with what's currently done, let
+> me know, just to put it online.
+
+Yes, please do.
+
+
+-- 
+Rob Warren
+
+email: greslin@li...
+homepage: http://www.iag.net/~aleris
+
+GXAnim: http://www.iag.net/~aleris/gxanim.html
+The Canvas Project: canvas.linuxpower.org
+OpenLaw DVD FAQ: http://www.cssfaq.org 
+
+
+
+[Dillo-dev]CPU Hogging
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-12 13:21
+
+Hello list!
+
+Greetings to the new members, and to the old ones!
+
+Some news from current project-status:
+
+I've been working with the CPU-hogging problem, and after
+fixing several things here and there (dns.c, socket.c, http.c,
+IO.c, IO.h, web.c, cache.c...), it's a decision: I'll rewrite the
+cache module.
+
+The cache module is split among several different parts in the
+code, and integrated in a subtle way with some others. Getting
+the idea of the data flow (and the algorithms) becomes a titanic
+task, and maintenance is almost impossible. Ah, and it's broken!
+
+Now I'm working on it, and when its done: a new tarball will be
+released. After that, we'll set dillo.so....net to be a
+mirror of our main site, and I'll make a freshmeat announce "urbi
+et orbi". 
+
+The new site server is almost ready. Just need to move the
+database and the bug-track engine there...
+
+If you feel like patching dillo, please focus on the rendering
+part for now; the low level routines are under heavy
+reconstruction.
+
+
+Best regards
+Jorge.-
+
+
+
+Ps: If you want to get a tarball with what's currently done, let
+me know, just to put it online.
+Ps2: Don't use the CVS now, it's outdated, and when we get it
+sync. it will serve as a checkout only. 
+
+
+
+[Dillo-dev]CPU hogging (part 1)
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-04-05 14:27
+
+Hi,
+
+I just fixed the short CPU hogging that happened when waiting 
+for a DNS query. (Look bug #50 in the bug-track).
+This doesn't mean that the whole CPU hogging problem is solved. Our
+mailing-list-archives-link still hogs the CPU (And forever).
+I'll focus on that now.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Announce
+
+From: <greslin@li...> - 2000-04-04 21:25
+
+On Tue, Apr 04, 2000 at 02:41:45PM -0400, Jorge Arellano Cid wrote:
+> [Rob said]
+> > Right now I'm far more concerned about this runaway CPU usage. Dillo compiled
+> > great out of the box, and it looks good and stable. But after only calling up
+> > a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable.
+> > 
+> > Does anyone have any idea what is causing this? I assume Dillo is using a
+> > threading system of some kind; could this be the problem?
+> 
+> OK, I've been workink on that.
+> It is NOT the threading system!
+> Actually, what causes the problem is URL redirection. If you hit a
+> redirected URL, the CPU will be hogged.
+
+I don't buy this. I've tried calling up my own web page at:
+
+http://www.iag.net/~aleris
+
+and sometimes it causes CPU hogging, sometimes it doesn't. It doesn't seem to be
+tied into the threading system at this point; I disabled threading support and
+it still happens. Somewhere there is a piece of code that drops into a nearly
+infinite loop or something. I suspect it is somewhere in the vicinity of the DNS
+resolution code but I can't prove it yet.
+
+
+
+> 
+> > Before we get too deep in making it pretty, we need to improve the infrastructure.
+> > The alternative is to end up with Netscape Communicator. :(
+> 
+> Yes man, I agree.
+> Have you figured out the whole mess that we had before this release?
+> 
+> Well, technically talking I've been studying the problem and almost
+> every problem comes from the IO engine change. It behaves asynchronously
+> but, it was struggled-in without the minimal considerations about that
+> kind of processing. I mean, several critical races were introduced and
+> it was merged with the former (streamed) implementatiom. Frankly I'm not
+> sure now if trying to fix it, or plainly rewriting it.
+
+The latter may be a better idea. This code is a mess, and we'll end up
+spending more time trying to figure the code out than we will fixing it.
+We should probably aim at a gradual rewrite of the browser itself before
+we start shoehorning new features into the current architecture.
+
+
+Rob Warren
+
+email: greslin@li...
+homepage: http://www.iag.net/~aleris
+
+GXAnim: http://www.iag.net/~aleris/gxanim.html
+The Canvas Project: canvas.linuxpower.org
+OpenLaw DVD FAQ: http://www.cssfaq.org 
+
+
+
+Re: [Dillo-dev]Announce
+
+From: <greslin@li...> - 2000-04-04 18:39
+
+On Tue, Apr 04, 2000 at 02:41:45PM -0400, Jorge Arellano Cid wrote:
+> 
+> Rob,
+> 
+> 
+> > I'm getting it through Sourceforge.
+> 
+> But you checked our site in the academico server, right?
+
+Yes, I have. It's just that I'm working through SF for other projects; this
+is more convenient for me.
+
+> 
+> > Do me a favor; could you go ahead and
+> > clear me as a developer? 
+> 
+> Sorry (my poor english), what do you mean?
+
+Go to Sourceforge and indicate to their systems that "Greslin" is one of
+your developers. This will give me update access to the CVS tree.
+
+
+> > Right now I'm far more concerned about this runaway CPU usage. Dillo compiled
+> > great out of the box, and it looks good and stable. But after only calling up
+> > a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable.
+> > 
+> > Does anyone have any idea what is causing this? I assume Dillo is using a
+> > threading system of some kind; could this be the problem?
+> 
+> OK, I've been workink on that.
+> It is NOT the threading system!
+> Actually, what causes the problem is URL redirection. If you hit a
+> redirected URL, the CPU will be hogged.
+
+I'll tinker with it when I get time.
+
+
+-- 
+Rob Warren
+
+email: greslin@li...
+homepage: http://www.iag.net/~aleris
+
+GXAnim: http://www.iag.net/~aleris/gxanim.html
+The Canvas Project: canvas.linuxpower.org
+OpenLaw DVD FAQ: http://www.cssfaq.org 
+
+
+
+Re: [Dillo-dev]Announce
+
+From: Jorge Arellano Cid <jcid@in...> - 2000-04-04 18:33
+
+Rob,
+
+
+> I'm getting it through Sourceforge.
+
+But you checked our site in the academico server, right?
+
+> Do me a favor; could you go ahead and
+> clear me as a developer? 
+
+Sorry (my poor english), what do you mean?
+
+> Right now I'm far more concerned about this runaway CPU usage. Dillo compiled
+> great out of the box, and it looks good and stable. But after only calling up
+> a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable.
+> 
+> Does anyone have any idea what is causing this? I assume Dillo is using a
+> threading system of some kind; could this be the problem?
+
+OK, I've been workink on that.
+It is NOT the threading system!
+Actually, what causes the problem is URL redirection. If you hit a
+redirected URL, the CPU will be hogged.
+
+> Before we get too deep in making it pretty, we need to improve the infrastructure.
+> The alternative is to end up with Netscape Communicator. :(
+
+Yes man, I agree.
+Have you figured out the whole mess that we had before this release?
+
+Well, technically talking I've been studying the problem and almost
+every problem comes from the IO engine change. It behaves asynchronously
+but, it was struggled-in without the minimal considerations about that
+kind of processing. I mean, several critical races were introduced and
+it was merged with the former (streamed) implementatiom. Frankly I'm not
+sure now if trying to fix it, or plainly rewriting it.
+
+The cache system integrates with the IO and it is also obscure :-(
+I still can't find a clear way of using it and handling close and abort
+requests the way it should be so, basically I'm studying the code now
+to try to find whether to heavily fix it or to change it.
+As a matter of fact, this would not be the first module rewrite in the
+project.
+
+If you suggest me an IRC channel now, 
+no problem to meet you there.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Announce
+
+From: <greslin@li...> - 2000-04-04 16:59
+
+On Tue, Apr 04, 2000 at 09:33:08AM -0400, Jorge Arellano Cid wrote:
+> 
+> Rob,
+> 
+> First of all, welcome aboard!
+> You were the first to answer the announce, and I already saw
+> you in the mailing list!
+> I know our server was down for a couple of hours (or more?),
+> but it is working now! Please let me know if you were able to
+> reach it.
+
+I'm getting it through Sourceforge. Do me a favor; could you go ahead and
+clear me as a developer? 
+
+
+> > I'm a C programmer, familiar with GTK and application development. I currently
+> > maintain GXAnim (GTK frontend to XAnim movie player) and am very slowly working
+> > on the Canvas Project, another video-related project. In my spare time I
+> > work with the Open File Sharing Initiative (napster-esque file transfer) and do
+> > quite a bit of work with the Openlaw DVD forum at Harvard Law.
+> 
+> Perfect, GUIs and some networking!
+> May a suggest you take a look at Dillo widget bugs?
+> We are very concerned of the small pages rendering bug.
+
+Right now I'm far more concerned about this runaway CPU usage. Dillo compiled
+great out of the box, and it looks good and stable. But after only calling up
+a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable.
+
+Does anyone have any idea what is causing this? I assume Dillo is using a
+threading system of some kind; could this be the problem?
+
+Before we get too deep in making it pretty, we need to improve the infrastructure.
+The alternative is to end up with Netscape Communicator. :(
+
+
+
+Rob Warren
+
+email: greslin@li...
+homepage: http://www.iag.net/~aleris
+
+GXAnim: http://www.iag.net/~aleris/gxanim.html
+The Canvas Project: canvas.linuxpower.org
+OpenLaw DVD FAQ: http://www.cssfaq.org 
+
+
+
+Re: [Dillo-dev]bug - incomplete rendering of html
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-04 13:42
+
+Sammy,
+
+On Mon, 3 Apr 2000, nightstalker wrote:
+
+> i have noticed something about this bug (reading small html files can
+> result in incomplete displays .. workaround is to hit reload :)
+
+Just sometimes. You may have to resize the window or go back
+and forward to fix the display.
+This is a Dillo-Widget bug.
+I think its due to initialization problems. If you look at it
+in detail, you'll notice that sometimes, a gray square renders on
+top of the page (try loading a small image for instance), and
+that its height is exactly the same of the whole set of toolbars.
+Some other times, small HTML pages "appear" with an upward
+shift...
+
+
+> i first ran dillo with the 'nstalkie' user who uses the Aqua gtk-theme.
+> the bug occured. Then i ran dillo with the 'progs' user who
+> uses the Cheese gtk-theme. The bug
+> also occured BUT in a different way. i had to press reload twice in
+> order to view the whole page.
+
+Yes, what we have here is not a single thread problem but an
+asynchronous race condition. That explains the variations. If you
+try it several times, with different CPU loads for instance, you
+may notice diferences with the same gtk-theme.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Re: tarball location, etc.
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-04 13:42
+
+James,
+
+On Mon, 3 Apr 2000, James McCollough wrote:
+
+> hey -
+> 
+> Sourceforge has webspace for us at dillo.so....net. Could you
+> send me all the files that make up the dillo website, so I can mirror
+> them on so....net?
+
+No. :-)
+
+Not every file. The problem is mainly with Dillo bug-track
+engine; it uses a database that's set in 'tonatiuh' server, and I
+want to keep it there (Is faster an easier to administrate).
+Well, there're several other pages that I can send you, just
+let me make absolute links for them.
+The other important fact is that if we have sourceforge
+mirroring the site, you (or someone else) has to do the sync.
+work...
+
+> I will also move the tarball there shortly. 
+
+By now, you already did it; I checked all the links.
+Thanks.
+(Don't erase download.so....net/dillo/dillo-0.1.0.tar.gz)
+
+> By the I really like the new release. 
+> It is very stable.
+
+Good!!!
+(Stabilization is one of our main concerns.)
+
+> I am also going to update the CVS shortly.
+
+Don't you hurry.
+I'm thinking of setting it locally in 'huallepen'.
+Why?
+Because so....net is a very slow link form here, the CVS
+doesn't generate a big network load, and I have an exclusive
+machine to put it on!
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Announce
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-04 13:42
+
+Rob,
+
+First of all, welcome aboard!
+You were the first to answer the announce, and I already saw
+you in the mailing list!
+I know our server was down for a couple of hours (or more?),
+but it is working now! Please let me know if you were able to
+reach it.
+
+> I just saw your announcement on gtk-app-devel. All I can say is, good. It's 
+> good to know that someone's picked up gzilla from the dustbin; I hate to think
+> that the only modern browsers we have for Linux are commercial ones.
+
+Well, our beloved Dillo is far away from challenging those big
+ones, but its speed and anti-bloat design are addictive!
+(We'll try to make it render the whole HTML 4.0 before thinking
+of extending it. And when I say "render HTML 4.0", I mean to have
+the info displayed in a suitable way.)
+
+> I'm a C programmer, familiar with GTK and application development. I currently
+> maintain GXAnim (GTK frontend to XAnim movie player) and am very slowly working
+> on the Canvas Project, another video-related project. In my spare time I
+> work with the Open File Sharing Initiative (napster-esque file transfer) and do
+> quite a bit of work with the Openlaw DVD forum at Harvard Law.
+
+Perfect, GUIs and some networking!
+May a suggest you take a look at Dillo widget bugs?
+We are very concerned of the small pages rendering bug.
+
+> Anyway, I don't know how much time I'll be able to devote here, but I'll put
+> my two bits in where I can and throw a piece of code out every so often. Do
+> you guys have a CVS of your current source? (I assume so.. you're on
+> Sourceforge, right?)
+
+Actually we have, but I'll try to set it up on another server,
+not sourceforge (We are half sourceforgers)
+When the CVS is set, I'll let you all know. It will work only
+as a checkout in the beginning...
+
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]problem with urls.
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-04 13:42
+
+Sammy,
+
+
+On Sun, 2 Apr 2000, nightstalker wrote:
+
+> hi,
+> 
+> this is a minor thingie ...
+> when you enter an url like this:
+> http://www.skoardy.demon.co.uk/rlnews
+> dillo must put a '/' behind this .. i have already found the place in
+> the code
+> where it should happen, but i was thinking :
+
+Actually that happens!
+Look at the VT screen behind Dillo (Nav_open_url) and you'll
+see the URL change.
+
+> how can you know this is a directory ? 
+
+There's no way, that I know, to know that in advance.
+If you have " 'hi' can be either a file or a
+directory.
+
+> i'm thinking of this :
+> i can add a test to see if there are any '.' or '?' in the tail (in this
+> example /rlnews) (the ? is for queries which can be without
+> a dot but may not get a trailing '/' for example :
+> http://www.altavista.com/cgi-bin/query?pg=q&sc=on&hl=on&q=dillo&kl=XX&stype=stext
+
+Sure, there're those URLs too.
+I think that a good guess can be done using the last filename:
+If it has a '.', most probably it's a dir!
+You have to check it for POST or GET or whatever before making
+the gess though.
+The sure way to proceed is to check the RFC.
+
+> is it possible for a http address to have a '.' in the directory name ?
+
+Yes.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Announce
+
+From: <greslin@li...> - 2000-04-03 21:44
+
+On Mon, Apr 03, 2000 at 04:56:52PM -0400, Jorge Arellano Cid wrote:
+> 
+> Ok, I made the announcement to gtk app devel list,
+> Does anyone feel like announcing it to sourceforge news? James? Luca?
+> 
+> Ah, also updated the website.
+> 
+> Jorge.-
+
+Hey ho.
+
+I just saw your announcement on gtk-app-devel. All I can say is, good. It's
+good to know that someone's picked up gzilla from the dustbin; I hate to think
+that the only modern browsers we have for Linux are commercial ones.
+
+I'm a C programmer, familiar with GTK and application development. I currently
+maintain GXAnim (GTK frontend to XAnim movie player) and am very slowly working
+on the Canvas Project, another video-related project. In my spare time I
+work with the Open File Sharing Initiative (napster-esque file transfer) and do
+quite a bit of work with the Openlaw DVD forum at Harvard Law.
+
+Anyway, I don't know how much time I'll be able to devote here, but I'll put
+my two bits in where I can and throw a piece of code out every so often. Do
+you guys have a CVS of your current source? (I assume so.. you're on
+Sourceforge, right?)
+
+
+Rob Warren
+
+email: greslin@li...
+homepage: http://www.iag.net/~aleris
+
+GXAnim: http://www.iag.net/~aleris/gxanim.html
+The Canvas Project: canvas.linuxpower.org
+OpenLaw DVD FAQ: http://www.cssfaq.org 
+
+
+
+[Dillo-dev]Announce
+
+From: Jorge Arellano Cid <jcid@hu...> - 2000-04-03 21:18
+
+Ok, I made the announcement to gtk app devel list,
+Does anyone feel like announcing it to sourceforge news? James? Luca?
+
+Ah, also updated the website.
+
+Jorge.-
+
+
+--------------------
+gtk announce follows
+--------------------
+Hi there,
+
+I only hope this to be the right place for this announcement; please
+don't suggest freshmeat cause Dillo is still alpha code.
+
+Dillo is a gtk+based web browser that's very fast, lean and extensible.
+It has its own HTML parsing routines, is written completely in C and the
+tarball is just 200Kb! (The stripped binary is also 200Kb).
+There's no support for Java, javascript.
+
+We are in need of developers; those of you who feel interested in
+this project, or just wnat more info, take a look at
+
+http://academico.inf.utfsm.cl:81/~jcid/Dillo/project.html
+
+you'll find everything there.
+
+
+Jorge.-
+Dillo project maintainer
+
+
+Ps: Dillo is GPLed! 
+
+
+
+Re: [Dillo-dev]Developer release
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-04-03 13:21
+
+Hi,
+
+On Sun, 2 Apr 2000, nightstalker wrote:
+
+> Jorge Arellano Cid wrote:
+> 
+> > Hi everyone!
+> >
+> > Today dillo-0.1.0.tar.gz is ready for download. It will be our
+> > first public developer release!
+> >
+> 
+> cool !
+> 
+> >
+> > When James finish setting it to on the sourceforge ftp server,
+> > I'll add a download link to the home page, announce it to the gtk
+> > devel mailing list, and it will be public!
+> >
+> 
+> we can also announce it on freshmeat (freshmeat.net)
+
+Yes, we can, but later...
+Why?
+
+1.- Because I need to address server traffic concerns.
+Currently the source is in the academico server and also at
+ftp://ftp.so....net/pub/sourceforge/dillo/dillo-0.1.0.tar.gz 
+The first one is not able to handle a big load, as what could
+be generated by a freshmeat announce, and the second one is very
+slow and unreliable. This week I'll set up a new server, and
+maybe put the source on a ftp port with a maximum concurrent
+connection limit. 
+The best setting (IMHO) is to have dillo source at:
+http://dillo.so....net/dillo-0.1.0.tar.gz
+and everything else in the new server.
+
+2.- Because we need more developers, and the gtk mailing list
+is a better place to find gtk skilled guys. The freshmeat list
+has a broader range, and our release is not ready for users yet.
+(Anyway, if the gtk-mailing-list announce fails to bring new
+devels. to the project, a freshmeat one will follow quickly!)
+
+
+Jorge.-
+
+
+Ps: James, would you mind setting the
+http://dillo.so....net/dillo-0.1.0.tar.gz URL? 
+
+
+
+[Dillo-dev]bug - incomplete rendering of html
+
+From: nightstalker <nstalkie@tv...> - 2000-04-03 00:02
+
+i have noticed something about this bug (reading small html files can
+result
+in incomplete displays .. workaround is to hit reload :)
+
+i first ran dillo with the 'nstalkie' user who uses the Aqua gtk-theme.
+the bug
+occured.
+then i ran dillo with the 'progs' user who uses the Cheese gtk-theme.
+the bug
+also occured BUT in a different way. i had to press reload twice in
+order to
+view the whole page.
+
+this bug is getting weirder and weirder :)
+
+ns 
+
+
+
+[Dillo-dev]problem with urls.
+
+From: nightstalker <nstalkie@tv...> - 2000-04-02 23:15
+
+hi,
+
+this is a minor thingie ...
+when you enter an url like this:
+http://www.skoardy.demon.co.uk/rlnews
+dillo must put a '/' behind this .. i have already found the place in
+the code
+where it should happen, but i was thinking :
+
+how can you know this is a directory ? i'm thinking of this :
+i can add a test to see if there are any '.' or '?' in the tail (in this
+example
+/rlnews) (the ? is for queries which can be without a dot but may not
+get a
+trailing '/' for example :
+http://www.altavista.com/cgi-bin/query?pg=q&sc=on&hl=on&q=dillo&kl=XX&stype=stext
+
+is it possible for a http address to have a '.' in the directory name ?
+
+ns.
+
+ps: yes i'm a roguelike fan :) 
+
+
+
+Re: [Dillo-dev]Developer release
+
+From: nightstalker <nstalkie@tv...> - 2000-04-02 21:58
+
+Jorge Arellano Cid wrote:
+
+> Hi everyone!
+>
+> Today dillo-0.1.0.tar.gz is ready for download. It will be our
+> first public developer release!
+>
+
+cool !
+
+>
+> When James finish setting it to on the sourceforge ftp server,
+> I'll add a download link to the home page, announce it to the gtk
+> devel mailing list, and it will be public!
+>
+
+we can also announce it on freshmeat (freshmeat.net)
+
+>
+> Comments are welcomed.
+>
+> Jorge.-
+>
+> Pd: Haven't got any feedback on the former release yet :-|
+>
+
+i haven't really tried the newest release yet .. (i'll try 0.1.0)
+all i saw was that it was good :)
+
+ns. 
+
+
diff --git a/old/oldmail/200005.txt b/old/oldmail/200005.txt
new file mode 100644
index 0000000..a2076f2
--- /dev/null
+++ b/old/oldmail/200005.txt
@@ -0,0 +1,388 @@
+Re: [Dillo-dev]Bug 35... fixed! (I hope)
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-05-29 01:48
+
+Andrew,
+
+On Thu, 25 May 2000 andrew@ma... wrote:
+
+> I think I finally nailed that nasty bug 35. From extensive g_prints, I
+> discovered what was going on:
+> 
+> ...
+> 
+> Sorry, that wasn't very clear. I hope you can sort of follow what I'm
+> saying.
+
+Thank you very much for the explanation. Although I haven't got
+the time (yet) to analyze it in full detail, it is and will be of
+great help.
+
+When dealing with the new cache scheme (and formerly with the
+dicache and the image resize), I faced similar problems. It seems
+that a state machine is a good way to solve that nasty race
+conditions, but I prefer a flag scheme, just because it is more
+flexible and easier to implement. Maybe that'd become the final
+fix of it...
+
+> Hope the change works out.
+
+I've been stress testing the patch, it works nearly 95% of the
+time, not perfect, but definitively better than what we had.
+It *earned* its way into the code!
+
+Once again, thank you very much.
+
+
+Jorge.-
+
+
+Ps: Expect dillo-0.2.0 release near friday. 
+
+
+
+[Dillo-dev]Bug 35... fixed! (I hope)
+
+From: <andrew@ma...> - 2000-05-25 23:02
+
+Attachments: Message as HTML      
+
+I think I finally nailed that nasty bug 35. From extensive g_prints, I
+discovered what was going on:
+
+1) Dillo makes a new browser, and a GtkDwView structure some time later.
+This starts out with a visible region of (0,0) to (101,101) for its
+container.
+2) Shortly thereafter, dw_gtk_view_size_allocate is called to make the
+viewport the correct size. However, the container's visible region only
+gets updated if the widget is realized, which it is not (yet).
+3) Meanwhile, the first paint requests have been called, and dillo begins
+to start the drawing functions. All rectangles get clipped to the
+"visible" region of (0,0)-(101,101).
+4) Finally (a fraction of a second later), the window shows up and the
+viewport is realized. But it's too late. The drawing is done on the old
+visible rectangle.
+5) Right _after_ this happens, dw_gtk_view_size_allocate is called again,
+with a realized widget. The visible rectangle of the viewport's container
+is properly adjusted, and things work from here on out.
+
+Sorry, that wasn't very clear. I hope you can sort of follow what I'm
+saying.
+
+Anyway, the fix I came up with involves changing the code in
+Dw_gtk_view_size_allocate so that dw_view->dw_container->visible is
+updated regardless of whether the widget is realized or not. I don't think
+this should create any problem as there is already a check in place to
+make sure the widget isn't null. The diff is attached.
+
+The only other way around this that I saw was to change the structure of
+dillo so that the drawing functions only got called after the window was
+visible, but this might have taken a total rewrite of many of the
+functions.
+
+Hope the change works out.
+
+-Andrew 
+
+
+
+Re: [Dillo-dev]Very close to a new release
+
+From: <andrew@ma...> - 2000-05-24 23:03
+
+On Wed, 24 May 2000, Jorge Arellano Cid wrote:
+
+> 
+> Andrew: 
+> 
+> It would be very nice to integrate a fix for bug #35 in the new
+> release; Any progress with that?
+> 
+
+Well, progress but no fix. My time just sort of disappeared. (I joined the
+project during a time of low activity in my other projects, which
+subsequently picked up again. Figures.)
+
+Anyway, I'll look back at it. I think it could be as simple as setting the
+visible rectangle of the viewport to be the size of the window rather than
+the default 101x101. I just haven't nailed down the best way to do that.
+
+There will be a fix, but it might come after the initial release.
+
+-Andrew 
+
+
+
+[Dillo-dev]Very close to a new release
+
+From: Jorge Arellano Cid <jcid@hu...> - 2000-05-24 21:50
+
+Hi!
+
+The traffic here has been very low, but Dillo survived a major
+architecture change; the new release will be a half-new browser!
+
+In fact, all the IO engine and http stuff was rewritten from 
+scratch, and even the way data is passed to rendering routines 
+changed.
+Mainly this means that the cache integrates with the IO engine
+and that the rest of the browser deals with the cache part only
+(it works as an abstraction layer).
+
+Although the system remains very complex, it is much easier to
+understand, extend and change.
+
+THIS IS NOT VAPORWARE!!!
+It is running NOW!
+
+I'm just polishing raw edges to follow the "evolving" model we 
+use, and accordingly, to release a better browser.
+Primary tests had gone very well. (Except for a problem with 
+redhat and its socket handling --Don't worry, its OK now).
+
+
+
+Andrew: 
+
+It would be very nice to integrate a fix for bug #35 in the new
+release; Any progress with that?
+
+
+Mark:
+
+Please get a user account on sourceforge, and send me your login 
+(UID) to allow you workout the web site.
+
+
+James:
+
+Are you getting this message?
+You're email address seems not to be working...
+
+
+Everyone:
+
+Any feedback is welcome.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug 35 progess
+
+From: <andrew@ma...> - 2000-05-10 14:25
+
+On Tue, 9 May 2000, Jorge Arellano Cid wrote:
+
+> 
+> Andrew,
+> 
+> On Fri, 21 Sep 1956 andrew@ma... wrote:
+> Note the date!!!
+> I know I'm a little late answering this one! ;-)
+
+Sorry, that should be fixed now...
+
+> > I turned on verbose messaging and added a lot of g_print's of my own so I
+> > could get a feel for what's going on. First of all, on my Intel box
+> > running GTK+ 1.2.3, I noticed that creating the window never calls
+> > size_allocate, but it does show all the widgets, so the first time around,
+> > the sizes are things like (0,0) to (10, 65533), negative numbers, and
+> > other crazy stuff. This doesn't happen on GTK+ 1.2.6 on PowerPC. This is
+> > undoubtedly a GTK flaw, not a Dillo one, and I think it's unrelated to the
+> > problem.
+> 
+> Good! 
+> That's the kind of work we need.
+> 
+> > ... I think the fundamental problem is in
+> > dw_gtk_view.c in the a_Dw_gtk_view_new function. It sets the visible
+> > rectangle as (0,0)-(101,101) with a "todo"comment to make it reflect the
+> > widget size. (101,101) is coincidentally where the drawing gets cut off on
+> > the Power Mac.
+> > 
+> > When I hit reload, it gets updated, and I haven't traced the code to
+> > figure out where or how that happens.
+> 
+> Well, not having documentation about Dillo widget is one of our
+> problems. I'd very much like to have that written; but priorities
+> had kept me away from that...
+> 
+> > I figure that the best fix is to make the visible rectangle update right
+> > away (I don't know how I'll do that yet). Or is that just covering the
+> > symptoms without fixing the problem?
+> 
+> Sorry, but I can't tell you if that's THE right fix. Probably
+> what needs to be done is to find out how the update is triggered
+> (and carried out) after hitting the reload button. And noting why
+> sometimes a page renders and some others not; due to a race
+> condition on a gtk idle function? Bad init values?
+> ... and after that, to decide if that's the right patch.
+> 
+> Anyway, if it fixes the problem, we can make it into our code
+> with a "todo: assert this is the right way to do this" tag on it
+> :)
+> 
+> Any new or progress notice is welcomed
+
+I'll see what I can do. Maybe I'll post some sort of log here if I get
+stuck again. Right now I'm just fighting lack of time.
+
+I think the reason that sometimes it gets rendered and sometimes not has
+to do with the rect that gets sent to the draw function-- it gets clipped
+to the supposed "visible" region of the dillo widget, which, at least the
+first time, isn't correct.
+
+-Andrew 
+
+
+
+Re: [Dillo-dev]Bug 35 progess
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-05-10 03:15
+
+Andrew,
+
+On Fri, 21 Sep 1956 andrew@ma... wrote:
+Note the date!!!
+I know I'm a little late answering this one! ;-)
+
+
+> I turned on verbose messaging and added a lot of g_print's of my own so I
+> could get a feel for what's going on. First of all, on my Intel box
+> running GTK+ 1.2.3, I noticed that creating the window never calls
+> size_allocate, but it does show all the widgets, so the first time around,
+> the sizes are things like (0,0) to (10, 65533), negative numbers, and
+> other crazy stuff. This doesn't happen on GTK+ 1.2.6 on PowerPC. This is
+> undoubtedly a GTK flaw, not a Dillo one, and I think it's unrelated to the
+> problem.
+
+Good! 
+That's the kind of work we need.
+
+> ... I think the fundamental problem is in
+> dw_gtk_view.c in the a_Dw_gtk_view_new function. It sets the visible
+> rectangle as (0,0)-(101,101) with a "todo"comment to make it reflect the
+> widget size. (101,101) is coincidentally where the drawing gets cut off on
+> the Power Mac.
+> 
+> When I hit reload, it gets updated, and I haven't traced the code to
+> figure out where or how that happens.
+
+Well, not having documentation about Dillo widget is one of our
+problems. I'd very much like to have that written; but priorities
+had kept me away from that...
+
+> I figure that the best fix is to make the visible rectangle update right
+> away (I don't know how I'll do that yet). Or is that just covering the
+> symptoms without fixing the problem?
+
+Sorry, but I can't tell you if that's THE right fix. Probably
+what needs to be done is to find out how the update is triggered
+(and carried out) after hitting the reload button. And noting why
+sometimes a page renders and some others not; due to a race
+condition on a gtk idle function? Bad init values?
+... and after that, to decide if that's the right patch.
+
+Anyway, if it fixes the problem, we can make it into our code
+with a "todo: assert this is the right way to do this" tag on it
+:)
+
+Any new or progress notice is welcomed
+Good luck!
+Jorge.- 
+
+
+
+Re: [Dillo-dev]I need help :(
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-05-06 02:04
+
+Hi,
+
+On Wed, 3 May 2000, Luca Rota wrote:
+
+> I've some problem so I can't work on dillo awhile. 
+> I've the patch for a not yet working preferences gui, so if someone woulds work
+> on it, please let me know.
+
+I would like the preferences stuff to be worked out as a
+plugin. I mean something like "dillo:/preferences". It would be
+easier to maintain and that way we keep the core small.
+As a matter of fact, the bookmarks can also be implemented that
+way.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Bug 35 progess
+
+From: <andrew@ma...> - 2000-05-05 18:23
+
+OK, I'm busy trying to track down the source of bug 35 (screen not drawing
+properly the first time), and I've found some interesting things in the
+process.
+
+I turned on verbose messaging and added a lot of g_print's of my own so I
+could get a feel for what's going on. First of all, on my Intel box
+running GTK+ 1.2.3, I noticed that creating the window never calls
+size_allocate, but it does show all the widgets, so the first time around,
+the sizes are things like (0,0) to (10, 65533), negative numbers, and
+other crazy stuff. This doesn't happen on GTK+ 1.2.6 on PowerPC. This is
+undoubtedly a GTK flaw, not a Dillo one, and I think it's unrelated to the
+problem.
+
+On my Intel box, the page draws correctly except for the hr tags. I
+haven't figured that out yet. On the Power Mac, it only draws a part of
+the screen until I hit reload. I think the fundamental problem is in
+dw_gtk_view.c in the a_Dw_gtk_view_new function. It sets the visible
+rectangle as (0,0)-(101,101) with a "todo"comment to make it reflect the
+widget size. (101,101) is coincidentally where the drawing gets cut off on
+the Power Mac.
+
+When I hit reload, it gets updated, and I haven't traced the code to
+figure out where or how that happens.
+
+I figure that the best fix is to make the visible rectangle update right
+away (I don't know how I'll do that yet). Or is that just covering the
+symptoms without fixing the problem?
+
+-Andrew 
+
+
+
+[Dillo-dev]I need help :(
+
+From: Luca Rota <drake@fr...> - 2000-05-03 13:35
+
+Hi,
+
+I've some problem so I can't work on dillo awhile. 
+I've the patch for a not yet working preferences gui, so if someone woulds work
+on it, please let me know.
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]ematic mail
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-05-02 02:03
+
+Hi there!
+
+I received mail from Mark, Andrew, and some time ago from James
+in my ematic.com address. In fact I receive Ok from several other
+places, and will assume it works right unless someone here tells
+me it failed.
+
+Thanks
+Jorge.-
+
+
+Ps: Send failure notices to jcid@em... 
+
+
diff --git a/old/oldmail/200006.txt b/old/oldmail/200006.txt
new file mode 100644
index 0000000..1ab1ebf
--- /dev/null
+++ b/old/oldmail/200006.txt
@@ -0,0 +1,309 @@
+[Dillo-dev]progress
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-06-28 17:45
+
+Hi there!
+
+We are getting closer to a new release due to several changes
+in the code. Current Changelog looks like this:
+
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
+dillo-0.2.2 [July ?, 2000]
+
+- * Added a gtk_window_set_wmclass to all windows to prevent dialogs
+from having the same size as the main window. (Ex: with Sawfish)
+Patch Jörgen Viksell <vsksga@ho...>
+- * Fixed a segfault when calling "about:" method
+Patch: Dominic Wong <lwong@ch...>
+- * Added an option to force dillorc-defined colors (Try it with slashdot!)
+* Fixed display of encoded-URL-links on the status bar
+Patches: Adam Sampson <azz@gn...>
+- * Removed several compiler dependencies
+(detected with lcc on a 64 bit machine)
+* Modified mime.c and Url.c to use list.h, and eliminated hdlr.c
+* Standarized unsigned types to glib all around the code
+* Added some includes for libc5 compatibility
+* Modified IO_callback to avoid a CPU-hog (it happened in some systems).
+* Fixed a bug that added a trailing ampersand to GET and POST queries.
+* FIxed attribute parsing. It had nasty side effects; as providing
+wrong attribute values to POST and GET methods.
+* Joined Url.c and url.c into a single module.
+* Reimplemented URL resolving functions.
+* Implemented a new parser for "file:" URLs (Try "file:" & "file:.").
+Patches: Jorge Arellano Cid <jcid@ma...>
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
+
+
+If you read it carefully, you'll notice several improvements,
+most notably:
+
+- POST & GET work better (google search is working!).
+- "file:" URLs got better handled.
+- slashdot is readable.
+- The code got more "portable" and stable.
+
+
+I'd like to include Jörgen patches too (if they get finished):
+
+> I have been working on getting checkbuttons and radiobuttons to render
+> properly, and it works now. Strangely enough it works when you call
+> gtk_toggle_button_set_mode(GTK_TOGGLE_BUTTON(widget), FALSE), even though
+> this is supposed to be set by default...
+
+Maybe due to a lack of a window for the button widget.
+This happened with the horizontal ruler, and the first attempt
+to fix it, by packing it into an event box, worked OK.
+I'm not sure though, just a thing to check.
+
+> What bugs me now is that radio buttons appears as squares instead of
+> diamond-shaped.
+> I also worked on the SELECT stuff (width and height of the clist widget)
+> which now seems to work.
+
+If you finish them please let me know.
+
+
+- o -
+
+Dominic asks:
+
+> I have some questions about dillo. I find one dillo task in the task list
+> when open nothing. But if I open a web page, one more dillo appear in my task
+> list. Thus, two dillo in the task list. With top, I find both of them
+> consume the same memory size. Could you tell me why? Since netscape becomes 4
+> when a web page is opened, and I wonder why it happened.
+
+Well, that's due to threaded code (pthreads).
+When dillo starts, there's just a single thread running (the
+main thread). When another thread is spawned for the first time,
+(due to a DNS, or local file request), TWO more threads get
+running, one for the thread scheduler and other for the spawned
+process. When the spawned one finishes, the thread manager
+remains; if you 'ps aux | grep dillo', you'll see two processes
+that consume the same memory size but THAT'S NOT TRUE!!!
+Pthreads are light weight processes that run using the same
+memory space as the father (one of the advantages over fork).
+
+
+- o -
+
+CscHTML:
+
+Certainly to be taken into account.
+When I first downloaded it, found almost no documentation for
+it, appart from 350Kb of code and library dependencies.
+
+Haven't tested the speed yet.
+
+The biggest concern is the cost of making the widget change,
+and the loose of control over the rendering. Currently we have a
+widget set that needs moderate work to start handling tables (and
+that's lean, fast and already integrated to our browser).
+
+I think if we manage to provide a basic TABLE facility with Dw,
+developers will start to work together improving it. The
+advantage of having small, documented code is a nicer learning
+curve that lets developers jump-in quickly.
+BTW our main documentation fault is on Dw (dillo widget); any
+contribution will be highly appreciated. :-)
+
+On the other hand, if we fail to improve Dw, the change is
+almost forced (if possible).
+
+This remains an open issue.
+
+
+Jorge.-
+
+Ps: Thanks for reading this far.
+Ps2: Jörgen, I'll send you an email to your hotmail address, at
+the same time I send this one to the list, please let me
+know if you receive it (I've had problems with hotmail.com). 
+
+
+
+[Dillo-dev]CSCHTML widget
+
+From: <bigdaddy@ll...> - 2000-06-26 18:00
+
+Check this out
+http://www.cscmail.net/cschtml/
+
+this appears to be a GTK widget with _all_ html tags. I haven't done
+extensive research into this, but this could be huge. It may be worth
+while to look into this.
+
+-Mark
+
+"You can't get a blue screen on a black and white monitor." 
+
+
+
+[Dillo-dev]form fixes
+
+From: Jörgen Viksell <vsksga@ho...> - 2000-06-25 18:11
+
+Hi!
+
+I have been working on getting checkbuttons and radiobuttons to render 
+properly, and it works now. Strangely enough it works when you call
+gtk_toggle_button_set_mode(GTK_TOGGLE_BUTTON(widget), FALSE), even though 
+this is supposed to be set by default...
+What bugs me now is that radio buttons appears as squares instead of 
+diamond-shaped.
+
+I also worked on the SELECT stuff (width and height of the clist widget) 
+which now seems to work.
+
+The patch can be found here:
+http://hem.passagen.se/vsksga/patches/patch-0.2.1-form_fixes
+
+I would appreciate if someone could try it out. And maybe fix the bugs =)
+
+// Jörgen
+________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com 
+
+
+
+[Dillo-dev]ematic.com
+
+From: Jorge Arellano Cid <jcid@hu...> - 2000-06-21 02:37
+
+Hi everyone!
+
+
+First, I want to welcome every new member of this list. 
+
+I'm eager to "hear" your impressions and comments on dillo but
+it seems that the ematic server went down the hard way, and I
+haven't received mail since early Jun 18. So please, if you had
+sent me mail, please resend it to jcid@ma....
+
+We have new patches! I've also found a couple of bugs that
+will be nailed down pretty soon.
+
+
+regards
+Jorge.-
+
+
+
+-- 
+
+
+
+[Dillo-dev]dillo-0.2.1
+
+From: Jorge Arellano Cid <jcid@me...> - 2000-06-17 18:09
+
+Hi there!
+
+A lot of water went down the bridge! 
+Just check our new release (and website) at:
+http://dillo.so....net/
+
+(You'll find all the info there)
+
+Jorge.-
+-- 
+
+
+
+Re: [Dillo-dev]New release
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-06-07 14:21
+
+Andrew:
+
+> The new release seems to work well. Thanks!
+
+Good!
+It was tested on Slackware 7.0, Slackware 3.6 libc5 (with a few
+changes), Redhat 6.2 and Suse.
+
+It behaves very stable here and I hope it works the same for
+everyone.
+
+> Is it just me or has bug 9 disappeared? (The one with mishandled # tags).
+> I browsed around a page with them in it and I never saw page.html#a#b or
+> anything like that. 
+
+No, the bug IS there; it just hides! :)
+
+If you browse a page that has a # anchor to another page,
+there's no problem, but if the # refers to the same page -> BUG.
+
+Test this one: http://dillo.inf.utfsm.cl/test/spg.htm
+
+> And, for that matter, how many of those other bugs have been fixed in
+> Dillo 0.2.0 without the database being updated?
+
+Not a single one. The database reflects current state.
+
+I left bug #35 there cause the BUG remains there; mitigated but
+still alive...
+
+
+> Thanks,
+
+You're welcome.
+
+
+Jorge.-
+
+
+Pd: Updated "--" to "McPherson" 
+
+
+
+Re: [Dillo-dev]New release
+
+From: Andrew McPherson <andrew@ma...> - 2000-06-07 00:19
+
+The new release seems to work well. Thanks!
+
+Is it just me or has bug 9 disappeared? (The one with mishandled # tags).
+I browsed around a page with them in it and I never saw page.html#a#b or
+anything like that. Did somebody fix that without updating the bug-track
+engine?
+
+And, for that matter, how many of those other bugs have been fixed in
+Dillo 0.2.0 without the database being updated?
+
+Thanks,
+
+-Andrew 
+
+
+
+[Dillo-dev]New release
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-06-03 03:16
+
+Hi!
+
+Its been a long long time since the last release (two months)
+and I want to apologize for this. Although work had been hectic
+on my side, I couldn't make it in less time...
+
+Well, an evolving model, and always releasing a better browser
+are good rules to follow.
+
+The good news is that we have a HALF-NEW browser!!!
+(Check the Changelog.who for details)
+
+I hope you enjoy this version.
+Feedback is encouraged.-
+
+
+Jorge.-
+
+
+Pd : I'll update the web site ASAP (maybe on Monday).
+
+Pd2: Luca:
+I didn't include your justification patch in this version
+cause it broke the rendering of some pages. 
+
+
diff --git a/old/oldmail/200007.txt b/old/oldmail/200007.txt
new file mode 100644
index 0000000..6d74355
--- /dev/null
+++ b/old/oldmail/200007.txt
@@ -0,0 +1,1378 @@
+Re: [Dillo-dev]Bug #4, #62, #63
+
+From: Seth de l'Isle <szoth@ub...> - 2000-07-31 20:08
+
+On Mon, Jul 31, 2000 at 11:47:36PM +0900, Eric GAUDET wrote:
+> Le 29-Jul-2000, on m'a dit : 
+
+> 
+> > Bug #63 (Segfault when you click enter in location field): I can't reproduce
+> > it.
+
+I found that bug running on an older slack install, when I tried to reproduce
+it on a newer mandrake install everything seemed fine.
+
+> > 
+> 
+> Me neither
+
+
+
+-- -- -- -- -- -- -- -- -- -- -- --. 
+,_ /) (\ _, Seth de l'Isle, President |
+>> <<,_,>> << Arctic Fox Technology Inc. |
+// _0.-.0_ \\ PO Box 70468 |
+\'._/ \_.'/ Fairbanks, AK 99707 |
+'-.\.--.--./.-' (907) 452-1199 |
+__/ : :Y: : \ _ http://www.ubertechnique.com |
+';, .-(_| : : | : : |_)-. ,:' -- -- -- -- -- -- -- -- --' 
+\\/.' |: : :|: : :| `.\//
+(/ |: : :|: : :| \)
+|: : :|: : :;
+/\ : : | : : /\
+(_/'.: :.: :.'\_)
+\\ `""`""` //
+jgs \\ //
+':. .:' 
+
+
+
+RE: [Dillo-dev]Bug #4, #62, #63
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-31 14:48
+
+Le 29-Jul-2000, on m'a dit : 
+> Hello World!
+> 
+> I've some questions on bug in subject!
+> 
+> Bug #4 (images as white square): I can reproduce it only with PNG. Gif and
+> jpeg works just fine. Maybe a png specific problem ?!?
+> 
+
+I noticed that too. I've been investigating dillo's source, and what I can tell
+so far is it seems to be a libpng bug : in png.c, function Png_datarow_callback
+calls the libpng function :
+png_progressive_combine_row(png_ptr, png->row_pointers[row_num], new_row);
+The 3 *same* parameters, can either build a (buggy) white row or the correct
+image row.
+I can't see anything wrong with png_ptr, which is pretty much always handled by
+libpng functions.
+I noticed the bug is much more frequent when there is several images : I wonder
+if my libpng is compiled reentrant.
+I'm using libpng-1.0.8-1mdk.rpm
+Does anybody have a system where this bug never occurs ? If so, please tell us
+your libpng version.
+
+> Bug #63 (Segfault when you click enter in location field): I can't reproduce
+> it.
+> 
+
+Me neither
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 31-Jul-2000 a 21:59:21
+---------------------------------- 
+
+
+
+[Dillo-dev]Bug #4, #62, #63
+
+From: Luca Rota <drake@it...> - 2000-07-31 09:39
+
+Hello World!
+
+I've some questions on bug in subject!
+
+Bug #4 (images as white square): I can reproduce it only with PNG. Gif and
+jpeg works just fine. Maybe a png specific problem ?!?
+
+Bug #62 (<hr> tag's width problem): Dw_hruler_size_nego_y() (file dw_hrule.c)
+is commented. But that code seem ok! It works! Why is commented?
+
+Bug #63 (Segfault when you click enter in location field): I can't reproduce it.
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]Html test suite
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-30 16:34
+
+I've done some pages to begin with : basic html structure, colors. I'm
+currently finishing the characters page. 
+But I'm not sure what's urgent to do next.
+
+What html specs do you want me to build test pages for (high and medium
+priority) ? Do you want first (only ?) well-formated documents, or do you need
+faulty documents too (missing, misplaced or incorrect tags)
+
+Here is a list topics we can test :
+- basic html structure
+- characters
+- Text rendering (style, colour, fonts)
+- Text formating (paragraphs)
+- Images
+- language (encoding, direction, AFAIK gtk+ can't print 16bits chars)
+- lists
+- links 
+- forms
+- tables
+- frames
+- objets
+- style sheets
+
+Eric
+
+PS: Do we aim for html 3 or html 4 compliance ?
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 31-Jul-2000 a 01:09:08
+---------------------------------- 
+
+
+
+RE: [Dillo-dev]Re: Eric
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-29 00:47
+
+Eric,
+
+> Jorge,
+> I tryied 3 different email addresses yo mail you, all rejected. Where can I
+> send you the screenshots ?
+
+I got your emails. As a matter of fact, you can browse the
+screenshots in our site ;-)
+
+Thanks a lot Eric
+Jorge.-
+
+
+Ps: I've got some unanswered emails still... I've been very busy,
+but that's good! 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-29 00:47
+
+Sebastian,
+
+> > Jorge Arellano Cid wrote:
+> > > [...]
+> > > Ah, let me know if you'd prefer to continue working the patch
+> > > after next release (having the docs and new code), or to try to
+> > > push it into dillo 0.2.3.
+> > 
+> > Docs is currently not the matter (unless I would find out a much more
+> > elegant solution after I've better understood the code ;-), but there is
+> > still a bit to do, so it depends on when you are planning to release
+> > version 0.2.3.
+> 
+> Perhaps, it *is* a matter. I have unterstood Dw not well, but mostly
+> well enough for my problem. But there are some other problems.
+
+I think it's a matter cause it doesn't work as expected. Some
+parts are missing, some other are incomplete, and some have
+workaround tweaks.
+For instance, when Jörgen fixed the checkboxes, his code was
+right, but it didn't work because button widgets were not
+receiving the expose events.
+
+If the "scroller" and "view" code was right, maybe I'd suggest
+you to try a patch based on "changed" and "value changed"
+signals, but that code is a mess!
+
+> A current problem is: When do the pixel positions of anchors definitely
+> have their correct values?
+
+When all the previous images sizes are known. This is not
+deterministic, and heavily depends on network traffic. Even more,
+if we add more resizing widgets, those should be accounted too.
+
+> They sometimes must be corrected (e. g.
+> because the size of an image was unknown before),
+
+Yes.
+
+> so the scrolling
+> position sometimes changes in my timeout function, which does therefor
+> not stop after this was successful (otherwise you have often wrong
+> scroller positions), but first when a flag in DwScroller is set.
+> 
+> Where should this flag be set? I only tried Html_close, and I get
+> *allways* the correct scroller position (although I did not expect
+> that), but often the timeout function continues. (Even when not the
+> two cases are given: 1. no HTML, 2. the transmission was canceled.)
+
+I see several things here:
+
+- The timeout function should not override user scrolling
+(i.e. if the user scrolls the page with the mouse).
+- Html_close can't be trusted to happen.
+- Image reception can't be trusted.
+- It would be nice to have a #anchor display function that
+doesn't get fooled with page resizes (as we're trying).
+
+Maybe, if the timeout function validates itself, the problem can
+be addressed in a simpler way. I mean, let the timeout function
+start, poll until it finds the #anchor, then set its AnchorFound
+flag and to continue correcting the value until:
+
+- #anchor is not found anymore or
+- user scrolls the page (either with keyboard or with mouse)
+
+When one of those happens, it removes itself.
+
+I know this is not perfect, but you'll find a way! ;)
+
+
+Jorge.-
+
+Ps: It took some time to build this hint. I hope it helps! 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-07-28 13:27
+
+I wrote:
+> [...] 
+> Jorge Arellano Cid wrote:
+> > [...]
+> > Ah, let me know if you'd prefer to continue working the patch
+> > after next release (having the docs and new code), or to try to
+> > push it into dillo 0.2.3.
+> 
+> Docs is currently not the matter (unless I would find out a much more
+> elegant solution after I've better understood the code ;-), but there is
+> still a bit to do, so it depends on when you are planning to release
+> version 0.2.3.
+
+Perhaps, it *is* a matter. I have unterstood Dw not well, but mostly
+well enough for my problem. But there are some other problems.
+
+A current problem is: When do the pixel positions of anchors definitely
+have their correct values? They sometimes must be corrected (e. g.
+because the size of an image was unknown before), so the scrolling
+position sometimes changes in my timeout function, which does therefor
+not stop after this was successful (otherwise you have often wrong
+scroller positions), but first when a flag in DwScroller is set.
+
+Where should this flag be set? I only tried Html_close, and I get
+*allways* the correct scroller position (although I did not expect
+that), but often the timeout function continues. (Even when not the
+two cases are given: 1. no HTML, 2. the transmission was canceled.)
+
+I tried to traceback Html_close in gdb, but for my taste there are to
+much void pointers ;-)
+
+Sebastian. 
+
+
+
+RE: [Dillo-dev]Re: Eric
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-28 04:38
+
+Jorge,
+I tryied 3 different email addresses yo mail you, all rejected. Where can I
+send you the screenshots ?
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Jul-2000 a 13:36:08
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-07-27 16:29
+
+Hi, Jorge!
+
+Jorge Arellano Cid wrote:
+> [...]
+> > Currently, I store the requested anchor (what Nav_open_url reads behind
+> > the "#") in DwGtkScroller (which I find somehow logical), but this is
+> > only a detail which may be changed.
+> 
+> Yes, to DwPage.
+> In the next release I'll include more documentation about Dw.
+> 
+> Doc Preview :-)
+> 
+> DwGtkScroller is the topmost widget, it contains the vertical
+> and horizontal scrollers and GtkDwView. GtkDwView serves as the
+> container for the topmost Dw.
+> When the HTML page changes, these widgets remain, only the
+> topmost Dw is destroyed and new one created.
+> 
+> So, it seems to me that te #anchor belongs to DwPage.
+
+The new DwPage does not exist in Nav_open_url, so I put the #anchor in
+GtkDwScroller; but it is removed when it isn't used anymore.
+
+For an implementation of frames there should probably a new Dw widget
+DwFrameSet or so, but since frames can be scrolled, the DwFrameSet may
+perhaps itself contain other GtkDwScoller's with there own 
+#anchors, so (and because currently there aren't any concrete ideas
+about frames) I don't change this (in the near future).
+
+> > However, "queuing" this adjustment
+> > setting (in the case the page has to be loaded) brings some problems.
+> > The way I mentioned (in Dw_page_rewrap or Html_open_a) does not work,
+> > either a few others (e. g. Html_close). In any case,
+> > gtk_adjustment_set_value is called, but is has no effect.
+> 
+> What about adding an idle function to change the adjustment
+> value when the #anchor is found?
+> I mean, making a gtk idle function to poll the widget for the
+> requested anchor until it succeeds, and after that, changing the
+> adjustment value.
+
+Perhaps better a timeout function (with a small intervall of 200 ms or
+so), since idle functions take a lot of CPU time.
+
+I have tested it and --- it did not work :-)
+
+But I have found a solution (based on a timeout function) that works! By
+debugging I realized that there are problems when this timeout function
+accesses the DwPage's hashtable (again threads?), so I rewrote this
+function, so it does not access the hashtable in any case. In theory
+this should work always, in practise there are a few problems in some
+special cases, but I think this is the right way.
+
+> [...]
+> Ah, let me know if you'd prefer to continue working the patch
+> after next release (having the docs and new code), or to try to
+> push it into dillo 0.2.3.
+
+Docs is currently not the matter (unless I would find out a much more
+elegant solution after I've better understood the code ;-), but there is
+still a bit to do, so it depends on when you are planning to release
+version 0.2.3.
+
+Sebastian. 
+
+
+
+RE: [Dillo-dev]Re: Eric
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-27 05:05
+
+Le 26-Jul-2000, on m'a dit : 
+> Considering your skills, you have several choices to contribute!
+> 
+> - We need to assemble an HTML test suite. I have a bunch of
+> pages for that purpose, but it'd be great to make a master HTML
+> testing page with short descriptive links of what the page is
+> meant to test. We coul finally wrap it into a tar.gz and make
+> it available to other developers.
+> 
+
+I can do that. I'll submit the first pages in a day or two (the documentation
+will be in the page itself ;-).
+
+> - Finding bugs, identifying them and making good entries at the
+> bug track.
+> 
+
+I'm already doing that. I'm not sure I'm doing "good entries" tough ;-)
+
+> - Making a screenshots page for dillo (A few jpg thumbs with
+> links to middle sized jpg images).
+> 
+
+I can do that too. Middle sized would be 640x480 max ? Do you want me to do the
+page to present them too ?
+
+> - Implementing the bookmarks as an external plugin. The idea of
+> doing it keeps rolling in my mind. Basically a dpi:/ (dillo
+> plugin) URL can be defined, and when accessing dpi:/bm (bookmark)
+> an external program can be launched on a thread to 'cat' the
+> bookmarks file (this is very much like current file handling).
+> The point with this scheme is that the plugin can be extended
+> to achieve more functionality (add, move, remove bookmark, make
+> category, etc). All implemented in a CGI fashioned way.
+> With that example, other people can start thinking of other
+> plugins, like a man page processor, or info file processor, a
+> dillorc options interface, etc.
+> 
+
+You said that before and I love this idea. I'd like to see a practical example
+of plugin, even alpha stage, before I decide I can do it right.
+What I understand, is there's a program called bm in ~/.dillo/plugin/ or
+/usr/local/lib/dillo/ (or is it /usr/local/share/dillo/ ?), that take its
+arguments on the command line (ie : when calling the URL
+"dpi:/bm?subdirectoy=News&fontsize=16", dillo is opening a read only pipe with
+the command line "bm subdirectory=News fontsize=16"), then the program "bm"
+prints a html page in stdout (and can do something else, like writing a file
+on the disk), which page dillo will render.
+Is that what you have in mind ? If not, can you describe precisely the calling
+mecanism, as well as the data retrieving.
+
+> - Finish the 64bit CPU support.
+> I've been working on that. Standarized type handling and made
+> dillo compilable with lcc. Dillo "runs" on 64bit machines, but
+> very bad.
+> 
+
+I definitly can't do that, unless I benefit a donation of a 64bit workstation
+;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 27-Jul-2000 a 12:17:08
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Jorge Arellano Cid <jcid@ww...> - 2000-07-27 00:23
+
+Sebastian,
+(and everyone interested in Dw internals)
+
+> I indeed store the offsets in a hashtable (stored in DwPage, see below),
+> but these pseudo-widget are to make recalculating of them simpler when
+> the page is resized. More precisely, I added mainly following until now:
+> 
+> - Html_tag_open_a adds an anchor to the page and stores its current
+> offset in this hashtable. (This is done by a new function
+> a_Dw_page_add_anchor.)
+> 
+> - In Dw_page_rewrap this value is corrected. This is needed for resizing
+> of the page, as well as for images whose size changes (to the correct
+> value, after the size has been determined).
+> 
+> - I added a bit code to Nav_open_url, which I described already (see
+> below, after "> > ")
+> 
+> This first two points already work quite well.
+> 
+> If the page with this anchor has already be loaded (completely), when
+> Nav_open_url is called, only a gtk_adjustment_set_value(...) is needed.
+> This works already.
+
+Nice! [suggestions below]
+
+
+> > > o The point to start is Nav_open_url. This function should get the
+> > > requested anchor after the "#" and store it somewhere.
+> > 
+> > I think the best place for it is within the linkblock. This
+> > structure is used to handle auxiliary data structures derived
+> > from HTML procesing (as forms, base URL, etc).
+> > 
+> 
+> How long does a linkblock exist? The reason, why I stored the hashtable
+> for anchors in DwPage, is because these informations should exist as
+> long the user views the page. That is exactly as long the DwPage exists.
+
+At least until the form is sent :-)
+Use DwPage, I agree with you.
+
+> > > Probably, the
+> > > page should not be loaded when the href points to an anchor in the same
+> > > file. Later, the pixel position should be calculated. "Later" means:
+> > >
+> > > - when the page has already been loaded: immediatly, or
+> > > - otherwise: when the lines in the page are wrapped, or, perhaps,
+> > > already when the correct <a name="..."> is read (probably not).
+> > >
+> > > The last problem does not seem too hard.
+> But in practise, it *is* :-)
+
+See suggestions below.
+
+> > If we put the anchor (lets think of a gchar*) in the linkblock,
+> > NULL can mean NO anchor (draw from top), and anything else, draw
+> > from anchor. A new #anchor in the same page overwrites the former
+> > one.
+> > 
+> > That way, we won't fool the user when pressing the BACK key.
+> > One click would show the #anchor-scrolled page from the top and
+> > the next one would go back.
+> 
+> Do you mean to ignore the text before the <a name="...">? I thought of
+> setting the value of the DwGtkScroller's GtkAdjustment, so that the user
+> can scroll back and view the text before the anchor.
+
+I meant exactly what you wrote!
+(My point was not to queue multiple #anchor references, of the
+same page, in the navigation stack)
+
+
+> > > My question is: where to store the requested anchor? 
+> > > [...]
+> > 
+> > As I wrote above, my vote goes to the linkblock.
+
+Well, leave it in DwPage for now. Maybe in the future we'll use
+DwPage as a base widget for frames, and it seems simpler.
+
+
+> Currently, I store the requested anchor (what Nav_open_url reads behind
+> the "#") in DwGtkScroller (which I find somehow logical), but this is
+> only a detail which may be changed.
+
+Yes, to DwPage.
+In the next release I'll include more documentation about Dw.
+
+Doc Preview :-)
+
+DwGtkScroller is the topmost widget, it contains the vertical
+and horizontal scrollers and GtkDwView. GtkDwView serves as the
+container for the topmost Dw. 
+When the HTML page changes, these widgets remain, only the
+topmost Dw is destroyed and new one created.
+
+So, it seems to me that te #anchor belongs to DwPage.
+
+
+> However, "queuing" this adjustment
+> setting (in the case the page has to be loaded) brings some problems.
+> The way I mentioned (in Dw_page_rewrap or Html_open_a) does not work,
+> either a few others (e. g. Html_close). In any case,
+> gtk_adjustment_set_value is called, but is has no effect.
+
+What about adding an idle function to change the adjustment
+value when the #anchor is found?
+I mean, making a gtk idle function to poll the widget for the
+requested anchor until it succeeds, and after that, changing the
+adjustment value.
+
+> A reason for this may be the different threads, and I think Gtk isn't
+> thread-save (what is generally a problem with X).
+
+OH, I'll try to include more documentation (already wrote, but
+in .ps format...)
+
+Doc preview 2:
+
+The threaded systems in dillo were isolated for use only by the
+dns engine and file transfer. They don't mess with shared memory,
+and data exchange is carried on with pipes.
+Threads don't access, nor use GTK+ code.
+
+Plainly stated: If you're coding for dillo, and don't change
+anything in dns.c and file.c, you can forget about threads!
+
+
+> Actually, somehow the
+> text "gets visible" (sorry for this vague expression, but I don't know,
+> where), and this point is perhaps to continue. Perhaps someone can give
+> me some hints.
+
+Sure, I've had problems too when trying to understand it.
+
+Weird behaviour is most notably due to an incomplete
+implementation of the Dw mechanism. For instance:
+
+Dw_gtk_view_adjustment_changed does NOTHING!
+(But it gets called)
+
+I used Dw_gtk_view_v_scroll to solve the scrolling problem. If
+scrolling presents weird behaviour for you, start investigating
+from there.
+
+Ah, let me know if you'd prefer to continue working the patch
+after next release (having the docs and new code), or to try to
+push it into dillo 0.2.3.
+
+--
+--
+
+Ah, I've been working out the code, improved the rendering speed
+(yes it was possible), removed several segfault sources, fixed
+some bugs, etc.
+It seems we're close to 0.2.3.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Re: Eric
+
+From: Jorge Arellano Cid <jcid@ww...> - 2000-07-27 00:23
+
+Hi everyone!
+(This is mainly several replies to Eric's posts, 
+but it's intended to everyone)
+
+> ...
+> However, is it a good thing,
+> when location bar focused, to map left and right arrows to move
+> the cursor, and up, down, page up, page down to scroll the page?
+
+I'm not sure, but it has proven practical!
+Let's keep it that way until someone comes with something better.
+
+> [personal skills]
+> I'd love to contribute to dillo, but I'd prefer the code to
+> be more documented.
+
+Me too!
+Documentation has been one of the key points in our efforts. We
+have advanced a lot with it (documenting inside and outside the
+code), but there's still work to do. No doubt.
+
+I'll include more docs in the next release (I write them as fast
+as I can). I'd also appreciate some feedback on the subject. What
+is already clear from the docs, and what needs more work. No one
+has written me a single line about it :-( --AFAIR
+
+--
+
+Considering your skills, you have several choices to contribute!
+
+- We need to assemble an HTML test suite. I have a bunch of
+pages for that purpose, but it'd be great to make a master HTML
+testing page with short descriptive links of what the page is
+meant to test. We coul finally wrap it into a tar.gz and make
+it available to other developers.
+
+- Finding bugs, identifying them and making good entries at the
+bug track.
+
+- Making a screenshots page for dillo (A few jpg thumbs with
+links to middle sized jpg images).
+
+- Implementing the bookmarks as an external plugin. The idea of
+doing it keeps rolling in my mind. Basically a dpi:/ (dillo
+plugin) URL can be defined, and when accessing dpi:/bm (bookmark)
+an external program can be launched on a thread to 'cat' the
+bookmarks file (this is very much like current file handling).
+The point with this scheme is that the plugin can be extended
+to achieve more functionality (add, move, remove bookmark, make
+category, etc). All implemented in a CGI fashioned way.
+With that example, other people can start thinking of other
+plugins, like a man page processor, or info file processor, a
+dillorc options interface, etc.
+
+- Finish the 64bit CPU support.
+I've been working on that. Standarized type handling and made
+dillo compilable with lcc. Dillo "runs" on 64bit machines, but
+very bad.
+
+
+Just tell me what you'd like to do (volunteers welcome).
+
+Sincerely
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-07-25 15:33
+
+Hi, again!
+
+Jorge Arellano Cid wrote:
+> 
+> Sebastian,
+> 
+> On 11 Jul 2000, Sebastian Geerken wrote:
+[...]
+> > 2. My basic idea is:
+> >
+> > o Extend the DwPage widget: add a new DW_PAGE_CONTENT_ANCHOR, which has
+> > zero size and is not drawn in any way.
+> 
+> Are you planning to get the offset from this pseudo-widget?
+>
+
+I indeed store the offsets in a hashtable (stored in DwPage, see below),
+but these pseudo-widget are to make recalculating of them simpler when
+the page is resized. More precisely, I added mainly following until now:
+
+- Html_tag_open_a adds an anchor to the page and stores its current
+offset in this hashtable. (This is done by a new function
+a_Dw_page_add_anchor.)
+
+- In Dw_page_rewrap this value is corrected. This is needed for resizing
+of the page, as well as for images whose size changes (to the correct
+value, after the size has been determined).
+
+- I added a bit code to Nav_open_url, which I described already (see
+below, after "> > ")
+
+This first two points already work quite well.
+
+If the page with this anchor has already be loaded (completely), when
+Nav_open_url is called, only a gtk_adjustment_set_value(...) is needed.
+This works already.
+
+> > o The point to start is Nav_open_url. This function should get the
+> > requested anchor after the "#" and store it somewhere.
+> 
+> I think the best place for it is within the linkblock. This
+> structure is used to handle auxiliary data structures derived
+> from HTML procesing (as forms, base URL, etc).
+> 
+
+How long does a linkblock exist? The reason, why I stored the hashtable
+for anchors in DwPage, is because these informations should exist as
+long the user views the page. That is exactly as long the DwPage exists.
+
+> > Probably, the
+> > page should not be loaded when the href points to an anchor in the same
+> > file. Later, the pixel position should be calculated. "Later" means:
+> >
+> > - when the page has already been loaded: immediatly, or
+> > - otherwise: when the lines in the page are wrapped, or, perhaps,
+> > already when the correct <a name="..."> is read (probably not).
+> >
+> > The last problem does not seem too hard.
+But in practise, it *is* :-)
+
+> 
+> If we put the anchor (lets think of a gchar*) in the linkblock,
+> NULL can mean NO anchor (draw from top), and anything else, draw
+> from anchor. A new #anchor in the same page overwrites the former
+> one.
+> 
+> That way, we won't fool the user when pressing the BACK key.
+> One click would show the #anchor-scrolled page from the top and
+> the next one would go back.
+
+Do you mean to ignore the text before the <a name="...">? I thought of
+setting the value of the DwGtkScroller's GtkAdjustment, so that the user
+can scroll back and view the text before the anchor.
+
+> 
+> > My question is: where to store
+> > the requested anchor? BrowserWindow would be simple, but when frames are
+> > implemented later, the requested anchor should belong to a frame. DwPage
+> > would be better, but when I follow all the created structures, there is
+> > a break in the IO/Mime module where the anchor gets lost (?). What about
+> > DwBorder becoming a base Widget for a frame?
+> 
+> As I wrote above, my vote goes to the linkblock.
+> We're still one step behind the frame implementation design.
+> Currently we're aiming towards a table representation for it.
+> Anyway, if it would finally get implemented in adifferent way,
+> the information, most probably would end in the linkblock!
+> 
+
+Currently, I store the requested anchor (what Nav_open_url reads behind
+the "#") in DwGtkScroller (which I find somehow logical), but this is
+only a detail which may be changed. However, "queuing" this adjustment
+setting (in the case the page has to be loaded) brings some problems.
+The way I mentioned (in Dw_page_rewrap or Html_open_a) does not work,
+either a few others (e. g. Html_close). In any case,
+gtk_adjustment_set_value is called, but is has no effect.
+
+A reason for this may be the different threads, and I think Gtk isn't
+thread-save (what is generally a problem with X). Actually, somehow the
+text "gets visible" (sorry for this vague expression, but I don't know,
+where), and this point is perhaps to continue. Perhaps someone can give
+me some hints.
+
+Sebastian. 
+
+
+
+Re: [Dillo-dev]Bug #57
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-07-25 08:19
+
+Jorge Arellano Cid wrote:
+> 
+> Hi!
+> 
+> Can anyone tell me how to reproduce bug #57? The procedure in
+> the bug-track works fine for me (no bug).
+> 
+> Jorge.-
+>
+
+I once encountered this bug (not by intention!), but I think it was in
+dillo 0.2.0. As I remember, it was due to some strange characters in the
+title; perhaps this hint might help.
+
+Otherwise: If I start dillo and open a new window (File/New Browser),
+the new window always has an empty bookmark menu. This is so strange
+that it seems to be intended ;-) 
+
+
+
+RE: [Dillo-dev]Bug #57
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-25 01:50
+
+Le 24-Jul-2000, on m'a dit : 
+> 
+> Hi!
+> 
+> Can anyone tell me how to reproduce bug #57? The procedure in
+> the bug-track works fine for me (no bug).
+> 
+> Jorge.-
+> 
+
+I don't konw if it's related, but the page shown by "view bookmarks" (file
+~/.dillo/bookmarks.html) doesn't list the same bookmarks than those in the
+"bookmark" menu : the bookmark menu contains all bookmarked URLs, but the
+bookmark file is only updated when exiting dillo, thus containing only the URLs
+present at dillo's launch.
+No random char for me. (dillo v0.2.2 with focus patch)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Jul-2000 a 23:07:33
+---------------------------------- 
+
+
+
+[Dillo-dev]Bug #57
+
+From: Jorge Arellano Cid <jcid@ww...> - 2000-07-24 12:56
+
+Hi!
+
+Can anyone tell me how to reproduce bug #57? The procedure in
+the bug-track works fine for me (no bug).
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #54 : a hint
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-19 09:19
+
+Le 19-Jul-2000, on m'a dit : 
+> Eric,
+...
+> I sent you a patch for testing (private email), but if your
+> will to help is so good as described above, I'd very much like to
+> know your skills, just to know what I can ask you to do.
+> 
+> Sincerely
+> Jorge.-
+> 
+
+Patch tested and answered. I've never done gtk developement (nor motif, qt or
+any X toolkit), but I've been coding on linux for a year or so (C, pthreads,
+java, php3, html, sql), and I know how to compile and trace a program with
+xxgdb (I still have trouble with makefiles, no improvement to expect here
+because I'm heavily using CodeCrusader with automated makefiles generation, and
+I've got to read the man pages everytime I want to apply patches ;-)
+I haven't done C++ for a while, since I'm no more doing Visual C++
+developement. I wasn't so good doing that anyway :-/
+The "bigest" linux coding project I've been involved in is recoding a dockapp
+(wmtime) for my own fits. Dockapps only use Xlib for rendering. ... oh, and I
+tried to improve gnome-o-phone sending patches, but I stoped it because of an
+argument with the maintener because applying my patches was too much work for
+him.
+
+I'd love to contribute to dillo, but I'd prefer the code to be more documented.
+
+PS: I also know quite well forth, asm68k, and Dr's GEM toolkit, but I don't
+think you'll find that usefull for dillo ;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 19-Jul-2000 a 18:03:25
+"Not so long ago if you had a 3 1/2 inch floppy 
+you hoped nobody found out!"
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Bug #54 : a hint
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-19 01:17
+
+Eric,
+
+> [BUG 54]
+> If you guys need me to track this bug down, you just have to ask : I can
+> reproduce it every time. I can change to gtk-1.2.6, or whatever you ask. I
+> don't know what informations are pertinent for this problem (parameters passed
+> to the gtk_signal_emit_by_name() that can cause errors), name them and I'll do
+> a complete report.
+
+I sent you a patch for testing (private email), but if your
+will to help is so good as described above, I'd very much like to
+know your skills, just to know what I can ask you to do.
+
+Sincerely
+Jorge.- 
+
+
+
+[Dillo-dev]Dw?
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-18 00:35
+
+Hi there!
+
+Here's a question that keeps comming back to me:
+
+Q: What's the point in having the whole Dillo Widget mechanism
+over having a simple GTK+-derived widget set?
+
+I've found reasons like eliminating the window creation
+overhead for images, but, is that the main point of it? I doubt.
+
+
+Any light on the subject is welcomed.
+Jorge.- 
+
+
+
+[Dillo-dev]Bug #58 same as #58 ?
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-15 14:50
+
+Hi guys,
+I've read the bug list, and I have the feeling bug #35 and bug #58 are the same
+(#35 looks like an extreme case of #58 where the "small" page is scrolled too
+high)
+Does this info help ?
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Jul-2000 a 23:46:53
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Bug #54 : a hint
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-15 14:47
+
+Le 14-Jul-2000, on m'a dit : 
+> Il ven, 14 lug 2000, hai scritto:
+> > Hi again,
+> 
+> > There's still some weird code around "the line".
+> > Would you mind sending me a short patch Luca?
+> 
+> As you noticed Dw is incomplete. And it has some problem with focus, too.
+> 
+> Without Interface_handle_key_event() when the location bar has the focus and
+> you press Arrow Down (or Tab) the focus is lost. But Dw (and then Dw_view)
+> doesn't get it.
+> 
+
+...
+
+> 
+> If gtk_signal_emit_by_name() gives some problem well it's safe deleting this
+> line. But it's not a definitive solution. Please note that I've no problem
+> with gtk-1.2.6.
+> 
+
+If you guys need me to track this bug down, you just have to ask : I can
+reproduce it every time. I can change to gtk-1.2.6, or whatever you ask. I
+don't know what informations are pertinent for this problem (parameters passed
+to the gtk_signal_emit_by_name() that can cause errors), name them and I'll do
+a complete report.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Jul-2000 a 23:42:08
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Bug #54 : a hint
+
+From: Luca Rota <drake@it...> - 2000-07-15 12:54
+
+Il ven, 14 lug 2000, hai scritto:
+> Hi again,
+
+> There's still some weird code around "the line".
+> Would you mind sending me a short patch Luca?
+
+As you noticed Dw is incomplete. And it has some problem with focus, too.
+
+Without Interface_handle_key_event() when the location bar has the focus and
+you press Arrow Down (or Tab) the focus is lost. But Dw (and then Dw_view)
+doesn't get it.
+
+With Interface_handle_key_event() when the location bar has the focus and you
+press Arrow Down (or Arrow Up, Page Down, Page Up) this handler send a signal
+(with gtk_signal_emit_by_name()) to dw_view and stop the original signal. If we
+delete gtk_signal_emit_by_name(), dw_view doesn't get the key_press event and so
+the page isn't scrolled. If we delete gtk_signal_emit_stop_by_name() the
+location bar will lose the focus.
+
+If gtk_signal_emit_by_name() gives some problem well it's safe deleting this
+line. But it's not a definitive solution. Please note that I've no problem with
+gtk-1.2.6.
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]Bug #54 : a hint
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-13 23:39
+
+Hi again,
+
+On Mon, 10 Jul 2000, Luca Rota wrote:
+
+> > Commenting this line prevents dillo form segfaulting when pressing PgUp,
+> > PgDown, Up and Down arrows, but I'm pretty sure this line has a purpose ;-) and
+> > just removing it is not what you'd call "clean fix".
+> 
+> Now, I think, it's safe deleting this line.
+> With my RedHat Linux box and gtk 1.2.6 I've no problem.
+
+There's still some weird code around "the line".
+Would you mind sending me a short patch Luca?
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-13 23:39
+
+Sebastian,
+
+
+On 11 Jul 2000, Sebastian Geerken wrote:
+
+> Hi!
+> 
+> I'm currently working on anchors (to get URL's like "foo#bar" rendered
+> correctly, bug #10), and I have two questions:
+
+Good!
+That's would make dillo much better.
+
+> 1. Does anyone do anything on tables? It's because I will change the
+> DwPage widget, and this is probably also necessary for tables; so we
+> should avoid to get problems patching both togeher.
+
+Yes, and No :-)
+Currently we're studying Dw in order to understand it
+thoroughly and document it (I have three pages written now).
+Although I have made several patches inside it, the general
+design behind it is still somewhat obscure to me; with my latest
+studies I've began to understand why: Dw is incomplete!
+
+Yes, it was designed (by Raph Levien) to manage an interesting
+bunch of funcionality, but some of its key parts are not
+implemented yet!
+
+For instance, embedded GTK+ widgets can't pass resize requests
+to their respective Dw containers (this is necessary if tables
+are to be implemented with GTK+ widgets).
+Some parts of the rewrap and paint stuff are still waiting to
+be completed.
+
+So, our current work consists on studying Dw, documenting it,
+with a view to decide what to extend (or change) and finally
+start designning our table handling scheme upon that base.
+
+(I've also sent emails to Raph, but have had no answers. Maybe
+he's on vacation; it's summer there in Europe!)
+
+> 2. My basic idea is:
+> 
+> o Extend the DwPage widget: add a new DW_PAGE_CONTENT_ANCHOR, which has
+> zero size and is not drawn in any way.
+
+Are you planning to get the offset from this pseudo-widget?
+
+> o The point to start is Nav_open_url. This function should get the
+> requested anchor after the "#" and store it somewhere. 
+
+I think the best place for it is within the linkblock. This
+structure is used to handle auxiliary data structures derived
+from HTML procesing (as forms, base URL, etc).
+
+
+> Probably, the
+> page should not be loaded when the href points to an anchor in the same
+> file. Later, the pixel position should be calculated. "Later" means:
+> 
+> - when the page has already been loaded: immediatly, or
+> - otherwise: when the lines in the page are wrapped, or, perhaps,
+> already when the correct <a name="..."> is read (probably not).
+> 
+> The last problem does not seem too hard. 
+
+If we put the anchor (lets think of a gchar*) in the linkblock,
+NULL can mean NO anchor (draw from top), and anything else, draw
+from anchor. A new #anchor in the same page overwrites the former
+one.
+
+That way, we won't fool the user when pressing the BACK key.
+One click would show the #anchor-scrolled page from the top and
+the next one would go back.
+
+> My question is: where to store
+> the requested anchor? BrowserWindow would be simple, but when frames are
+> implemented later, the requested anchor should belong to a frame. DwPage
+> would be better, but when I follow all the created structures, there is
+> a break in the IO/Mime module where the anchor gets lost (?). What about
+> DwBorder becoming a base Widget for a frame?
+
+As I wrote above, my vote goes to the linkblock.
+We're still one step behind the frame implementation design.
+Currently we're aiming towards a table representation for it.
+Anyway, if it would finally get implemented in adifferent way,
+the information, most probably would end in the linkblock!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Bug #10 (Anchors): questions
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-07-11 15:32
+
+Hi!
+
+I'm currently working on anchors (to get URL's like "foo#bar" rendered
+correctly, bug #10), and I have two questions:
+
+1. Does anyone do anything on tables? It's because I will change the
+DwPage widget, and this is probably also necessary for tables; so we
+should avoid to get problems patching both togeher.
+
+2. My basic idea is:
+
+o Extend the DwPage widget: add a new DW_PAGE_CONTENT_ANCHOR, which has
+zero size and is not drawn in any way.
+
+o The point to start is Nav_open_url. This function should get the
+requested anchor after the "#" and store it somewhere. Probably, the
+page should not be loaded when the href points to an anchor in the same
+file. Later, the pixel position should be calculated. "Later" means:
+
+- when the page has already been loaded: immediatly, or
+- otherwise: when the lines in the page are wrapped, or, perhaps,
+already when the correct <a name="..."> is read (probably not).
+
+The last problem does not seem too hard. My question is: where to store
+the requested anchor? BrowserWindow would be simple, but when frames are
+implemented later, the requested anchor should belong to a frame. DwPage
+would be better, but when I follow all the created structures, there is
+a break in the IO/Mime module where the anchor gets lost (?). What about
+DwBorder becoming a base Widget for a frame?
+
+Any suggestions?
+
+Sebastian. 
+
+
+
+Re: [Dillo-dev]dillo-0.2.2
+
+From: <tjs17@co...> - 2000-07-11 01:49
+
+On Sun, 9 Jul 2000, Jorge Arellano Cid wrote: 
+
+> Some time ago I was informed that dillo compiled with freeBSD
+> (with lots of segfaults at run time); was that a 64bit machine?
+> which compiler? (He's a member of this list!).
+
+That was me. I'm using a 32bit machine, gcc 2.7.2.3, and frebsd 3.5. I 
+suppose that my freebsd compilation doesn't really crash much more than 
+my linux one (or netscape for that matter...). BTW, the only tweak I 
+needed for 0.2.2. was to use -pthread instead of -lpthread. 
+
+
+
+Re: [Dillo-dev]Bug #54 : a hint
+
+From: Luca Rota <drake@it...> - 2000-07-10 16:02
+
+Il lun, 10 lug 2000, hai scritto:
+
+> This bug has something to do with interface.c line1048 :
+> in Interface_handle_key_event()
+> 
+> gtk_signal_emit_by_name (GTK_OBJECT (dw_view), "key_press_event", event);
+> 
+Uh! Let me see!
+Oh! yes, I remember!
+
+Some release ago dillo had a bug which prevents form to be focused. And so,
+with gtk 1.2.4 and before the patch for that bug gtk_signal was a little hack.
+
+> Commenting this line prevents dillo form segfaulting when pressing PgUp,
+> PgDown, Up and Down arrows, but I'm pretty sure this line has a purpose ;-) and
+> just removing it is not what you'd call "clean fix".
+
+Now, I think, it's safe deleting this line.
+With my RedHat Linux box and gtk 1.2.6 I've no problem.
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]Bug #54 : a hint
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-10 07:03
+
+This bug has something to do with interface.c line1048 :
+in Interface_handle_key_event()
+
+gtk_signal_emit_by_name (GTK_OBJECT (dw_view), "key_press_event", event);
+
+Commenting this line prevents dillo form segfaulting when pressing PgUp,
+PgDown, Up and Down arrows, but I'm pretty sure this line has a purpose ;-) and
+just removing it is not what you'd call "clean fix".
+
+I'm not much familiar with gtk coding. Can anyone tell me what this line does ?
+(I mean : I know it emits a signal named "key_press_event" ; what I want 
+to know is how dillo is dealing with this signal. It seems that its only
+purpose is to call Interface_handle_key_event, the very same function the
+emission is from ???)
+
+Le 09-Jul-2000, on m'a dit : 
+> Ah, there's a bug (#54) in the bug track engine that seems to
+> concern GTK+, not dillo. Anyway, I'm using GTK+-1.2.6 and don't
+> have any trouble with it (no segfault with the described
+> procedure). Which GTK+ version (or OS) is the poster using?
+> --just curiousity.
+> 
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Jul-2000 a 15:26:13
+"Not so long ago if you had a 3 1/2 inch floppy 
+you hoped nobody found out!"
+---------------------------------- 
+
+
+
+RE: [Dillo-dev]dillo-0.2.2
+
+From: Eric GAUDET <egaudet@in...> - 2000-07-10 03:10
+
+Le 09-Jul-2000, on m'a dit : 
+> Ah, there's a bug (#54) in the bug track engine that seems to
+> concern GTK+, not dillo. Anyway, I'm using GTK+-1.2.6 and don't
+> have any trouble with it (no segfault with the described
+> procedure). Which GTK+ version (or OS) is the poster using?
+> --just curiousity.
+> 
+
+Thats me. This bug is very reproductible : every time (for me).
+I'm on linux kernel 2.4.0-test2-ac2, based on Mandrake 7.0, with
+gtk+-1.2.7 and glib-1.2.7.
+
+I'll try to track this bug, though it seems burried in a 15 or so deep gtk-call
+:-/
+
+Where is the code for the URL box ? (init and loop)
+
+(PS: I got some segfault I can't reproduce, after browsing a few pages (on
+0.2.1))
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Jul-2000 a 11:54:28
+"Not so long ago if you had a 3 1/2 inch floppy 
+you hoped nobody found out!"
+---------------------------------- 
+
+
+
+[Dillo-dev]Dillo web-page comments (fwd)
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-10 00:53
+
+Hi there!
+
+I just received this email and frankly, I think skeff is right:
+
+---------- Forwarded message ----------
+Date: Sun, 09 Jul 2000 23:11:58 +0300
+From: skeff <skeff@on...>
+To: jcid@ma...
+Subject: Dillo web-page comments
+
+Ok site and all that.
+But hey, SCREENSHOTS !!! ;)
+
+People don't bother downloading your program unless you have a
+screenshots, or if they're very interested.
+
+-skeff
+---------------------------------------
+
+If there's someone willing to make that, it'd be great.
+An HTML page with, let's say five small thumbnails and their
+links (jpeg images).
+OK, if you just send me the thumbs and full-pictures pairs
+that'll be enough to build the page.
+If you plan to commit yourself with the task, please send an
+email to this list to let others know it has been taken.
+
+Thanks a lot.
+Jorge.- 
+
+
+
+[Dillo-dev]dillo-0.2.2
+
+From: Jorge Arellano Cid <jcid@em...> - 2000-07-09 18:59
+
+Hi!
+
+Well, maybe a little delayed, but dillo-0.2.2 is finally
+there, ready for download. I think the wait was worth the delay
+because it finally can handle forms very much better, and there's
+also an option that will let slashdot fans read the site. There
+are several other improvements and changes detailed in the
+Changelog.
+
+I want to thank every single patch you've sent me and hope you
+enjoy this release.
+
+Ah, there's a bug (#54) in the bug track engine that seems to
+concern GTK+, not dillo. Anyway, I'm using GTK+-1.2.6 and don't
+have any trouble with it (no segfault with the described
+procedure). Which GTK+ version (or OS) is the poster using?
+--just curiousity.
+
+For those of you that had worked in the HTML parser, this
+release comes with some significant changes. Basically the
+parsing stack was modified with a clearer design (you'll easily
+get it from the code). Form processing no longer depends on the
+stack, but only on the linkblock. The child_linkblock was also
+integrated into the html_linkblock.
+
+Several changes had taken place in order to achieve
+compatibility with lcc compiler (it enhances portability).
+Although I got dillo to compile with lcc, I can't still make it
+run well on 64 bit machines. 
+
+Some time ago I was informed that dillo compiled with freeBSD
+(with lots of segfaults at run time); was that a 64bit machine?
+which compiler? (He's a member of this list!).
+
+
+Jorge.- 
+
+
diff --git a/old/oldmail/200008.txt b/old/oldmail/200008.txt
new file mode 100644
index 0000000..8133b5d
--- /dev/null
+++ b/old/oldmail/200008.txt
@@ -0,0 +1,3527 @@
+Re: [Dillo-dev]bug#77 is anchor-related
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-27 16:32
+
+Eric GAUDET wrote:
+> 
+> Hi all,
+> bug#77 (segfault with http://www.w3.org/TR/html4/) has to do with
+> Dw_page_set_scroller_pos. For an unknown (to me, at least ;-) reason,
+> dw->container is null for one widget, doing a segfault when accessed.
+> This is related to anchors, so I hope Sebastian can fix that easilly ;-)
+
+Funny, I've inserted this bug. ;-)
+
+Dw_page_set_scroller_pos searches the GtkDwScroller that "contains"
+the DwPage. Normally, page->parent is a DwBorder, page->parent->parent
+is NULL (i. e. the DwBorder is a toplevel Dw widget), and
+page->parent->container->widget point to the GtkDwView (a normal Gtk+
+widget, which parent is the GtkDwScroller). page->container is always
+NULL.
+
+When examining the bug, I found that page->parent is NULL (and also
+page->container). The bug seems to lie deeper in Dw, but since Dw is
+planned to be elemenated and relaced by Gtk+, I'd suggest to forget
+it. ;-)
+
+Sebastian 
+
+
+
+[Dillo-dev]bug#77 is anchor-related
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-27 14:07
+
+Hi all,
+bug#77 (segfault with http://www.w3.org/TR/html4/) has to do with
+Dw_page_set_scroller_pos. For an unknown (to me, at least ;-) reason,
+dw->container is null for one widget, doing a segfault when accessed.
+This is related to anchors, so I hope Sebastian can fix that easilly ;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 27-Aug-2000 a 23:01:22
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]support for background images?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-26 14:30
+
+Sean 'Shaleh' Perry wrote:
+> That said, please do visit the html validator link I sent previously. In css
+> supporting browsers, a line of incorrect html is set against a grey background.
+
+At least it is readable in dillo. ;-)
+
+> We have to be able to affect the appearance of a page on a per word basis.
+
+Currently, DwPage can assign attributes to words. I don't think it is
+too difficult to add backgrounds to DwPageAttr. I'll test it soon.
+
+Sebastian 
+
+
+
+[Dillo-dev]bug no insertion : I'm patching lists
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-26 13:18
+
+Hi all,
+the inserting in bug tracking engine doesn't work for me (server
+internal error).
+Be aware I'm partching the lists tags and dw_bullets right now, to make
+attribute type being recognized (both OL and UL), and also to correct
+the bug about numbering reported a few days ago.
+
+I wont address bug#78 this time because it's a P tag problem.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Aug-2000 a 16:29:43
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]support for background images?
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-26 10:00
+
+> I'm currently working on DwPage (table sections will be DwPage's,
+> too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in
+> Html_tag_open_body), I'll set it as the the page's background. (I
+> hope. ;-)
+> 
+
+hmm, seems the dicache and the rest of the image code assumes the goal is to
+place the image on the page. Will have to read thru the entire image code to
+lay this out and understand a proper implementation. Sounds like this can wait
+(-: 
+
+
+
+Re: [Dillo-dev]support for background images?
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-26 09:37
+
+> I'm currently working on DwPage (table sections will be DwPage's,
+> too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in
+> Html_tag_open_body), I'll set it as the the page's background. (I
+> hope. ;-)
+> 
+
+will add this to my list of things todo.
+
+That said, please do visit the html validator link I sent previously. In css
+supporting browsers, a line of incorrect html is set against a grey background.
+We have to be able to affect the appearance of a page on a per word basis. 
+
+
+
+Re: [Dillo-dev]support for background images?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-26 09:25
+
+Sean 'Shaleh' Perry wrote:
+> 
+> Thought I would toss this out in the mess of ideas lately:
+> 
+> we ought to support background images. style sheets allow you to specify
+> backgrounds for just about everything. So, what would be best is a mechanism
+> for:
+> 
+> load image
+> place image in the background of widget X
+> 
+> X could be Page, table section, etc.
+> 
+> Seems funny that the bug list looks better in ns than in dillo (-:
+
+I'm currently working on DwPage (table sections will be DwPage's,
+too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in
+Html_tag_open_body), I'll set it as the the page's background. (I
+hope. ;-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Anchor : feature wish
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-26 03:21
+
+Le 25-Aug-2000, on m'a dit : 
+> > ok, what about both, then (anchors and headings) ? Some of them can
+> > be
+> > duplicates (anchor are often used to link to pararaphs titles).
+> > And "Top of page" and "Bottom of page", even if not anchored, would
+> > be
+> > useful too.
+> 
+> It's quite simple, I've begun to implement it (both headings and
+> anchors). But I will not work on it the next time. Is anyone
+> interested in completing it? I'll send him the patch.
+> 
+> Sebastian
+
+I can try. Send me the patch.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Aug-2000 a 12:21:03
+---------------------------------- 
+
+
+
+[Dillo-dev]support for background images?
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-26 00:14
+
+Thought I would toss this out in the mess of ideas lately:
+
+we ought to support background images. style sheets allow you to specify
+backgrounds for just about everything. So, what would be best is a mechanism
+for:
+
+load image
+place image in the background of widget X
+
+X could be Page, table section, etc.
+
+Seems funny that the bug list looks better in ns than in dillo (-: 
+
+
+
+Re: [Dillo-dev]Anchor : feature wish
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 18:59
+
+Eric GAUDET wrote:
+> 
+> Le 25-Aug-2000, on m'a dit :
+> > Eric GAUDET wrote:
+> > > Hi,
+> > > I just thought about one (new idea?) feature about anchors : would
+> > > it
+> > > be possible to list them in a menu entry (Named "Chapters"?
+> > > "Index"?
+> > > "Content"?). Doing that, each time a page is loaded, this menu
+> > > entry
+> > > would be updated and the user could conveniently "jump" to anchors
+> > > in
+> > > the page without scrolling.
+> > >
+> > > What do you think ?
+> >
+> > That would be possible. But I think a menu of the anchors in a page
+> > is not very useful. Better would be to list all the <h1>...<h6>.
+> > That could also be possible by adding "pseudo anchors". If you get
+> > a tag which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR
+> > "@id" or so, where id is a unique number (unique in the page).
+> >
+> 
+> ok, what about both, then (anchors and headings) ? Some of them can be
+> duplicates (anchor are often used to link to pararaphs titles).
+> And "Top of page" and "Bottom of page", even if not anchored, would be
+> useful too.
+
+It's quite simple, I've begun to implement it (both headings and
+anchors). But I will not work on it the next time. Is anyone
+interested in completing it? I'll send him the patch.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Anchor : feature wish
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-25 14:22
+
+Le 25-Aug-2000, on m'a dit : 
+> I didn't actually mean dillo's plugins (I currenty don't know how
+> they work anyway), but some other sort of
+> extend-dillo-without-modifying-the-sources, which could be called
+> modules to avoid confusing. What I thought is: You can think of
+> thousands of useful functions for dillo. When putting them all into
+> dillo, the code gets big although a user might not use all these
+> features. Indeed, such an interface should 1. be designed properly,
+> and 2. not in the near future (currently we have other problems).
+> 
+
+Totally agreed ! (on everything : "thousands useful functions", "module
+interface design", "we have other problems") What I was pointing out is
+such a module interface design could be really tricky to come out with,
+especially since it hasn't been planned of from the begining.
+
+> Sebastian
+> 
+> PS1: I'm currently not interested in working on something like that,
+> it was just an idea. ;-)
+> 
+
+While you're talking about that, I wanted to tell how nice it is to be
+in that mailing list, with people throwing interesting ideas (even if
+not interested in working on them ;-), nice and respectful ambiance (no
+troll here : great !).
+
+> PS2: Counting characters is exotic enough that is reasonable to let
+> the user save the page and start an other program. Trying to connect
+> a webbrowser to all of the world is indeed quite idiotic.
+
+ok, that was a poor example, but who knows ? ;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 25-Aug-2000 a 23:09:58
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Anchor : feature wish
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 13:43
+
+Eric GAUDET wrote:
+> [...]
+> > Another idea: What about a mechanism to let the user ("user" is
+> > anyone who does not changes the sources of dillo ;-) write such
+> > things.
+> > Perhaps plugins? The plugin transmits to dillo what is interesting
+> > for it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id
+> > for referring to the tags to the plugin. When a user clickes on an
+> > item in the plugin's list, the plugin sends a url to dillo.
+> >
+> 
+> That would mean calling _every_ (registered) plugin each time a page
+> is loaded. Seems possible, but that can slow down thing.
+> Registering the tags is interesting because dillo doesn't have to send
+> the whole page, and the plugin doesn't have to parse html. But I'm not
+> sure that's how plugins are supposed to work, though I'm still waiting
+> for complete plugins specs (Jorge ?).
+> I mean : we'll have to change dillo's html parsing for that type of
+> plugins ; what about a plugin wanting to count how many "e" there's in
+> a page ? interesting, but we'll have to change dillo's sources for that.
+> What about a pluggin wanting to scan images before rendered and censor
+> those where there's too much "skin tones" ? interesting, but we'll have
+> to change dillo's sources once again for that.
+> The cleanest way would be to send each page to the pluggin, and wait for
+> the plugin to render the page. The html parser could be a plugin : that
+> way we could have a pdf-plugin, a rtf-plugin ... that would be nice.
+> But that's not what we are doing : we are doing an html browser, and
+> html source is intended to be in the browser, not sent to plugins.
+> The way Jorge defined plugins (that can change) is clean and simple : a
+> plugin call looks like a link ("dpi://myplugin"), some datas are sent
+> (name=value type), the plugin sends back an html page (and possibly ask
+> dillo to update its menus, but there's no protocol for that yet, though
+> I'm working on it). That's it. There's no two-way interaction between
+> dillo and the plugins. There is no possibility for a plugin to ask dillo
+> about its internals, such as page source, history.
+> Albeit your module/plugin idea is interesting, that would mean a big
+> rewrite in dillo's whole html parsing and plugin system (I know,
+> it's not written yet) just to avoid small changes in dillo's menus and
+> anchor (and H1..h6) parsing.
+> In a nutshell, I think it's better and easier to keep these things in
+> dillo, until we define (not soon) a clear mecanisme for external
+> modules, which aren't plugins.
+> 
+> (man, _that's_ a long answer to a not very useful question ;-)
+
+I didn't actually mean dillo's plugins (I currenty don't know how they
+work anyway), but some other sort of
+extend-dillo-without-modifying-the-sources, which could be called
+modules to avoid confusing. What I thought is: You can think of
+thousands of useful functions for dillo. When putting them all into
+dillo, the code gets big although a user might not use all these
+features. Indeed, such an interface should 1. be designed properly,
+and 2. not in the near future (currently we have other problems).
+
+Sebastian
+
+PS1: I'm currently not interested in working on something like that,
+it was just an idea. ;-)
+
+PS2: Counting characters is exotic enough that is reasonable to let
+the user save the page and start an other program. Trying to connect a
+webbrowser to all of the world is indeed quite idiotic. 
+
+
+
+Re: [Dillo-dev]Anchor : feature wish
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-25 11:03
+
+Le 25-Aug-2000, on m'a dit : 
+> Eric GAUDET wrote:
+> > Hi,
+> > I just thought about one (new idea?) feature about anchors : would
+> > it
+> > be possible to list them in a menu entry (Named "Chapters"?
+> > "Index"?
+> > "Content"?). Doing that, each time a page is loaded, this menu
+> > entry
+> > would be updated and the user could conveniently "jump" to anchors
+> > in
+> > the page without scrolling.
+> > 
+> > What do you think ?
+> 
+> That would be possible. But I think a menu of the anchors in a page
+> is not very useful. Better would be to list all the <h1>...<h6>.
+> That could also be possible by adding "pseudo anchors". If you get
+> a tag which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR
+> "@id" or so, where id is a unique number (unique in the page).
+> 
+
+ok, what about both, then (anchors and headings) ? Some of them can be
+duplicates (anchor are often used to link to pararaphs titles).
+And "Top of page" and "Bottom of page", even if not anchored, would be
+useful too.
+
+> Another idea: What about a mechanism to let the user ("user" is
+> anyone who does not changes the sources of dillo ;-) write such
+> things.
+> Perhaps plugins? The plugin transmits to dillo what is interesting
+> for it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id
+> for referring to the tags to the plugin. When a user clickes on an
+> item in the plugin's list, the plugin sends a url to dillo.
+> 
+
+That would mean calling _every_ (registered) plugin each time a page
+is loaded. Seems possible, but that can slow down thing.
+Registering the tags is interesting because dillo doesn't have to send
+the whole page, and the plugin doesn't have to parse html. But I'm not
+sure that's how plugins are supposed to work, though I'm still waiting
+for complete plugins specs (Jorge ?). 
+I mean : we'll have to change dillo's html parsing for that type of
+plugins ; what about a plugin wanting to count how many "e" there's in
+a page ? interesting, but we'll have to change dillo's sources for that.
+What about a pluggin wanting to scan images before rendered and censor
+those where there's too much "skin tones" ? interesting, but we'll have
+to change dillo's sources once again for that.
+The cleanest way would be to send each page to the pluggin, and wait for
+the plugin to render the page. The html parser could be a plugin : that
+way we could have a pdf-plugin, a rtf-plugin ... that would be nice.
+But that's not what we are doing : we are doing an html browser, and
+html source is intended to be in the browser, not sent to plugins.
+The way Jorge defined plugins (that can change) is clean and simple : a 
+plugin call looks like a link ("dpi://myplugin"), some datas are sent
+(name=value type), the plugin sends back an html page (and possibly ask
+dillo to update its menus, but there's no protocol for that yet, though
+I'm working on it). That's it. There's no two-way interaction between
+dillo and the plugins. There is no possibility for a plugin to ask dillo
+about its internals, such as page source, history.
+Albeit your module/plugin idea is interesting, that would mean a big
+rewrite in dillo's whole html parsing and plugin system (I know,
+it's not written yet) just to avoid small changes in dillo's menus and
+anchor (and H1..h6) parsing. 
+In a nutshell, I think it's better and easier to keep these things in
+dillo, until we define (not soon) a clear mecanisme for external
+modules, which aren't plugins.
+
+(man, _that's_ a long answer to a not very useful question ;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 25-Aug-2000 a 19:02:34
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]java in dillo
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 09:58
+
+Sean 'Shaleh' Perry wrote:
+> 
+> On 25-Aug-2000 Eric GAUDET wrote:
+> > Hi again,
+> > Anybody working on applets in Dillo ? I wondered if it was possible for
+> > dillo to launch the 'appletviewer' program (from a separate JDK) and
+> > then "swallow" its windows to render the initial html page (just like
+> > wharf, dock or gnome/kde pannel do with dockable applets).
+> >
+> > I don't think I'll see that soon, but that could be fairly doable.
+> >
+> 
+> I doubt this will work. swallowed apps work because of an agreement between
+> the app and the window manager / panel.
+
+Furthermore, communication between applet and browser (class
+AppletContext) will not be possible. Perhaps Kaffe or Japhar can be
+used somehow.
+
+> What we probably need to do is have a
+> widget which is an arbitrary window. Then java, javascript, embedded
+> <objects>, animations, etc can be placed in this widget.
+
+Perhaps look at GtkSocket/GtkPlug. They provide a mechanism to embed
+windows created by other programs.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Anchor : feature wish
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 09:58
+
+Eric GAUDET wrote:
+> Hi,
+> I just thought about one (new idea?) feature about anchors : would it
+> be possible to list them in a menu entry (Named "Chapters"? "Index"?
+> "Content"?). Doing that, each time a page is loaded, this menu entry
+> would be updated and the user could conveniently "jump" to anchors in
+> the page without scrolling.
+> 
+> What do you think ?
+
+That would be possible. But I think a menu of the anchors in a page is
+not very useful. Better would be to list all the <h1>...<h6>. That
+could also be possible by adding "pseudo anchors". If you get a tag
+which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR "@id"
+or so, where id is a unique number (unique in the page).
+
+Another idea: What about a mechanism to let the user ("user" is anyone
+who does not changes the sources of dillo ;-) write such things.
+Perhaps plugins? The plugin transmits to dillo what is interesting for
+it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id for
+referring to the tags to the plugin. When a user clickes on an item in
+the plugin's list, the plugin sends a url to dillo.
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]java in dillo
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-25 04:17
+
+On 25-Aug-2000 Eric GAUDET wrote:
+> Hi again,
+> Anybody working on applets in Dillo ? I wondered if it was possible for
+> dillo to launch the 'appletviewer' program (from a separate JDK) and
+> then "swallow" its windows to render the initial html page (just like
+> wharf, dock or gnome/kde pannel do with dockable applets).
+> 
+> I don't think I'll see that soon, but that could be fairly doable.
+> 
+
+I doubt this will work. swallowed apps work because of an agreement between
+the app and the window manager / panel. What we probably need to do is have a
+widget which is an arbitrary window. Then java, javascript, embedded
+<objects>, animations, etc can be placed in this widget. 
+
+
+
+[Dillo-dev]java in dillo
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-25 04:10
+
+Hi again,
+Anybody working on applets in Dillo ? I wondered if it was possible for
+dillo to launch the 'appletviewer' program (from a separate JDK) and
+then "swallow" its windows to render the initial html page (just like
+wharf, dock or gnome/kde pannel do with dockable applets).
+
+I don't think I'll see that soon, but that could be fairly doable.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 25-Aug-2000 a 13:06:05
+---------------------------------- 
+
+
+
+[Dillo-dev]Anchor : feature wish
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-25 04:06
+
+Hi,
+I just thought about one (new idea?) feature about anchors : would it
+be possible to list them in a menu entry (Named "Chapters"? "Index"?
+"Content"?). Doing that, each time a page is loaded, this menu entry
+would be updated and the user could conveniently "jump" to anchors in
+the page without scrolling.
+
+What do you think ?
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 25-Aug-2000 a 12:59:58
+---------------------------------- 
+
+
+
+[Dillo-dev]another fun test site
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-24 20:09
+
+validator.w3.org
+
+This takes a web site and shows how valid its HTML is. Also can include the
+parse tree of the document.
+
+dillo currently fails to lay out the results properly. 
+
+
+
+[Dillo-dev]Dw -> Gtk
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-24 16:34
+
+Hi!
+
+There is a problem (and an idea on its solution) with Gtk+:
+
+A rule of Gtk+ is, that widgets have to deal with any size allocation,
+but some of the Dw widgets depend on a more complicated size
+negotiation, which is currently done by a_Dw_size_nego_x, e. g.:
+
+- DwPage, which should always allocate the size needed to display all
+the text,
+- the not-yet-written table widget, comparable to DwPage, and
+- DwImage's with relative size (?).
+
+I've thought about several ways, the one I prefer is this:
+
+Such widgets do not simply accept the GtkAllocation in
+gtk_xxx_size_allocate, but correct it before storing it in
+widget->allocation. The standard Gtk+ containers do not refer to these
+corrected allocations, but to those they have calculated for there
+children, so you get either unintended spaces or overlapping widgets.
+So, dillo's new containers (e. g. the table) should use these
+"reallocations".
+
+I've tested it by writing a few useless widgets, and it works.
+
+Some alternatives which have also come to my mind:
+
+- Derive all widgets from one base widget GtkDwWidget which has a
+functionality similar to a_Dw_size_nego_x. A container could do some
+thing like this:
+
+if (GTK_IS_DW_WIDGET (child)) {
+/* use the functionality of GtkDwWidget */
+} else {
+/* standard size allocation */
+}
+
+Since Gtk+ does not provide multiple inheritance, there will be the
+problem which base class to use for GtkDwBase. E.g., should images be
+containers? Deriving from and so reusing other Gtk+ widgets will be
+impossible.
+
+- Children resize themselves on a size allocation. This is somehow
+possible (I once wrote something like this), but this will result in a
+horrible overhead.
+
+Comments?
+
+Sebastian 
+
+
+
+[Dillo-dev]still some concerns about HR tag
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-23 13:46
+
+Hi, I just tested the HR "bug-fix" in dillo v0.2.4 : the line's width
+is the page's width all right. But the horizontal page slider is still
+there !!! (you can scroll to see the emptyness in the right)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Aug-2000 a 22:42:31
+"Si la japonaise est la négation la plus aboslue de la femme,
+elle est aussi la négation la plus absolue de la beauté grecque."
+(Louis Martin, l'Anglais est-il un juif ?, 1895)
+---------------------------------- 
+
+
+
+[Dillo-dev]style sheets
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-23 07:02
+
+So, was driving home tonight and an idea hit me.
+
+Style sheets are meant to be cascading (they stack). So, we can implement user
+preferences as local style sheets which come first (highest) or last based on
+settings. The allow_whitebg becomes a simple style sheet line.
+
+Properly implementing font and what not will require some ground work and if I
+am doing that, I may as well look to the future.
+
+Comments? 
+
+
+
+RE: [Dillo-dev]other requests
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-23 06:59
+
+> 
+> And the same thing when going to http://www.mysite.org/ and the browser
+> popups-up a window asking for your login and password. (the http side
+> is the same, basically you have to encode in base64 the string
+> "user:password" and send that in the http request)
+> 
+
+right
+
+Playing with <font> right now and pondering style sheets. Need to set up a
+local http server to play with http auth, cgi, and the like. 
+
+
+
+RE: [Dillo-dev]other requests
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-23 03:35
+
+Le 22-Aug-2000, on m'a dit : 
+> > 
+> > I mean http auth, as in http://user:password@ww.../
+> > 
+> 
+> the URL parser needs to understand this. Then the proper http send
+> mechanism
+> needs to be used. I do not think this would be too hard. Now I
+> have two
+> reasons to read the HTTP spec.
+> 
+
+And the same thing when going to http://www.mysite.org/ and the browser
+popups-up a window asking for your login and password. (the http side
+is the same, basically you have to encode in base64 the string
+"user:password" and send that in the http request)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Aug-2000 a 12:31:30
+---------------------------------- 
+
+
+
+[Dillo-dev]currently working on <font>
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-23 01:39
+
+I have an initial implementation of <font> put together. It currently only
+handles the color attribute, but more to come. My current problem is that when
+the tag is popped, the color is not reset. I am confused, the rest of the font
+like tags (bold, cite) clean up after themselves by simply popping their tag. 
+Will get it when I get a chance. 
+
+
+
+Re: [Dillo-dev]0.2.4 release
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 22:27
+
+Hi, Sean,
+
+Sean 'Shaleh' Perry wrote:
+> 
+> >
+> > 2. The better way: Leave "not-reloading" enabled, but push the url's
+> > on the stack "by hand". See the "else" part of "if (must_load)". I
+> > tried to implement it, bud didn't understand how. I think it is done
+> > in a_Nav_expect_done, but calling it (or a modified version of it)
+> > didn't work. This is an other point worth to improve.
+> >
+> 
+> enclosed is the beginnings of this patch. If I go to foo.html, then follow
+> foo.html#link, then hit back, I get to foo.html. However if I go to
+> foo.html#second from foo.html#link, then hit back I still go to foo.html. Not
+> quite sure how the anchor system works. Maybe you can take the code and go
+> from there.
+
+My changes in the Nav module only consist of a few lines. Most of my
+code is in GtkDwScroller and DwPage. Furthermore, I did not understand
+the navigation mechanism very good, so perhaps someone else should
+work on this problem.
+
+BTW: I sent Jorge some documentation, I think, he should include it
+into the release.
+
+> The patch is longer than it needs to be because I moved Nav_open_url to the end
+> of the file and places a declaration at the top so the other functions know
+> about it. This mimics the layout of the other source modules.
+
+What about including "nav.h" in "nav.c"? That would also let the
+compiler check the function prototypes against there definitions.
+
+> I think there is something wrong with calling a_Foo_bar() in module Foo.
+
+Yes, propably there should be a seperate function, which is called by
+Nav_open_url and a_Nav_expect_done.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]weird bug in anchor code
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 21:24
+
+Jorge Arellano Cid wrote:
+> 
+> Sean,
+> 
+> > http://www.gphoto.org/news.html
+> >
+> > The GNU Public License link points to http://www.gnu.org, but dillo
+> > thinks it points to http://www.gphoto.org.
+> 
+> Fixed! (BUG #79)
+
+I wrote:
+> [...]
+
+Ok, 5 minutes of wasted time. ;-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]weird bug in anchor code
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 21:19
+
+Sean 'Shaleh' Perry wrote:
+> 
+> http://www.gphoto.org/news.html
+> 
+> The GNU Public License link points to http://www.gnu.org, but dillo
+> thinks it points to http://www.gphoto.org.
+
+The html file looks like this:
+
+<a href=
+">
+
+When there are whitespaces after the attribute name, Html_get_attr
+returns an empty string, and so a_Url_resolve_relative returns the
+wrong url.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]weird bug in anchor code
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-22 20:50
+
+Sean,
+
+
+> http://www.gphoto.org/news.html
+> 
+> The GNU Public License link points to http://www.gnu.org, but dillo
+> thinks it points to http://www.gphoto.org.
+
+Fixed! (BUG #79) 
+
+
+
+Re: [Dillo-dev]0.2.4 release
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 19:22
+
+Attachments: nav.patch      
+
+> 
+> 2. The better way: Leave "not-reloading" enabled, but push the url's
+> on the stack "by hand". See the "else" part of "if (must_load)". I
+> tried to implement it, bud didn't understand how. I think it is done
+> in a_Nav_expect_done, but calling it (or a modified version of it)
+> didn't work. This is an other point worth to improve.
+> 
+
+enclosed is the beginnings of this patch. If I go to foo.html, then follow
+foo.html#link, then hit back, I get to foo.html. However if I go to
+foo.html#second from foo.html#link, then hit back I still go to foo.html. Not
+quite sure how the anchor system works. Maybe you can take the code and go
+from there.
+
+The patch is longer than it needs to be because I moved Nav_open_url to the end
+of the file and places a declaration at the top so the other functions know
+about it. This mimics the layout of the other source modules.
+
+I think there is something wrong with calling a_Foo_bar() in module Foo. 
+
+
+
+RE: [Dillo-dev]other requests
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 18:10
+
+> 
+> I mean http auth, as in http://user:password@ww.../
+> 
+
+the URL parser needs to understand this. Then the proper http send mechanism
+needs to be used. I do not think this would be too hard. Now I have two
+reasons to read the HTTP spec. 
+
+
+
+Re: [Dillo-dev]the source viewer widget
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 18:08
+
+On 22-Aug-2000 Sebastian Geerken wrote:
+> Sean 'Shaleh' Perry wrote: 
+>> I tried to add horizontal scrollbars to the GtkText widget in
+>> a_Commands_viewsource(). For whatever reason, they are not used. Passing
+>> them
+>> into the constructor of GtkText has no effect. Even with the policy set to
+>> ALWAYS the scrollbar is shown but does not actually function.
+> 
+> I assume you want to enable horizontal scrolling and disable line
+> wrapping?
+> 
+> You can do this by calling gtk_text_set_line_wrap (text, FALSE), but
+> horizontal adjustment isn't working correctly now. This is a bug of
+> Gtk+, and it will propably fixed soon (or perhaps is already), so you
+> should not care about it (or fix this bug in Gtk+ :-).
+> 
+
+well i feel better. I did all the line_wrap, word_wrap calls. 
+
+
+
+RE: [Dillo-dev]0.2.4 release
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 18:08
+
+On 22-Aug-2000 Jorge Arellano Cid wrote:
+> 
+> 
+> On Mon, 21 Aug 2000, Sean 'Shaleh' Perry wrote:
+> 
+>> we need a "DNS not found" message in the GUI
+>> 
+>> If the DNS resolver has problems, the user has no feed back on why
+> 
+> Actually there's a message in the status window.
+> Maybe not enough, but not nonexistent.
+> 
+
+yesterday I could not reach gtk.org, lots of IO_Abort messages on a terminal. 
+But the GUI gave no indication. I hit Stop, then tried again and I could not
+tell it was doing anything except for more abort messages on the term. 
+
+
+
+Re: [Dillo-dev]Dw vs. Gtk
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 17:09
+
+Jorge Arellano Cid wrote:
+> If you want to join in this effort, that's all I need to get
+> started.
+
+If it's ok, I'll start with DwPage, because I have some ideas on it
+(I'll post to the list when something gets useful).
+
+(Starting with DwPage doesn't make much sense, since I'll have to
+deactivate the adding of Dw widgets. ;-)
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]0.2.4 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-22 14:36
+
+On Mon, 21 Aug 2000, Sean 'Shaleh' Perry wrote:
+
+> we need a "DNS not found" message in the GUI
+> 
+> If the DNS resolver has problems, the user has no feed back on why
+
+Actually there's a message in the status window.
+Maybe not enough, but not nonexistent.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dw vs. Gtk
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 13:58
+
+Jorge Arellano Cid wrote:
+> [...]
+> > I'm interrested in implementing tables, and the simplest approach is
+> > propably nesting of DwPage's. I have already played around with it
+> > (nothing directly useful, but only to test how it could work), and got
+> > results which are not what I intended, but --- you can see something
+> > ;-)
+> 
+> Yes, but we have Dw widgets in the way (some not instantiable
+> some not nesting well).
+
+No, I meant something different: I extended DilloHtml by a stack for
+DwPage's, so that parts of the same html doc can be written in
+different DwPage's (this is needed for tables). This works mainly, so
+I think it's a useful approach.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]0.2.4 release
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 13:08
+
+Sean 'Shaleh' Perry wrote:
+> The back option after following an anchor takes me to the last page loaded,
+> not
+> the location I was at before I followed the anchor.
+
+There are two different ways to change it:
+
+1. Force reloading in Nav_open_url. (Set a "must_reload = TRUE" before
+"if (must_load)" or so.) Then the page will be reloaded always, so
+*all* url's will be pushed on the navigation stack. (Reloading will be
+quite fast. :-)
+
+2. The better way: Leave "not-reloading" enabled, but push the url's
+on the stack "by hand". See the "else" part of "if (must_load)". I
+tried to implement it, bud didn't understand how. I think it is done
+in a_Nav_expect_done, but calling it (or a modified version of it)
+didn't work. This is an other point worth to improve.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]the source viewer widget
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 13:08
+
+Sean 'Shaleh' Perry wrote: 
+> I tried to add horizontal scrollbars to the GtkText widget in
+> a_Commands_viewsource(). For whatever reason, they are not used. Passing
+> them
+> into the constructor of GtkText has no effect. Even with the policy set to
+> ALWAYS the scrollbar is shown but does not actually function.
+
+I assume you want to enable horizontal scrolling and disable line
+wrapping?
+
+You can do this by calling gtk_text_set_line_wrap (text, FALSE), but
+horizontal adjustment isn't working correctly now. This is a bug of
+Gtk+, and it will propably fixed soon (or perhaps is already), so you
+should not care about it (or fix this bug in Gtk+ :-).
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]other requests
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-22 05:54
+
+Le 22-Aug-2000, on m'a dit : 
+> 
+> On 22-Aug-2000 Eric GAUDET wrote:
+> > Le 22-Aug-2000, on m'a dit : 
+> >> animated gif support
+> >> 
+> >> improved font support
+> >> 
+> >> cookies
+> >> 
+> > 
+> > And basic html authetification too.
+> > 
+> 
+> do you mean SSL kinda stuff? http auth? or actual "this is good
+> HTML"?
+> 
+
+I mean http auth, as in http://user:password@ww.../
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 22-Aug-2000 a 14:53:52
+---------------------------------- 
+
+
+
+[Dillo-dev]weird bug in anchor code
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 05:28
+
+http://www.gphoto.org/news.html
+
+The GNU Public License link points to http://www.gnu.org, but dillo
+thinks it points to http://www.gphoto.org. 
+
+
+
+RE: [Dillo-dev]other requests
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 05:13
+
+On 22-Aug-2000 Eric GAUDET wrote:
+> Le 22-Aug-2000, on m'a dit : 
+>> animated gif support
+>> 
+>> improved font support
+>> 
+>> cookies
+>> 
+> 
+> And basic html authetification too.
+> 
+
+do you mean SSL kinda stuff? http auth? or actual "this is good HTML"? 
+
+
+
+RE: [Dillo-dev]other requests
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-22 05:10
+
+Le 22-Aug-2000, on m'a dit : 
+> animated gif support
+> 
+> improved font support
+> 
+> cookies
+> 
+
+And basic html authetification too.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 22-Aug-2000 a 14:07:36
+---------------------------------- 
+
+
+
+[Dillo-dev]other requests
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 04:30
+
+animated gif support
+
+improved font support
+
+cookies 
+
+
+
+Re: [Dillo-dev]GTK 1.3.1
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 04:28
+
+> May I suggest one of the following:
+> 
+> * BUG#27: Client side image maps
+> * BUG#62: Horizontal rules (50% already done)
+> * BUG#60: Png's transparent backgrounds
+> * <DIV> tag?
+> 
+
+div is only truly useful once we support style sheets. Until then it has no
+meaning (it is like event boxes without events otherwise).
+
+Another would be to make dillo properly display numbered lists. Currently too
+many newlines are shown. Compare netscape / mozilla / konqueror / whatever.
+
+Also, if code has:
+
+foo<br>
+<br>
+
+the first br is used, any immediately following are ignored. 
+
+
+
+RE: [Dillo-dev]0.2.4 release
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 00:31
+
+On 21-Aug-2000 Jorge Arellano Cid wrote:
+> 
+> Hi!
+> 
+> Dillo-0.2.4 is ready for download!
+> 
+> The guys at sourceforge managed to complicate file releases
+> even more; I hope they change it soon...
+> 
+
+The back option after following an anchor takes me to the last page loaded, not
+the location I was at before I followed the anchor. 
+
+
+
+RE: [Dillo-dev]0.2.4 release
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 00:27
+
+On 21-Aug-2000 Jorge Arellano Cid wrote:
+> 
+> Hi!
+> 
+> Dillo-0.2.4 is ready for download!
+> 
+> The guys at sourceforge managed to complicate file releases
+> even more; I hope they change it soon...
+> 
+
+we need a "DNS not found" message in the GUI
+
+If the DNS resolver has problems, the user has no feed back on why 
+
+
+
+[Dillo-dev]0.2.4 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 16:51
+
+Hi!
+
+Dillo-0.2.4 is ready for download!
+
+The guys at sourceforge managed to complicate file releases
+even more; I hope they change it soon...
+
+Anyway, the file is there.
+
+Enjoy!
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dw vs. Gtk
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 01:28
+
+Sebastian,
+
+> What is the current state in:
+> 
+> 1. the question "Replace the Dw widgets by Gtk+ widgets or not?", and
+> 2. tables?
+
+Basically what I wrote in 'DilloWidget.txt' (within /doc dir).
+I was expecting some help to start porting back Dw to GTK+
+(unless a better approach was pointed out).
+
+> I'm interrested in implementing tables, and the simplest approach is
+> propably nesting of DwPage's. I have already played around with it
+> (nothing directly useful, but only to test how it could work), and got
+> results which are not what I intended, but --- you can see something
+> ;-)
+
+Yes, but we have Dw widgets in the way (some not instantiable
+some not nesting well).
+
+> There should propably a widget for tables 
+
+Of course!
+
+> [...]
+
+Looks quite similar to DilloWidget.txt!
+
+> So, what is currently planned on this topic?
+
+A question to Peter Mattis for advice on the table widget
+implementation, and to start by porting back Dw to GTK+, and
+finally, to work the table widget.
+
+If you want to join in this effort, that's all I need to get
+started.
+BTW: I wrote the widget documentation with a view to help it
+happen ;-)
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]GTK 1.3.1
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 01:17
+
+Jörgen,
+
+> Hi all!
+> 
+> I recently downloaded the devel branch of GTK and tried it with Dillo. I'm 
+> pleased to see that the exposure problems are not there anymore. I could 
+> remove the event boxes from the checkboxes and radio buttons.
+
+!!???
+Funny, I always thought that the problem was with Dw. Even
+more, the event boxes were designed for widgets lacking a window,
+just a the ones we had.
+
+Unless the new GTK+ provides a default window for every widget,
+I'm a little puzzled with this.
+
+> There were no problems porting the code either.
+
+Let's keep the event boxes for now (it will be a long time
+until updating makes 1.3.1 the default GTK+).
+
+> PS. I really need something to code on instead of writing stuff like this 
+> ;-)
+
+May I suggest one of the following:
+
+* BUG#27: Client side image maps
+* BUG#62: Horizontal rules (50% already done)
+* BUG#60: Png's transparent backgrounds
+* <DIV> tag?
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]dillo can't read pngs on gphoto.org
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 01:16
+
+Sean,
+
+> So, I was making dillo ignore the text between SCRIPT tags (it puts them in the
+> stash, then ignores the stash)
+
+Good!
+
+> I was looking for test sites. gphoto.org is a
+> good one. It uses roll overs and what not for fancy browsing. While looking
+> around the site I notice that dillo often fails to render the pngs it find
+> there. Anyone mind looking at this and suggesting why?
+
+This is BUG#4. 
+I went to gphoto with 0.2.4 and everything was OK.
+
+Anyway, I'm planning to release 0.2.4 tomorrow in the morning!
+
+Jorge.- 
+
+
+
+[Dillo-dev]the source viewer widget
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-21 00:27
+
+I tried to add horizontal scrollbars to the GtkText widget in
+a_Commands_viewsource(). For whatever reason, they are not used. Passing them
+into the constructor of GtkText has no effect. Even with the policy set to
+ALWAYS the scrollbar is shown but does not actually function. 
+
+
+
+[Dillo-dev]dillo can't read pngs on gphoto.org
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-20 21:45
+
+So, I was making dillo ignore the text between SCRIPT tags (it puts them in the
+stash, then ignores the stash) I was looking for test sites. gphoto.org is a
+good one. It uses roll overs and what not for fancy browsing. While looking
+around the site I notice that dillo often fails to render the pngs it find
+there. Anyone mind looking at this and suggesting why?
+
+On the SCRIPT reading, the stash is a great thing. When we get around to
+adding script support, we just pass the stash to the interpreter. 
+
+
+
+[Dillo-dev]GTK 1.3.1
+
+From: Jörgen Viksell <vsksga@ho...> - 2000-08-19 23:32
+
+Hi all!
+
+I recently downloaded the devel branch of GTK and tried it with Dillo. I'm 
+pleased to see that the exposure problems are not there anymore. I could 
+remove the event boxes from the checkboxes and radio buttons.
+There were no problems porting the code either.
+
+PS. I really need something to code on instead of writing stuff like this 
+;-)
+
+// Jörgen
+________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com 
+
+
+
+Re: [Dillo-dev]Question
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-19 20:22
+
+Okki,
+
+> Hi,
+> 
+> Can we have a CVS (read only ?) acces for the sources ?
+> 
+> Thanx
+
+This is a good idea, and we have the possibility to set it up
+in sourceforge. The problem is with me, not savvy in CVS and too
+busy to be in charge of it. Anyway, if the volunteer arises, no
+problem.
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-19 20:21
+
+Sean,
+
+> >> Alternatively, what do you think about getting rid of the location
+> >> window and Ctrl-L fucing the cursor to the location bar?
+
+Just as Andrew pointed out, the idea is to move the text cursor
+
+> one use most browsers give their location window is a file chooser so it is
+> easy to browse local html directories, like those in library docs. dillo
+> currently has no way to do this and removing the location window would give no
+> obvious place to put this functionality.
+
+There's a way: File | Open File. (Ctrl-O)
+Unfortunately, the shortcut-keys code is somewhat buggy and
+needs a revision.
+
+Anyway, you can type 'file:' in the location bar.
+
+Maybe I'll let everyone test the feature with Ctrl-N (New),
+having the same functionallity of the "NEW" button.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]I18n
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-19 20:21
+
+Sebastian,
+
+> Jorge Arellano Cid wrote:
+> > Personally, I hate internationalization. (This is just my
+> > personal feel on the subject).
+> > [...]
+> 
+> I, personally, cannot confirm this, my experiences with traductions
+> (into german) are quite good.
+
+Germans are serious people! :-)
+
+> [...]
+> Of course, any other tasks, mainly writing the .po files (the message
+> tables), currently have very low priority.
+
+Let's work the code base for tables. I'll answer your post ASAP
+(basically I also think better to lean on GTK+).
+
+> > I think that if we
+> > manage to provide those "mission critical" ones, a growing
+> > community will provide patches for the others; but if we fail
+> > with the critical ones, the whole project could get stuck and ...
+> 
+> >From this point of view, you are right: after a specific point
+> (assumed it will be reached), productivity somehow grows. (Why is it
+> not possible to use "quasi" as an adverb in english? ;-)
+
+Hmmmm, sometimes they use 'almost', and certainly some of those
+prefer to express it in a ironic way! ;)
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Dw vs. Gtk
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-19 16:26
+
+Le 19-Aug-2000, on m'a dit : 
+> I'm interrested in implementing tables, 
+...
+> It could be implemented as Dw or as Gtk+ widget. The latter would
+> have following effects:
+> 
+> - It would be simpler to write, since I know Gtk+ better that Dw
+> (and there are much more examples :-)
+> 
+....
+> 
+> So, what is currently planned on this topic?
+> 
+> Sebastian
+> 
+
+I guess you're elected to implement tables in dillo : congratulations
+;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 20-Aug-2000 a 01:22:35
+---------------------------------- 
+
+
+
+[Dillo-dev]Dw vs. Gtk
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-19 09:26
+
+What is the current state in:
+
+1. the question "Replace the Dw widgets by Gtk+ widgets or not?", and
+2. tables?
+
+I'm interrested in implementing tables, and the simplest approach is
+propably nesting of DwPage's. I have already played around with it
+(nothing directly useful, but only to test how it could work), and got
+results which are not what I intended, but --- you can see something
+;-)
+
+There should propably a widget for tables (I think it should be
+written from scratch, since the Gtk+ containers do not exactly provide
+the functionality for this problem). It could be implemented as Dw or
+as Gtk+ widget. The latter would have following effects:
+
+- It would be simpler to write, since I know Gtk+ better that Dw (and
+there are much more examples :-)
+
+- Perhaps the table widget should itself contain Gtk+ widgets. So,
+until DwPage gets gtk'd (or not), there is a wrapper widget needed as
+container for DwPage. Currently, only GtkDwView may contain a Dw
+widget, but cannot be used for this case.
+
+- One function of Dw is not provided by Gtk+: changing only one
+dimension (normally the width), which then affects the other. This had
+to be added.
+
+- The well known problems would be eliminated.
+
+So, what is currently planned on this topic?
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]I18n
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-19 09:26
+
+Hi, Jorge!
+
+Jorge Arellano Cid wrote:
+> Personally, I hate internationalization. (This is just my
+> personal feel on the subject).
+> 
+> This mostly because:
+> 
+> - I understand english!
+> 
+> - Living in a spanish-speaking country, had brought several
+> nasty experiences related with it. Bad traductions,
+> missconfigured systems, and impossible to understand spanish
+> books.
+> [...]
+
+I, personally, cannot confirm this, my experiences with traductions
+(into german) are quite good. But I think this is no point. (You are
+free to unset your $LANG variable ;-)
+
+> I can also see several tasks (like this one, download
+> implementation, etc), that can be added easily, my main concerns
+> are not with them but with those that can affect the whole
+> project (as not being able to render tables).
+
+I only meant to prepare dillo, i. e. only include "_" and "_N". I
+personally think, it should always be included from the beginning,
+since it gets quite hard to add it to an existing project. Then use of
+"_" and "_N" is quite simple (assumed you remember it ;-).
+
+Of course, any other tasks, mainly writing the .po files (the message
+tables), currently have very low priority.
+
+> I think that if we
+> manage to provide those "mission critical" ones, a growing
+> community will provide patches for the others; but if we fail
+> with the critical ones, the whole project could get stuck and ...
+
+From this point of view, you are right: after a specific point
+(assumed it will be reached), productivity somehow grows. (Why is it
+not possible to use "quasi" as an adverb in english? ;-)
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-19 00:39
+
+>> 
+>> Alternatively, what do you think about getting rid of the location
+>> window and Ctrl-L fucing the cursor to the location bar?
+> 
+> Cool!
+> 
+> Is it OK with you Sean?
+> 
+
+one use most browsers give their location window is a file chooser so it is
+easy to browse local html directories, like those in library docs. dillo
+currently has no way to do this and removing the location window would give no
+obvious place to put this functionality. 
+
+
+
+[Dillo-dev]Question
+
+From: Okki <okki@wa...> - 2000-08-18 22:46
+
+Hi,
+
+Can we have a CVS (read only ?) acces for the sources ?
+
+Thanx 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Andrew McPherson <andrew@ma...> - 2000-08-17 19:35
+
+On Thu, 17 Aug 2000, Sean 'Shaleh' Perry wrote:
+
+> 
+> On 16-Aug-2000 Jorge Arellano Cid wrote:
+> > 
+> > Eric,
+> > 
+> >> Le 15-Aug-2000, on m'a dit : 
+> >> > > Anyway, we can get rid of the open
+> >> > > location window (because the location bar provides the same
+> >> > > functionality).
+> >> > > Comments?
+> >> > > 
+> >> > 
+> >> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and
+> >> > never move
+> >> > my mouse.
+> >> > 
+> >> 
+> >> Alternatively, what do you think about getting rid of the location
+> >> window and Ctrl-L fucing the cursor to the location bar?
+> > 
+> > Cool!
+> > 
+> > Is it OK with you Sean?
+> > 
+> 
+> Hey, it's your project. I was always told to never move the mouse. How about
+> testing this feature and leaving the other code #if 0'ed out?
+> 
+
+Sorry to jump in on the conversation. I haven't posted anything in a
+while.
+
+I think he means move the text cursor to the location bar, not the mouse
+pointer. Moving the mouse pointer would be a bit strange- it reminds me of
+hitting the "start menu" button on Windows keyboards. Ugh. Moving the text
+cursor would be nice, though, as long as it selected the current location.
+That way I could still do Ctl-L, then type, without having to manually
+delete the existing location.
+
+Just my $.02
+
+-Andrew 
+
+
+
+Re: [Dillo-dev]I18n
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-17 18:58
+
+> 
+> I can also see several tasks (like this one, download
+> implementation, etc), that can be added easily, my main concerns
+> are not with them but with those that can affect the whole
+> project (as not being able to render tables). I think that if we
+> manage to provide those "mission critical" ones, a growing
+> community will provide patches for the others; but if we fail
+> with the critical ones, the whole project could get stuck and ...
+> 
+
+the html renderer should render the page in whatever language it was told the
+page was. More on this as I (we) add <meta> tag and HTML 4.x support.
+
+The part we care about for code is the actual gui -- i.e. menus, buttons, etc. 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-17 18:53
+
+On 16-Aug-2000 Jorge Arellano Cid wrote:
+> 
+> Eric,
+> 
+>> Le 15-Aug-2000, on m'a dit : 
+>> > > Anyway, we can get rid of the open
+>> > > location window (because the location bar provides the same
+>> > > functionality).
+>> > > Comments?
+>> > > 
+>> > 
+>> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and
+>> > never move
+>> > my mouse.
+>> > 
+>> 
+>> Alternatively, what do you think about getting rid of the location
+>> window and Ctrl-L fucing the cursor to the location bar?
+> 
+> Cool!
+> 
+> Is it OK with you Sean?
+> 
+
+Hey, it's your project. I was always told to never move the mouse. How about
+testing this feature and leaving the other code #if 0'ed out? 
+
+
+
+Re: [Dillo-dev]I18n
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:11
+
+Sebastian,
+
+> Hi!
+> 
+> When dillo is supposed to be used by end users (in the future ;-),
+> perhaps we should start to internationalize it. Soon, because it gets
+> more difficult the more the project advances. From the view of a
+> programmer, gettext is quite simple to use (and can easily be
+> deactivated on systems on which it is not supported).
+> [...]
+> What do you think about this?
+
+Personally, I hate internationalization. (This is just my
+personal feel on the subject).
+
+This mostly because:
+
+- I understand english!
+
+- Living in a spanish-speaking country, had brought several
+nasty experiences related with it. Bad traductions,
+missconfigured systems, and impossible to understand spanish
+books.
+
+...............................................................
+For instance:
+
+'case sensitive' : "sensible al caso". (awful!)
+("hace diferencia entre mayúsculas y
+minúsculas" is the right one)
+
+'Save' : 'Salvar' (to escape danger! instead of 'Grabar')
+
+'Do you want to delete (Y/N)'
+'Desea borrar el archivo (S/N)'
+You got to answer 'Y' to get the job done!
+
+Not to mention the big mess with Hotkeys (not mnemonic anymore)
+
+Translated manpages on missconfigured terminals:
+'había un niño' becomes 'hab<ED>a un ni<F1>o'
+(this is a big problem when you're not root)
+
+Finally, when traductions are larger (in characters) than the
+original sentences, they often render truncated.
+...............................................................
+
+
+I'm not against been understood in other languajes, is just
+that my experiences are bad with it, except when the SW authors
+include their own support (i.e. they provide the translations,
+menu arrangements, new hotkeys and things like that).
+
+I can also see several tasks (like this one, download
+implementation, etc), that can be added easily, my main concerns
+are not with them but with those that can affect the whole
+project (as not being able to render tables). I think that if we
+manage to provide those "mission critical" ones, a growing
+community will provide patches for the others; but if we fail
+with the critical ones, the whole project could get stuck and ...
+
+
+Jorge.-
+
+--
+
+Ps: The guys from Intel (Taiwan) told me that dillo was ported
+to the StrongARM-110 and StrongARM-11x0 boards. 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:11
+
+Eric,
+
+> Le 15-Aug-2000, on m'a dit : 
+> > > Anyway, we can get rid of the open
+> > > location window (because the location bar provides the same
+> > > functionality).
+> > > Comments?
+> > > 
+> > 
+> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and
+> > never move
+> > my mouse.
+> > 
+> 
+> Alternatively, what do you think about getting rid of the location
+> window and Ctrl-L fucing the cursor to the location bar?
+
+Cool!
+
+Is it OK with you Sean?
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Html Parser
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:10
+
+Sebastian,
+
+> Is there any reason for a separate function list F_list in html.c. Why
+> are the functions not directly integrated in the Tags list (static
+> TagInfo Tags[NTAGS])?
+
+Once upon a time there was one, but I don't remember it now! ;)
+
+Sean provided me with a patch for that, so consider it done.
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:10
+
+Sean,
+
+> In previous projects, smaller patches over time were easier to get applied
+> than one giant "I changed everything" patch. But each group is different.
+
+My point is that as each patch modified the former, I had to
+study them all. (And YES, I also prefer small patches).
+
+> [...]
+> > I found a better place that needs a single call to the entity
+> > parsing function. Not implemented yet, but if it works, I'll keep
+> > it.
+> > 
+> 
+> that would be cool, I have not quite understood all that is html.c
+
+Well, it seems I'll keep the old scheme. The entities parsing
+could have been handled in Html_write, but that requires to show
+unsupported tags as words (not bad, but the standar advices to
+ignore them).
+
+> >> loading large images is rather slow, I noticed this on screen
+> >> shot pages
+>
+> > Maybe due to ...
+> 
+> nope, simply going to some guys web page with a 1200x100 screen shot.
+
+I guess you are comparing the time with another browser...
+There's a tricky way to speed up image transfers on slow
+networks: If you get a Content-Length tag from the web server,
+you can use HTTP1.1 to open new connections to start retrieving
+partial chunks of unreceived data...
+
+I remember that sometime ago I started donloading a big image
+with Netscape and after a while, started dillo to do the same;
+dillo finished first and Netscape took a lot more to finish (Not
+only Network traffic, also the specific HTTP-connection can be
+significant sometimes).
+
+> the bug about http://www.hotmail.com seems to be a POST is improperly supported bug. 
+> I will have to set up a cgi and test it more thoroughly.
+
+Not the server expecting a cookie? (unsuported in dillo)
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]I18n
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-15 11:25
+
+Hi!
+
+When dillo is supposed to be used by end users (in the future ;-),
+perhaps we should start to internationalize it. Soon, because it gets
+more difficult the more the project advances. From the view of a
+programmer, gettext is quite simple to use (and can easily be
+deactivated on systems on which it is not supported).
+
+I do not mean to start writing .po files, but simply prepare dillo by
+using the "_" and "_N" macros, and define them as
+
+#define _(s) (s)
+#define _N(s) (s)
+
+somewhere. Then, use of these macros should become part of the coding
+standards. After this, the following tasks could be done later:
+
+- adding calls of setlocale() and textdomain(), and
+- writing .po files.
+
+What do you think about this?
+
+Sebastian. 
+
+
+
+[Dillo-dev]Html Parser
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-15 10:42
+
+Hi!
+
+Is there any reason for a separate function list F_list in html.c. Why
+are the functions not directly integrated in the Tags list (static
+TagInfo Tags[NTAGS])?
+
+Sebastian. 
+
+
+
+[Dillo-dev]Dillo on StrongARM
+
+From: <chester@li...> - 2000-08-15 10:34
+
+Hi all,
+I am glad to let you know that,dillo is port to StrongARM-110 and
+StrongARM-11x0 board.
+And I hope dillo will more strong!!
+
+
+Best regards,
+
+Chester 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-15 09:41
+
+Le 15-Aug-2000, on m'a dit : 
+> > Anyway, we can get rid of the open
+> > location window (because the location bar provides the same
+> > functionality).
+> > Comments?
+> > 
+> 
+> please keep it. This allows me to "Ctrl-L, http://foo, enter" and
+> never move
+> my mouse.
+> 
+
+Alternatively, what do you think about getting rid of the location
+window and Ctrl-L fucing the cursor to the location bar ? 
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Aug-2000 a 18:39:05
+---------------------------------- 
+
+
+
+RE: [Dillo-dev]Misc. answers.
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-15 08:47
+
+> 
+> From the four patches you sent on the same thing, I finally
+> kept the full entities list and used a libc binary search call.
+> There're some interesting points:
+> 
+> - All the isocodes in the list are not supported by current
+> font (Some of them don't render).
+> - Performance is a very relative subject here (commented below)
+> 
+> (more on this subject near the bottom)
+> 
+
+My apologies on the rapid patches. I am used to people who want them early. 
+Plus I get eager (-:
+
+I hope I did not actually send you four identical files, I seem to recall each
+adding onto the last. But yes, I could have held them and sent one big patch.
+
+In previous projects, smaller patches over time were easier to get applied than
+one giant "I changed everything" patch. But each group is different.
+
+>> {Sean}
+>> So, I used dillo some more today. yp.yahoo.com has a submit button whose
+>> text
+>> is: "Start&nbsp;Search". This is not handled by dillo either. So, I went
+>> thru
+>> and added Html_parse_entities() calls in a few more places. Now I need to
+>> handle the memory use associated with this, right now I am leaking small
+>> bits
+>> of memory. Once I get this sorted out I will send a new patch.
+> 
+> I found a better place that needs a single call to the entity
+> parsing function. Not implemented yet, but if it works, I'll keep
+> it.
+> 
+
+that would be cool, I have not quite understood all that is html.c
+
+>> {Sean}
+>> The open location window does not seem to set itself as a transient. 
+>> This causes several window managers to hide the window when it opens. It
+>> should load on top of the browser window. This window too could use some
+>> beautification.
+> 
+> Yes, that semms to be a bug. Anyway, we can get rid of the open
+> location window (because the location bar provides the same
+> functionality).
+> Comments?
+> 
+
+please keep it. This allows me to "Ctrl-L, http://foo, enter" and never move
+my mouse.
+
+>> loading large images is rather slow, I noticed this on screen
+>> shot pages
+> 
+> Mmmmm.... There's no special handling for image connections.
+> Maybe you were downloading another document while fetching the
+> page. This seems weird at the beginning, but it's possible!
+> 
+
+nope, simply going to some guys web page with a 1200x100 screen shot.
+
+>> {Sean}
+>> Also, as I mention on #70, dillo acts like it does POST but doesn't. I am
+>> reading the HTTP spec and looking at a proper implementation of this. If
+>> anyone else is looking at this, let me know.
+> 
+> I read your complaints on GET method too, the bug track engine
+> uses GET and I've used POST without any problems. I'm not saying
+> it's perfect, but can you be more specific please?
+> 
+
+the bug about http://www.hotmail.com seems to be a POST is improperly supported bug. 
+I will have to set up a cgi and test it more thoroughly.
+
+> 
+> Performance is a very relative subject here. Mainly because
+> entities are scarce in the average HTML page (a minimal ratio),
+> and because the Html_parse_entities function, returns without
+> any searching almost all of the time (when the word doesn't have
+> entities). 
+> 
+
+absolutely, however, I do go to sites where there is an entity on every line. 
+
+
+
+[Dillo-dev]Misc. answers.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-14 22:16
+
+Hi everyone!
+(I've been a bit overworked and also caught by a cold, I hope
+that explains my disappearance ;)
+
+
+Here I'll try to answer queued stuff:
+
+> {Sean}
+> Bug #61: strrchr(parent, '/') returned NULL for . and .., but was assumed ok
+> plus I added some more checking around the .dillo directory at startup.
+
+Integrated (done).
+
+> {Sean}
+> Enclosed is a patch for #68. My solution was to pull the call to
+> Html_parse_entities() out of the else, so it will get called regardless of the
+> current DILLO_HTML_PARSE_MODE. Also, I changed the entities struct to include
+> a len member and simply added the length of every entity to the array.
+> ... by adding the len field the call to
+> strlen() is removed from the for loop. This should help the performance of
+> Html_parse_entities some.
+
+From the four patches you sent on the same thing, I finally
+kept the full entities list and used a libc binary search call.
+There're some interesting points:
+
+- All the isocodes in the list are not supported by current
+font (Some of them don't render).
+- Performance is a very relative subject here (commented below)
+
+(more on this subject near the bottom)
+
+> {Sean}
+> So, I used dillo some more today. yp.yahoo.com has a submit button whose text
+> is: "Start&nbsp;Search". This is not handled by dillo either. So, I went thru
+> and added Html_parse_entities() calls in a few more places. Now I need to
+> handle the memory use associated with this, right now I am leaking small bits
+> of memory. Once I get this sorted out I will send a new patch.
+
+I found a better place that needs a single call to the entity
+parsing function. Not implemented yet, but if it works, I'll keep
+it.
+
+> {Sebastian}
+> I encounterd a bug which sounds very simimar to #69:
+>
+> When I go to "
+> and then, before the page is completely loaded (chances are quite good,
+> since it is rather long), click on a link at the top, dillo starts to
+> load and show the new page, but after a second or so *allways* crashes.
+
+Yes, I'll try to explain that here:
+
+That happens cause the IO engine is not finished yet. When you
+load a page, and start loading another before the former
+finishes, the IO emgine keeps loading and feeding both! (a sure
+way for crashes).
+That happens with the main page, not with images (unless the
+image is the main page). 
+Images within an HTML page have already an aborting mechanism,
+within the image sink, so the browser doesn't crash with these.
+
+A correct solution for this problem is not an easy task (I have
+some ideas, but queued in favor of table support).
+
+> {Sean}
+> Enclosed is a patch that includes the changes to html.c I sent last time along
+> with the additional changes so that entities are checked for in FORM inputs
+> as well. As far as I can tell, all entities are caught now.
+
+I hope the previous solution to work with forms too...
+
+> Also in my patch is a bug fix for Html_parse_entities(). If the html contained
+> a malformed entity, i.e. "&amp", the output would be "mp". This would be a
+> good item to add to test case html files. Another would be "&cpy;", which is
+> copyright with a typo. This flexes the case where it is a valid form of an
+> entity, but not a matching entity.
+
+In the spirit of XHTML, I don't aim to support "malformed" HTML
+pages. Anyway, the bug fix is OK (I mean, unrecognized "entities"
+must be rendered as a word).
+
+
+> {Sean}
+> The open location window does not seem to set itself as a transient. 
+> This causes several window managers to hide the window when it opens. It
+> should load on top of the browser window. This window too could use some
+> beautification.
+
+Yes, that semms to be a bug. Anyway, we can get rid of the open
+location window (because the location bar provides the same
+functionality).
+Comments?
+
+> loading large images is rather slow, I noticed this on screen
+> shot pages
+
+Mmmmm.... There's no special handling for image connections.
+Maybe you were downloading another document while fetching the
+page. This seems weird at the beginning, but it's possible!
+
+As you all may have noticed, dillo doesn't handle downloads
+yet, but if you click on a link that has an unhandled MIME type,
+the download starts, and is not aborted (see explanation above).
+Furthermore, if you wait until it's got, you can put the url in
+the location bar and force dillo to go there (nothing will be
+rendered), and after that, hitting save does the trick!
+
+If not the case, I'm sure someone will appreciate the trick :)
+
+> The number of images gauge often shows "N of M" instead of "N of N", 
+> i.e. "20 of 23". Why are some images not getting loaded?
+
+Another subtle explanation!
+Images are got in general, the problem is that the gauge is not
+updated right (yes, a Bug).
+
+I say in general, because when the image hits a redirection,
+it's not retrieved (not a bug, but lack of implementation).
+
+> {Sean}
+> Also, as I mention on #70, dillo acts like it does POST but doesn't. I am
+> reading the HTTP spec and looking at a proper implementation of this. If
+> anyone else is looking at this, let me know.
+
+I read your complaints on GET method too, the bug track engine
+uses GET and I've used POST without any problems. I'm not saying
+it's perfect, but can you be more specific please?
+
+> {Sean}
+> I re-did the core of Html_parse_entities(). The named entity check is now a
+> binary search. Also added a few checks so that malformed html never makes it
+> in to be checked.
+>
+> My initial tests show the new version is about twice as fast as the old one.
+> [...]
+> 76.92 0.10 0.10 6000 16666.67 16666.67 Html_parse_entities
+> 15.38 0.12 0.02 main
+> 7.69 0.13 0.01 6000 1666.67 1666.67 Html_parse_entities2
+> [...]
+> Because a binary search is now used and I changed the code layout, the entity
+> list no longer needs my previous addition of length values. This patch removes
+> them.
+
+Performance is a very relative subject here. Mainly because
+entities are scarce in the average HTML page (a minimal ratio),
+and because the Html_parse_entities function, returns without
+any searching almost all of the time (when the word doesn't have
+entities). 
+
+Anyway, testing with a page that has a "high entity ratio",
+profiling shows that the time spent in Html_parse_entities is no
+more that 5%, so optimizing the (5%xratio) is not very
+significant. Even more, the older scheme used a linear search,
+but its first items where the most expected entities, so it
+usually performed better than the binary search.
+
+Please don't get me wrong, I was amazed too, so I pushed it
+further and implemented a minimal perfect hash function for the
+whole entities list. Guess what, the MPH function was slightly
+faster than the binary search, but not worth the added complexity
+though. The funny thing is that it was slower than the linear
+search for pages that only used the top five entities of the
+list! 
+
+Knowing that since ISO-LATIN1 was adopted as the standar
+charset for HTML (strongly decreasing the entities use), and
+considering several other facts, I decided to trade off and used
+a libc binary search and with the large entity list.
+
+----
+
+Some final suggestions:
+
+- Please don't rush your patches to me. It's much better to
+hold on for a while, test them thoroughly and finally sending
+them.
+
+- Please don't post things you're not sure off without stating
+clearly your doubts (Just to avoid confussion).
+
+- Please bear in mind that this is a public list and that
+several persons read it. Think carefully what you post and
+be as concise as you can.
+
+
+I want to thank everyone that was kind enough to read this far,
+and also want to thank the whole developing team for the
+excellent work, and in particular, the polite bounds into which
+we all agreed to express ourselves.
+
+
+Sincerely
+Jorge.-
+
+
+Ps: I'm studying Sebastian's code and trying to find a way to
+integrate the scroll-position remind feature into it. 
+
+
+
+Re: [Dillo-dev]meta refresh support, and form POST
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-12 00:33
+
+> 
+> Something like this might work:
+> 
+> gboolean stuff_to_do(gpointer data)
+> {
+> Do the stuff that is to be done...
+> 
+> return FALSE;
+> }
+> 
+> g_timeout_add(milliseconds, stuff_to_do, NULL);
+> 
+
+right, but the problem with a call back is I have to arrange for it to get data
+somehow. Which would me some kind of global data )-:
+
+Will consider the possibilties though. 
+
+
+
+Re: [Dillo-dev]some thoughts
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-12 00:32
+
+On 11-Aug-2000 Sebastian Geerken wrote:
+> Sean 'Shaleh' Perry wrote:
+>> [...]
+>> the view source window has the ok button at the bottom. It makes the
+>> window
+>> look ugly and is generally useless.
+> 
+> What about starting an external text viewer, determined by the user?
+> Dillo could write the content into a temporary file, or pipe it through
+> stdin. The builtin text viewer could be left as standard, but should not
+> be improved.
+> 
+
+nah, that is over kill. If the close button is removed, the window looks just
+like netscape's -- just without syntax highlighting. 
+
+
+
+Re: [Dillo-dev]meta refresh support, and form POST
+
+From: Jörgen Viksell <vsksga@ho...> - 2000-08-11 19:55
+
+>Implementation question: the format is content="2;URL= 
+>where
+>the '2' is the number of seconds before loading the page. How should I get
+>this pause without freezing the browser? My current code ignores the
+>delay completely.
+
+Something like this might work:
+
+gboolean stuff_to_do(gpointer data)
+{
+Do the stuff that is to be done...
+
+return FALSE;
+}
+
+g_timeout_add(milliseconds, stuff_to_do, NULL);
+
+// Jörgen
+
+
+
+________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com 
+
+
+
+Re: [Dillo-dev]some thoughts
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-11 10:04
+
+Sean 'Shaleh' Perry wrote:
+> [...]
+> the view source window has the ok button at the bottom. It makes the
+> window
+> look ugly and is generally useless.
+
+What about starting an external text viewer, determined by the user?
+Dillo could write the content into a temporary file, or pipe it through
+stdin. The builtin text viewer could be left as standard, but should not
+be improved.
+
+Sebastian. 
+
+
+
+[Dillo-dev]meta refresh support, and form POST
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-11 08:46
+
+I am working on meta refresh support. This causes dillo to crash just like the
+previously mentioned "click a link before the text is finished rendering" bug. 
+So, looks like I get to kill two birds with one stone (-:
+
+Implementation question: the format is content="2;URL= where
+the '2' is the number of seconds before loading the page. How should I get
+this pause without freezing the browser? My current code ignores the 
+delay completely.
+
+Also, as I mention on #70, dillo acts like it does POST but doesn't. I am
+reading the HTTP spec and looking at a proper implementation of this. If
+anyone else is looking at this, let me know.
+
+I have mailed Jorge several patches this week for improved entity support and
+some minor speed improvements to html.c in general.
+
+See you all in a week (-: I will be reading mail sporadically. 
+
+
+
+[Dillo-dev]some thoughts
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-10 23:56
+
+Been using dillo off and on for most of this week. My list of little gripes so
+far:
+
+the view source window has the ok button at the bottom. It makes the window
+look ugly and is generally useless.
+
+The open location window does not seem to set itself as a transient. This
+causes several window managers to hide the window when it opens. It should
+load on top of the browser window. This window too could use some
+beautification.
+
+loading large images is rather slow, I noticed this on screen shot pages
+
+the number of images gauge often shows "N of M" instead of "N of N", i.e. "20
+of 23". Why are some images not getting loaded? 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-09 00:31
+
+Sebastian,
+
+> > [...]
+> > It should work in a reasonable way!
+> > I mean, in a clear, unambiguous, and practical way.
+> > (And finally we can always count on the always-reloading
+> > scheme; dillo is very fast doing that).
+> 
+> Yes, this is true. By testing I found that even long pages are reloaded
+> in a reasonable time.
+> 
+> Nevertheless, "not-reloading" is a nice feature,
+
+Of course it is.
+
+> but still not fully
+> complete, and I will stop writing on it in the next time (meanwhile I am
+> sucked of this whole problem :-). 
+
+I've been there...
+
+> It will be deactivated it in the
+> patch, but I think it should be left as an option for future extensions.
+> 
+> Shall I remove and put it in a separate patch, or leave it in the code,
+> but deactivate (#if 0 ... #endif) it?
+
+#if 0, it (I want to study the code anyway)
+
+
+> PS: Is it possible to include .php pages or so into the html test suite?
+> I used it to create some extreme situations, e. g. slowing down reading
+> by including "<?php sleep(10); ?>".
+
+If that's to de done, I'd prefer it to have its own tarball.
+Not everyone has a php-configured web server running. I like the
+idea though.
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Bug #69
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-08 20:06
+
+On 08-Aug-2000 Sebastian Geerken wrote:
+> Hi!
+> 
+> I encounterd a bug which sounds very simimar to #69:
+> 
+> When I go to "
+> and then, before the page is completely loaded (chances are quite good,
+> since it is rather long), click on a link at the top, dillo starts to
+> load and show the new page, but after a second or so *allways* crashes.
+> 
+
+I can confirm this. Most pages load so fast in dillo that this is hard to test
+(-: But try this:
+
+go to a search engine page, search and as soon as a link appears click it. 
+Just keep clicking links as fast as they appear (who cares where they go). I
+found about three or so in dillo dies. Most likely the result of lack of
+function return value checking. 
+
+
+
+[Dillo-dev]Bug #69
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-08 15:47
+
+Hi!
+
+I encounterd a bug which sounds very simimar to #69:
+
+When I go to "
+and then, before the page is completely loaded (chances are quite good,
+since it is rather long), click on a link at the top, dillo starts to
+load and show the new page, but after a second or so *allways* crashes.
+
+(You will get the wrong page because of bug #65, but after fixing the
+bug, it remains the same.)
+
+If you wait, until the page has been loaded completely, all works.
+
+I hope this will helpful.
+
+Sebastian. 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-08 12:58
+
+Hi, Jorge!
+
+Jorge Arellano Cid wrote:
+> > > Maybe, if the timeout function validates itself, the problem can
+> > > be addressed in a simpler way. I mean, let the timeout function
+> > > start, poll until it finds the #anchor, then set its AnchorFound
+> > > flag and to continue correcting the value until:
+> > >
+> > > - #anchor is not found anymore or
+> > > - user scrolls the page (either with keyboard or with mouse)
+> > > When one of those happens, it removes itself.
+> >
+> > Changing of anchor positions depends of other things (e. g. images), so
+> > this is not the point.
+> 
+> I meant that it'd be clearer to let the timeout function remove
+> itself, than to push a removal function into another function
+> (an attempt to avoid coupling).
+
+Yes, this has been done from the beginning (except only two cases:
+Dw_gtk_scroller_destroy, and before a new timeout function is started).
+
+> > An other point: A new behavior, which I have implemented, is, that the
+> > page is *not* reloaded (even from cache) in some cases. Currently: if
+> > old and new url are the same *and* there is no #anchor. In this case the
+> > url is pushed, the scroller jumps to the anchor, but nothing is done
+> > else.
+> 
+> Interesting; careful considerations must be done though...
+> 
+> > As I have seen, the HTML spec does not say anything about this, so how
+> > should it work at the end?
+> 
+> It should work in a reasonable way!
+> I mean, in a clear, unambiguous, and practical way.
+> (And finally we can always count on the always-reloading
+> scheme; dillo is very fast doing that).
+
+Yes, this is true. By testing I found that even long pages are reloaded
+in a reasonable time.
+
+Nevertheless, "not-reloading" is a nice feature, but still not fully
+complete, and I will stop writing on it in the next time (meanwhile I am
+sucked of this whole problem :-). It will be deactivated it in the
+patch, but I think it should be left as an option for future extensions.
+
+Shall I remove and put it in a separate patch, or leave it in the code,
+but deactivate (#if 0 ... #endif) it?
+
+Sebastian.
+
+PS: Is it possible to include .php pages or so into the html test suite?
+I used it to create some extreme situations, e. g. slowing down reading
+by including "<?php sleep(10); ?>". 
+
+
+
+RE: [Dillo-dev]bug #68
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-07 23:53
+
+On 07-Aug-2000 Jorge Arellano Cid wrote:
+> 
+> Sean,
+> 
+> First of all, I want to welcome you to the project and to thank
+> your first patch contributions (just integrated the first one;
+> look at the bug-track).
+> 
+
+thanks, it is nice to have a free browser again (-: Hope to have all of #68
+done in the next few days.
+
+> 
+> Ps: Please don't send patches to the mailing list, send them
+> directly to me (or privately upon request).
+> 
+
+will do. 
+
+
+
+RE: [Dillo-dev]bug #68
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-07 23:19
+
+Sean,
+
+First of all, I want to welcome you to the project and to thank
+your first patch contributions (just integrated the first one;
+look at the bug-track).
+
+> The functions without header comments (/* ? */), do we desire them to be
+> commented?
+
+Yes! (It'd be great if we ever get the full source commented).
+
+
+Jorge.-
+
+Ps: Please don't send patches to the mailing list, send them
+directly to me (or privately upon request). 
+
+
+
+Re: [Dillo-dev]Re: Plugins (was: Misc. answers)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-07 23:19
+
+Eric,
+
+> What's good in using http rather than a raw html page? I'm afraid http would
+> need much more code (libs) to do for a very small benefit (I can't even name
+> one :-/).
+
+Take it easy, all you'll need to do is to output the HTML page
+with a HTTP content header:
+
+·························
+Content-Type: text/html
+
+<HTML>
+...
+</HTML>
+·························
+
+You may also add a "Content-Length" field, but that's not a
+requirement (this is exactly the same way we use to handle local
+files).
+
+> ... or are we talking about the same thing ? ;-)
+
+Yes.
+(No MIME, no libs, no complicated stuff, just a minimal HTTP
+header).
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]bug #68
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-06 23:45
+
+On 06-Aug-2000 Sean 'Shaleh' Perry wrote:
+> Enclosed is a patch for #68. My solution was to pull the call to
+> Html_parse_entities() out of the else, so it will get called regardless of
+> the current DILLO_HTML_PARSE_MODE.
+
+So, I used dillo some more today. yp.yahoo.com has a submit button whose text
+is: "Start&nbsp;Search". This is not handled by dillo either. So, I went thru
+and added Html_parse_entities() calls in a few more places. Now I need to
+handle the memory use associated with this, right now I am leaking small bits
+of memory. Once I get this sorted out I will send a new patch.
+
+The functions without header comments (/* ? */), do we desire them to be
+commented? 
+
+
+
+[Dillo-dev]Gif segfault : not dillo's bug
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-06 14:42
+
+Hi all,
+I've been testing dillo's image rendering for a while, and I noticed a segfault
+with some gif (mostly banners, only animated ?). It's not dillo's fault, it's a
+libungif fault (v4.1.0) : every imlib-dependant program segfaults. Version
+4.1.0b1 corrects this bug, unfortunatly no package of this version is available
+: you'll have to get the tarball from libungif site, compile and install it
+yourself. Doing that, you'll break packages dependancies (imlib, ...), but
+compilation and replacement is very easy.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 06-Aug-2000 a 23:35:52
+---------------------------------- 
+
+
+
+[Dillo-dev]Re: est suite (was: Misc. answers)
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-06 10:27
+
+Le 05-Aug-2000, on m'a dit : 
+> 
+> ---- [Test Suite] ----
+> 
+> > > The main point of it is to have a set of pages to test backward
+> > > rendering capabilities (not breaking what was working in former
+> > > versions of dillo), and to have a record of simple things that
+> > > are not working yet, but that we're close to add.
+> > > 
+> > 
+> > That would be a collection of existing pages you and other developers have
+> > done before. (see above)
+> 
+> And some other interesting stuff added later.
+> 
+> > > Just assemble a small testing suite and you'll eventually
+> > > receive contributions (I have some!).
+> > 
+> > Do you want me to assemble the pages, then send you the assemblage for
+> > publishing ? I can do that.
+> 
+> Perfect.
+> 
+
+Ok, everybody send me your pages at the address below, in a tgz, if possible
+with a short description of what each page is supposed to test. I'll put them
+together.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 06-Aug-2000 a 11:56:07
+---------------------------------- 
+
+
+
+[Dillo-dev]Re: Plugins (was: Misc. answers)
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-06 10:27
+
+Le 05-Aug-2000, on m'a dit : 
+> ---- [Plugins] ----
+> 
+> > > The only difference is that information from the browser is
+> > > passed to the plugin using its stdin, not the command line, and
+> > > encoded as if the recepting program was a CGI.
+> >
+> > What do you mean with this CGI-thing : do you want the program to use HTTP
+> > as transport, not stdout?
+> 
+> The plugin-program outputs to its stdout in HTTP format.
+> 
+
+Herrr ... by http format, you mean a subset of it : some infos of the header
+(content, cache). Not the full mime-encoding stuff, I hope.
+
+> > AFAIK CGIs prints to stdout for the web server.
+> 
+> Right.
+> 
+
+an html page, plain text, no header, no http. The first bytes sent are "<html".
+
+What's good in using http rather than a raw html page ? I'm afraid http would
+need much more code (libs) to do for a very small benefit (I can't even name
+one :-/).
+
+... or are we talking about the same thing ? ;-)
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 06-Aug-2000 a 12:07:10
+---------------------------------- 
+
+
+
+[Dillo-dev]bug #68
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-06 09:17
+
+Attachments: dillo2.patch      
+
+Enclosed is a patch for #68. My solution was to pull the call to
+Html_parse_entities() out of the else, so it will get called regardless of the
+current DILLO_HTML_PARSE_MODE. Also, I changed the entities struct to include
+a len member and simply added the length of every entity to the array. 
+Since we know what the string is, it is silly to perform the computation. 
+This entire array could be dynamically generated from a list of entities,
+assuming the list ever changes. By adding the len field the call to
+strlen() is removed from the for loop. This should help the performance of
+Html_parse_entities some.
+
+The two patches (this one and the last one) are independent of each other. 
+
+
+
+[Dillo-dev]Bug #61 patch, plus extras
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-06 08:37
+
+Attachments: dillo.patch      
+
+It is soooo great to see a new browser. Anyway, here is a little contribution
+to the cause:
+
+Bug #61: strrchr(parent, '/') returned NULL for . and .., but was assumed ok
+plus I added some more checking around the .dillo directory at startup.
+
+To fully clean up #61, the path shown should not be: /path/to/directory/./. To
+solve this I have to understand where the URL is getting sent from and where
+the string displayed is shown.
+
+BTW, anyone have some emacs magic so I can edit the code with emacs? I used vi
+for this so I could follow the coding standards. 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-05 16:46
+
+Sebastian,
+
+> Since I had problems to understand how several modules are connected, I
+> tried to minimize communication between Html/Dw and GtkDwScroller by
+> using flags and timeout functions. This is a workaround, but it will
+> work ;-). I will comment and document my patch as good as it is needed
+> by someone else, who wants to implement it more elegant, after he has
+> understood the whole code better than I.
+
+Excellent, keep up the good work!
+
+> [...]
+> What does not work correct: Go to a (large) page, scroll down and resize
+> the window. Since the recalculation of the position is quite simple, you
+> often get to a different position. But this has nothing to do with my
+> patch. (A bug? Other browsers have this problem, too.)
+
+Yes, that's a different problem.
+I think better to solve the #anchor problem well, before we
+attempt to address this new one.
+Remember that we still have to support remembering the
+scrolling position of previously browsed pages (maybe just saving
+the vertical adjustment value in the navigation stack).
+[This problem will be affected by window resizes too.]
+
+> > Maybe, if the timeout function validates itself, the problem can
+> > be addressed in a simpler way. I mean, let the timeout function
+> > start, poll until it finds the #anchor, then set its AnchorFound
+> > flag and to continue correcting the value until:
+> > 
+> > - #anchor is not found anymore or
+> > - user scrolls the page (either with keyboard or with mouse)
+> > When one of those happens, it removes itself.
+> 
+> Changing of anchor positions depends of other things (e. g. images), so
+> this is not the point.
+
+I meant that it'd be clearer to let the timeout function remove
+itself, than to push a removal function into another function
+(an attempt to avoid coupling).
+
+> An other point: A new behavior, which I have implemented, is, that the
+> page is *not* reloaded (even from cache) in some cases. Currently: if
+> old and new url are the same *and* there is no #anchor. In this case the
+> url is pushed, the scroller jumps to the anchor, but nothing is done
+> else.
+
+Interesting; careful considerations must be done though...
+
+> As I have seen, the HTML spec does not say anything about this, so how
+> should it work at the end?
+
+It should work in a reasonable way!
+I mean, in a clear, unambiguous, and practical way.
+(And finally we can always count on the always-reloading
+scheme; dillo is very fast doing that).
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Re: Misc. answers
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-05 16:46
+
+Hi there!
+
+Here are some answers that were queued in my "todo:" list:
+
+
+---- [Test Suite] ----
+
+> > The main point of it is to have a set of pages to test backward
+> > rendering capabilities (not breaking what was working in former
+> > versions of dillo), and to have a record of simple things that
+> > are not working yet, but that we're close to add.
+> > 
+> 
+> That would be a collection of existing pages you and other developers have done
+> before. (see above)
+
+And some other interesting stuff added later.
+
+> ...
+> So, what you want basically is problem-exposing pages.
+
+Not only that.
+
+> > Just assemble a small testing suite and you'll eventually
+> > receive contributions (I have some!).
+> 
+> Do you want me to assemble the pages, then send you the assemblage for
+> publishing ? I can do that.
+
+Perfect.
+
+
+---- [PNG Code] ----
+
+> > Finally, Geoff Lane (author of PNG support), told me it was
+> > alpha code.
+> >
+>
+> Does he still support the code, or is it up to us ? 
+
+Geoff is not supporting it, so I guess it's up to Luca ;-)
+
+> I did all my testings with a png image _in_ an html page : if you don't have
+> the bug when loading the page, you'll never have it when clicking reload. You
+> have to quit dillo and reload the page.
+> 
+> That strange : does dillo have a different caching behavior when the the
+> "page" is an image? (it seems dillo re-decoding the image then)
+
+Good point!
+Actually the caching scheme is only one, but cache querying is
+different. When an IMG tag is found in a HTML page, the dicache
+is asked for the image (decompressed image cache), and when it's
+a bare URL, a_Cache_open_url is requested to do the job
+(bypassing the dicache).
+
+The dicache code is expecting a full rewrite (I wrote that
+before, but don't remember where nor to whom).
+
+Hope that helps.
+
+
+
+---- [Plugins] ----
+
+> > The only difference is that information from the browser is
+> > passed to the plugin using its stdin, not the command line, and
+> > encoded as if the recepting program was a CGI.
+>
+> What do you mean with this CGI-thing : do you want the program to use HTTP as
+> transport, not stdout?
+
+The plugin-program outputs to its stdout in HTTP format.
+
+> AFAIK CGIs prints to stdout for the web server.
+
+Right.
+
+> Will CGI environment variables be passed to the program ? (REMOTE_HOST and
+> stuff) I don't see that useful.
+
+No, we'll forget about environment vars.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]New release!
+
+From: Jorge Arellano Cid <jcid@ca...> - 2000-08-04 21:39
+
+Hi there,
+
+A lot of work and effort has been put in this release. I hope
+you all enjoy the difference.
+Most notably there's new extensive documentation about dillo widget 
+(Dw), and IO.txt has been polished.
+
+I'll qoute a bit from IO.txt here:
+
+" Data transfer between threads inside the browser is handled by
+pipes, shared memory is little used. This almost obviates the
+need for explicit synchronization, which is one of the main areas
+of complexity and bugs in concurrent programs. Dillo handles its
+threads in a way that its developers can think of it as running
+on a single thread of control. This is accomplished by making the
+DNS engine call-backs happen within the main thread, and by
+isolating file loading with pipes."
+
+
+
+Severals bugs and leaks were fixed, and stability also improved!
+
+Download and enjoy!
+
+Jorge.-
+-- 
+
+
+
+RE: [Dillo-dev]Re: Eric
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-02 04:50
+
+Le 01-Aug-2000, on m'a dit : 
+> > then the program "bm" prints a html page in stdout (and can do something
+> > else, like writing a file on the disk), which page dillo will render.
+...
+> 
+> Basically, that's the idea.
+> 
+> The only difference is that information from the browser is
+> passed to the plugin using its stdin, not the command line, and
+> encoded as if the recepting program was a CGI.
+> 
+> 
+
+What do you mean with this CGI-thing : do you want the program to use HTTP as
+transport, not stdout ? AFAIK CGIs prints to stdout for the web server.
+Will CGI environment variables be passed to the program ? (REMOTE_HOST and
+stuff) I don't see that useful.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 02-Aug-2000 a 13:41:55
+---------------------------------- 
+
+
+
+RE: [Dillo-dev]Bug #4, #62, #63
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:15
+
+Le 01-Aug-2000, on m'a dit : 
+> Il mar, 01 ago 2000, hai scritto:
+> 
+> > When I read libpng docs (example.c), it has directions on
+> > decoding several images at the same time, so it seems that the
+> > library can handle that.
+> > On the other hand, I can't reproduce the bug with a single
+> > image.
+> 
+> I can. I open a png image then click on reload button several timesand I got
+> a white image.
+> 
+
+I did all my testings with a png image _in_ an html page : if you don't have
+the bug when loading the page, you'll never have it when clicking reload. You
+have to quit dillo and reload the page.
+
+That's strange : does dillo have a different caching behavior when the the
+"page" is an image ? (it seems dillo's re-decoding the image then)
+
+> > An interesting fact is that sometimes PNGs render not
+> > completely white, but with colors bleached away! (One more hint
+> > towards thinking the bug is PNG specific).
+> 
+> Me too!
+> 
+
+I'll try again with image only.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 02-Aug-2000 a 12:08:52
+---------------------------------- 
+
+
+
+RE: [Dillo-dev]Bug #4, #62, #63
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:11
+
+Le 01-Aug-2000, on m'a dit : 
+> 
+> Eric,
+> 
+> > > Bug #4 (images as white square): I can reproduce it only with PNG. Gif
+> > > and jpeg works just fine. Maybe a png specific problem ?!?
+> > 
+> > I noticed the bug is much more frequent when there is several images: I
+> > wonder if my libpng is compiled reentrant.
+> 
+> When I read libpng docs (example.c), it has directions on
+> decoding several images at the same time, so it seems that the
+> library can handle that.
+> On the other hand, I can't reproduce the bug with a single
+> image.
+> 
+
+I've done all my testings using a page with a single png image. It happens. 
+It is true that it happens less with only one image (maybe 1 out of 20) than
+with several images (my test page with 17 png has 2 to 5 white images each
+time), but it happens. I noticed it happens less with the 17-images page when I
+print a lot of debug informations during decoding, thus slowing down the
+process, that's why I was thinking of a reentrance bug. I'm not sure now
+
+> An interesting fact is that sometimes PNGs render not
+> completely white, but with colors bleached away! (One more hint
+> towards thinking the bug is PNG specific).
+> 
+
+I'm using 64x32 one-color images, and sometimes (rarely) I have one or two
+lines of randomly colored pixels.
+
+> Finally, Geoff Lane (author of PNG support), told me it was
+> alpha code.
+> 
+
+Does he still support the code, or is it up to us ?
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 01-Aug-2000 a 22:46:29
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Html test suite
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:11
+
+Le 01-Aug-2000, on m'a dit : 
+> 
+> The main point of it is to have a set of pages to test backward
+> rendering capabilities (not breaking what was working in former
+> versions of dillo), and to have a record of simple things that
+> are not working yet, but that we're close to add.
+> 
+
+That would be a collection of existing pages you and other developers have done
+before. (see above)
+
+> For instance, a page that reproduces the white square rendering
+> bug, would be useful,
+
+I have a page doing that. Anybody interested ?
+
+> The other fact to take into account, is not to devote much time
+> on assembling an HTML test suite, just find a page that shows
+> some problems and add it to our test list; if you can reduce its
+> size, that'd be good.
+> 
+
+So, what you want basically is problem-exposing pages.
+
+> Just assemble a small testing suite and you'll eventually
+> receive contributions (I have some!).
+> 
+> Ps: If you want my test examples, drop me a note.
+> 
+
+Do you want me to assemble the pages, then send you the assemblage for
+publishing ? I can do that.
+
+I'll begin with "should-work-to-be-a-good-browser" pages : some basic text
+formating and character rendering : everything dillo can do now (as for
+v0.2.2), plus everything (I feel) should work on any decent browser.
+
+If anybody needs pages to test a specific problem and is not in the mood doing
+doing them by himself, just send me an email I'prepare a few pages for the next
+day.
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 01-Aug-2000 a 23:32:24
+---------------------------------- 
+
+
+
+RE: bookmarks [Dillo-dev]Re: Eric
+
+From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:11
+
+Le 01-Aug-2000, on m'a dit : 
+> 
+> Eric,
+> 
+> > You said that before and I love this idea. I'd like to see a practical
+> > example of plugin, even alpha stage, before I decide I can do it right.
+> 
+> OK, I'll try to provide you with that.
+> (Most probably a patch over dillo-0.2.3).
+> 
+...
+> The only difference is that information from the browser is
+> passed to the plugin using its stdin, not the command line, and
+> encoded as if the recepting program was a CGI.
+> 
+
+Understood. I'm interested, then. 
+
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 01-Aug-2000 a 22:55:20
+---------------------------------- 
+
+
+
+RE: [Dillo-dev]Bug #4, #62, #63
+
+From: Luca Rota <drake@it...> - 2000-08-01 23:14
+
+Il mar, 01 ago 2000, hai scritto:
+
+> When I read libpng docs (example.c), it has directions on
+> decoding several images at the same time, so it seems that the
+> library can handle that.
+> On the other hand, I can't reproduce the bug with a single
+> image.
+
+I can. I open a png image then click on reload button several timesand I got a
+white image.
+
+> An interesting fact is that sometimes PNGs render not
+> completely white, but with colors bleached away! (One more hint
+> towards thinking the bug is PNG specific).
+
+Me too!
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]Bug #10 (Anchors): questions
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-01 15:08
+
+Hi, Jorge!
+
+First a few notes:
+
+Anchors basicly work. There are a few details and tests to do, but I do
+not think I will get severe problems. So the patch will propably be
+finished in a few days.
+
+Since I had problems to understand how several modules are connected, I
+tried to minimize communication between Html/Dw and GtkDwScroller by
+using flags and timeout functions. This is a workaround, but it will
+work ;-). I will comment and document my patch as good as it is needed
+by someone else, who wants to implement it more elegant, after he has
+understood the whole code better than I.
+
+Jorge Arellano Cid wrote:
+> If the "scroller" and "view" code was right, maybe I'd suggest
+> you to try a patch based on "changed" and "value changed"
+> signals, but that code is a mess!
+
+I've tried to catch "changed" signals, but it didn't work reliable. The
+timeout function works well, and is always removed at some point (there
+is no "timeout function leak"). The only problem is, that it continues
+running a while without use (and so taking a not measurable amount of
+CPU time ;-), but this is only a question of design, not of runtime
+behaviour.
+
+> [...]
+> I see several things here:
+> 
+> - The timeout function should not override user scrolling
+> (i.e. if the user scrolls the page with the mouse).
+
+I already planned this. When, e. g, the user scrolls the page, before
+the requested anchor has been read *anyway* (e. g. when transmission is
+very slow, and meanwhile he is interrested in the informations at the
+top of the page), he should not be confused by a sudden jump to an other
+position (I think so). I have added a line to Dw_gtk_view_v_scroll, and
+it works.
+
+> - Html_close can't be trusted to happen.
+
+Ok, I don't use it. (It does not work either in many cases.)
+
+> - Image reception can't be trusted.
+
+I didn't use it.
+
+> - It would be nice to have a #anchor display function that
+> doesn't get fooled with page resizes (as we're trying).
+
+That works. Precisely, following works:
+
+1. Go to an url "foo#bar" where foo is very long and "#bar" at the very
+bottom, then *immediately* resize the window (before the <a name="bar">
+is read).
+
+2. Go to a page, wait until it is loaded, resize the window, and jump to
+an anchor in the same page.
+
+3. Go to an url "foo#bar", wait until it is visible (e. g. transmission
+is over), and resize the window. (This is not really intended, but a
+side effect, since the timeout function is still running.)
+
+What does not work correct: Go to a (large) page, scroll down and resize
+the window. Since the recalculation of the position is quite simple, you
+often get to a different position. But this has nothing to do with my
+patch. (A bug? Other browsers have this problem, too.)
+
+> Maybe, if the timeout function validates itself, the problem can
+> be addressed in a simpler way. I mean, let the timeout function
+> start, poll until it finds the #anchor, then set its AnchorFound
+> flag and to continue correcting the value until:
+> 
+> - #anchor is not found anymore or
+
+Changing of anchor positions depends of other things (e. g. images), so
+this is not the point.
+
+> - user scrolls the page (either with keyboard or with mouse)
+
+See above.
+
+> When one of those happens, it removes itself.
+
+An other point: A new behavior, which I have implemented, is, that the
+page is *not* reloaded (even from cache) in some cases. Currently: if
+old and new url are the same *and* there is no #anchor. In this case the
+url is pushed, the scroller jumps to the anchor, but nothing is done
+else.
+
+As I have seen, the HTML spec does not say anything about this, so how
+should it work at the end?
+
+Sebastian. 
+
+
+
+[Dillo-dev]Gtk containers
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-01 15:08
+
+Jorge Arellano Cid wrote:
+[about docs]
+> I think it's a matter cause it doesn't work as expected. Some
+> parts are missing, some other are incomplete, and some have
+> workaround tweaks.
+> For instance, when Jörgen fixed the checkboxes, his code was
+> right, but it didn't work because button widgets were not
+> receiving the expose events.
+
+Perhaps a hint: The container implementations of GtkDwScroller and
+GtkDwView look a bit incomplete. If you look e. g. at the source of
+GtkBox, you find that there are 6 specific functions defined by
+GtkContainer (like abstract virtual methods in C++), which are put into
+the class structure: gtk_box_add, gtk_box_remove, gtk_box_forall,
+gtk_box_child_type, gtk_box_set_child_arg and gtk_box_get_child_arg. So,
+perhaps, Jörgen's code works, when GtkDwView is implemented in the
+correct way. 
+
+
+
+RE: [Dillo-dev]Bug #4, #62, #63
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39
+
+Eric,
+
+> > Bug #4 (images as white square): I can reproduce it only with PNG. Gif and
+> > jpeg works just fine. Maybe a png specific problem ?!?
+> 
+> I noticed the bug is much more frequent when there is several images: I wonder
+> if my libpng is compiled reentrant.
+
+When I read libpng docs (example.c), it has directions on
+decoding several images at the same time, so it seems that the
+library can handle that.
+On the other hand, I can't reproduce the bug with a single
+image.
+
+An interesting fact is that sometimes PNGs render not
+completely white, but with colors bleached away! (One more hint
+towards thinking the bug is PNG specific).
+
+Finally, Geoff Lane (author of PNG support), told me it was
+alpha code.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #4, #62, #63
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39
+
+Seth,
+
+> > > Bug #63 (Segfault when you click enter in location field)
+> 
+> I found that bug running on an older slack install, when I tried to reproduce
+> it on a newer mandrake install everything seemed fine.
+
+Thanks for the explanation.
+
+Jorge.-
+
+Ps: Older than SLK-3.6? 
+
+
+
+RE: [Dillo-dev]Re: Eric
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39
+
+Eric,
+
+> > - Implementing the bookmarks as an external plugin. The idea of
+> > doing it keeps rolling in my mind. Basically a dpi:/ (dillo
+> > plugin) URL can be defined, and when accessing dpi:/bm (bookmark)
+> > an external program can be launched on a thread to 'cat' the
+> > bookmarks file (this is very much like current file handling).
+> > The point with this scheme is that the plugin can be extended
+> > to achieve more functionality (add, move, remove bookmark, make
+> > category, etc). All implemented in a CGI fashioned way.
+> > With that example, other people can start thinking of other
+> > plugins, like a man page processor, or info file processor, a
+> > dillorc options interface, etc.
+> > 
+> 
+> You said that before and I love this idea. I'd like to see a practical example
+> of plugin, even alpha stage, before I decide I can do it right.
+
+OK, I'll try to provide you with that.
+(Most probably a patch over dillo-0.2.3).
+
+> What I understand, is there's a program called bm in ~/.dillo/plugin/ or
+> /usr/local/lib/dillo/ (or is it /usr/local/share/dillo/ ?), that take its
+> arguments on the command line (ie : when calling the URL
+> "dpi:/bm?subdirectoy=News&fontsize=16", dillo is opening a read only pipe with
+> the command line "bm subdirectory=News fontsize=16"), then the program "bm"
+> prints a html page in stdout (and can do something else, like writing a file
+> on the disk), which page dillo will render.
+> Is that what you have in mind ? If not, can you describe precisely the calling
+> mecanism, as well as the data retrieving.
+
+Basically, that's the idea.
+
+The only difference is that information from the browser is
+passed to the plugin using its stdin, not the command line, and
+encoded as if the recepting program was a CGI.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #4, #62, #63
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39
+
+Luca,
+
+> Bug #4 (images as white square): I can reproduce it only with PNG. Gif and
+> jpeg works just fine. Maybe a png specific problem ?!?
+
+Could be...
+When I made the entry, a long time ago, it seemed to happen at
+random images in ESR's page (not only PNGs there). But when I
+checked it yesterday, the blank images were only PNGs.
+
+> Bug #62 (<hr> tag's width problem): Dw_hruler_size_nego_y() (file dw_hrule.c)
+> is commented. But that code seem ok! It works! Why is commented?
+
+Because I haven't finished it yet ;)
+Dillo 0.2.3 will have it uncommented.
+
+> Bug #63 (Segfault when you click enter in location field): 
+> I can't reproduce it.
+
+After reading Seth's post, I decided to remove the entry.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Html test suite
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39
+
+Eric,
+
+> I've done some pages to begin with : basic html structure, colors. I'm
+> currently finishing the characters page. 
+> But I'm not sure what's urgent to do next.
+
+I understand.
+
+> What html specs do you want me to build test pages for (high and medium
+> priority) ? Do you want first (only ?) well-formated documents, or do you need
+> faulty documents too (missing, misplaced or incorrect tags)
+
+The main point of it is to have a set of pages to test backward
+rendering capabilities (not breaking what was working in former
+versions of dillo), and to have a record of simple things that
+are not working yet, but that we're close to add.
+
+For instance, a page that reproduces the white square rendering
+bug, would be useful, but a table rendering suit makes no sense
+at this stage.
+
+The other fact to take into account, is not to devote much time
+on assembling an HTML test suite, just find a page that shows
+some problems and add it to our test list; if you can reduce its
+size, that'd be good.
+
+Just assemble a small testing suite and you'll eventually
+receive contributions (I have some!).
+
+
+> PS: Do we aim for html 3 or html 4 compliance ?
+
+Neither one!
+We strive for a "usable" HTML web browser.
+(Kind of a vague answer, but true)
+
+
+
+Jorge.-
+
+
+Ps: If you want my test examples, drop me a note. 
+
+
diff --git a/old/oldmail/200009.txt b/old/oldmail/200009.txt
new file mode 100644
index 0000000..c12cd17
--- /dev/null
+++ b/old/oldmail/200009.txt
@@ -0,0 +1,2365 @@
+[Dillo-dev]Dillo weekly news
+
+From: Allan Clark <shark@bl...> - 2000-09-28 16:10
+
+The first Dillo weekly news has been posted.
+The url for those interested is
+http://www.shark.pwp.blueyonder.co.uk/news240900.html
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+[Dillo-dev]Developer News
+
+From: Allan Clark <shark@bl...> - 2000-09-29 10:18
+
+(Sorry if this is a repeat but I didn't get one back and there isn't one in
+the archives.)
+The first Dillo weekly news has been posted.
+The url for those interested is
+http://www.shark.pwp.blueyonder.co.uk/news240900.html
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+RE: [Dillo-dev]Repeated patch
+
+From: Allan Clark <shark@bl...> - 2000-09-24 14:46
+
+Jorge, have you applied this patch? you're right the problem is deeper
+routed, the fact is we shouldn't be getting the null pointer there, however
+we should probably check for them just incase, so although this doesn't
+solve the problem I think the patch should go in, alternatively in the mean
+time use an assert there to assert that there is not a null pointer, this
+way we know where it is failing and why and don't just get a crash.
+
+> -----Original Message-----
+> From: dillo-dev-admin@li...
+> [mailto:dillo-dev-admin@li...]On Behalf Of Jorge
+> Arellano Cid
+> Sent: 22 September 2000 19:19
+> To: dillo dev list
+> Subject: Re: [Dillo-dev]Repeated patch
+>
+>
+>
+> Sam,
+>
+> > ... here's the patch I
+> > sent again, as I never received a copy back (sorry if this is a repeat).
+>
+> Yes, the problem has very deep roots, and I'm still trying to
+> find out a design solution that gets rid of all related problems.
+>
+> Whether to apply the "patch" is a matter of pragmatism.
+>
+> I'll keep trying to solve the problems behind...
+>
+> Jorge.-
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]Sorry
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-24 01:43
+
+Sorry if any of my last mails have got to you: they haven't got to me.
+
+Check the archives if they haven't, however.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Not again
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-24 01:24
+
+Getting tired of repeating. Check archives for messages. 
+
+
+
+Re: [Dillo-dev]Missing mails again
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-24 01:01
+
+Argh! Why is it that only the important mails disappear?
+
+Well, they seem to be appearing on the archives, so if you're not receiving
+them, best to check there.
+
+On the other hand, it could just be me.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Missing mails again
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-24 00:50
+
+I think it's done it to me again. Did anyone receive my reply to the comments
+on the segfaults?
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Repeated patch
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-24 00:08
+
+On Fri, Sep 22, 2000 at 02:19:16PM -0400, Jorge Arellano Cid wrote:
+> 
+> Sam,
+> 
+> > ... here's the patch I
+> > sent again, as I never received a copy back (sorry if this is a repeat).
+> 
+> Yes, the problem has very deep roots, and I'm still trying to
+> find out a design solution that gets rid of all related problems.
+> 
+> Whether to apply the "patch" is a matter of pragmatism.
+> 
+> I'll keep trying to solve the problems behind...
+
+Obviously I've been looking for the root causes, too. I get the impression
+that this is some how to do with widgets that don't (or shouldn't) exist
+receiving data from the caching system, but I'm probably completely wrong.
+
+As for applying the patch, I know that covering up the problem is generally
+speaking a bad thing, but when it causes the program to crash extremely
+frequently in normal usage unless the user is extremely cautious I think
+that some soft of temporary measure is needed. Besides, there's another
+problem that just occurs in images that I think is related, where the
+structure that parent points to is filled with garbage, so the problem isn't
+really covered up.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Dw (was new here)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-23 15:45
+
+Hi Allan!
+
+I've still some doubts if the port is really a good thing, because:
+
+1. Gtk+ was designed for GUIs, but not for size negotiation e.g.
+needed for tables. This could be solved by a Gtk+ widget set, see my
+post to the list (subject "[Dillo-dev]Dw -> Gtk").
+
+2. Gtk+ adopts the limitation of 32k pixels for an X window even for
+windowless widgets, so you have a limited height for pages (when only
+a part of DwPage is seen in a viewport), or at least for tables (when
+the DwPage is itself the viewport). 
+
+I've included my thoughts, which I sent Jorge, at the end of this
+mail.
+
+Allan Clark wrote:
+> [...]
+> This all sounds great, if you need any help porting Dw just let me know what
+> needs to be done.
+
+Send your ideas and comments on this topic. If you have an idea how to
+solve the problem with the height limitation, without a new widget
+set, that would be great.
+
+> I realised after I had sent the patch to the list that it was going to be a
+> little obsolete as you were working on the port of Dw. I think the cvs
+> version of the tree should be kept more up to date, I sent an e-mail to
+> Jorge about that, below is part of that e-mail (which discussed a number of
+> things) it is just an idea for dw_page which I think might help us with
+> table and frame support, and you may be in a better position to decide.
+
+Currently, the ported DwPage is only on my local harddisk, according
+to Jorge's philosophy of long holded patches, and since no one else
+showed interest in it, before. If you are interested, I may send you
+what I've done yet.
+
+Sebastian
+
+My mail to Jorge:
+
+I now think that is indeed not a good idea to use Gtk+ for the layout
+of the html elements, but to continue using a much improved Dw.
+Improvements coming currently to mind, are:
+
+- Include Dw into the Gtk+ object model, i.e. derive it from
+GtkObject. So, Dw can use the strengths of Gtk+ objects.
+
+- Write a Gtk+ Widget GtkDwEmbed for embedding a Dw widget, replacing
+GtkDwView, and probably best derived from GtkLayout. This widget must
+first handle all embedded Gtk+ widgets (see below), and second wrap
+the events for the Dw widgets.
+
+- Dw (or a derived class DwContainer) must strictly distinguish
+between Dw widgets and Gtk+ widgets. E.g., the forall "method" of
+GtkDwEmbed (defined by GtkContainer) should only work on the Gtk+
+widgets. Embedding Gtk+ widgets should be a mechanism of Dw itself,
+not of DwEmbedGtk.
+
+An incomplete "class" hierarchy could look like this:
+
+
+[GtkObject]
+___________|_______________
+/ \
+Dw [GtkWidget]
+__________|___________ |
+/ | \ |
+DwBullet DwImage DwContainer GtkDwEmbed
+___|___
+/ \
+DwPage DwTable
+
+
+Dw and DwContainer should be similar to GtkWidget and GtkContainer,
+but with a few modifications, e.g. in size negotiation. An idea from
+Gtk+, that containers are (partly) responsible for resising their
+children, could also be adopted (see my post to the list). 
+
+
+
+RE: [Dillo-dev]Dw (was new here)
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-23 05:08
+
+-- En reponse de "RE: [Dillo-dev]Dw (was new here)" de Allan Clark, le
+22-Sep-2000 :
+> Lastly (bet you're glad) how far are we with tables/frames support, if the
+> answer is "still discussing design options" then I would like to add my idea
+> into the arena, I'm sure someone has probably suggested this, but, why don't
+> we extend dw_page so that it can be one of the following
+> 1)Contain a number of horizontal sub pages
+> 2)Contain a number of vertical sub pages
+> 3)Be a page as they are now, stored as lines.
+
+That should do it for frames, but tables are more complex than that : one can
+colspan and rowspan a cell. Table implementation is difficult to be done with
+the current line/word page structure.
+
+> Or we could have a wrapper, say dw_frame which could either contain
+> horizontal subframes or vertical subframes or contain one dw_page, either
+> way it is the same principle.
+
+Do we really need a whole dw_page for a frameset ? I don't think so. I think it
+would be fairly easy to implement frames as a frameset (gtk) widget being mostly
+a gtk containers tree, each containing a dw_page.
+
+> Also a page could be divided up for other things such as alignment, eg if
+> you have two paragraphs the top is left aligned, and the bottom is center
+> aligned, then we just divide it into two horizontal sub frames and all that
+> would be needed would be coding to render a page whose lines are
+> center/right alligned.
+
+This is intereseting. It looks like an extension of the current line/word page
+construction. This probably can be done without the frame idea, though.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Sep-2000 a 13:56:14
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Repeated patch
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-09-22 20:09
+
+Sam,
+
+> ... here's the patch I
+> sent again, as I never received a copy back (sorry if this is a repeat).
+
+Yes, the problem has very deep roots, and I'm still trying to
+find out a design solution that gets rid of all related problems.
+
+Whether to apply the "patch" is a matter of pragmatism.
+
+I'll keep trying to solve the problems behind...
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Plugins design
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-09-22 20:09
+
+Eric,
+
+
+> Hi all,
+> I'm currently working for plugins support in dillo, and I feel the need
+> for a communication protocol between the plugin and dillo.
+
+Yes, but please try to make as much as possible with the
+current scheme (bookmarks).
+
+I also see the need for a second plugin scheme, with
+communication protocol, and better integration. The problem is
+that currently we're trying to design the future widget scheme
+and until that's done, the second scheme will have to wait.
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Dw (was new here)
+
+From: Allan Clark <shark@bl...> - 2000-09-22 19:39
+
+Sebastian,
+
+
+<snip>
+> It is planned to port Dw to Gtk+, and I'm currently working on DwPage.
+> DwHruler will then not used anymore (at least, unless all attributes
+> will be supported), but simply GtkHSeparator.
+>
+> (I've some general doubts on the port, and wrote Jorge about it, but
+> didn't get an anser yet.)
+>
+> I thought that size negotiation should be similar as in Gtk+, i.e.
+> containers should (mainly) be responsible for it, plus a few
+> extensions (look into the list archives). This is just your idea,
+> except that all parameters are stored in the container. For this I
+> defined:
+>
+> struct _DwPageChild
+> {
+> GtkWidget *widget;
+> gfloat rel_width; /* 0: do not resize,
+> otherwise: relative to DwPage's width */
+> gfloat rel_height; /* analogue */
+> };
+>
+> /* ... */
+>
+> void a_Dw_page_add_widget (DwPage *page,
+> GtkWidget *widget,
+> gfloat rel_width,
+> gfloat rel_height,
+> gint attr);
+>
+> Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start.
+>
+> I tested it with GtkHSeparator (setting rel_width to 1.0), and it
+> (mainly) works. This also makes rules with other widths simple (as
+> soon as centered text is implemented).
+<snip>
+
+This all sounds great, if you need any help porting Dw just let me know what
+needs to be done.
+I realised after I had sent the patch to the list that it was going to be a
+little obsolete as you were working on the port of Dw. I think the cvs
+version of the tree should be kept more up to date, I sent an e-mail to
+Jorge about that, below is part of that e-mail (which discussed a number of
+things) it is just an idea for dw_page which I think might help us with
+table and frame support, and you may be in a better position to decide.
+
+<part of e-mail I sent to Jorge>
+Next is the topic of the dillo widget, it says that on the dillo homepage
+http://dillo.so....net/Notes.txt that the dillo widget needs a
+revision, I gather from the list that Sebastian Geerken is porting the Dw to
+plain GTK+ just like to say that this solution gets my vote, I don't see why
+we should re-implement stuff that has already been done and tested and will
+be further tested and updated for us.
+Lastly (bet you're glad) how far are we with tables/frames support, if the
+answer is "still discussing design options" then I would like to add my idea
+into the arena, I'm sure someone has probably suggested this, but, why don't
+we extend dw_page so that it can be one of the following
+1)Contain a number of horizontal sub pages
+2)Contain a number of vertical sub pages
+3)Be a page as they are now, stored as lines.
+Or we could have a wrapper, say dw_frame which could either contain
+horizontal subframes or vertical subframes or contain one dw_page, either
+way it is the same principle.
+This as far as I can tell should be capable of coping with frames and
+tables, even nested frames or tables, also it shouldn't be to difficult to
+code the support for both tables and frames as frames are already divide a
+page either horizontally or vertically, a table as well is just a divided
+horizontally, with each horizontal division (ie a row) being divided up
+vertically, so the html already lends itself to this kind of design. Also a
+page could be divided up for other things such as alignment, eg if you have
+two paragraphs the top is left aligned, and the bottom is center aligned,
+then we just divide it into two horizontal sub frames and all that would be
+needed would be coding to render a page whose lines are center/right
+alligned.
+<end of the part of e-mail I sent to Jorge>
+
+Allan 
+
+
+
+Re: [Dillo-dev]new here
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-22 18:06
+
+Allan Clark wrote:
+> 
+> Hi
+> As the subject says I'm new here,
+
+Welcome!
+
+> but I would like to submit a patch,
+> which I *think* fixes bug number 62 where the horizontal rules mean that
+> when Dillo reformats after being down-sized it gives the user an
+> unneccesary horizontal slider.
+> I defined a new flag in dw.c which is set when a widget is a set to fill
+> all the horizontal space available, then dw_hruler.c is changed to set
+> this flag and then dw_page.c is changed so that we check for the flag
+> when reformating and deal with it accordingly.
+> The way I have dealt with it means that the hrule will be as long as the
+> text of the page is, this means that it won't be as long as an image
+> which may be longer (check with dillo on the dillo homepage to see
+> this), this is the way Netscape renders it, but would be easy to change
+> if you don't like it.
+
+It is planned to port Dw to Gtk+, and I'm currently working on DwPage.
+DwHruler will then not used anymore (at least, unless all attributes
+will be supported), but simply GtkHSeparator.
+
+(I've some general doubts on the port, and wrote Jorge about it, but
+didn't get an anser yet.)
+
+I thought that size negotiation should be similar as in Gtk+, i.e.
+containers should (mainly) be responsible for it, plus a few
+extensions (look into the list archives). This is just your idea,
+except that all parameters are stored in the container. For this I
+defined:
+
+struct _DwPageChild
+{
+GtkWidget *widget;
+gfloat rel_width; /* 0: do not resize,
+otherwise: relative to DwPage's width */
+gfloat rel_height; /* analogue */
+};
+
+/* ... */
+
+void a_Dw_page_add_widget (DwPage *page,
+GtkWidget *widget,
+gfloat rel_width,
+gfloat rel_height, 
+gint attr);
+
+Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start.
+
+I tested it with GtkHSeparator (setting rel_width to 1.0), and it
+(mainly) works. This also makes rules with other widths simple (as
+soon as centered text is implemented).
+
+> Also I think it mucks up slightly if the horizontal rule is not directly
+> after a hard break, (that is the hrule isn't on a line all by itself, again
+> this should be easy to fix) it seems to render slightly further than it should.
+> Anyway see what you think.
+
+Since <hr>'s are allways the only widget on a line, it is probably the
+best to insert hard breaks before and after them.
+
+> [...]
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]email problems
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-22 03:59
+
+-- En reponse de "Re: [Dillo-dev]email problems" de Jorge Arellano Cid, le
+20-Sep-2000 :
+> 
+> Eric,
+> 
+>> Jorge,
+>> I'm having the hardest time with my ISP loosing email for some domains.
+>> Please
+>> confirm you have received my patches.
+> 
+> I haven't received a single one!
+> 
+
+Damn ! I haven't even got a non-delivery warning !
+
+> (and I wrote to your address reporting that some time ago...)
+> 
+> Shame I can't suggest you a good email provider. I switch
+> between nettaxi and ematic :-). (Maybe you can try ematic as an
+> alternative account).
+> 
+
+Actually, I tried 2 different smpt in 2 different countries with the same
+(no-)result. 
+Do you mind if I try to send you some test emails to nettaxi and ematic ?
+
+Anyway, I posted all my patches and some explanations at :
+http://www.rti-zone.org/dillo/
+
+I'll try to fix these email problems soon.
+
+> Jorge.-
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 22-Sep-2000 a 12:39:40
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]email problems
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-09-22 01:58
+
+Eric,
+
+> Jorge,
+> I'm having the hardest time with my ISP loosing email for some domains. Please
+> confirm you have received my patches.
+
+I haven't received a single one!
+
+(and I wrote to your address reporting that some time ago...)
+
+Shame I can't suggest you a good email provider. I switch
+between nettaxi and ematic :-). (Maybe you can try ematic as an
+alternative account).
+
+Jorge.- 
+
+
+
+[Dillo-dev]Repeated patch
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-19 15:59
+
+Attachments: html_loading.diff      
+
+I think the mail server is eating my messages... anyway, here's the patch I
+sent again, as I never received a copy back (sorry if this is a repeat).
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev](no subject)
+
+From: Allan Clark <allan@al...> - 2000-09-19 13:16
+
+Attachments: hrule2.diff      
+
+Sorry about the empty e-mail I pressed the wrong button.
+Here is the newer patch for the hrules which differ slightly from the original
+and takes into account the feedback from Jorgen and Eric. 
+
+
+
+[Dillo-dev](no subject)
+
+From: Allan Clark <allan@al...> - 2000-09-19 13:11
+
+
+
+
+
+RE: [Dillo-dev]horizontal rules
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-19 13:01
+
+-- En reponse de "[Dillo-dev]horizontal rules" de Allan Clark, le 19-Sep-2000 :
+> Quick question for you all.
+> Should horizontal rules always be on a line by themeselves or should they be
+> allowed to follow text.
+> eg
+> allan------
+> is that correct or should it be forced to be
+> allan
+> -----------
+> 
+
+The latter is correct (html spec).
+Stop worrying about hrulers, I sent a patch for HR full rendering and
+correcting this behavior a few weeks ago (against 0.2.4, not published yet, but
+likely due for next version)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 19-Sep-2000 a 21:54:46
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]horizontal rules
+
+From: Jörgen Viksell <vsksga@ho...> - 2000-09-19 12:54
+
+>Quick question for you all.
+>Should horizontal rules always be on a line by themeselves or should they 
+>be
+>allowed to follow text.
+>eg
+>allan------
+>is that correct or should it be forced to be
+>allan
+>-----------
+
+The w3 recommendation defines it as a divider of sections of text. So I'd 
+say that it should be on its own line.
+
+// Jörgen
+
+
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
+
+Share information about yourself, create your own public profile at 
+http://profiles.msn.com. 
+
+
+
+Re: [Dillo-dev]cache patch
+
+From: Luca Rota <drake@it...> - 2000-09-19 12:32
+
+Il sab, 16 set 2000, hai scritto:
+
+> actually. i have placed all released versions of dillo in cvs. Jorge is now
+> using cvs. So cvs is newer than the release.
+
+Wow! Thank you, I didn't know.
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]horizontal rules
+
+From: Allan Clark <shark@bl...> - 2000-09-19 11:37
+
+Quick question for you all.
+Should horizontal rules always be on a line by themeselves or should they be
+allowed to follow text.
+eg
+allan------
+is that correct or should it be forced to be
+allan
+-----------
+
+Let me know what you think I can do it either way but I'm not sure which is
+correct.
+p.s. I realise the formatting of the above example might not work on some
+e-mail clients but I kept it small so that it should on most.
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+[Dillo-dev]Test
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-18 20:30
+
+Just testing, haven't received any mails back from this thing, oddly.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Actual fix
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-18 16:10
+
+Attachments: html_loading.diff      
+
+Sorry about the last patch, I didn't have a version of gdb that worked with
+dillo so diagnosing the problem was difficult. It turns out that to fix bugs
+#74 and #69, all that is needed is two simple checks. I'm sure that there's
+a deeper problem, but it doesn't hurt to check for null pointers, which is
+what we are currently getting, and this *does* solve the problem.
+
+Patch enclosed.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]new here
+
+From: Allan Clark <allan@al...> - 2000-09-18 10:52
+
+Attachments: hrule.diff      
+
+Hi
+As the subject says I'm new here, but I would like to submit a patch,
+which I *think* fixes bug number 62 where the horizontal rules mean that
+when Dillo reformats after being down-sized it gives the user an
+unneccesary horizontal slider.
+I defined a new flag in dw.c which is set when a widget is a set to fill
+all the horizontal space available, then dw_hruler.c is changed to set
+this flag and then dw_page.c is changed so that we check for the flag
+when reformating and deal with it accordingly.
+The way I have dealt with it means that the hrule will be as long as the
+text of the page is, this means that it won't be as long as an image
+which may be longer (check with dillo on the dillo homepage to see
+this), this is the way Netscape renders it, but would be easy to change
+if you don't like it.
+Also I think it mucks up slightly if the horizontal rule is not directly
+after a hard break, (that is the hrule isn't on a line all by itself, again
+this should be easy to fix) it seems to render slightly further than it should.
+Anyway see what you think.
+I am also hoping that the new flag defined might help us in frames and tables,
+where the frame or table cell width is not an absolute value but is given as
+"whatever space is left after drawing the previous frames/table cells.
+Also I don't think I have made the patch correctly, it says in the docs to use
+diff -pru but when I did cvs came back with an error saying no such option, in
+the end I used cvs diff > hrule.diff, please tell me if this is wrong and what
+I should be doing.
+
+Allan 
+
+
+
+[Dillo-dev]Debugging problems
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-17 23:48
+
+Has anyone else had problems debugging dillo with gdb? I'm getting unkown
+signals soon after I run or attach.
+
+Admittedly, I am using a gdb release from '96...
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]cache patch
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-16 17:04
+
+> Please, sends your patches to Jorge. But before takes the new dillo's version
+> from download.so....net/dillo/ the cvs version is quite outdated.
+> 
+
+actually. i have placed all released versions of dillo in cvs. Jorge is now
+using cvs. So cvs is newer than the release. 
+
+
+
+Re: [Dillo-dev]cache patch
+
+From: Luca Rota <drake@it...> - 2000-09-16 13:42
+
+Il sab, 16 set 2000, hai scritto:
+
+Welcome,
+
+> Hi, I'm new to dillo development, although I worked with armadillo for a
+> while, I've been looking at your cache system and have made a change which
+
+Oh, yes. I remember a justification patch and the html stack patch. Right?
+
+> seems to cause less segfaults when moving around without waiting for things
+> to finish downloading (which has crashed dillo many times for me). It's
+> probably not correct, but it does seem to improve the situation.
+
+Please, sends your patches to Jorge. But before takes the new dillo's version
+from download.so....net/dillo/ the cvs version is quite outdated.
+
+Ciao,
+Luca 
+
+
+
+[Dillo-dev]cache patch
+
+From: Sam Dennis <sdennis101@ge...> - 2000-09-16 04:15
+
+Attachments: cache_patch.gz      
+
+Hi, I'm new to dillo development, although I worked with armadillo for a
+while, I've been looking at your cache system and have made a change which
+seems to cause less segfaults when moving around without waiting for things
+to finish downloading (which has crashed dillo many times for me). It's
+probably not correct, but it does seem to improve the situation.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Sizes in html
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-14 12:07
+
+Hi!
+
+While porting the DwPage, I'm thinking about how widgets in the page
+should be resized. (Anything except text will be a widget, even
+probably <div>'s with align=left/right (a new DwPage), but alignments
+are far away from an implementation.)
+
+DwPage is derived from GtkContainer, and Gtk+ containers typically are
+responsible on positioning and resizing of their children. (An
+exception is, of course, when widgets resize thereselves, then the
+container has to react on this.) E.g., if you want to add a widget to
+a GtkBox, you use gtk_box_pack_start and set the arguments expand,
+fill and padding to the appropriate values, and anything else is done
+by the GtkBox.
+
+So, which parameters should be used by a_Dw_page_add_widget? My
+current idea is based on relative width and height, or zero to prevent
+resizing by DwPage. It the latter case, the widget's size has to be
+set otherwise (e.g. by the html parser). This is quite obvious for
+images, but it is also suitable for tables: they should (in most
+cases) be added with a relative width of 100%, since they should be
+resized when the page is resized, but then can calculate the size they
+really need.
+
+Send any comments, about this idea in general, or if you find that my
+idea is not suitable for a specified html elemtent.
+
+Another point is positioning. The only thing which comes currently to
+mind, is the "align" attribute of some tags. But this will be done
+later.
+
+Sebastian 
+
+
+
+[Dillo-dev]email problems
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-13 06:27
+
+Jorge,
+I'm having the hardest time with my ISP loosing email for some domains. Please
+confirm you have received my patches.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 13-Sep-2000 a 15:26:12
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Plugins design
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-13 00:30
+
+> I have two options :
+> - use a special Content-Type=x-dillo-command. What if we need to send
+> both commands and a document in a single answer ? Either I'll have to
+> dirty-hack the header parsing function to ignore and redirect 
+> x-dillo-command content until it finds an other content-type, or
+> I'll have to add support for multipart-mime, which seems an overkill.
+> - use special http header fields. Pragma seems to be an application
+> specific sort-of field. Sending Pragma: AddMenu="Add Bookmark" would be
+> understood by dillo to be a command sent by the plugin for him.
+> Alternatively, we can use a non-http field (X-Dillo-Command:), as
+> fields begining with X- can't exist in future http implementations, and
+> it's a local communication anyway.
+> 
+
+If you must use http, you definately want to use X- headers. 
+
+
+
+Re: [Dillo-dev]implementation question: how to decide if a font
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-12 09:35
+
+Sean 'Shaleh' Perry wrote:
+> [...]
+> > (Although the implementation looks a bit strange: 1. I think there
+> > should be a global font list; 2. The Gdk fonts are not removed? But
+> > this is a separate problem.)
+> >
+> 
+> yes, a global list would be nice, also, a global size array. I have font
+> size=2 or font size=+3 working, but i had to implement a local size list
+> because the open_h() function need a list in descending order and I wanted a
+> list in ascending order.
+
+I think, it is not very important, where the fonts are stored, when
+you have a simple interface to access them. This is an implementian
+detail, which does not effect the code outside.
+
+BTW: Other widgets (e. g. buttons) use fonts, too. Currently, there
+fonts are given by Gtk, but may the html author change them?
+
+> > I remember that there are a few more attributes (e.g. underlining,
+> > backgrounds), which I will add perhaps, after my Gtk port of DwPage is
+> > running correctly.
+> >
+> 
+> I am trying to implement the <u> tag now. It looks like all I have to do is
+> modify dw_page_expose_line(), this is where the link is underlined. However my
+> boolean is not surviving into the function call. Most confusing. If I don't
+> get it in a day or so, would you mind taking a peek?
+
+The best way will be to extend the DwPageAttr structure. Then any
+attributes can be simply set by filling an DwPageAttr structure, and
+DwPage will be responsible for render them. (I can do the last, but
+first I want to finish the Gtk+ port to DwPage.)
+
+> > a_Dw_page_init_attr (DW_PAGE (page), &attr);
+> > attr.font = a_Dw_page_find_font (DW_PAGE (page), &font);
+> > attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr);
+> > 
+> 
+> but a_Dw_page_find_font() does not actually check to see if a font can be
+> rendered. What if your system lacked 'times new roman'.
+> 
+> <font face="Lucida,Verdana,Helvetica,Arial">My text</font>
+> 
+> I have to decide which in that list of fonts I can use. In this case, Lucida
+> and Helvetica are known to work, I am sure Arial will. But I have no way to
+> query dillo to find out if font 'foo' can be loaded.
+> 
+> Perhaps find_font should try to look up the font via gdk and give back a "could
+> not find it" error? Or perhaps we need a query_system_font() to see if a font
+> is valid, then find_font() to load it into dillo.
+
+The font is loaded in Dw_page_realize_font. Perhaps this function
+could be modified, so that you may specify alternatives, when calling
+a_Dw_page_find_font. As I wrote above, the interface should be as
+simple as possible, so a query function is probably not a good idea.
+
+Sebastian 
+
+
+
+[Dillo-dev]Plugins design
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-12 01:58
+
+Hi all,
+I'm currently working for plugins support in dillo, and I feel the need
+for a communication protocol between the plugin and dillo.
+
+So far, dillo calls a plugin, sends a bunch of <name=value> parameters,
+and waits for an http-like answer, most of the time being
+Content-Type=text/html <html> ... </html>
+
+Now, say the Bookmarks plugin wants to ask dillo to ask an "Add
+Bookmark" menu, and also an "Edit Bookmarks" menu. How can it do that ?
+Say the Ftp plugin wants to tell dillo he can handle "ftp://" urls, as
+well as the "Mailto" plugin want to tell dillo he can handle "mailto:"
+urls. How can it do that ?
+
+I have two options :
+- use a special Content-Type=x-dillo-command. What if we need to send
+both commands and a document in a single answer ? Either I'll have to
+dirty-hack the header parsing function to ignore and redirect 
+x-dillo-command content until it finds an other content-type, or
+I'll have to add support for multipart-mime, which seems an overkill.
+- use special http header fields. Pragma seems to be an application
+specific sort-of field. Sending Pragma: AddMenu="Add Bookmark" would be
+understood by dillo to be a command sent by the plugin for him.
+Alternatively, we can use a non-http field (X-Dillo-Command:), as
+fields begining with X- can't exist in future http implementations, and
+it's a local communication anyway.
+
+What do you think ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Sep-2000 a 10:38:04
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-12 01:36
+
+--- En reponse de "Re: [Dillo-dev]Misc." de Luca Rota, le 11-Sep-2000 :
+> Il dom, 10 set 2000, hai scritto:
+> 
+> > If you'd like to know some of the reasons of current goals in
+> > dillo, may I suggest:
+> > 
+> > - Cathedral & the Bazaar (ESR)
+> > - Homesteading the noosphere (ESR) 
+> > - http://www.levien.com/free/decommoditizing.html (Raph Levien)
+> > - http://www.mcsr.olemiss.edu/~mudws/font.html
+> > - http://www.tuxedo.org/~esr/html-hell.html
+> 
+> May I suggest:
+> http://www.levien.com/free/gzilla-tour.html (A tour of Gzilla 0.1.7)
+> 
+
+All these links deserve to be in dillo's home page.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Sep-2000 a 10:35:42
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Luca Rota <drake@it...> - 2000-09-11 16:55
+
+Il dom, 10 set 2000, hai scritto:
+
+> If you'd like to know some of the reasons of current goals in
+> dillo, may I suggest:
+> 
+> - Cathedral & the Bazaar (ESR)
+> - Homesteading the noosphere (ESR) 
+> - http://www.levien.com/free/decommoditizing.html (Raph Levien)
+> - http://www.mcsr.olemiss.edu/~mudws/font.html
+> - http://www.tuxedo.org/~esr/html-hell.html
+
+May I suggest:
+http://www.levien.com/free/gzilla-tour.html (A tour of Gzilla 0.1.7)
+
+I'd like focus your attention on:
+levien> the main design goals were that Gzilla be small, simple, and fast. I
+had a few other goals. For one, I wanted Gzilla to be really good at
+incremental rendering. 
+
+levien> the Gzw (Gzilla Widget) framework was in place, providing a much more
+powerful infrastructure for future development such as tables.
+
+Please, read the GZW section carefully.
+
+Note: Dillo is based on gzilla code and GZW is the original name of Dw.
+
+Ciao,
+Luca 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: <ikluft@th...> - 2000-09-11 01:19
+
+>From: "Jorge Arellano Cid" <jcid@ne...>
+>> Embbeding Perl 5...
+>
+> Although not a bad idea "per se", this is not the project for
+>trying it. Dillo can't even render HTML by now, a module API is
+>inexistent, and the Dw (dillo widget) is migrating to GTK+ in an
+>effort to overcome a bunch of rendering-related problems. 
+>
+> May I suggest galeon? It uses gecko, has an API, is smaller
+>than mozilla and it's also free.
+
+Thanks for the pointer. I didn't see them on Freshmeat since they got
+categorized under GNOME instead of with the other web browsers.
+
+I'll go look over there. Consider the patch that I sent for using glib
+hash tables on the About menus to be a gift from an Open Source supporter
+who was "passing through". (But I can understand if you'll want to
+pull my personal URL out of there - I was planning on sticking around
+when I put that there. :-) For future reference, that kind of patch
+can also serve as an example of replacing linear searches with hash
+lookups to build future scalability into your project. That's experience
+I've gotten from 10 years working in the industry, including on OS's from
+a mainframe Unix to an embedded OS for large routers. I hope it helps.
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+Re: [Dillo-dev]implementation question: how to decide if a font
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 23:19
+
+> 
+> a_Dw_page_init_attr (DW_PAGE (page), &attr);
+> attr.font = a_Dw_page_find_font (DW_PAGE (page), &font);
+> attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr);
+> 
+
+but a_Dw_page_find_font() does not actually check to see if a font can be
+rendered. What if your system lacked 'times new roman'.
+
+<font face="Lucida,Verdana,Helvetica,Arial">My text</font>
+
+I have to decide which in that list of fonts I can use. In this case, Lucida
+and Helvetica are known to work, I am sure Arial will. But I have no way to
+query dillo to find out if font 'foo' can be loaded.
+
+Perhaps find_font should try to look up the font via gdk and give back a "could
+not find it" error? Or perhaps we need a query_system_font() to see if a font
+is valid, then find_font() to load it into dillo. 
+
+
+
+Re: [Dillo-dev]implementation question: how to decide if a font
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 23:04
+
+> 
+> It's quite simple, but I think, you should only use the
+> a_Dw_page_find_font function: Fill out a DwPageFont structure, then
+> call this function, and you will get an index you can use in the
+> DwPageAttr structure. I wrote something like the following, and it
+> worked:
+> 
+> <code snipped>
+> 
+> Only as an example. You don't have to bother about loading and
+> removing of fonts.
+> 
+> (Although the implementation looks a bit strange: 1. I think there
+> should be a global font list; 2. The Gdk fonts are not removed? But
+> this is a separate problem.)
+> 
+
+yes, a global list would be nice, also, a global size array. I have font
+size=2 or font size=+3 working, but i had to implement a local size list
+because the open_h() function need a list in descending order and I wanted a
+list in ascending order.
+
+> I remember that there are a few more attributes (e.g. underlining,
+> backgrounds), which I will add perhaps, after my Gtk port of DwPage is
+> running correctly.
+> 
+
+I am trying to implement the <u> tag now. It looks like all I have to do is
+modify dw_page_expose_line(), this is where the link is underlined. However my
+boolean is not surviving into the function call. Most confusing. If I don't
+get it in a day or so, would you mind taking a peek?
+
+> PS2: Two wishes: 1. Give the user the possibility to turn off any
+> loading of non-standard fonts (except the user's style sheet), 2. A
+> factor for size would be nice, i.e. the user should specify that dillo
+> should use x times the font size specified by the author of the page.
+> 
+
+these are both great options.
+
+Once my font patch is accepted, I would also like a standard size list created
+as mentioned above. I just winged it.
+
+Once I get underline working, I have all of the font modifying tags implemented. 
+
+
+
+Re: [Dillo-dev]implementation question: how to decide if a font
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-10 22:55
+
+Sean 'Shaleh' Perry wrote:
+> 
+> >
+> > However, this is widely used. If you can do it easily, why not ?
+> >
+> 
+> it can be done fairly easily. style sheets also allow for aribitrary fonts to
+> be used.
+> 
+> My initial question was: how do we want to implement this? My experience with
+> gtk is minimal, fonts even less.
+
+It's quite simple, but I think, you should only use the
+a_Dw_page_find_font function: Fill out a DwPageFont structure, then
+call this function, and you will get an index you can use in the
+DwPageAttr structure. I wrote something like the following, and it
+worked:
+
+DwPageFont font;
+DwPageAttr attr;
+gint attr_i;
+
+/* ... */
+
+font.name = "times";
+font.size = 14;
+font.bold = FALSE;
+font.italic = FALSE;
+
+a_Dw_page_init_attr (DW_PAGE (page), &attr);
+attr.font = a_Dw_page_find_font (DW_PAGE (page), &font);
+attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr);
+
+a_Dw_page_add_text (DW_PAGE (page), "Some text.", attr_i);
+
+Only as an example. You don't have to bother about loading and
+removing of fonts.
+
+(Although the implementation looks a bit strange: 1. I think there
+should be a global font list; 2. The Gdk fonts are not removed? But
+this is a separate problem.)
+
+I remember that there are a few more attributes (e.g. underlining,
+backgrounds), which I will add perhaps, after my Gtk port of DwPage is
+running correctly.
+
+Sebastian
+
+PS1: I'm currently porting DwPage to Gtk, but the interface will be
+the same (except adding widgets), so I hope, your changes will run
+with both versions of DwPage.
+
+PS2: Two wishes: 1. Give the user the possibility to turn off any
+loading of non-standard fonts (except the user's style sheet), 2. A
+factor for size would be nice, i.e. the user should specify that dillo
+should use x times the font size specified by the author of the page. 
+
+
+
+RE: [Dillo-dev]Misc.
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 22:22
+
+> 
+> Gentleman, please, there's no CSS support in dillo by now, it's
+> NOT a near future concern, and it can't cope with preferences
+> like: 
+> 
+> "don't allow cookies"
+> "download directory = ~/download"
+> "discard animated gifs"
+> "Don't load images"
+> "Start with 600x400"
+> etc...
+> 
+
+indeed, but it does handle:
+
+"no white backgrounds"
+"use font "blah" for tag foo"
+and just about any form of "I want html to look like"
+
+> --------------------------------------------------------------
+> 
+>> Badly written HTML...
+> 
+> Well, certainly an arguable topic, but the current position is
+> NOT to support badly written HTML.
+> 
+
+dillo should support the "oops" as much as possible. Simply forgetting to
+close a tag should not ruin the rest of the page. Users will see this as a bug
+in dillo.
+
+> - If the publisher wants to reach a broad spectrum, he'll
+> strive for correct HTML.
+
+Web sites that allow users to post responses with embedded html have no means
+to control what users enter. Letting a fellow open a font or bold tag and
+making the rest of the page look horrid just seems wrong. It is trivial to get
+tags like bold to clean up after previous bold tags.
+
+> --------------------------------------------------------------
+> 
+>> The question is do we want to actually make dillo display
+>> html like the web author intended?
+> 
+> Quite interesting question!
+> 
+> The answer is: NO!
+> 
+> Ideally, in dillo, the html should be displayed the way the
+> user wants, not the author.
+> 
+
+back to CSS here. Load YOUR sheet last, and you override the author. 
+
+
+
+[Dillo-dev]Misc.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-09-10 21:59
+
+Hi!
+
+
+Lots of email lately, hmmmm...
+
+Let's clarify some things:
+
+- Dillo is a lean, small and fast web client.
+- Dillo still can't render HTML (This is the main goal)
+- Dillo is very far away from supporting scripting languages.
+- CSS is NOT a priority, nor a concern by now.
+- Dillo aims to be a usable HTML web browser.
+
+The "fully standards compliant" browser project is mozilla, a
+better start for scripting languages is galeon (uses the gecko
+engine), if you also want to "get&feel" M$ content, you should go
+with the latest flavour of IE (probably on Windoze!;), and if you
+don't like Win* and also want the as-full-as-possible Internet
+experience, you'd probably should keep with Netscape.
+
+If you'd like to know some of the reasons of current goals in
+dillo, may I suggest:
+
+- Cathedral & the Bazaar (ESR)
+- Homesteading the noosphere (ESR) 
+- http://www.levien.com/free/decommoditizing.html (Raph Levien)
+- http://www.mcsr.olemiss.edu/~mudws/font.html
+- http://www.tuxedo.org/~esr/html-hell.html
+
+--------------------------------------------------------------
+
+> I have one problem that I can't seem to get around. Our site uses a SSL
+> (security socket layer) that the standard http_proxy setting doesn't allow
+> for. I would like some help regarding this issue if possible!
+
+Probably the easiest way around it is to grab the https pages
+with 'curl' and sending them to dillo using dillo's simple plugin
+scheme (currently in alpha, but working).
+Sean's idea is also a good starting point (libssl).
+
+> Thanks again for making Dillo such a great product!
+
+Thanks to you for greeting us
+(Would you believe that aprox. only 1 of 8 persons take time to
+write a gentle comment at first post?)
+
+--------------------------------------------------------------
+
+> Embbeding Perl 5...
+
+Although not a bad idea "per se", this is not the project for
+trying it. Dillo can't even render HTML by now, a module API is
+inexistent, and the Dw (dillo widget) is migrating to GTK+ in an
+effort to overcome a bunch of rendering-related problems. 
+
+May I suggest galeon? It uses gecko, has an API, is smaller
+than mozilla and it's also free.
+
+--------------------------------------------------------------
+> ...
+> as I mentioned in a previous mail, user preferences could easily 
+> be stored as a local style sheet which was added to the end of the style
+> sheet reading.
+
+Gentleman, please, there's no CSS support in dillo by now, it's
+NOT a near future concern, and it can't cope with preferences
+like: 
+
+"don't allow cookies"
+"download directory = ~/download"
+"discard animated gifs"
+"Don't load images"
+"Start with 600x400"
+etc...
+
+--------------------------------------------------------------
+
+> Badly written HTML...
+
+Well, certainly an arguable topic, but the current position is
+NOT to support badly written HTML.
+
+Mainly due to: 
+
+* http://www.levien.com/free/decommoditizing.html
+- If the publisher wants to reach a broad spectrum, he'll
+strive for correct HTML.
+
+Note: I'm sure there're different opinions on this.
+
+--------------------------------------------------------------
+
+> The question is do we want to actually make dillo display
+> html like the web author intended?
+
+Quite interesting question!
+
+The answer is: NO!
+
+Ideally, in dillo, the html should be displayed the way the
+user wants, not the author.
+
+One of the things a dislike more about Netscape is to have to
+see the page's as the author wants. No matter how hard I try to
+set my preferences to use certain fonts and sizes, they seem to
+always find the trick to get over my settings.
+Not to mention scaled fonts that look trembling & tiny, etc.
+
+Finally, I definitively agree that those pages have, by far, a
+better looking result when looked from a distance :-). Personally
+I do prefer dillo's rendering for reading HTML documentation.
+
+--------------------------------------------------------------
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]implementation question: how to decide if a font
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 19:46
+
+> 
+> However, this is widely used. If you can do it easily, why not ?
+> 
+
+it can be done fairly easily. style sheets also allow for aribitrary fonts to
+be used.
+
+My initial question was: how do we want to implement this? My experience with
+gtk is minimal, fonts even less. 
+
+
+
+RE: [Dillo-dev]implementation question: how to decide if a font
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-10 09:38
+
+--- En reponse de "RE: [Dillo-dev]implementation question: how to
+decide if a font" de Sean 'Shaleh' Perry, le 10-Sep-2000 :
+> > 
+> > A good thing would be to load 2 fonts (proportionnal and mono) from
+> > dillorc and use only these everywhere in dillo.
+> > I'm not sure you want to load fonts on request. You probably can do
+> > it,
+> > it's even possible other browsers do it, but I'm not sure it's
+> > needed. 
+> > 
+> 
+> dillo currently uses: courier and lucida for special tags and
+> helvetica for everything else. The question is do we want to
+> actually make dillo display html like the web author intended? I
+> can understand not wanting to load each and every font asked for,
+> but requests for items like arial or in the case of
+> freshmeat lucida, which we are already using, why not allow it?
+
+The html author is not supposed to ask for a font (even if he can) :
+only if it's proportionnal or fixed width. He's not even supposed to
+specify B(old), I(talic) or any style, but use instead STRONG, EM tags.
+That's the same thing of using special chars instead of entities.
+
+However, this is widely used. If you can do it easily, why not ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Sep-2000 a 18:32:45
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]implementation question: how to decide if a font
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 06:56
+
+> 
+> A good thing would be to load 2 fonts (proportionnal and mono) from
+> dillorc and use only these everywhere in dillo.
+> I'm not sure you want to load fonts on request. You probably can do it,
+> it's even possible other browsers do it, but I'm not sure it's needed. 
+> 
+
+dillo currently uses: courier and lucida for special tags and helvetica for
+everything else. The question is do we want to actually make dillo display
+html like the web author intended? I can understand not wanting to load each
+and every font asked for, but requests for items like arial or in the case of
+freshmeat lucida, which we are already using, why not allow it? 
+
+
+
+RE: [Dillo-dev]implementation question: how to decide if a font 
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-10 06:46
+
+--- En reponse de "[Dillo-dev]implementation question: how to decide if
+a font is v" de Sean 'Shaleh' Perry, le 10-Sep-2000 :
+> I am working on <font face="foo,bar">. There is no central list of
+> fonts dillo
+> is willing to support or a way to query them. Html_page_check
+> declares an array
+> of 4 font names, but only helvetica ([0]) is used from that array.
+> 
+
+teletype style and PRE use courier, but hard-coded, not from this array
+(which is local anyway). 
+
+...
+> 
+> can dillo load font 'foo'?
+> 
+> Suggestions? I suspect this will require code in dw_page.c.
+> 
+
+A good thing would be to load 2 fonts (proportionnal and mono) from
+dillorc and use only these everywhere in dillo.
+I'm not sure you want to load fonts on request. You probably can do it,
+it's even possible other browsers do it, but I'm not sure it's needed. 
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Sep-2000 a 15:34:09
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]implementation question: how to decide if a font is valid
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 06:00
+
+I am working on <font face="foo,bar">. There is no central list of fonts dillo
+is willing to support or a way to query them. Html_page_check declares an array
+of 4 font names, but only helvetica ([0]) is used from that array.
+
+the face attribute of font is a comma separated list of the fonts the html
+author wanted to use, in order of preference. To continue with freshmeat:
+
+<FONT FACE="Lucida,Verdana,Helvetica,Arial">
+
+so, try Lucida, then Verdana, then Helvetica, then settle for Arial.
+
+What I need is a way to say:
+
+can dillo load font 'foo'?
+
+Suggestions? I suspect this will require code in dw_page.c. 
+
+
+
+[Dillo-dev]handling poorly written html
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 05:45
+
+So, was reading the recent freshmeat editorial when i noticed that freshmeat's
+html creation software likes to leave <b>'s open. So I tried to make bold
+close any open bold tags. First I tried Html_cleanup_tag(), which was already
+in use and thus documented. However cleanup_tag only handles the case of
+"<p><p>", i.e. back to back tags. freshmeat was doing "<b><font></font><b>". 
+So I looked at pop_tag. This function appears to properly handle the case
+where there are extra tags between the tag in question and the one I want
+removed. my dillo can now read html that has dangling b tags. Will probably
+add more of this type code as we discover other bad html.
+
+Point of this letter is this: Html_cleanup_tag is redundant considering the
+power of Html_pop_tag. Html_cleanup_tag also fails miserably on many pieces of
+html. I have a patch prepared which removes this function and replaces all
+calls to it with Html_pop_tag.
+
+Comments?
+
+P.S. Html_pop_tag has a todo comment, handle the case where tags dont nest. As
+I have stated above, it seems to do so. Can anyone point to cases where it
+fails? 
+
+
+
+RE: [Dillo-dev]on the subject of SCRIPT tags
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 02:41
+
+> 
+> I guess the events (onClick in a A tag,...) are to be done yet.
+> 
+
+yep, setup the events and then make it so they call the interpeter. 
+
+
+
+RE: [Dillo-dev]News
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 02:40
+
+> 
+> I remember that. Do we support style sheets now ? (or are we about to ?)
+> Good idea anyway.
+> 
+
+no, but it is on my todo list. As I mentioned we can inch our way in by
+storing prefs in style sheet format. This gets the style sheet parser working. 
+
+
+
+Re: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: <ikluft@th...> - 2000-09-10 02:27
+
+>From: Eric GAUDET <egaudet@in...>
+>Embeding perl in dillo would probably never go into dillo's main
+>distribution. But that doesn't mean it's not interesting nor you
+>shouldn't do it. Find your way doing it as a side project for dillo
+>using dillo's standard interfaces (plugin or module).
+
+Well, it's too big an effort to undertake unless it's likely the
+project will embrace it to a greater degree than that.
+
+I fully respect that the volunteers who have contributed to the project
+should determine its direction. And I think Dillo looks promising.
+
+But I'm sure it won't be a surprise if I continue looking for a place
+where the browser-side perl idea would have a stronger acceptance. I'm
+willing to do this work but I most certainly don't want it to disturb
+volunteers who have already contributed. Maybe the idea's time just
+hasn't come yet.
+
+In any case, I appreciate the time you've taken to help me consider what
+the options were for this idea. I wish you success. I'll mention this
+project to anyone who sounds like they might be interested in volunteering.
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+RE: [Dillo-dev]News
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-10 02:14
+
+--- En reponse de "RE: [Dillo-dev]News" de Sean 'Shaleh' Perry, le
+09-Sep-2000 :
+> > 
+> > I'm working on the Bookmarks plugin right now, and I've got lots of
+> > ideas fo plugins things. I'm willing to make a Preferences plugin
+> > too, as I saw the project is suspended and drake is most likely
+> > out of dillo.
+> > 
+> 
+> as I mentioned in a previous mail, user preferences could easily be
+> stored as a local style sheet which was added to the end of the
+> style sheet reading. This way user prefers override the author's
+> prefs. Or maybe an option "override web author?". If no, the
+> style would be read first.
+>
+> style sheets let the user specifiy almost anything about the look of
+> a web page
+> -- bg color, image, text colors by tag, etc.
+> 
+> If you could make the preference item output a style sheet formatted
+> file, we can only load it and ignore style sheets for right now.
+
+I remember that. Do we support style sheets now ? (or are we about to ?)
+Good idea anyway.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Sep-2000 a 11:12:05
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: <ikluft@th...> - 2000-09-10 02:14
+
+>From: "Sean 'Shaleh' Perry" <shaleh@vi...>
+>And here I was thinking the point of dillo was not to be the next mozilla.
+>
+>Guys, just once could a project do its job and only its job. I want a lean,
+>mean, web browser. It should support whatever the w3c says a web browser
+>should support and that is about it. Maybe some little tweaks to make a user's
+>life happier.
+
+OK, I understand.
+
+That was why I asked. I didn't know the opinions out there. You're all
+the ones who have done the work so far and that must be respected in
+any volunteer effort. The polite thing to do was bring it up for
+discussion and actually listen to the answers.
+
+Well, I'm listening and it's 0 for 2 right now. One more makes it
+a trend. :-) Oh well. It was worth the try.
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+Re: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-10 02:11
+
+--- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian
+Kluft, le 09-Sep-2000 :
+<snip snip>
+> Those examples were looking further out in the future, assuming this
+> feature were accepted by the group and had time to build out
+> access to lots of Dillo's APIs. I'm thinking of starting with a
+> module, adding perl interfaces to existing Dillo module APIs one
+> at a time, and seeing where it goes from
+> there. The idea of a plugin could be explored as a follow-on.
+> 
+<snip snip>
+
+Ok, as you seem quite excited by this idea, here are your options:
+
+- If you don't feel the need for constant interaction with dillo, go
+for a plugin. You can do that without any dillo-dev consensus : this is
+an external program (a project outside of dillo) launched in a shell by
+dillo when clicking on a fake url "dpi://<plugin-name>/<parameters>",
+doing his job (such as saving a file), sending datas to dillo (such as
+an html page), then exit. Plugins are being implemented now (I did a
+plugin-lib and I'm studying dillo's side calls), you'll be able to test
+your plugin quite soon, and you'll have support (by me at least ;-)
+
+- If you can live without dillo's interactions, you'll need a module.
+There's no module interface planned for now : you'll have to design it,
+and it will be accepted only if it's a generic module interface (not
+perl-specific) so others can benefit your work and do other modules.
+You'll have to work alone because we don't want to bloat dillo with a
+bunch of modules, and we don't feel immediate use of modules (you've
+heard Sean : I believe he doesn't want modules at all, I'm not sure I
+want that myself).
+
+Embeding perl in dillo would probably never go into dillo's main
+distribution. But that doesn't mean it's not interesting nor you
+shouldn't do it. Find your way doing it as a side project for dillo
+using dillo's standard interfaces (plugin or module).
+
+ciao
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Sep-2000 a 10:45:10
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]on the subject of SCRIPT tags
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-10 01:19
+
+--- En reponse de "[Dillo-dev]on the subject of SCRIPT tags" de Sean
+'Shaleh' Perry, le 09-Sep-2000 :
+> One of the patches I have given Jorge is to have script tags use the
+> stash. 
+> So, now all of the script code is stored somewhere, you just have to
+> get
+> it to the interpreter and add support for script hooks in html tags.
+
+I guess the events (onClick in a A tag,...) are to be done yet.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Sep-2000 a 10:17:46
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]News
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 19:12
+
+> 
+> I'm working on the Bookmarks plugin right now, and I've got lots of
+> ideas fo plugins things. I'm willing to make a Preferences plugin too,
+> as I saw the project is suspended and drake is most likely out of dillo.
+> 
+
+as I mentioned in a previous mail, user preferences could easily be stored as a
+local style sheet which was added to the end of the style sheet reading. This
+way user prefers override the author's prefs. Or maybe an option "override web
+author?". If no, the style would be read first.
+
+style sheets let the user specifiy almost anything about the look of a web page
+-- bg color, image, text colors by tag, etc.
+
+If you could make the preference item output a style sheet formatted file, we
+can only load it and ignore style sheets for right now. 
+
+
+
+[Dillo-dev]on the subject of SCRIPT tags
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 19:08
+
+One of the patches I have given Jorge is to have script tags use the stash. 
+So, now all of the script code is stored somewhere, you just have to get
+it to the interpreter and add support for script hooks in html tags. 
+
+
+
+RE: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 19:07
+
+And here I was thinking the point of dillo was not to be the next mozilla.
+
+Guys, just once could a project do its job and only its job. I want a lean,
+mean, web browser. It should support whatever the w3c says a web browser
+should support and that is about it. Maybe some little tweaks to make a user's
+life happier. 
+
+
+
+Re: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: <ikluft@th...> - 2000-09-09 18:49
+
+>From: Eric GAUDET <egaudet@in...>
+>I'm not really against the idea : I know perl, I like perl, I don't
+>know javascript. If you think you can achieve that fast and _as_a_
+>_dillo_module_, good for you and for us. (I don't see immediate
+>applications, though, but if you do it, I'll most likely use it ;-)
+
+OK, thank for that note. :-)
+
+Yes, as I re-read the docs for the difference between a module and a plug-in,
+I think a module is what I had in mind. The intent behind it could also
+be thought of as a way to write new Dillo modules in perl.
+
+It's something that I've thought since the dawn of the web that someone
+should do with a browser. Nearly all my web software development over
+that time has been on the server side. Over the years, work on several
+closed-source web servers has occasionally prevented me from contributing
+to projects like Apache. Although I did take one opportunity to contribute
+a module (mod_mime_magic) that Apache accepted in 1997.
+
+In the meantime, perl never happened on the browser side. So I'm looking
+around for a project which would be receptive to the idea. Dillo is the
+first choice after a quick survey because it uses GTK with no Motif legacy,
+it's GPL, it's relatively new, etc. Admittedly, I'm in no political
+position to push this on any project so this idea completely depends on
+others liking it too. If I can't convince anyone, the idea goes nowhere.
+
+>But we need to keep dillo's priorities in mind : dillo's still lacking
+>a lot of important features for a browser, and we sure can use some
+>extra coders. (If you know gtk+ and you want to help with tables and
+>frames support, contact Jorge)
+
+Sorry - I've been on the server side of the web. I don't have that
+kind of experience.
+
+I can understand that the project needs to have priorities. Even if this
+idea doesn't (yet) serve a higher priority, I'll accept the repsonsibility
+to make sure it doesn't get in the way of them. I think after some of the
+implementation is started, it could actually help implement some of the
+priorities.
+
+>Having an embeded language would be nice, but IMHO the criterias for
+>such a thing in dillo are :
+>- either a quick-hack, very lightweight, non-standard language (ie: not
+>javascript) : no wasting our time doing that, just add some dillo-only
+>dynamic html pages.
+>- or javascript, with all the efforts it needs.
+>
+>My main concern is : why perl ? If you spend a lot of time glueing perl
+>with dillo, I'd prefer you do it in a way other languages can be
+>interfaced too. I know you link about embeding perl in a C program, but
+>it's too much perl-specific to my taste.
+
+Well, yeah, it's still in the thinking/proposal stage. But the idea looks
+like the perl-specific code would have to be kept to its own separate module.
+On the surface of it, except for occasional additional functions in some
+API's to make information available to other modules (like the perl module),
+I don't yet see any reason why it can't be contained in its own module
+much like mod_perl contains all the perl-specific code in Apache.
+
+As I continue to form the idea with your input, this Dillo module would
+be glue code between the Dillo APIs and Perl APIs. Each would view the
+other as a module, and access to their APIs.
+
+>> The thought I had for Dillo was not to replace any existing C code
+>> in Perl. But rather it should allow access to as many as possible
+>> of the APIs so that some new features can be prototyped or
+>> implemented as an embedded perl script calling Dillo API functions. 
+>> It could also customize things like menus by putting embedded
+>> perl scripts behind some of the callbacks that handle them. 
+>> (Imagine having live Slashdot headlines in a pulldown menu. :-)
+>
+>This has been discussed in this list a few weeks ago (check the
+>archives), under the name of "modules", and rejected (for now) because
+>it seemed too much work and second priority.
+
+OK, sorry. Then that wasn't a good example. :-) Time to go through
+the archives... (So far I've gone through the web site and been watching
+the mail list for a couple weeks.)
+
+But the point is that such extensions could be possible to write in perl,
+not just in C.
+
+>Some of your examples let me think you might want to implement a perl
+>"plugin", which is not a "module", much more like a local CGI (check
+>the archives for that too, or ask me, as I'm the one working on
+>plugins). I like _this_ idea : you could put together and maintain your
+>perl plugin without bothering patching/linking with dillo, because it
+>would be an _external_ program called by dillo.
+
+Those examples were looking further out in the future, assuming this feature
+were accepted by the group and had time to build out access to lots of
+Dillo's APIs. I'm thinking of starting with a module, adding perl interfaces
+to existing Dillo module APIs one at a time, and seeing where it goes from
+there. The idea of a plugin could be explored as a follow-on.
+
+>Anyway, embeding whatever in dillo will be Jorge's decision eventually:
+>wait for his answer before you begin something big ;-)
+
+:-) Yup, don't worry. I did read the authors page. I haven't written
+any code for this yet.
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+Re: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-09 13:37
+
+--- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian
+Kluft, le 09-Sep-2000 :
+> The main question is whether people want it. I clearly understand
+> your first impression was against the idea, and respect your
+> opinion. If you're still open for some more technical info, take
+> a look at
+...
+
+I'm not really against the idea : I know perl, I like perl, I don't
+know javascript. If you think you can achieve that fast and _as_a_
+_dillo_module_, good for you and for us. (I don't see immediate
+applications, though, but if you do it, I'll most likely use it ;-)
+But we need to keep dillo's priorities in mind : dillo's still lacking
+a lot of important features for a browser, and we sure can use some
+extra coders. (If you know gtk+ and you want to help with tables and
+frames support, contact Jorge)
+Having an embeded language would be nice, but IMHO the criterias for
+such a thing in dillo are :
+- either a quick-hack, very lightweight, non-standard language (ie: not
+javascript) : no wasting our time doing that, just add some dillo-only
+dynamic html pages.
+- or javascript, with all the efforts it needs.
+
+My main concern is : why perl ? If you spend a lot of time glueing perl
+with dillo, I'd prefer you do it in a way other languages can be
+interfaced too. I know you link about embeding perl in a C program, but
+it's too much perl-specific to my taste.
+
+> The thought I had for Dillo was not to replace any existing C code
+> in Perl. But rather it should allow access to as many as possible
+> of the APIs so that some new features can be prototyped or
+> implemented as an embedded perl script calling Dillo API functions. 
+> It could also customize things like menus by putting embedded
+> perl scripts behind some of the callbacks that handle them. 
+> (Imagine having live Slashdot headlines in a pulldown menu. :-)
+
+This has been discussed in this list a few weeks ago (check the
+archives), under the name of "modules", and rejected (for now) because
+it seemed too much work and second priority.
+
+Some of your examples let me think you might want to implement a perl
+"plugin", which is not a "module", much more like a local CGI (check
+the archives for that too, or ask me, as I'm the one working on
+plugins). I like _this_ idea : you could put together and maintain your
+perl plugin without bothering patching/linking with dillo, because it
+would be an _external_ program called by dillo.
+
+Anyway, embeding whatever in dillo will be Jorge's decision eventually:
+wait for his answer before you begin something big ;-)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 09-Sep-2000 a 22:04:07
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: <ikluft@th...> - 2000-09-09 12:42
+
+>From: Eric GAUDET <egaudet@in...>
+>"Embeding" perl can be done in two ways : you can merge perl in dillo,
+>or link to perl dynamically.
+>IMHO, the fist is not doable : perl is too much heavy and I think we
+>want to keep dillo's light weight.
+
+I'm sure it's doable. But I'd have to implement it one API function
+at a time. It can also be done so that it's optional and you could
+leave it out at compile time.
+
+The main question is whether people want it. I clearly understand your
+first impression was against the idea, and respect your opinion. If you're
+still open for some more technical info, take a look at
+http://www.cpan.org/doc/manual/html/pod/perlembed.html
+http://www.cpan.org/doc/manual/html/pod/perlguts.html
+That's how a Perl5 interpreter can be embedded into any C program, or
+vice versa. A number of performance-critical Perl modules have been
+reimplemented in C too.
+
+So the embedding can go both ways. The perl interpreter can be a shared
+library. Or it can accept any module as a shared library.
+
+The counterpart to this idea on the server side is mod_perl for Apache.
+Perl and Apache each think the other is a module. :-) The perl interpreter
+runs inside the Apache process. I've used mod_perl on the job or on
+my personal web servers almost as long as it's been out.
+
+The thought I had for Dillo was not to replace any existing C code in Perl.
+But rather it should allow access to as many as possible of the APIs so
+that some new features can be prototyped or implemented as an embedded perl
+script calling Dillo API functions. It could also customize things like
+menus by putting embedded perl scripts behind some of the callbacks that
+handle them. (Imagine having live Slashdot headlines in a pulldown menu. :-)
+
+Also, depending on what access there might be to control the display
+window, it could be possible to have some kinds of local forms and pages
+controllable within the browser, and feed responses directly into
+browser-side perl code instead of a remote web server. So it could be a
+kind of scriptable local GUI in addition to a remote web browser. But it
+would take a lot of incremental API support before enough internal APIs
+could be covered to allow that.
+
+If the consensus is not to do this on Dillo, I can look around for another
+browser to try this on. But I like Dillo so far and think it has good
+potential. So I'm still holding out hope that some others will like
+the idea.
+
+>The latter seems better, adding support for the SCRIPT tag (a script in
+>an html page can actually be in any language, albeit javascript is the
+>only one used). But that's a lot of work : adding event calls on each
+>widget (links, images, words, almost all javascript's Document calls),
+>then figure out an interface between perl and dillo.
+>Though perl is quite an interesting language, my advice would be to
+>support javascript first (there's 2 open sourced javascript engines
+>around), because this will be immediatly usefull. Then you can add perl
+>with the same scripting interface.
+>
+>A few days ago, I tried to evaluate how hard it would be to embed a
+>tiny scripting language in dillo (10KB max), dillo-specific, so I can
+>add dynamic behavior to my dillo-plugins-generated pages. I suspended
+>this project for now, but if you dillo guys think that can be an
+>interesting add-on, tell me.
+>
+>Ian, if you want to add SCRIPT tag to dillo, I can help.
+
+Well, the SCRIPT tag will be needed for future Javascript support anyway.
+No doubt about that.
+
+But I'd be hesitant to allow it to use Perl. There is a Perl5 SAFE module
+which is intended to act as a kind of sandbox. But it doesn't have wide
+enough testing or trust to confidently use as downloadable code in a
+browser. I can almost see the CERT advisories already...
+
+Besides, there's no support among current web sites or browsers for such
+functionality right now.
+
+Though you would probably still have needed to use the perlembed interface
+to link a perl interpreter in for the SCRIPT tag. So I don't think it
+would have turned out any better on your concerns of a larger program size.
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+RE: [Dillo-dev]idea: embed Perl5 in Dillo
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-09 11:35
+
+"Embeding" perl can be done in two ways : you can merge perl in dillo,
+or link to perl dynamically.
+IMHO, the fist is not doable : perl is too much heavy and I think we
+want to keep dillo's light weight.
+The latter seems better, adding support for the SCRIPT tag (a script in
+an html page can actually be in any language, albeit javascript is the
+only one used). But that's a lot of work : adding event calls on each
+widget (links, images, words, almost all javascript's Document calls),
+then figure out an interface between perl and dillo.
+Though perl is quite an interesting language, my advice would be to
+support javascript first (there's 2 open sourced javascript engines
+around), because this will be immediatly usefull. Then you can add perl
+with the same scripting interface.
+
+A few days ago, I tried to evaluate how hard it would be to embed a
+tiny scripting language in dillo (10KB max), dillo-specific, so I can
+add dynamic behavior to my dillo-plugins-generated pages. I suspended
+this project for now, but if you dillo guys think that can be an
+interesting add-on, tell me.
+
+Ian, if you want to add SCRIPT tag to dillo, I can help.
+
+--- En reponse de "[Dillo-dev]idea: embed Perl5 in Dillo" de Ian Kluft,
+le 09-Sep-2000 :
+> Part of my intent behind the just-submitted about-URL-hashing
+> experiment was
+> to dig around the sources to check what it might take to embed Perl5
+> in
+> Dillo. I envision this as an optional feature, not a requirement,
+> since
+> it would fit Dillo's goal of extensibility very well but would also
+> add
+> to its size. Such compromises should be weighed by group
+> discussion.
+> (I haven't been on the list long enough to know the Dillo developer
+> community well.)
+> 
+> I've wanted for a long time to try to embed Perl in a web browser. 
+> The
+> possibilities for local user interface control seem very powerful. 
+> But it
+> would be better to work on such changes with a relatively new
+> browser where
+> the concept can grow with the project if it's accepted by other
+> participants.
+> I'll watch the following discussion for everyone's opinions...
+> -- 
+> Ian Kluft KO6YQ PP-ASEL sbay.org
+> coordinator
+> ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San
+> Jose, CA
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 09-Sep-2000 a 20:17:40
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]idea: embed Perl5 in Dillo
+
+From: <ikluft@th...> - 2000-09-09 11:03
+
+Part of my intent behind the just-submitted about-URL-hashing experiment was
+to dig around the sources to check what it might take to embed Perl5 in
+Dillo. I envision this as an optional feature, not a requirement, since
+it would fit Dillo's goal of extensibility very well but would also add
+to its size. Such compromises should be weighed by group discussion.
+(I haven't been on the list long enough to know the Dillo developer
+community well.)
+
+I've wanted for a long time to try to embed Perl in a web browser. The
+possibilities for local user interface control seem very powerful. But it
+would be better to work on such changes with a relatively new browser where
+the concept can grow with the project if it's accepted by other participants.
+I'll watch the following discussion for everyone's opinions...
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+[Dillo-dev]patch: add hashing to "about:" handler
+
+From: <ikluft@th...> - 2000-09-09 11:00
+
+Attachments: dillo-about-patch      
+
+Hello. This is a simple patch while I'm learning my way around Dillo.
+It changes the "about:" URL handler to use a hash table. It also adds an
+a_About_add() function so other parts of Dillo can dynamically add their
+own about-string/URL pairs on the fly.
+
+Though I submit to the editorial authority of the project coordinators,
+I used the patch to show how this can more easily and scalably add
+about-URLs for developer resources (like the Dillo, gtk and glib home pages)
+or for project participants to add their own URLs (with two of mine shown
+as an example.) Hopefully that will be viewed as a "perk" for contributing
+source code and add to the popularity of the project.
+
+The patch is submitted to the project as an attachment to this message.
+Or if you want to give me permission to commit it myself, my SourceForge
+user name is ikluft.
+-- 
+Ian Kluft KO6YQ PP-ASEL sbay.org coordinator
+ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA 
+
+
+
+[Dillo-dev]seen this a couple of times
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 10:03
+
+***** BUG found! (buffer needs allocation) *****
+Width = 1, Height = 1
+
+I can not reproduce it. 
+
+
+
+[Dillo-dev]word of caution and my status
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 09:35
+
+I have initial working of the FONT tag functional. I can say <font
+color="blue">Hi there</font> and get blue text. Will code the rest.
+
+The warning is that html_push_tag has to be called as early in a function as
+possible. I was having problems with open_font() because I was calling
+html_push_tag() at the end and thus pushing myself too far onto the stack it
+seems. the close font tag would not reset the text color. simply moving the
+function call fixed it. 
+
+
+
+RE: [Dillo-dev]Great Product!
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 03:29
+
+> 
+> I have one problem that I can't seem to get around. Our site uses a SSL
+> (security socket layer) that the standard http_proxy setting doesn't allow
+> for. I would like some help regarding this issue if possible!
+> 
+
+dillo could use ssl support -- feel free to help us code it. Or find someone
+else to contribute the code to us.
+
+start with libssl. 
+
+
+
+[Dillo-dev]Great Product!
+
+From: Bill Brooks <wdbrooksiii@ea...> - 2000-09-09 02:52
+
+To all concerned!
+
+Dillo is a great tool! I am working on a project that involves kiosk web
+browsing on thin clients with Linux RH61. We need to keep the operation
+simple and lock the user down to a limited range of use. Dillo seems to be
+the best browser that I have come across. It is simple (if browsers can be
+termed simple), fast, and can be extensible with knowledge of C and gtk+
+programming.
+
+I have one problem that I can't seem to get around. Our site uses a SSL
+(security socket layer) that the standard http_proxy setting doesn't allow
+for. I would like some help regarding this issue if possible!
+
+Thanks again for making Dillo such a great product!
+Bill Brooks
+MIS Anaylst
+Lowe's Companies, Inc. 
+
+
+
+RE: [Dillo-dev]News
+
+From: Eric GAUDET <egaudet@in...> - 2000-09-08 19:00
+
+06-Sep-2000, Jorge said : 
+> Personally, I gave a look to reload and double-click bugs, and
+> noted that they're most the same problem. 
+...
+> As a matter of fact, I'm currently working on it.
+...
+
+Shouldn't you register in the bug tracking database accordingly ?
+
+Anyway, I had email sending problems lately, and I was wondering if
+you've received my patches.
+
+I'm working on the Bookmarks plugin right now, and I've got lots of
+ideas fo plugins things. I'm willing to make a Preferences plugin too,
+as I saw the project is suspended and drake is most likely out of dillo.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 08-Sep-2000 a 22:25:38
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]News
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-09-06 13:58
+
+Hi!
+
+The list has been quiet for some time, and that's a good sign!
+(we are diligently working on the code by now).
+
+Personally, I gave a look to reload and double-click bugs, and
+noted that they're most the same problem. There're also a several
+more problems related to this that are not recorded in the
+bug-track. The main problem is the lack of implementation of a
+consistent error control and abort systems between different
+layers in dillo. This is a design concern.
+
+I also noted that it deserves a high priority on my list,
+because new developers don't know the internals of the browser
+and perceive dillo as crash-prone, and get discouraged, instead
+of knowing that this is just a lack of implementation that's to
+be overcomed soon.
+
+As a matter of fact, I'm currently working on it.
+
+I checked and fixed the cache clients scheme to handle not only
+concurrent clients on the same connection, but also to provide a
+handler for error control and aborting (This means that
+concurrent download functionality is working).
+
+As a mentioned above, the problem is among middle layers. For
+instance: do you remember Sebastian's post about image
+backgrounds? Yes, current scheme handles image transfers directly
+to rendering image widgets. I'm also working on that.
+
+Note that this is not a patching task, but a design one, that
+takes time and key decisions have to be made, so I'll take some
+time in trying to get it right.
+
+
+Jorge.-
+
+
+PS: I wander if some among the new memebers are experienced GTK+
+developers... 
+
diff --git a/old/oldmail/200010.txt b/old/oldmail/200010.txt
new file mode 100644
index 0000000..57816c2
--- /dev/null
+++ b/old/oldmail/200010.txt
@@ -0,0 +1,3767 @@
+[Dillo-dev]Dw details
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-31 15:04
+
+Hi!
+
+Some details on my Dw design. Implementation is far enough to make be
+beleive that this design should work quite well. In detail:
+
+- DwWidget: set_width and set_height are currently not used, instead,
+this feature is currently implemented otherwise. Will be changed
+next.
+The implementation of a_widget_queue_resize is currently very simple
+and inefficient, but works; changes should not effect the other
+code.
+
+- DwContainer: There won't be much implementation, anyway.
+
+- Interaction between Gtk and Dw: GtkLayout does a good job ;-).
+Embedding of Gtk+ widgets by DwEmbedGtk works mainly. (BTW, focus
+works very nice now.)
+
+DwWidget
+--------
+
+My goal for the new design was mainly to make dillo's widgets more
+similar to Gtk+ widgets.
+
+struct _DwWidget
+{
+GtkObject object;
+
+/* some more members, will change */
+};
+
+
+struct _DwWidgetClass
+{
+GtkObjectClass parent_class;
+
+void (*size_request) (DwWidget *widget,
+DwRequisition *requisition);
+void (*size_allocate) (DwWidget *widget,
+DwAllocation *allocation);
+void (*set_width) (DwWidget *widget,
+guint32 width);
+void (*set_height) (DwWidget *widget,
+guint32 height);
+void (*draw) (DwWidget *widget,
+DwRectangle *area,
+GdkEventExpose *);
+/* further methods for events */
+};
+
+size_request and size_allocate work quite exactly as in GtkWidget. I
+added two methods, set_width and set_height, which may (but need not)
+have an effect on the behaviour of size_request. (Probably, set_height
+will not be used anyway, but it is there for symmetry.) Most widgets
+in dillo will use size_request much more often that size_allocate.
+
+There is a function a_dw_widget_queue_resize, which a widget must call
+when its desired change has changed (e.g. if a word is added to a
+page). The implementation is based on the size_request and
+size_allocate methods, similar to gtk_widget_queue_resize), so a
+widget must not implement anything like idle functions etc. (BTW,
+a_dw_widget_queue_resize as well as gtk_widget_queue_resize do work
+with idle functions.)
+
+Since DwWidget's are windowless "per se", there is no need for
+distinguishing between a draw and an expose method. However, if the
+draw function is called because of an expose event, the method will
+receive it as third argument (otherwise NULL), in case, if the widget
+is interested in further details.
+
+
+DwContainer
+-----------
+
+Quite similar to GtkContainer.
+
+
+Interaction between Gtk and Dw
+------------------------------
+
+The top level Dw widget is handled by a Gtk+ widget GtkDwViewport,
+derived from GtkLayout. GtkDwViewport is responsible for all events
+for Dw widgets, the underlying GtkLayout for events for embedded Gtk+
+widgets.
+
+There is still a widget DwEmbedGtk for embedding Gtk+ widgets into a
+DwWidget. Some "events" (like destroy or size_request) of those
+widgets have to be caught by signals, since Gtk+ does not regard the
+DwEmbedGtk as the parent of the Gtk+ widget.
+
+(I first tried another approach, without GtkLayout, which made the
+design simpler, but had severe problems with the Gtk+ widgets. So I
+decided to use GtkLayout, which does a good job for this.)
+
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Progress
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-10-30 00:36
+
+During some recent plane trips I have mostly finished my work on dillo and
+rendering of font modifying tags. font tab itself is supported, it does not
+yet support the face attribute. The sub and super tags need attention, they
+are the only major things not working yet.
+
+I intend to add a flag to dillo's configuration to ignore all font modifying
+tags in the html, or only specific ones. I have even pondered saying it is ok
+if font color= is set, but not font face=. Jorge, I know how much you hate not
+being able to control what html authors do and I would like to give our users a
+rich set of control over this. Personally, I like to see pages the way the
+author intended, but I know not everyone does. Comments on implementation of
+user prefs welcome. Need just a little cleanup of the code and I can submit a
+patch.
+
+Jorge, would you like for this to happen after Sebastian's Dw changes?
+
+Sorry for not being very talkative lately, this is the first time this machine
+has been on in a week. 
+
+
+
+[Dillo-dev]Dw progress
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-28 10:43
+
+Hi!
+
+Another good news: Dw is working quite nice already. Embedding Gtk+
+widgets is now (nearly) perfect, there are no expose problems anymore,
+even resize queueing of Gtk+ widgets are recognized. After making
+some changes and fixing some bugs, I'll soon start re-intigreating it
+into dillo.
+
+A note to bug #86: tabbing between widgets works automatically (done
+by the base class GtkLayout or somewhere else), but the toplevel Gtk+
+widget (GtkDwViewport) isn't focussable yet, so e.g. the arrow keys
+don't work. Making GtkDwViewport focussable will cause some other
+problems, since you may not focus children of focussable containers by
+pressing the tab key (but you may by clicking on them). I'll work on
+it (and make an entry in the bug tracking engine).
+
+Images: I'll first deactivate images, and then take a look at Jorge's
+changes.
+
+Sebastian 
+
+
+
+[Dillo-dev]Dillo-plugins first release
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-27 16:07
+
+Hi guys,
+As I promised, I just made available all the Dillo-plugins stuff I've
+been working on at:
+http://www.rti-zone.org/dillo/
+
+Feel free to send me any comments about this. 
+It's stable and almost complete, so you can try and do your own
+Dillo-plugins right now.
+
+I'm still working on the patch, and I'll finish it hopefully soon
+enough to be reviewed by Jorge and integrated in Dillo v0.3.
+
+A usable Bookmarks Dillo-plugin will be available soon too, but its
+developement will be disconnected of Dillo. (I'm not forking Dillo !
+The purpose of plugins is to be external programs). 
+The internal bookmarks menu won't be removed until Jorge decides so.
+
+Ciao
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Oct-2000 a 00:55:24
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Progress
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-10-27 12:40
+
+Hi!
+
+A few days ago I finally devised a way to simplify the complex
+alternative design; it was a major task with lots of changes that
+I hope to document in the future.
+
+The good news is that I have a running prototype of dillo-0.3.0
+with it!
+
+The prototype runs very good and only requires some polishing
+before being adopted as the basis for our new release. 
+
+In brief:
+
+- The imgsink stuff was completely removed.
+- The dicache was rewritten from scratch and integrated
+into the normal cache.
+- A single client queue is being used for both caches.
+- The file descriptors were replaced by cache keys that serve
+as connection handlers.
+- The image data structure and related sources got changed.
+- Every decoder (png, gif, jpeg) was adapted to the new
+scheme.
+
+
+The current prototype already solves the file caching problem
+(and the severe memory leaks related). Now, I'll try to fix BUGs
+using the tools that this new design provide. When I finish that,
+it will be time to move the patch queue... But before I start
+patching, I'll upload the prototype to the CVS server so it can
+be tested.
+
+I only hope this design succeeds to provide what we need...
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Dillo Weekly News
+
+From: Allan Clark <shark@bl...> - 2000-10-24 14:53
+
+I've just posted the latest Dillo weekly news, this was meant to be done on
+Sunday so I'm sorry it's so late but I had a uni deadline to make (just).
+Anyway you can find it at
+http://www.shark.pwp.blueyonder.co.uk/news/news221000.html
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+Re: [Dillo-dev]Wild idea : frames
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-24 12:39
+
+-- En reponse de "Re: [Dillo-dev]Wild idea : frames" de Eric GAUDET, le
+24-Oct-2000 :
+>>> Don't render frames embeding DwPages in DwPages, but
+>>> create an actual browser page for each frame of the
+>>> frameset, with the correct width and height. The
+>>> user can then place the frames as he wants without
+>>> being bugged with having to read a page in a tiny
+>>> window.
+>> 
+>> As I think about this, this sounds like a neat
+>> approach for re-sizable frames. But bear in mind that
+>> not all frames are re-sizable. We'll need to handle
+>> both re-sizable AND non-re-sizable frames, IMHO.
+>> 
+> 
+> While we could probably intercept resizing messages, I'm not sure
+> this
+> would be a good idea. I want to keep control over sites designed for
+> large screens (I "only" have a 800x600 laptop). I don't see where in
+> html concepts the user is denied to customised his browser's
+> behavior.
+> 
+
+More precisely on attributes :
+- NORESIZE should be used to allow the browser window to be
+resized without the DwPage renegotiation its dimensions. (only useful
+with sizes in %)
+- SCROLLING should always be auto : there's no point to deny scrolling
+in such a frame implementation.
+- FRAMEBORDER, MARGINWIDTH, MARGINHEIGHT : ignored. I agree there will
+be a problem here with complex pages using frames for showing fancy
+displays, mostly for java applets and video streaming (none of which we
+plan to support anytime soon). Those pages should be built with tables
+anyway, and I don't care if we can't render "correctly" poorly designed
+pages.
+
+This multi-window implementation for frames is allowed by HTML4 specs :
+(quoted from W3C site)
+"16.1 Introduction to frames
+HTML frames allow authors to present documents in multiple views,
+which may be independent windows or subwindows. Multiple views offer
+designers a way to keep certain information visible, while other views
+are scrolled or replaced."
+
+The "subwindows" is the way most browsers render frames, but not the
+only one ;-)
+
+PS: I didn't came with this idea to make frames implementation simpler,
+but because I think this could be convenient for users.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Oct-2000 a 21:21:30
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Wild idea : frames
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-24 08:57
+
+-- En reponse de "Re: [Dillo-dev]Wild idea : frames" de Daniel Roberts,
+le 24-Oct-2000 :
+> --- Eric GAUDET <egaudet@in...> wrote:
+>> Don't render frames embeding DwPages in DwPages, but
+>> create an actual browser page for each frame of the
+>> frameset, with the correct width and height. The
+>> user can then place the frames as he wants without
+>> being bugged with having to read a page in a tiny
+>> window.
+> 
+> As I think about this, this sounds like a neat
+> approach for re-sizable frames. But bear in mind that
+> not all frames are re-sizable. We'll need to handle
+> both re-sizable AND non-re-sizable frames, IMHO.
+> 
+
+While we could probably intercept resizing messages, I'm not sure this
+would be a good idea. I want to keep control over sites designed for
+large screens (I "only" have a 800x600 laptop). I don't see where in
+html concepts the user is denied to customised his browser's behavior.
+
+>> We'll also need to add an identifier for the
+>> frameset (say a hash of the url ?), in case the same
+>> target names are used in different framesets. That
+>> doesn't seem pose any problem.
+> 
+> Actually, would it not be easier if we simply embedded
+> the DwPages within some master widget that contained
+> the master URL and the master frameset?
+> 
+
+That's the current design "to-be" with Sebastian's new Dw widgets.
+
+> Also, another problem will surface in the course of
+> this: How on earth do we plan to handle bookmarking,
+> and back/forward buttons for frames? Last time I
+> checked, the W3C HTML specs generally seemed to admit
+> that this was a very messy situation in HTML. In
+> Netscape, they had a HECK of a time with this. 
+> Bookmarking was impossible, and back/forward had to be
+> given an ugly hack to handle frames, originally.
+> 
+
+For bookmarking, we can bookmark only the frameset's URL. For
+back/forward button, I don't see any problem : each browser window
+already has its own history.
+
+> In this course of thought, yet another thought has
+> occured to me: With so many different
+> languages/protocols (http, ftp, html, xml, xslt, css,
+> JavaScript, etc.), why not make Dillo more generic and
+> modular by breaking the HTML support out into a
+> plugin?
+> 
+
+Plugins plan do handle all this (both protocols and languages).
+However, we'll need a final rendering language, and IMHO html is not
+worth than any other, and likely better designed than anything we can
+design for scratch for our own use.
+And plugins have a drawback, which was already addressed (in
+Dillo-plugins protocol, to be plublished soon) about make a http plugin:
+"While it is possible to override "http:", this unlikely to be a good
+idea : doing that will cause Dillo to fork a Dillo-plugin for each http
+request. While Dillo's main purpose is being an http client, it would
+be much better to patch Dillo's http layer (instead of doing a
+Dillo-plugin for that) if you want to modify/fix/enhance Dillo's http
+behavior."
+
+Same for html : Dillo was designed for fast html rendering, we should
+keep html inside Dillo as THE low-level language for pages rendering.
+
+> Speaking of which, BTW, whatever became of the FTP plugin?
+
+It's cooking, be patient.
+
+More on Dillo-plugins by friday. (protocol and design draft
+documentation, patch, sample plugin and usable bookmark plugin)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Oct-2000 a 17:39:29
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Wild idea : frames
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-24 01:53
+
+--- Eric GAUDET <egaudet@in...> wrote:
+> Don't render frames embeding DwPages in DwPages, but
+> create an actual browser page for each frame of the
+> frameset, with the correct width and height. The
+> user can then place the frames as he wants without
+> being bugged with having to read a page in a tiny
+> window.
+
+As I think about this, this sounds like a neat
+approach for re-sizable frames. But bear in mind that
+not all frames are re-sizable. We'll need to handle
+both re-sizable AND non-re-sizable frames, IMHO.
+
+> We'll also need to add an identifier for the
+> frameset (say a hash of the url ?), in case the same
+> target names are used in different framesets. That
+> doesn't seem pose any problem.
+
+Actually, would it not be easier if we simply embedded
+the DwPages within some master widget that contained
+the master URL and the master frameset?
+
+Also, another problem will surface in the course of
+this: How on earth do we plan to handle bookmarking,
+and back/forward buttons for frames? Last time I
+checked, the W3C HTML specs generally seemed to admit
+that this was a very messy situation in HTML. In
+Netscape, they had a HECK of a time with this. 
+Bookmarking was impossible, and back/forward had to be
+given an ugly hack to handle frames, originally.
+
+In this course of thought, yet another thought has
+occured to me: With so many different
+languages/protocols (http, ftp, html, xml, xslt, css,
+JavaScript, etc.), why not make Dillo more generic and
+modular by breaking the HTML support out into a
+plugin?
+
+Speaking of which, BTW, whatever became of the FTP plugin?
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Messenger - Talk while you surf! It's FREE.
+http://im.yahoo.com/ 
+
+
+
+[Dillo-dev]Wild idea : frames
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-24 01:23
+
+The list is so sleepy, let me share with you an idea I had for
+framesets rendering : (not inline frame, not tables)
+Don't render frames embeding DwPages in DwPages, but create an actual
+browser page for each frame of the frameset, with the correct width and
+height. The user can then place the frames as he wants without being
+bugged with having to read a page in a tiny window.
+To make that working, we'll have to add in DwPage a target attribute :
+I already did that in my href page. We'll also need to add an
+identifier for the frameset (say a hash of the url ?), in case the same
+target names are used in different framesets. That doesn't seem pose any
+problem.
+We can also render the frameset window showing a scalled-down version
+of the frame map : gtk containers with buttons named after the frames
+titles should fo the trick. A window-manager "pager" sort of thing.
+
+Any comment ?
+
+If you like the idea, I'll probably give it a try when next Dillo
+version comes out.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Oct-2000 a 10:12:56
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]BSD ports
+
+From: Sammy Mannaert <nstalkie@tv...> - 2000-10-18 17:46
+
+Jorge Arellano Cid wrote:
+
+> Sammy,
+>
+>
+> On the DNS scheme concerns. That's the expected behaviour: one
+> solving thread per request (Tested with more than a hundred
+> simoultaneous requests crowding 4 server channels).
+>
+> It seems the problem is highly related to BSD's threads
+> implementation; but please note that FreeBSD 3.5 does the trick.
+
+it's the expected behaviour of gethostbyname() actually (that it garbles
+
+up it's internal data when called simultaneously in threads). i think
+the thing here is that glibc might automatically use a multithread
+capable
+gethostbyname (which isn't one of the *_r functions specified by posix).
+
+i did a little research today and found out that most unices have a
+gethostbyname_r function, but apparently BSD hasn't (because the
+function isn't standardized yet).
+
+dillo runs fine when i put the max number of server channels to 1, so
+i'll use that for now :)
+
+
+>
+> Hope this helps
+> Jorge.-
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]BSD ports
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-10-18 12:30
+
+Sammy,
+
+Kurt Lidl reported no problems using dillo with his BSD/OS
+4.0.1 i386system <lidl@en...>.
+
+Ryan Oberlin <ryan@sc...> got it running on
+FreeBSD (with some changes that I haven't got).
+
+tjs17@co... reported no problems with a a 32bit machine,
+gcc 2.7.2.3 and FreeBSD 3.5 (with -pthread instead of -lpthread).
+
+Jeremy C. Reed <reed@re...> has reported some
+problems trying to run dillo on NetBSD (I'm sure he'll appreciate
+any helping information).
+
+Feel free to contact and ask them (please tell them I gave you
+the addresses).
+
+---
+
+On the DNS scheme concerns. That's the expected behaviour: one
+solving thread per request (Tested with more than a hundred
+simoultaneous requests crowding 4 server channels).
+
+It seems the problem is highly related to BSD's threads
+implementation; but please note that FreeBSD 3.5 does the trick.
+
+
+Hope this helps
+Jorge.- 
+
+
+
+Re: [Dillo-dev]bug with dns or .. ?
+
+From: Sammy Mannaert <nstalkie@tv...> - 2000-10-17 21:20
+
+Allan Clark wrote:
+
+> Just tried it and it worked fine for me.
+>
+>
+
+i have found what the problem is. apparently we are doing something
+quite dangerous here :)
+
+in Dns_server we call gethostbyname()
+
+from manpage gethostbyname
+These functions use static data storage; if the data is needed for future
+
+use, it should be copied before any subsequent calls overwrite it.
+
+but what we do is: we run Dns_Servers (several of them) in threads.
+so it is quite possible that one query starts while another one is busy and
+it will garble up gethostbyname's internal data (which is what's happening)
+
+when i disable threading for dns i have no problems.
+
+the debug output i get is for example :
+
+a_Cache_open_url:
+http://images.freshmeat.net/FreshMeat/Core/pc.gif?/index.php3,971817463
+a_Cache_open_url: http://phoenix-adrunner.mycomputer.com/b/ar/freshmeat1/1
+Dns_server: starting...
+channel: 0
+Dns_server: starting...
+channel: 1
+a_Cache_open_url: http://ads.freshmeat.net/egra5006en.gif?971817463
+
+etc ... etc ..
+
+from this point no single gethostbyname function will return !! note that we
+had two
+requests very fast after eachother. 
+
+
+
+RE: [Dillo-dev]bug with dns or .. ?
+
+From: Allan Clark <shark@bl...> - 2000-10-17 20:34
+
+Just tried it and it worked fine for me.
+
+> -----Original Message-----
+> From: dillo-dev-admin@li...
+> [mailto:dillo-dev-admin@li...]On Behalf Of Sammy
+> Mannaert
+> Sent: 17 October 2000 21:14
+> To: Dillo-dev@li...
+> Subject: [Dillo-dev]bug with dns or .. ?
+> 
+> 
+> hi,
+> 
+> as i don't know if this is a bug or not, i want to ask some of you who
+> run dillo on linux:
+> 
+> - go to http://www.freshmeat.net (or freshmeat.net)
+> - try to click any of the links above (linux.com, slashdot, etc ..)
+> - you will only see DNS resolving <domain here> and that's it ..
+> 
+> as i am running dillo on freebsd, i'm aware this might be a freebsd
+> specific
+> thingie, so i'd like to see if it's also happening on a linux platform.
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]bug with dns or .. ?
+
+From: Sammy Mannaert <nstalkie@tv...> - 2000-10-17 20:25
+
+hi,
+
+as i don't know if this is a bug or not, i want to ask some of you who
+run dillo on linux:
+
+- go to http://www.freshmeat.net (or freshmeat.net)
+- try to click any of the links above (linux.com, slashdot, etc ..)
+- you will only see DNS resolving <domain here> and that's it ..
+
+as i am running dillo on freebsd, i'm aware this might be a freebsd
+specific
+thingie, so i'd like to see if it's also happening on a linux platform. 
+
+
+
+[Dillo-dev]Find text (quite long sorry)
+
+From: Allan Clark <shark@bl...> - 2000-10-17 16:10
+
+Hi,
+First of all I am having trouble with my network, I seem to be able to send
+and recieve mail and that is about it, anyway that is why this is not a patch
+but I have just included the text, there isn't much anyway and is all in one
+function but sorry about that. The code below cleans up the findtext implemented
+by Sam, it uses a pretty fast algorithm which will also work if we ever choose
+to use unicode characters. You should be able to follow the algorithm fairly
+easily but essentially it pre-computes a prefix function for the find string
+this it does in linear time according to the length of the find string and only
+depends on the search string and not the page's text, it then searches through
+the text of the page which can also be done in linear time, and so it is pretty
+fast. This will find text that is span over one or more lines, but there is one
+slight known problem, this concerns moving the scroller to the correct
+position, currently if the occurence of the find string is in one line then the
+correct thing happens, if it spans two lines then again the correct thing
+happens and the scroller is positioned as if it were only contained in the top
+of the two lines, but if it spans more than two lines the scroller is placed as
+if the occurence started at the second last line the the occurence spans. Other
+points to note is that I have included code to enable the user to either match
+the case or not, I haven't updated the rest of the code as I realised because
+of my strange network problem I wouldn't be able to patch so I wanted to keep
+my changes limited to one function. Also the foundAt variable gives us a little
+more information than it needs but I
+left it the way it is as it will make it easier to highlight the text when we
+add support for that. Okay so if you're still with me, apply Sam's patch 
+http://www.shark.pwp.blueyonder.co.uk/patches/findtext.diff.gz
+then Sebastian's patch
+http://www.shark.pwp.blueyonder.co.uk/patches/findtext2.diff
+and then open up dw_page.c, scroll to the bottom where you will find the
+a_Dw_page_find_text(DwPage *page, char *find) function and replace it with the
+one below
+
+/*
+* Find the text in the page.
+*/
+void a_Dw_page_find_text(DwPage *page, char *find)
+{
+
+GString *stext;
+GtkDwScroller *scroller;
+DwContainer *container;
+gint m;
+gint *prefix;
+gboolean matchCase;
+gint k = 0;
+gint q = 1;
+gint line_num = 0;
+gint foundAt = -1;
+gint ii = 0;
+gint t = 0;
+gint s = 0;
+gint fromPrevious = 0;
+
+
+matchCase = FALSE; /* Not yet implemented */
+
+if ( !(container = a_Dw_find_container(&page->dw)) ){
+g_print("BUG: Dw container not found\n");
+return;
+}
+
+m = strlen(find);
+if (!m)
+return;
+
+prefix = (gint*) g_malloc (m * sizeof(gint));
+stext = g_string_sized_new(64);
+
+/* First compute a static prefix function
+* this can be done in linear time and
+* based solely on the search string
+*/
+
+prefix[0] = 0; /*Must be this reguardless of the string */
+
+if (!matchCase)
+g_strdown (find);
+
+for (q = 1; q < m; q++)
+{
+while (k > 0 && find[k] != find[q])
+k = prefix[k - 1];
+if (find[k] == find[q])
+k++;
+prefix[q] = k;
+}
+
+/*Go in loop searching each line until we find
+the search string */
+for (line_num = 0; line_num < page->num_lines; line_num++)
+{
+/* this allows us to find strings that span over two or more lines */
+if (stext->len > m)
+stext = g_string_erase(stext, 0, stext->len - m);
+fromPrevious = stext->len; /*might not be as long as m */
+/* Now we get the next block of text */
+for(s = 0; s < page->lines[line_num].num_words; s++)
+{
+if (page->lines[line_num].words[s].content_type != DW_PAGE_CONTENT_TEXT)
+continue;
+stext = g_string_append(stext, page->lines[line_num].words[s].content.text);
+stext = g_string_append(stext, " ");
+}
+if (stext->len < m)
+continue;
+
+/* Now we search the stext for the search string */
+if(!matchCase)
+stext = g_string_down(stext);
+foundAt = -1;
+ii = 0;
+t = 0;
+while (stext->str[ii])
+{
+while (t > 0 && (find[t] != stext->str[ii]))
+t = prefix[t - 1];
+if (find[t] == stext->str[ii])
+t++;
+ii++;
+if (t == m) {
+foundAt = ii - m;
+break;
+}
+}
+/* Now if we have found it then highlight the line */
+if (foundAt != -1) {
+scroller = GTK_DW_SCROLLER (container->widget->parent);
+if (foundAt < fromPrevious && line_num > 0) /*line_num <= 0 shouldn't ever happen if foundAt < fromPrevious*/
+a_Dw_gtk_scroller_jump_pos (scroller,
+page->lines[line_num - 1].y_top);
+else
+a_Dw_gtk_scroller_jump_pos (scroller,
+page->lines[line_num].y_top);
+break;
+}
+}
+
+g_string_free(stext, TRUE);
+g_free (prefix);
+} 
+
+
+
+Re: [Dillo-dev]Patches
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-17 12:23
+
+Eric GAUDET wrote:
+> I've already included in most of the pages I made if dillo v0.2.4's behavior is
+> correct or not, and sometime what it should be. I planned to update this when
+> next version (not cvs) will be available.
+> It's an HTML-rendering testsuite only. I won't build any testsuite for cache
+> behavior, http requests and other things a browser is supposed to do.
+> I understood there's a bedtest for Sebastian's new Dw : I can include that.
+
+It's simply a main-function of 20 lines, which creates some widgets
+and then calls gtk_main. It helps me testing all functions and finding
+bugs. (Furthermore, most widgets aren't ported yet, although they are
+mostly simple ones, like DwBullet.) This could perhaps done also for
+other modules, i.e. separating the module's code and calling all of
+its functions "by hand".
+
+Another way could be to use the existing possibilities of a server.
+E.g., I already used php pages with included "<? sleep(10) ?>" to
+simulate slow connections (this could also be done by a simple cgi
+script), or you may create specific http headers etc.
+
+> It's the very first version : no one has reacted on it yet. I expect to receive
+> your own pages, comments and (grammar :-/) corrections so it can be improved.
+> (actually I was waiting for Jorge's green light and corrections before
+> publishing it, but you guys may want to know what's happening ;-)
+
+I have written some test pages. I'll download your suite and look what
+I might send you.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Patches
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-17 01:41
+
+Jorge Arellano Cid writes:
+> 
+> Hi!
+> 
+> The minimal consideration I expect from newcomers, is to read
+> the home page before posting to this mailing list. If they don't
+> or even worse, they do but decide to force their ways into this
+> project, we have a bad start...
+> 
+> Rules are there for a reason, and I want to thank Eric for
+> pointing them out to the mailing list.
+> 
+
+Ok, sorry. I didn't mean to break all your "rules" and cause any
+confusion. I was just trying to contribute, and not "forcing" my way
+into the project. I did read the home page, and read a bunch of
+previous mails from the archive list, but it wasn't clear to me that
+we weren't suppossed to post patches and stuff in the mailing
+list. Now it's very clear, sorry.
+
+(...) 
+
+> > Sorry if I seemed annoyed, but I not. It just not nice to have
+> > people effort thrown away in vain, when they could be producing lots
+> > if things were a little bit more organized.
+> 
+> Please don't blame on us the results of you not following our
+> rules. You could have known that in advance. As a matter of fact,
+> you knew I was working some of the bugs you tried to fix.
+
+Wow, I wasn't blaming anyone of anything, I was just stating my
+opinion about how the project was organized. But since am a newcomer,
+and don't nothing about it, you can just ignore my remarks ;-).
+
+> 
+> If you read the mailing list archives, you'll find an
+> "Activity" post (by me); there you'll find a list of things that
+> your patch doesn't solve, and maybe then it will become clear why
+> patches are reviewed before inclusion.
+
+I agree with this, all patches should be reviewed. I was just
+exposing an idea I had about the problem (not a total fix). I sent the
+patch to show to everyone the idea I had, and wanted some feed back
+about the *idea*, I know that the patch didn't solve all the problems,
+and I don't expect it to be included in Dillo's next version.
+
+
+I'm REALLY sorry that I caused all this commotion, I did not mean to
+have a "bad start". Jorge, what should I do to "redeem" my situation?
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]how i compiled under freebsd (4.1)
+
+From: Sammy Mannaert <nstalkie@tv...> - 2000-10-17 00:10
+
+Sammy Mannaert wrote:
+
+> i'm not a freebsd expert by far, but i think this explenation offers
+> more detail than
+> the readme in the tarball .. (for example it doesn't add the problem of
+> -D_THREAD_SAFE,
+> if you forget it, dillo will only load the first url you go to, the
+> other ones will only
+> display "resolving DNS" or something alike in the statusbar)
+>
+
+it seems as if this isn't really fixed yet (though i used correct
+compiling options ..) sometimes (quite a lot really) i get DNS
+solving <host> and nothing else ... weird ...
+
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]how i compiled under freebsd (4.1)
+
+From: Sammy Mannaert <nstalkie@tv...> - 2000-10-16 23:38
+
+hi,
+
+i've succesfully compiled and tested dillo on freebsd (the platform i
+run now)
+in order to be able to compile, i had to do quite a few things which i
+will explain
+here.
+
+i'm not sure if i took the "correct" freebsd way of doing things
+however ..
+
+first step: freebsd uses -pthread and -D_THREAD_SAFE instead of
+-lpthread
+and -D_REENTRANT :
+type
+export CFLAGS="-pthread -D_THREAD_SAFE"
+or setenv CFLAGS "-pthread -D_THREAD_SAFE"
+(depending on shell)
+
+second step: freebsd uses gtk12-config instead of gtk-config :
+do
+ln /usr/X11R6/bin/gtk12-config /usr/X11R6/bin/gtk-config
+(as root ofcourse)
+
+third step:
+do
+./configure --with-gtk-prefix=/usr/X11R6
+--with-gtk-exec-prefix=/usr/X11R6
+
+
+now here is when a problem emerges. it seems our configure script
+doesn't really
+support the option to set the jpeg include lib directories ? (for the
+record: freebsd
+has jpeglib.h etc .. in /usr/local/include) .. anyways, i couldn't get
+it to work :)
+what i did:
+in configure.in i outcommented following part:
+if test "$jpeg_ok" = yes; then
+AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h,
+jpeg_ok=yes, jpeg_ok=no)
+fi
+
+it then worked as suspected. (do we really need this part ? can't we
+assume that
+the jpeglib is correctly installed after we did the first test in
+configure ?
+checking for jpeg_destroy_decompress in -ljpeg (<- this one))
+
+
+i'm not a freebsd expert by far, but i think this explenation offers
+more detail than
+the readme in the tarball .. (for example it doesn't add the problem of
+-D_THREAD_SAFE,
+if you forget it, dillo will only load the first url you go to, the
+other ones will only
+display "resolving DNS" or something alike in the statusbar) 
+
+
+
+[Dillo-dev]help needed: sigsuspend with new glibc
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 16:49
+
+Hi all,
+I've updated my glibc to 2.1.3-5mdk a few days ago, and now I'm catching a lot
+of sigsuspend in gdb (I hadn't a single one before) : on sigsuspend every
+pthread_create (one for each image on a page). That's really bugging me.
+What can I do to avoid this ?
+
+Does this have anything to do with that message :
+(gdb) run
+Starting program: /home/eric/src/dillo-0.2.4.orig/src/./dillo 
+warning: Unable to find dynamic linker breakpoint function.
+GDB will be unable to debug shared library initializers
+and track explicitly loaded dynamic code.
+dillo_dns_init: Here we go!
+
+Can anyone help me on this ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 17-Oct-2000 a 01:43:21
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Patches
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 16:34
+
+-- En reponse de "RE: [Dillo-dev]Patches" de Daniel Roberts, le 16-Oct-2000 :
+>> It's an HTML-rendering testsuite only. I won't build
+...
+> [extra deleted for brevity...]
+> 
+> I just took a look at it. At the moment, it does look
+> to me like a reasonable subset of HTML tests, given
+> Dillo's current status/capabilities. When
+> tables/frames support is complete, I am guessing that
+> tables/frames tests will be the next thing to be
+> added. :-)
+> 
+
+Sure, but Jorge already urged me *not* to bother with table testing pages, as
+the first line of code for it is not even written.
+But that's the next big step all right.
+
+> BTW, Mozilla has a *HUGE* test suite, with tests
+> scattered all over the place. I suggest we might want
+> to consider using some of these tests. I'd be willing
+> to bring them over here and adapt them for Dillo's
+> use, if you'd like to add them to your testsuite. 
+
+That would be nice. Just focus on dillo's current/likely next capabilities for
+now.
+
+> When the time comes, Mozilla also has XML, CSS, and
+> JavaScript tests as well. They are good and complete,
+> what's more.
+> 
+
+Forget it, we won't need them soon.
+
+> I think however that we *DO* also need things like
+> http requests, cache behavior, and other things a
+> browser should do. 
+
+That's not easy to publish this as a test suite : who here has an http server
+running on his machine ? Who wants to patch, say boa, for faking altered http
+responses to see how dillo's handling the problem, and maintain such a
+malformed monster ? How helping would it be : everyone having the same
+behaviour in a tight controlled environment and make sure dillo's working ok ?
+
+What can be done, though, is one (or some) of us publish some results. 
+But the most likely guy doing that is the feature-coder himself, with his own
+tests. And I'm sure he won't submit a non-fully tested patch.
+
+I'm not sure there's a point doing a test suite for this now. When dillo reach
+v1.0 and everyone will be willing to add nigty feature, then we'll want to make
+sure we won't break anything.
+
+For now, I mainly want to test what I'm adding, relying on others to do the
+same for what they're doing.
+
+> For example, how about the
+> bookmark bug that someone pointed out was fixed THREE
+> times? A regression test on this should have helped
+> point this out earlier. :-) 
+
+The bookmark thing was always alpha code. It's a quick hack nobody wants to fix
+because :
+1) there's a lot to do elsewhere
+2) there's a bookmark as pluggin planned since day one, better, easier to fix,
+external to dillo, hopefully making obsolete the current fishy code.
+
+> However, since I actually 
+> probably know HTML and CSS better than I do XML or C,
+> I will probably be able to do these most readily.
+> 
+[2nd post]
+> I would definitely be willing to perform the tests,
+> given the links Eric just posted.
+
+If you want to maintain the Html testsuite thing, help yourself. You can take
+what I made and mix it with whatever you think is relevant. Or we can both
+update it.
+
+> Also, with Gzilla/Armadillo, I used to post Insure++
+> memory leak reports sometimes. I can do the same for
+> Dillo if it helps.
+
+That would be great !
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 17-Oct-2000 a 01:11:01
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Patches
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-16 15:20
+
+--- Jorge Arellano Cid <jcid@ne...> wrote:
+
+> I've read Daniel's posts on the subject and if
+> he's willing to perform the tests (or any one
+> else), please contact Eric and start working from
+his
+> test-suite.
+
+I would definitely be willing to perform the tests,
+given the links Eric just posted.
+
+Also, with Gzilla/Armadillo, I used to post Insure++
+memory leak reports sometimes. I can do the same for
+Dillo if it helps.
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Messenger - Talk while you surf! It's FREE.
+http://im.yahoo.com/ 
+
+
+
+RE: [Dillo-dev]Patches
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-16 15:17
+
+--- Eric GAUDET <egaudet@in...> wrote:
+
+> It's an HTML-rendering testsuite only. I won't build
+> any testsuite for cache behavior, http requests and
+> other things a browser is supposed to do. 
+> I understood there's a bedtest for Sebastian's new
+> Dw : I can include that.
+> It's the very first version : no one has reacted on
+> it yet. I expect to receive your own pages, comments
+> and (grammar :-/)
+> corrections so it can be improved.
+[extra deleted for brevity...]
+
+I just took a look at it. At the moment, it does look
+to me like a reasonable subset of HTML tests, given
+Dillo's current status/capabilities. When
+tables/frames support is complete, I am guessing that
+tables/frames tests will be the next thing to be
+added. :-)
+
+BTW, Mozilla has a *HUGE* test suite, with tests
+scattered all over the place. I suggest we might want
+to consider using some of these tests. I'd be willing
+to bring them over here and adapt them for Dillo's
+use, if you'd like to add them to your testsuite. 
+When the time comes, Mozilla also has XML, CSS, and
+JavaScript tests as well. They are good and complete,
+what's more.
+
+I think however that we *DO* also need things like
+http requests, cache behavior, and other things a
+browser should do. For example, how about the
+bookmark bug that someone pointed out was fixed THREE
+times? A regression test on this should have helped
+point this out earlier. :-) However, since I actually
+probably know HTML and CSS better than I do XML or C,
+I will probably be able to do these most readily.
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Messenger - Talk while you surf! It's FREE.
+http://im.yahoo.com/ 
+
+
+
+RE: [Dillo-dev]Patches
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 12:34
+
+-- En reponse de "[Dillo-dev]Patches" de Jorge Arellano Cid, le 16-Oct-2000 :
+> Regression tests:
+> -----------------
+> 
+> Some time ago Eric commited to compiling a test-suite for dillo
+> (we discussed several topics and its ready). I've had no time to
+> test it, nor to include it in official plans (due to lack of
+> time, --I sincerely apologize Eric).
+> 
+
+No problem : I much prefer you working on dillo's next version ;-)
+
+> I've read Daniel's posts on the subject and if he's willing to
+> perform the tests (or any one else), please contact Eric and
+> start working from his test-suite.
+> 
+
+I've already included in most of the pages I made if dillo v0.2.4's behavior is
+correct or not, and sometime what it should be. I planned to update this when
+next version (not cvs) will be available. 
+It's an HTML-rendering testsuite only. I won't build any testsuite for cache
+behavior, http requests and other things a browser is supposed to do. 
+I understood there's a bedtest for Sebastian's new Dw : I can include that.
+It's the very first version : no one has reacted on it yet. I expect to receive
+your own pages, comments and (grammar :-/) corrections so it can be improved.
+(actually I was waiting for Jorge's green light and corrections before
+publishing it, but you guys may want to know what's happening ;-)
+
+Here's a link where anyone can visite :
+http://www.rti-zone.org/dillo/Html.testsuite/
+
+Here's where you can download the whole suite :
+http://www.rti-zone.org/dillo/Html.testsuite.tar.gz
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 16-Oct-2000 a 21:19:43
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Patches
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-10-16 11:49
+
+Hi!
+
+The minimal consideration I expect from newcomers, is to read
+the home page before posting to this mailing list. If they don't
+or even worse, they do but decide to force their ways into this
+project, we have a bad start...
+
+Rules are there for a reason, and I want to thank Eric for
+pointing them out to the mailing list.
+
+
+> It would be really nice if we had an updated CVS version to patch
+> to, or if someone (one of the olders guys with the project) released a
+> 0.2.5 or 0.2.4-1 or something like that, with all the "pending"
+> patches included, cause frankly it seems too confusing and I have no
+> idea where to start programming so my works are all wasted/outdated.
+
+The CVS version is the most current (official).
+Developers can patch 0.2.4 (or CVS).
+
+> Sorry if I seemed annoyed, but I not. It just not nice to have
+> people effort thrown away in vain, when they could be producing lots
+> if things were a little bit more organized.
+
+Please don't blame on us the results of you not following our
+rules. You could have known that in advance. As a matter of fact,
+you knew I was working some of the bugs you tried to fix.
+
+If you read the mailing list archives, you'll find an
+"Activity" post (by me); there you'll find a list of things that
+your patch doesn't solve, and maybe then it will become clear why
+patches are reviewed before inclusion.
+
+Finally, I'll keep my schedule exactly as described in the
+"Activity" post.
+
+---
+
+Bug track engine:
+----------------
+
+I see one source of confussion (and a solution) here.
+
+I'll use the word "done" to signal a CVS commited patch.
+Developers, please only use comments or a percentage.
+
+Example:
+
+MrX@so... 70% <- The guy is making some progress
+
+MrX@so... 100% <- The guy is finished his work and the
+patch is expecting a review.
+
+MrX@so... 100% done <- The patch was reviewed (fixed) and
+commited to the CVS.
+
+
+----
+
+Regression tests:
+-----------------
+
+Some time ago Eric commited to compiling a test-suite for dillo
+(we discussed several topics and its ready). I've had no time to
+test it, nor to include it in official plans (due to lack of
+time, --I sincerely apologize Eric).
+
+I've read Daniel's posts on the subject and if he's willing to
+perform the tests (or any one else), please contact Eric and
+start working from his test-suite.
+
+
+----
+
+News:
+-----
+
+I want to thank Allan for his excellent work with dillo weekly
+News.
+
+
+
+Sincerely
+Jorge.- 
+
+
+
+Re: [Dillo-dev]About bugs #74 and #69 (better program and watch
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 11:12
+
+-- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and
+watch" de Livio Baldini Soares, le 16-Oct-2000 :
+>> Looks nice. I can't really test it, because my cable modem loads pages too
+>> fast
+>> and I can barely see the watch ;-) I wanted to see if one can scroll in a
+>> partially loaded page, but I can tell really.
+>> However, it seems not to wait until all images on a page are loaded, is it
+>> the expected behavior ?
+> 
+> Err, it's suppossed to do that. The watch serves so one can control
+> when the lock was ON or OFF, not when/while all the page was
+> loading. I did that cause sometimes the lock would go ON and wouldn't
+> go off like it should (like when a page is not found or some other
+> error, which currently the lock system isn't implemented to work
+> on). So if the cursor continued to be the watch for no reason, just
+> hit the STOP button, and everything should go back to normal.
+> 
+
+I'm asking because it seems to segfault too when clicking a link (or the
+button "back") on a page where all images are not loaded yet. Wasn't it
+supposed to protect from that too ?
+
+>> I experienced some segfaults too. I can't reproduce them each time, but it
+>> seems to occur when closing a window where a page (an image ?) is still
+>> loading.
+>> 
+> 
+> Yeah, I get that too, but as Sebastian said, closing windows are not
+> that simple... there's a need for a little bit of cleaning up, or else
+> pending requests don't have a place to go, then they get sad and crash
+> Dillo ;-)
+> 
+
+Ok, makes sens. So, is the windows closing code going to be your next patch ?
+;-))
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 16-Oct-2000 a 20:07:27
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]About bugs #74 and #69 (better program and watch
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-16 09:28
+
+Eric GAUDET writes:
+> -- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and
+> watch " de Livio Baldini Soares, le 16-Oct-2000 :
+
+> ...
+> Looks nice. I can't really test it, because my cable modem loads pages too fast
+> and I can barely see the watch ;-) I wanted to see if one can scroll in a
+> partially loaded page, but I can tell really.
+> However, it seems not to wait until all images on a page are loaded, is it the
+> expected behavior ?
+
+Err, it's suppossed to do that. The watch serves so one can control
+when the lock was ON or OFF, not when/while all the page was
+loading. I did that cause sometimes the lock would go ON and wouldn't
+go off like it should (like when a page is not found or some other
+error, which currently the lock system isn't implemented to work
+on). So if the cursor continued to be the watch for no reason, just
+hit the STOP button, and everything should go back to normal.
+
+> I experienced some segfaults too. I can't reproduce them each time, but it
+> seems to occur when closing a window where a page (an image ?) is still loading.
+> 
+
+Yeah, I get that too, but as Sebastian said, closing windows are not
+that simple... there's a need for a little bit of cleaning up, or else
+pending requests don't have a place to go, then they get sad and crash
+Dillo ;-)
+
+> 
+> please don't include the whole old messages.
+
+Oops, :-o forgot to cut it, sorry.
+
+bye,
+
+-- 
+Livio 
+
+
+
+Re: [Dillo-dev]About bugs #74 and #69 (better program and watch 
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 09:11
+
+-- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and
+watch " de Livio Baldini Soares, le 16-Oct-2000 :
+> Hi yall,
+> 
+> I've been working on my patch, to better it. First thing I wanted to
+> make the cursor change into a watch or something while the lock (which
+> I mention below) was on. To do is I started messing more with the code
+> and realized that the lock system which I created was starting to turn
+> into a headache. So what I did was, I encapsulated the system into
+> basically two calls (which I included into nav.c):
+> 
+...
+Looks nice. I can't really test it, because my cable modem loads pages too fast
+and I can barely see the watch ;-) I wanted to see if one can scroll in a
+partially loaded page, but I can tell really.
+However, it seems not to wait until all images on a page are loaded, is it the
+expected behavior ?
+I experienced some segfaults too. I can't reproduce them each time, but it
+seems to occur when closing a window where a page (an image ?) is still loading.
+
+> 
+> Attached is the gzipped patch, which should deprecate the previous I
+> sent. I don't know if this will help in the future, maybe Jorge will
+> sanitate all our problems with his new misterious Dw ;-). But until
+> then, I think this is a nice working patch. What do guys think?
+> 
+
+anyway that's a nice patch : I can't speak for Jorge, and I'm not so much in
+page-loading/caching stuff, but the concept seems good.
+
+> bye,
+> 
+> Livio.
+> 
+> Livio Baldini Soares writes:
+>> Hi (again),
+>> 
+...
+
+please don't include the whole old messages.
+
+bye
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 16-Oct-2000 a 18:00:54
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]File baseurl resolving behaviour
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-16 05:15
+
+Hi guys,
+
+again browsing in Dillo I tried to do the following; I wanted to
+check the contents of my /tmp directory, so I typed in:
+/tmp/
+
+on the "New Url", instead of file:/tmp/. Dillo assumed that it was a
+http request and tried to resolve http://tmp/.
+
+Im my opinion, this shouldn't happen. I think that if a user enters
+an URL starting with a '/' then he wants a file not a http. What do
+you guys think?
+
+Anyway, I've already made the patch (its really small), and am
+sending along with the message.
+
+bye,
+
+-- 
+Livio
+
+--- dillo.orig/src/interface.c Sat Sep 9 21:08:36 2000
++++ dillo.my/src/interface.c Mon Oct 16 03:06:12 2000
+@@ -654,7 +656,7 @@ Interface_openfile_ok_callback(GtkWidget
+*/
+void a_Interface_entry_open_url(GtkWidget *widget, BrowserWindow *bw)
+{
+- gchar *url;
++ gchar *url, *BaseUrl;
+GtkEntry *entry;
+
+/* Find which entry to get the URL from. This is a bit of a hack. */
+@@ -666,7 +668,13 @@ void a_Interface_entry_open_url(GtkWidge
+#ifdef VERBOSE
+g_print(ëntry_open_url %s\n", gtk_entry_get_text(entry));
+#endif
+- url = a_Url_resolve_relative("http:/", gtk_entry_get_text(entry));
++ if ( (gtk_entry_get_text(entry))[0] == '/') /* if the first char is a slash, */
++ BaseUrl = "file:"; /* the user wants a file. */
++ else
++ BaseUrl = "http:/";
++
++ url = a_Url_resolve_relative(BaseUrl, gtk_entry_get_text(entry));
++
+if ( url ) {
+a_Nav_push(bw, url);
+g_free(url); 
+
+
+
+Re: [Dillo-dev]About bugs #74 and #69 (better program and watch cursor feature)
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-16 03:02
+
+Attachments: seg_fault2.diff.gz      
+
+Hi yall,
+
+I've been working on my patch, to better it. First thing I wanted to
+make the cursor change into a watch or something while the lock (which
+I mention below) was on. To do is I started messing more with the code
+and realized that the lock system which I created was starting to turn
+into a headache. So what I did was, I encapsulated the system into
+basically two calls (which I included into nav.c):
+
+a_Nav_lock_acquire
+a_Nav_locl_release
+
+And except for some early BrowserWindow initilization, these are
+what you should call, and never access bw->nav_lock directly (like a
+private in C++). This way the code looks much better, and easier to
+understand and expand.
+
+With this done I was able to successfully implement the little
+"loading watch" which I wanted (it was getting on my nerves not
+knowing what Dillo was doing, if it was loading the page or not,
+etc. with this watch cursor a now the lock is acquire threfore
+*should* be indicating that it's loading a root-Url).
+
+Attached is the gzipped patch, which should deprecate the previous I
+sent. I don't know if this will help in the future, maybe Jorge will
+sanitate all our problems with his new misterious Dw ;-). But until
+then, I think this is a nice working patch. What do guys think?
+
+bye,
+
+Livio.
+
+Livio Baldini Soares writes:
+> Hi (again),
+> 
+> I know that Jorge is working on these bugs, but I *think* I've found
+> a good solution to the problems (actually I'm not really sure...). It
+> seems to me that the problem comes from a type of "concurrency"
+> problem within the IO and html/cache modules. The http requests in
+> Dillo, from what I understand, are all asynchronous, but I've seen no
+> concurrency controls in the modules. I think this lack of control is
+> generating the problem.
+> 
+> For example, if I press the "Achieved Goals" link in Dillo's home
+> page, don't wait for it to load and press the "Changelog" link (or any
+> other, even the "Acheived Goals" repeatelly), Dillo will request ALL
+> the "clicked" links pages. Up to this part everything should be ok
+> (actually no, but I'll get to that later), the problem comes in when
+> the requests arrive. Many requests start coming in and Dillo gets
+> "confused" and can't handle them all.
+> 
+> What I've done is prevented various (root) Url requests at the same
+> time. This is what Netscape does, when you click a link on a page, the
+> cursos turns into a watch and all the other links become
+> "un-clickable" until the new page gets loaded. I think this is a
+> "correct" behaviour and not a restriction to the user.
+> 
+> I did this in Dillo by placing a type of LOCK in the BrowserWindow
+> (browser.h) structure. Its a gboolean `nav_lock`. When someone tries
+> to load a root-url, by using the `a_Nav_push` I set the nav_lock to
+> TRUE. By doing this I disabled any type of user navigation. The only
+> two places where `nav_lock` comes FALSE again is by pressing STOP (in
+> the `a_Commands_stop_callback) and in the `a_Nav_expect_done`
+> function, because here we can assume that the root url has changed
+> (bw->nav_stack[nav_stack_ptr]) and therefore we can allow the user to
+> navigate savely again.
+> 
+> When I got this working I would still (very seldomly) get
+> seg. faults. Studying the problem I found out that if, for example,
+> you click on a link, then wait until it get "unlocked" (when the
+> `a_expect_done` is called), then press BACK before the entire page
+> loaded (pics and all), a few pending requests for that page are still
+> coming in. With that in mind, I tought of two choices:
+> 
+> 1) Everytime the user requested for an URL, Dillo should cancel all
+> the pending requests for old URLs, so that the requests wouldn't
+> arrive later "unexpectedly".
+> 
+> 2) Don't cancel the requests since Dillo has already made then; I
+> think it would be a wast of data. Instead just ignore the few pending
+> requests.
+> 
+> I chose option 2. I did this similar to what Sam Dennis did a while
+> ago (when he send the patch). From what I can see applying these two
+> ideas (the lock and Sam's patch) we have a pretty much clean fix to
+> the problem. Of course I could be wrong and missing the "root" of the
+> problem. Does anybody see any flaws in what I've described above?
+> 
+> This lock system, if it's conceptually correct, should fix this
+> bug. But what I've implemented is NOT the complete lock system, it's
+> just a preview on how I tought to fix this problem. If you guys like
+> the idea, I'll have to finish up the exception handling (so if there's
+> an error while downloading a page, navigation doesn't become forever
+> disabled, erroneously locked).
+> 
+> I'm sending the patch that should implement this fix, included is
+> Sam's patch (html_loading.diff) and the cache patch (cache_patch), so
+> there's no need to apply those patches, only this one. This patch
+> should be applyed against the CVS version.
+> 
+> hope this helps, bye,
+> 
+> -- 
+> Livio 
+
+
+
+RE: [Dillo-dev]Where's bug #80 fix?
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 01:59
+
+-- En reponse de "RE: [Dillo-dev]Where's bug #80 fix?" de Eric GAUDET, le
+16-Oct-2000 :
+> If you want to test all my patches, here's an (temporary, don't rely on it)
+> address where you can download all of them with a txt file of explanations :
+> 
+
+Sorry, here's the address :
+http://www.rti-zone.org/dillo/
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 16-Oct-2000 a 10:58:42
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Where's bug #80 fix?
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-16 01:28
+
+-- En reponse de "[Dillo-dev]Where's bug #80 fix?" de Livio Baldini Soares, le
+15-Oct-2000 :
+> Hello,
+> 
+> I saw in the Bug Engine that bug #80 (seg. fault, when right
+> clicking in a text/plain page) was taken cared of. If I recall
+> correctly it stated that Eric fixed it, but I can't seem to find
+> anything about it in the mail archive, nor any of Allan's patches
+> contain a solution for it. Anybody know how's the fix? Eric?
+> 
+> bye,
+> 
+
+I always send my patches t directly to Jorge, not to the mailing list, because
+that's what Jorge asked.
+If you want to test all my patches, here's an (temporary, don't rely on it)
+address where you can download all of them with a txt file of explanations :
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 16-Oct-2000 a 10:20:19
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Where's bug #80 fix?
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-15 20:17
+
+Hello,
+
+I saw in the Bug Engine that bug #80 (seg. fault, when right
+clicking in a text/plain page) was taken cared of. If I recall
+correctly it stated that Eric fixed it, but I can't seem to find
+anything about it in the mail archive, nor any of Allan's patches
+contain a solution for it. Anybody know how's the fix? Eric?
+
+bye,
+
+-- 
+Livio 
+
+
+
+Re: [Dillo-dev]Close Window command
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-15 20:07
+
+Sebastian Geerken writes:
+> Livio Baldini Soares wrote:
+(...)
+> 
+> There is a function a_Interface_new_browser_window, so there should
+> probably also be a function a_Interface_destroy_browser_window, which
+> will do a bit more that destroying the widget. Merely destroying the
+> widget could even cause crashes (AFAIK dillo), since the still active
+> IO stuff could try to add text into the nonexisting page widget.
+
+Oops, guess your right... sorry. So we don't "forget" to do this, I
+inserted this as a Bug in the Bug Engine, it's bug #87.
+
+bye,
+
+-- 
+Livio 
+
+
+
+Re: [Dillo-dev]Old CVS
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-15 19:56
+
+--- Sam Dennis <sdennis101@ge...> wrote:
+> Correct me if I'm wrong, but isn't an out of date
+> cvs version an oxymoron?
+> 
+> It seems like it's extremely difficult to avoid
+> repeating work currently
+> because patches have been made but the cvs version
+> hasn't changed.
+
+I agree. Question is, why are the patches not being
+committed to CVS? I would think the thing to do it
+have them checked in, after undergoing a code review. 
+Then we wouldn't have this problem. Besides, if a
+change is found later to cause problems, it can be
+backed out. Again, some kind of automated regression
+testing infrastructure would make this part easier, too.
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Messenger - Talk while you surf! It's FREE.
+http://im.yahoo.com/ 
+
+
+
+[Dillo-dev]Old CVS
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-15 19:32
+
+Correct me if I'm wrong, but isn't an out of date cvs version an oxymoron?
+
+It seems like it's extremely difficult to avoid repeating work currently
+because patches have been made but the cvs version hasn't changed.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Dillo Weekly News
+
+From: Allan Clark <shark@bl...> - 2000-10-15 11:43
+
+This weeks Dillo Weekly News has been posted you can find it here
+http://www.shark.pwp.blueyonder.co.uk/news/news151000.html
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+Re: [Dillo-dev]Close Window command
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-15 10:29
+
+Livio Baldini Soares wrote:
+> 
+> Hi all,
+> 
+> messing with Dillo, I tried to do the `Close Window` function
+> (Crtl-W or Menu select `File -> Close Window`), well nothing
+> happenned. I looked at commands.c, and all I found was the empty stub:
+> 
+> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data)
+> {
+> }
+> 
+> Below it I also saw the exit_callback and in it a commentary:
+> /* There should be a close command that does this: */
+> /* gtk_widget_destroy (bw->main_window); */
+> 
+> So, that's exactly what I did, now close_callback looks like:
+> 
+> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data)
+> {
+> gtk_widget_destroy(((BrowserWindow *) client_data)->main_window);
+> }
+> 
+> What gives? Am I missing something? Why wasn't this already done? I
+> tried it out and it's working fine. Including when your in the last
+> window (only one left) and when you `close` it (not `exit`), dillo
+> exits normally.
+> 
+> I guess I've probably missed some previous discussion... Just in case,
+> I'm sending the "patch".
+
+There is a function a_Interface_new_browser_window, so there should
+probably also be a function a_Interface_destroy_browser_window, which
+will do a bit more that destroying the widget. Merely destroying the
+widget could even cause crashes (AFAIK dillo), since the still active
+IO stuff could try to add text into the nonexisting page widget.
+
+Sebastian 
+
+
+
+[Dillo-dev]About bugs #74 and #69
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-15 08:49
+
+Attachments: seg_fault.diff      
+
+Hi (again),
+
+I know that Jorge is working on these bugs, but I *think* I've found
+a good solution to the problems (actually I'm not really sure...). It
+seems to me that the problem comes from a type of "concurrency"
+problem within the IO and html/cache modules. The http requests in
+Dillo, from what I understand, are all asynchronous, but I've seen no
+concurrency controls in the modules. I think this lack of control is
+generating the problem.
+
+For example, if I press the "Achieved Goals" link in Dillo's home
+page, don't wait for it to load and press the "Changelog" link (or any
+other, even the "Acheived Goals" repeatelly), Dillo will request ALL
+the "clicked" links pages. Up to this part everything should be ok
+(actually no, but I'll get to that later), the problem comes in when
+the requests arrive. Many requests start coming in and Dillo gets
+"confused" and can't handle them all.
+
+What I've done is prevented various (root) Url requests at the same
+time. This is what Netscape does, when you click a link on a page, the
+cursos turns into a watch and all the other links become
+"un-clickable" until the new page gets loaded. I think this is a
+"correct" behaviour and not a restriction to the user.
+
+I did this in Dillo by placing a type of LOCK in the BrowserWindow
+(browser.h) structure. Its a gboolean `nav_lock`. When someone tries
+to load a root-url, by using the `a_Nav_push` I set the nav_lock to
+TRUE. By doing this I disabled any type of user navigation. The only
+two places where `nav_lock` comes FALSE again is by pressing STOP (in
+the `a_Commands_stop_callback) and in the `a_Nav_expect_done`
+function, because here we can assume that the root url has changed
+(bw->nav_stack[nav_stack_ptr]) and therefore we can allow the user to
+navigate savely again.
+
+When I got this working I would still (very seldomly) get
+seg. faults. Studying the problem I found out that if, for example,
+you click on a link, then wait until it get "unlocked" (when the
+`a_expect_done` is called), then press BACK before the entire page
+loaded (pics and all), a few pending requests for that page are still
+coming in. With that in mind, I tought of two choices:
+
+1) Everytime the user requested for an URL, Dillo should cancel all
+the pending requests for old URLs, so that the requests wouldn't
+arrive later "unexpectedly".
+
+2) Don't cancel the requests since Dillo has already made then; I
+think it would be a wast of data. Instead just ignore the few pending
+requests.
+
+I chose option 2. I did this similar to what Sam Dennis did a while
+ago (when he send the patch). From what I can see applying these two
+ideas (the lock and Sam's patch) we have a pretty much clean fix to
+the problem. Of course I could be wrong and missing the "root" of the
+problem. Does anybody see any flaws in what I've described above?
+
+This lock system, if it's conceptually correct, should fix this
+bug. But what I've implemented is NOT the complete lock system, it's
+just a preview on how I tought to fix this problem. If you guys like
+the idea, I'll have to finish up the exception handling (so if there's
+an error while downloading a page, navigation doesn't become forever
+disabled, erroneously locked).
+
+I'm sending the patch that should implement this fix, included is
+Sam's patch (html_loading.diff) and the cache patch (cache_patch), so
+there's no need to apply those patches, only this one. This patch
+should be applyed against the CVS version.
+
+hope this helps, bye,
+
+-- 
+Livio 
+
+
+
+[Dillo-dev]Close Window command
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-15 06:24
+
+Hi all,
+
+messing with Dillo, I tried to do the `Close Window` function
+(Crtl-W or Menu select `File -> Close Window`), well nothing
+happenned. I looked at commands.c, and all I found was the empty stub:
+
+void a_Commands_close_callback(GtkWidget *widget, gpointer client_data)
+{
+}
+
+Below it I also saw the exit_callback and in it a commentary:
+/* There should be a close command that does this: */
+/* gtk_widget_destroy (bw->main_window); */
+
+So, that's exactly what I did, now close_callback looks like:
+
+void a_Commands_close_callback(GtkWidget *widget, gpointer client_data)
+{
+gtk_widget_destroy(((BrowserWindow *) client_data)->main_window);
+}
+
+What gives? Am I missing something? Why wasn't this already done? I
+tried it out and it's working fine. Including when your in the last
+window (only one left) and when you `close` it (not `exit`), dillo
+exits normally.
+
+I guess I've probably missed some previous discussion... Just in case,
+I'm sending the "patch".
+
+bye,
+
+-- 
+Livio <livio@li...>
+
+--- dillo.orig/src/commands.c Mon Aug 28 22:25:45 2000
++++ dillo.my/src/commands.c Sun Oct 15 04:17:31 2000
+@@ -63,10 +63,11 @@ void a_Commands_prefs_callback(GtkWidget
+}
+
+/*
+- * ?
++ * Close only the selected Window
+*/
+void a_Commands_close_callback(GtkWidget *widget, gpointer
+client_data)
+{
++ gtk_widget_destroy(((BrowserWindow *) client_data)->main_window);
+}
+
+/* 
+
+
+
+Re: [Dillo-dev]Archiving patches
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-15 06:21
+
+-- En reponse de "Re: [Dillo-dev]Archiving patches" de Livio Baldini Soares, le
+15-Oct-2000 :
+> 
+> With all these patches I'm starting to get a little confused... I'm
+> trying to solve bug 74# (and others that arise due to the same
+> problem), I believe I've found the problem and have a "clean"and
+> simple fix, but I'm supposed to build it on top of what version?
+> 0.2.4? CVS? CVS with all the patches applyed?
+> 
+
+You should not bother with published patches unless you want to test one (and
+only one at time : it's very unlikely you can apply all without reworking most
+of the diffs, which will be done by Jorge for next version)
+You want to patch against v0.2.4, (or CVS version, which claims to be v0.2.5).
+It's also possible you need/find handy to patch a patched version. If you don't
+patch against vanilla v0.2.4, list all patches needed before yours.
+
+> I'm asking cause some of these changes will affect other code we
+> build on top. Plus there seems to be a new Dw beeing made, and a
+> testbed(?).
+> 
+
+We're not sure of what the new Dw will look like. Sebastian hasn't finished it
+yet.
+
+> It would be really nice if we had an updated CVS version to patch
+> to, or if someone (one of the olders guys with the project) released a
+> 0.2.5 or 0.2.4-1 or something like that, with all the "pending"
+> patches included, cause frankly it seems too confusing and I have no
+> idea where to start programming so my works are all wastedøutdated.
+> 
+
+Only jorge can decide if a submitted patch will be included in the official
+dillo version. It's not a good thing to have a fully patched version. For us
+patchers, there's only one developper version, the lastest : 0.2.4.
+CVS is to be considered experimental.
+
+> By the way, is the `Bug Track System` being used? More precisely is it
+> valid and not outdated?
+> 
+
+The bug track system is the most up-to-date informations you'll have, because
+it's automated and updated by everybody (actually I think Jorge is kind of
+moderating it, but the delay is not noticably larger than one day).
+Use it to report bugs you've found and things you want fixed by somebody else.
+Use it to tell everybody what you are working on (to avoid duplicate efforts).
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Oct-2000 a 13:07:20
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Archiving patches
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-15 03:15
+
+Allan Clark writes:
+> Just to let everyone know I have started to archive most of the patches that
+> get sent to the list, it was prompted by Sammy's post about looking for the
+> first find text patch, anyway you can find a sort of index at
+> http://www.shark.pwp.blueyonder.co.uk/patches.html I say sort of as it makes
+> no attempt to explain the patches merely provides links to them.
+> 
+
+This is really helpfull! I got all the patches (ps. seems like
+html_loading.diff and html_loading1.diff are the same. Anything wrong
+with that?).
+
+With all these patches I'm starting to get a little confused... I'm
+trying to solve bug 74# (and others that arise due to the same
+problem), I believe I've found the problem and have a "clean"and
+simple fix, but I'm supposed to build it on top of what version?
+0.2.4? CVS? CVS with all the patches applyed?
+
+I'm asking cause some of these changes will affect other code we
+build on top. Plus there seems to be a new Dw beeing made, and a
+testbed(?).
+
+It would be really nice if we had an updated CVS version to patch
+to, or if someone (one of the olders guys with the project) released a
+0.2.5 or 0.2.4-1 or something like that, with all the "pending"
+patches included, cause frankly it seems too confusing and I have no
+idea where to start programming so my works are all wastedøutdated.
+
+Sorry if I seemed annoyed, but I'm not. It's just not nice to have
+people's effort thrown away in vain, when they could be producing lots
+if things were a little bit more organized.
+
+By the way, is the `Bug Track System` being used? More precisely is it
+valid and not outdated?
+
+bye and sorry for bugging yall ;-)
+
+-- 
+Livio 
+
+
+
+[Dillo-dev]Archiving patches
+
+From: Allan Clark <shark@bl...> - 2000-10-14 18:25
+
+Just to let everyone know I have started to archive most of the patches that
+get sent to the list, it was prompted by Sammy's post about looking for the
+first find text patch, anyway you can find a sort of index at
+http://www.shark.pwp.blueyonder.co.uk/patches.html I say sort of as it makes
+no attempt to explain the patches merely provides links to them.
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+Re: [Dillo-dev]Bug #85 fix
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-14 18:20
+
+--- Daniel Roberts <zuperdee@ya...> wrote:
+
+> That's why one does QA/regression tests. :-) 
+> Perhaps this is a sign that Dillo needs some kind of
+> QA/regression testing framework?
+
+BTW, this also is reason to think about open-source
+philosophy... I am not ordinarily that philosophical,
+but it has occured to me that ESR said in "The
+Cathedral and the Bazaar," that "given enough eyes,
+all bugs are shallow."
+
+However, seeing this bug which has regressed THREE
+times now, I think, proves ESR wrong on this point. 
+His approach seems rather like the classic "monkeys at
+typewriters" approach to Shakespeare--that is, given
+enough 1000's of monkeys at enough 1000's of
+typewriters, one of them somewhere will type "to be or
+not to be."
+
+I do believe however, this proves why one needs to
+think of open-source as merely the LICENSING framework
+for a project, and not a specification on how the
+development efforts are coordinated and managed... 
+Case in point: the GCC Steering Committee does
+automated regression tests. I think Dillo could
+benefit from this, too.
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Messenger - Talk while you surf! It's FREE.
+http://im.yahoo.com/ 
+
+
+
+Re: [Dillo-dev]Bug #85 fix
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-14 17:10
+
+--- Sammy Mannaert <nstalkie@tv...> wrote:
+
+> this is a bug i once fixed ... i know the bookmarks
+> have been rewritten so the old mistake might have
+> come back for the THIRD time :) (it was originally
+in
+> gzilla/armadillo, where i fixed it, then dillo came
+> into existance, where i fixed it again (i think),
+and
+> now again)
+
+> any predictions on how much it will show up again ?
+
+That's why one does QA/regression tests. :-) Perhaps
+this is a sign that Dillo needs some kind of
+QA/regression testing framework?
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Messenger - Talk while you surf! It's FREE.
+http://im.yahoo.com/ 
+
+
+
+Re: [Dillo-dev]Bug #85 fix
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-14 15:42
+
+-- En reponse de "Re: [Dillo-dev]Bug #85 fix" de Sammy Mannaert, le 14-Oct-2000
+> 
+> strange ...
+> 
+> this is a bug i once fixed ... i know the bookmarks have been rewritten
+> so the old mistake might have come back for the THIRD time :) (it was
+> originally in gzilla/armadillo, where i fixed it, then dillo came into
+> existance, where i fixed it again (i think), and now again)
+> 
+> any predictions on how much it will show up again ? :)
+> 
+
+When the bookmark plugin I'm coding will be integrated, it won't anymore :
+there will be *new* bugs ;-)
+
+> sammy
+> 
+> PS: i've been pretty inactive lately (though i have been following the
+> mailing list), i'll try doing a few patches in the coming month ...
+> 
+
+me too :-/
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Oct-2000 a 00:39:28
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Bug #85 fix
+
+From: Sammy Mannaert <nstalkie@tv...> - 2000-10-14 15:13
+
+Livio Baldini Soares wrote:
+
+> Hi again,
+>
+> first let me thank Eric for taking the time in answering me. I found
+> out what the problem was with my glib (I had 2 glib's installed, one
+> in /usr/ and the other in /usr/local, I guess they were conflicting,
+> since their versions didn't match).
+>
+> Messing around with Dillo I wanted to bookmark Dillo's home page
+> (dillo.so....net) and then Seg. Fault!
+>
+> I looked at the code, and I guess I got a patch working (actually just
+> an tiny change, just a NULL check). Latter I found out at the Bug
+> Track page that this was bug #85. Hope this helps, here's the patch.
+>
+> bye,
+>
+> PS: I read in the mail archive that someone made a patch for the `Find
+> Text...' function, where can I find it? The only thing I found was
+> another patch to be used afterwards so the use of anchors wouldn't be
+> needed.
+>
+> --
+> Livio <livio@li...>
+>
+> $ diff -pru dillo/src/bookmark.c dillo.my/src/bookmark.c
+>
+> --- dillo/src/bookmark.c Mon Aug 28 22:43:47 2000
+> +++ dillo.my/src/bookmark.c Fri Oct 13 21:25:41 2000
+> @@ -165,7 +165,7 @@ void a_Bookmarks_add(GtkWidget *widget,
+> return;
+>
+> /* If the page has no title, lets use the URL */
+> - if (strcmp (title, ¨) == 0)
+> + if ( !title || (strcmp (title, ¨) == 0))
+> title = url;
+>
+> #ifdef TITLE39
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+strange ...
+
+this is a bug i once fixed ... i know the bookmarks have been rewritten
+so the old mistake might have come back for the THIRD time :) (it was
+originally in gzilla/armadillo, where i fixed it, then dillo came into
+existance, where i fixed it again (i think), and now again)
+
+any predictions on how much it will show up again ? :)
+
+sammy
+
+PS: i've been pretty inactive lately (though i have been following the
+mailing list), i'll try doing a few patches in the coming month ... 
+
+
+
+RE: [Dillo-dev]Bug #85 fix
+
+From: Allan Clark <shark@bl...> - 2000-10-14 08:47
+
+You should find the original message in the archives here
+http://www.geocrawler.com/lists/3/SourceForge/702/0/4469704/
+also I put it on the site I use for the dillo news although I don't link to
+it, I do that with most of the pathces just for safe keeping you can find it
+here
+http://www.shark.pwp.blueyonder.co.uk/findtext.diff.gz
+
+<snip>
+> PS: I read in the mail archive that someone made a patch for the `Find
+> Text...' function, where can I find it? The only thing I found was
+> another patch to be used afterwards so the use of anchors wouldn't be
+> needed.
+<snip> 
+
+
+
+[Dillo-dev]Bug #85 fix
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-13 23:52
+
+Hi again,
+
+first let me thank Eric for taking the time in answering me. I found
+out what the problem was with my glib (I had 2 glib's installed, one
+in /usr/ and the other in /usr/local, I guess they were conflicting,
+since their versions didn't match). 
+
+Messing around with Dillo I wanted to bookmark Dillo's home page
+(dillo.so....net) and then Seg. Fault!
+
+I looked at the code, and I guess I got a patch working (actually just
+an tiny change, just a NULL check). Latter I found out at the Bug
+Track page that this was bug #85. Hope this helps, here's the patch.
+
+bye,
+
+PS: I read in the mail archive that someone made a patch for the `Find
+Text...' function, where can I find it? The only thing I found was
+another patch to be used afterwards so the use of anchors wouldn't be
+needed. 
+
+--
+Livio <livio@li...>
+
+$ diff -pru dillo/src/bookmark.c dillo.my/src/bookmark.c 
+
+--- dillo/src/bookmark.c Mon Aug 28 22:43:47 2000
++++ dillo.my/src/bookmark.c Fri Oct 13 21:25:41 2000
+@@ -165,7 +165,7 @@ void a_Bookmarks_add(GtkWidget *widget, 
+return;
+
+/* If the page has no title, lets use the URL */
+- if (strcmp (title, ¨) == 0)
++ if ( !title || (strcmp (title, ¨) == 0))
+title = url;
+
+#ifdef TITLE39 
+
+
+
+RE: [Dillo-dev]Newbie questions
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-13 11:14
+
+-- En reponse de "[Dillo-dev]Newbie questions" de Livio Baldini Soares, le
+13-Oct-2000 :
+> Hi guys,
+> 
+> I was looking around in Sourceforge for a new browser in constrution
+> (or finished), 'cause I'm goddam sick of Netscape exiting for no
+> reason at all. I found that Dillo was the best project and looks like
+> it has future. I liked the project so I've decided to try to
+> contribute in any way way I can. The problem is I'm still a newbie in
+> Linux and Unix programming, so if I'm being out of hand or something,
+> please let me know.
+> 
+
+Welcome.
+
+> Where are the latest versions/patches? I saw somewhere on your webpage
+> (dillo.so....net/Dname.html) that there are MIME/ and URL/
+> directories undeer the src/, but when I got the 0.2.4 version, I found
+> no such directories.
+> 
+
+Lastest version is 0.2.4. You can patch against it. mime and url directories,
+as well as the Dname.html page look like old stuff (gzilla era), you can safely
+ignore them.
+
+> I downloaded the cvs files by doing:
+> 
+> $ cvs -z3 -d:pserver:anonymous@cv...:/cvsroot/dillo co
+> dillo
+> 
+> like indicated on the Sourceforge CVS page. And then couldn't compile
+> it. The problem was with the `g_print()'. I don't know, but there must
+> be something wrong with my system (I use Debian 2.1, aka potato, and
+> have installed: libglib1.2(-dev) -- 1.2.7-2). I try to compile a
+> simple program like:
+> 
+> -----------------------
+>#include <glib.h>
+> 
+> int main(void){
+> 
+> g_print("Testing...\n");
+> 
+> return 0;
+> }
+> -----------------------
+> And compile it:
+> $ gcc test.c -o test -lglib -I/usr/lib/glib/include/
+> $ ./test
+> Segmentation fault
+> 
+
+Did you try to trace the program ? (I use xxgdb, which is an athena
+front-end to gdb, crude but efficient : "xxgdb ./test", then run, then stack )
+
+> Someone knows what's going on? 
+> 
+> What I did to "overcome" this problem is switched to plain `printf()'
+> function:
+> 
+> $ cd src/
+> $ for i in `find . -name "*.c"`; do ./chg $i g_print printf; done
+> 
+> And THEN it compiled. I'm running it fine and enjoying it! Congrats on
+> the great work guys.
+> 
+
+If you want your patches included in dillo, you'll have to fix this glib
+problem.
+
+> PS: Sorry about the stupid questions, and the long mail.
+
+We're here to help, you can ask.
+
+> PS1: Sorry for the bad english..., I'm Brazilian.
+> 
+
+No problem : most of us are not native english speaker and we won't even notice
+a thing ;-)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 13-Oct-2000 a 20:02:55
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Newbie questions
+
+From: Livio Baldini Soares <livio@li...> - 2000-10-13 04:56
+
+Hi guys,
+
+I was looking around in Sourceforge for a new browser in constrution
+(or finished), 'cause I'm goddam sick of Netscape exiting for no
+reason at all. I found that Dillo was the best project and looks like
+it has future. I liked the project so I've decided to try to
+contribute in any way way I can. The problem is I'm still a newbie in
+Linux and Unix programming, so if I'm being out of hand or something,
+please let me know.
+
+Where are the latest versions/patches? I saw somewhere on your webpage
+(dillo.so....net/Dname.html) that there are MIME/ and URL/
+directories undeer the src/, but when I got the 0.2.4 version, I found
+no such directories.
+
+I downloaded the cvs files by doing:
+
+$ cvs -z3 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo
+
+like indicated on the Sourceforge CVS page. And then couldn't compile
+it. The problem was with the `g_print()'. I don't know, but there must
+be something wrong with my system (I use Debian 2.1, aka potato, and
+have installed: libglib1.2(-dev) -- 1.2.7-2). I try to compile a
+simple program like:
+
+-----------------------
+#include <glib.h>
+
+int main(void){
+
+g_print("Testing...\n");
+
+return 0;
+}
+-----------------------
+And compile it:
+$ gcc test.c -o test -lglib -I/usr/lib/glib/include/
+$ ./test
+Segmentation fault
+
+Someone knows what's going on? 
+
+What I did to "overcome" this problem is switched to plain `printf()'
+function:
+
+$ cd src/
+$ for i in `find . -name "*.c"`; do ./chg $i g_print printf; done
+
+And THEN it compiled. I'm running it fine and enjoying it! Congrats on
+the great work guys.
+
+PS: Sorry about the stupid questions, and the long mail.
+PS1: Sorry for the bad english..., I'm Brazilian.
+
+thanks for the attention,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Patch to support font-loading on the iPaq handheld.
+
+From: Eric Christianson <echristi@ri...> - 2000-10-12 17:15
+
+This patch allows one of the default fonts on the compaq iPaq
+linux distribution to work. (www.handhelds.org)
+
+
+1098,1103d1097
+< 
+< if (font->font == NULL) {
+< /* Can't load the font - try another platform font that should be available. (iPaq) */
+< font->font = gdk_font_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1");
+< }
+< 
+
+Eric Christianson
+RidgeRun, Inc.
+http://www.ridgerun.com 
+
+
+
+Re: [Dillo-dev]Find text patch
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-11 20:03
+
+Sam Dennis wrote:
+> I did think of doing something like that, but I presumed that the functions
+> already in place would have been exported if that was desirable.
+I wrote all these functions (from
+Dw_gtk_scroller_adjustment_value_changed to the end) for anchors, and
+exported only those which were necessary for them. If some functions
+are useful for other purposes, they may be exported, too.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Find text bugs
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-10 17:24
+
+On Tue, Oct 10, 2000 at 01:25:42AM +0000, Sam Dennis wrote:
+> Er, it does segfault sometimes, I have to admit, but I'm almost certain that
+> it's not my fault...
+
+I think that most of the crashes are happening in the html rendering,
+actually. Although I have had one or two of them inside a perfectly valid
+call to realloc.
+
+Since then I've tried to test it by searching around a nice long court
+transcript and it didn't crash once. This and a number of other things makes
+me begin to suspect my libc instead...
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Find text patch
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-10 17:19
+
+On Tue, Oct 10, 2000 at 04:43:17PM +0200, Sebastian Geerken wrote:
+> Sam Dennis wrote:
+> > 
+> > I've implemented a find text command for the first instance of the string
+> > (it shouldn't be too difficult to extend it to finding multiple instances,
+> > probably just starting by looking from the line after the last instance was
+> > found).
+> > 
+> > I'm sorry about the anchor, but it seemed like the only sane way to scroll
+> > to the line we found.
+> 
+> This patch doesn't use anchors. Apply it after Sam's patch.
+> 
+> Sebastian
+
+I did think of doing something like that, but I presumed that the functions
+already in place would have been exported if that was desirable.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Find text patch
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-10 13:08
+
+Attachments: findtext2.diff      
+
+Sam Dennis wrote:
+> 
+> I've implemented a find text command for the first instance of the string
+> (it shouldn't be too difficult to extend it to finding multiple instances,
+> probably just starting by looking from the line after the last instance was
+> found).
+> 
+> I'm sorry about the anchor, but it seemed like the only sane way to scroll
+> to the line we found.
+
+This patch doesn't use anchors. Apply it after Sam's patch.
+
+Sebastian 
+
+
+
+[Dillo-dev]Find text bugs
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-10 00:22
+
+Er, it does segfault sometimes, I have to admit, but I'm almost certain that
+it's not my fault...
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Find text patch
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-10 00:10
+
+Attachments: findtext.diff.gz      
+
+I've implemented a find text command for the first instance of the string
+(it shouldn't be too difficult to extend it to finding multiple instances,
+probably just starting by looking from the line after the last instance was
+found).
+
+I'm sorry about the anchor, but it seemed like the only sane way to scroll
+to the line we found.
+
+It doesn't highlight the string found in any way, partially because I don't
+think that any mechanism for this is currently in place.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Find text implementation problems
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-09 20:15
+
+On Mon, Oct 09, 2000 at 10:54:32PM +0200, Sebastian Geerken wrote:
+> ...
+> scroller = GTK_DW_SCROLLER (bw->docwin);
+> view = GTK_DW_VIEW (dw_scroller->viewport);
+> border = (DwBorder*) (view->dw);
+> page = (DwPage*) (border->child);
+
+Er, a little convoluted, isn't it?
+
+> 
+> I think border is sometimes NULL, so you may add some checks.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Find text implementation problems
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-09 19:21
+
+Sam Dennis wrote:
+> 
+> I've been looking at implementing the find text function and had got half
+> way through mentally coding a solution (because of the DwPage{Line,Word})
+> before I realised that all the callback has is the browser window, and I
+> could see no way of getting at a DwPage from that, which is essential for
+> searching.
+> 
+> Am I missing something obvious?
+
+BrowserWindow *bw;
+GtkDwScroller *scroller;
+GtkDwView *view;
+DwBorder *border;
+DwPage *page;
+
+scroller = GTK_DW_SCROLLER (bw->docwin);
+view = GTK_DW_VIEW (dw_scroller->viewport);
+border = (DwBorder*) (view->dw);
+page = (DwPage*) (border->child);
+
+I think border is sometimes NULL, so you may add some checks.
+
+Sebastian 
+
+
+
+[Dillo-dev]Small idea for caching
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-09 17:22
+
+I've just discovered a note I made to myself a while ago about dillo's
+caching system. There is currently a complex system of callbacks necessary,
+but couldn't a lot of that be thrown away with a simple pipe between the
+caching system (server) and the dillo widget (client)?
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Activity
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-10-09 17:07
+
+Hi there!
+
+
+Just as before, silence periods on the mailing list, signal
+high activity on the background! (Well, my email box seldom stops
+its flow).
+
+I'm very pleased for the "parallel" working the code is getting
+(Several improvement and fixing patches, design on the widget
+side and design on the Networking and middle layers by my side).
+
+Currently I have a lengthy queue of patches waiting to be
+processed (from Jörgen, Eric, Agustín, Marcos, ...). And I keep
+trying to solve the design issues of Networking/Middle-Layers
+that result in a lot of related bugs. I think this is the highest
+priority (for me to work on); Look this:
+
+- BUGs 74, 84, 64 and 69 are related to it.
+- File images being decoded every time (not fed by the dicache)
+- Fine reload functionality can't be done without it.
+- The problem asked by Sean MacLennan
+- Sudden crashes
+- Slow downloads (it may happen)
+- General browser stability.
+- etc.
+
+I'll keep working on it all October; If I don't succeed, I'll
+start reviewing/integrating every patch and make a new release
+based on 0.2.4.
+
+The good news is that finally I got into a design model that
+handles all the necessary stuff. The bad new is that it's too
+complex (and we all know that maintaining such things becomes a
+nightmare). So, it will be done when I devise a way to simplify
+it one or two "degrees".
+
+
+Jorge.-
+
+Ps: Marcos has sent me a patch with basic authentication support!
+
+------------------------- ooOOoo -----------------------------
+Some answers:
+
+> I am try to add Mosaic style remote access to dillo. From a unix signal
+> handler I want to push an url. The command a_Nav_push works *once*, then
+> fails from then on.
+
+Yes, I know. That's the right way to do it though. 
+I mean: a_Nav_push should not crash; that's a BUG.
+
+> I have a patch below that shows a very simple
+> example of this, plus an attempt to set the text in the location widget.
+> I can set the text correctly, but I do not know how to then signal gtk
+> to process the line.
+
+That is part of a_Nav_push's work. You should not worry doing
+it "by hand". It seems to me that you'll have to wait until the
+design concerns that eliminate "the BUG" are done.
+
+(The only thing you need to worry about is not calling
+a_Nav_push from an interrupt handler, but to generate an event
+that triggers it from GTK's main loop).
+
+-------------------------------------
+
+> I've been looking at implementing the find text function and had got half
+> way through mentally coding a solution (because of the DwPage{Line,Word})
+> before I realised that all the callback has is the browser window, and I
+> could see no way of getting at a DwPage from that, which is essential for
+> searching.
+> 
+> Am I missing something obvious?
+
+Obvious? I don't think so!
+
+The top 'dw' is set by a_Dw_gtk_scroller_set_dw (you can follow
+the chain from there).
+
+In brief:
+
+bw->docwin is a GtkDwScroller
+bw->docwin->viewport->dw is a DwBorder
+bw->docwin->viewport->dw->child is a DwPage or a DwImage
+
+so, something like this will get you going:
+
+GtkDwScroller *scroller = bw->docwin;
+DwBorder *border = scroller->viewport->dw;
+DwPage *page = border->child;
+
+Notes: you have to add type checks and things like that.
+I haven't tested this but it should be very close.
+
+Hope this helps. 
+
+
+
+Re: [Dillo-dev]Find text implementation problems
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-09 16:43
+
+On Mon, Oct 09, 2000 at 10:26:07AM +0900, Eric GAUDET wrote:
+> -- En reponse de "[Dillo-dev]Find text implementation problems" de Sam Dennis,
+> le 08-Oct-2000 :
+> > I've been looking at implementing the find text function and had got half
+> > way through mentally coding a solution (because of the DwPage{Line,Word})
+> > before I realised that all the callback has is the browser window, and I
+> > could see no way of getting at a DwPage from that, which is essential for
+> > searching.
+> > 
+> > Am I missing something obvious?
+> > 
+> 
+> You'll have to create a new external function in DwPage (a_Dwpage_findtext ?).
+> That way you can either register it as a callback, or call it yourself from
+> whatever other source (command.c ?).
+> 
+
+Even if I do that, I still need a pointer to a DwPage, and I see no way of
+getting it. There is also the issue of frames and (possibly) tables here, as
+both are separate pages, how do we know which to search even if we can get
+pointers to them?
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+RE: [Dillo-dev]Find text implementation problems
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-09 01:26
+
+-- En reponse de "[Dillo-dev]Find text implementation problems" de Sam Dennis,
+le 08-Oct-2000 :
+> I've been looking at implementing the find text function and had got half
+> way through mentally coding a solution (because of the DwPage{Line,Word})
+> before I realised that all the callback has is the browser window, and I
+> could see no way of getting at a DwPage from that, which is essential for
+> searching.
+> 
+> Am I missing something obvious?
+> 
+
+You'll have to create a new external function in DwPage (a_Dwpage_findtext ?).
+That way you can either register it as a callback, or call it yourself from
+whatever other source (command.c ?).
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 09-Oct-2000 a 10:23:31
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Find text implementation problems
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-08 22:41
+
+I've been looking at implementing the find text function and had got half
+way through mentally coding a solution (because of the DwPage{Line,Word})
+before I realised that all the callback has is the browser window, and I
+could see no way of getting at a DwPage from that, which is essential for
+searching.
+
+Am I missing something obvious?
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]RE: table/frames (was:What can I do?)
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-08 17:03
+
+--- Sebastian Geerken <S.Geerken@pi...> wrote:
+> DwPage doesn't bother about its parent widget
+> (either at toplevel, or in a DwTable, or, as inline
+> frame, in a DwPage?). It will just paint itself
+where
+> the parent wants it to do, and report size changes
+> (incremental rendering!) to its parent. (BTW: Vice
+> versa, DwTable will not bother about its children,
+it
+> only regards at them as DwWidget's.)
+
+This sounds like a VERY nice thing! I believe
+Incremental reflow is what the Mozilla people call
+this in Gecko, BTW. This should make Dillo better
+than Netscape 4.x was at table rendering! Incidently,
+Netscape's table rendering was VERY slow, inefficient,
+and memory-hogging. It sized things dynamically
+during multiple attempts, storing every attempt in
+memory. This meant (if I understand them correctly)
+that say, for tables of 10 columns by 10 rows, it
+would store 100 attempted and failed trials in memory
+before getting it right. Since Netscape never
+implemented incremental layout of page sections, the
+document state was split up and most of it used to
+simulate a cell as a nested HTML document. This
+allowed them to use the existing layout code to
+simulate the layout of that cell multiple times until
+the size was right. It was slow and wasteful of
+memory. To make matters worse, their attempts to
+optimize and streamline made the code difficult to
+read and never really solved the problem of less than
+optimal memory use and speed.
+
+For details, and mistakes to avoid that Netscape made,
+I find this document VERY interesting reading:
+
+http://www.mozilla.org/classic/layodesc.html
+
+> This is very nice in Gtk+: all widgets have a very
+> special purpose, a button is something where you can
+> click on, but how it looks is determined by *its
+> child*. You can even nest buttons, which is
+> admittedly quite silly, but who knows. (In early
+> versions of gnome, the panel menu entries had
+> submenus on the right side.) This results sometimes
+> in a horrible widget hierarchy, but is still
+> efficient enough, and much easier to extend than if
+> you have buttons with a label, buttons with a
+pixmap,
+> buttons with a pixmap and a label below the pixmap,
+> buttons with a pixmap and a label right of the
+pixmap
+> etc.
+
+Interesting. So does this mean that you could have
+say 3 distinct buttons inside each other, each
+performing different actions, like so:
+
+------------------------
+| Button 1 |
+| |
+| |---------| |------| |
+| |Button 2 | |Btn. 3| |
+| | | | | |
+| ----------- -------- |
+| |
+------------------------
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
+http://photos.yahoo.com/ 
+
+
+
+Re: [Dillo-dev]RE: table/frames (was:What can I do?)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-08 15:03
+
+Eric GAUDET wrote:
+> > As I say, I'll need to learn from the ground up on more basic
+> > things first, however. :-) But I do want to see what I can do.
+> >
+> 
+> What I did for that is choose easy bugs in the bug-track engine (or some of my
+> own ideas) and try to make a patch, as a skill training. You'll find most of
+> the code clean and easy to understand. Some areas are still obscure to me
+> (attrs ? cache ?). Even if the patches are rejected, this is still a great way
+> to learn before trying hardcore table/frame coding ;-).
+> May I suggest :
+> - PNG transparency (bug #60)
+> - GIF animations support
+> - form widget jumping with tab/shift+tab (bug #86)
+
+This depends heavily on the Dw structure (in both cases, either if you
+let Gtk+ (GtkWindow) do the work, or -- which I would prefer -- let it
+do by GtkDwViewport).
+
+> - X clipboard support (bug #59)
+> - adding "copy this link" to the popup menu
+> - adding "save this image" to the popup menu
+> - fix the status bar informations disapearing
+> - implement "find text"
+> - implement basic httpauth (see with Sean if he's not doing it already)
+> - implement SUP and SUB tags
+> - fix corrupted PNG segfault.
+
+Or:
+- When jumping to an #anchor in the same page, the url should be
+pushed on the navigation stack. See Nav_open_url and struct
+_BrowserWindow.
+- A menu of the last visited urls, like the one you get when you hold
+the "Back" button pressed for a while in Netscape, or click on the
+small button right on the "Back" button in MSIE.
+- Implement the <link> tag, and e.g. add an menu "Related pages" or
+so, with some accelerators, so the user must only press N for the next
+page etc. (I hope, some authors still use this tag.)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]RE: table/frames (was:What can I do?)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-08 15:03
+
+Eric GAUDET wrote:
+> I'm thinking of 3 reasons why table and frames are different.
+> [...]
+
+4) Tables are 2-dimensional, while frames are only aligned in one
+direction, i.e. you must nest framesets to get a grid of frames.
+
+5) The size of a table cell is (in most cases) calculated by the
+browser, the frame's size is determined by the web author.
+
+> [...]
+> Perhaps we can come with a common page structure (ex DwPage ?), that would have
+> the ability to be both a full html page (part of a frameset) or a table cell.
+
+DwPage doesn't bother about its parent widget (either at toplevel, or
+in a DwTable, or, as inline frame, in a DwPage?). It will just paint
+itself where the parent wants it to do, and report size changes
+(incremental rendering!) to its parent. (BTW: Vice versa, DwTable will
+not bother about its children, it only regards at them as DwWidget's.)
+This is very nice in Gtk+: all widgets have a very special purpose, a
+button is something where you can click on, but how it looks is
+determined by *its child*. You can even nest buttons, which is
+admittedly quite silly, but who knows. (In early versions of gnome,
+the panel menu entries had submenus on the right side.) This results
+sometimes in a horrible widget hierarchy, but is still efficient
+enough, and much easier to extend than if you have buttons with a
+label, buttons with a pixmap, buttons with a pixmap and a label below
+the pixmap, buttons with a pixmap and a label right of the pixmap etc.
+
+> I'm not sure this will be the best way : most table cells contain only an image
+> or a text paragraph. Building a whole html page for that will be a big waste
+> (think about those >1000k tables ;-).
+
+(gdb) print sizeof (DwPage)
+$1 = 184
+
+(I admit that it will take a bit more after initialization.)
+
+Memory is not the problem, but perhaps time, since size negotiation
+could happen to often. But currently it works very fast for normal
+pages, and so I think we should look how it will work for tables, and
+then eventually optimize it in detail.
+
+> I'd prefer to split the current DwPage in two widgets : one for the html
+> rendering only (say DwRenderedHtml) which would do what the current DwPage do
+> with lines, words ; one just like DwPage, but without what's done by
+> DwRender : only links, gc, attrs, anchors, ... This DwPage would of course
+> point to a DwRenderedHtml
+
+I'll bother about this, when Dw is complete. ;-)
+
+Sebastian 
+
+
+
+[Dillo-dev]Dillo News
+
+From: Allan Clark <shark@bl...> - 2000-10-08 14:36
+
+Hi all, the Dillo Weekly News is up and the url is
+http://www.shark.pwp.blueyonder.co.uk/news081000.html
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+[Dillo-dev]Minor view source change
+
+From: Sam Dennis <sdennis101@ge...> - 2000-10-08 13:27
+
+Attachments: viewsource.diff      
+
+View source shouldn't get the url from the location widget as that isn't
+necessarily the url of the page that is shown.
+
+-- 
+Sam Dennis <sdennis101@ge...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]RE: table/frames (was:What can I do?)
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-08 06:52
+
+-- En reponse de "Re: [Dillo-dev]RE: table/frames (was:What can I do?)" de
+Daniel Roberts, le 08-Oct-2000 :
+>> To make frames look like this, you'll have to do
+>> much more complicated things.
+> 
+> Ah, but what about inline frames?
+> 
+
+right, iframes are like a single table cell embeding a separate page (URL). No
+span tough. And you still can show the same structure as a complex table with
+it.
+It's kind of new too (HTML4 ?) : even my nestcape 4.72 can't render them.
+Anyway, all suggestions I heard about table/frames handling can quite easily be
+extended to iframe (once we've decided how to embed a page in a page).
+Not a big deal.
+
+> 
+> All in all, it looks to me like tables/frames are THE
+> next big thing to concentrate on in Dillo.
+
+Right again !
+
+> As I say, I'll need to learn from the ground up on more basic
+> things first, however. :-) But I do want to see what I can do.
+> 
+
+What I did for that is choose easy bugs in the bug-track engine (or some of my
+own ideas) and try to make a patch, as a skill training. You'll find most of
+the code clean and easy to understand. Some areas are still obscure to me
+(attrs ? cache ?). Even if the patches are rejected, this is still a great way
+to learn before trying hardcore table/frame coding ;-).
+May I suggest :
+- PNG transparency (bug #60)
+- GIF animations support
+- form widget jumping with tab/shift+tab (bug #86)
+- X clipboard support (bug #59)
+- adding "copy this link" to the popup menu
+- adding "save this image" to the popup menu
+- fix the status bar informations disapearing
+- implement "find text"
+- implement basic httpauth (see with Sean if he's not doing it already)
+- implement SUP and SUB tags
+- fix corrupted PNG segfault.
+
+As you can see, there's some big code planned (table/frames, IO engine,
+unified alignment), but there's also a lot of small things to do you can
+choose to improve both your skills and dillo :-)
+
+> BTW, I am also curious now about cross-platform
+> plans... Is the plan just to support Unices, or
+> others like BeOS, Mac, or Windows? I am thinking
+> since it is GTK+-based, Unices would be relatively
+> easy... Windows support could be added too, since
+> GTK+ supports Windows, but I can see a new
+> networking/IO layer being needed... Same for BeOS,
+> since GTK+ supports BeOS, too. Mac I would think
+> would be even harder though.
+> 
+
+AFAIR there was a big effort to make dillo compile under libc5, and I heard
+somebody tryied it on BSD with some success (a little less stable than on
+linux ?).
+I don't know about windos and beos, but I'm sure the folks here would welcome
+any volunteer.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 08-Oct-2000 a 15:02:53
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]RE: table/frames (was:What can I do?)
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-08 04:54
+
+--- Eric GAUDET <egaudet@in...> wrote:
+
+> I'm thinking of 3 reasons why table and frames are
+> different.
+
+These all do seem like valid reasons, too.
+
+> To make frames look like this, you'll have to do
+> much more complicated things.
+
+Ah, but what about inline frames?
+
+
+All in all, it looks to me like tables/frames are THE
+next big thing to concentrate on in Dillo. As I say,
+I'll need to learn from the ground up on more basic
+things first, however. :-) But I do want to see what
+I can do.
+
+BTW, I am also curious now about cross-platform
+plans... Is the plan just to support Unices, or
+others like BeOS, Mac, or Windows? I am thinking
+since it is GTK+-based, Unices would be relatively
+easy... Windows support could be added too, since
+GTK+ supports Windows, but I can see a new
+networking/IO layer being needed... Same for BeOS,
+since GTK+ supports BeOS, too. Mac I would think
+would be even harder though.
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
+http://photos.yahoo.com/ 
+
+
+
+[Dillo-dev]RE: table/frames (was:What can I do?)
+
+From: Eric GAUDET <egaudet@in...> - 2000-10-08 02:31
+
+-- En reponse de "RE: [Dillo-dev]What can I do?" de Allan Clark, le 07-Oct-2000
+:
+> <snip>
+>> How are tables that different? Netscape/Mozilla used
+>> to render tables as complete HTML documents within a
+>> larger one. After all, tables can also have images,
+>> text, and everything else a complete HTML document
+>> has.
+> That's the exact point that I made, I don't see how tables and frames are
+> really any different.
+
+I'm thinking of 3 reasons why table and frames are different.
+
+1) Table cell can span on several row or colomns, frames don't.
+Example :
+<table>
+<tr><td rowspan=2>a</td><td colspan=2>b</td></tr>
+<tr><td>c</td><td>d</td></tr>
+<tr><td>e</td><td>f</td><td>g</td>
+</table>
+should be rendered like :
++---+-------+
+| | b |
+| a +---+---+
+| | c | d |
++---+---+---+
+| e | f | g |
++---+---+---+
+To make frames look like this, you'll have to do much more complicated things.
+
+2) Frames can have sliders and be resized, tables don't.
+
+3) Table cells embedding an htlm page is only a convenient way of
+rendering tables, but there is no actual html page (eg: file) as such.
+Framesets _are_ separate html (or not) pages (in the cache) that have to be
+loaded.
+
+That's why frames are not a subset of tables, and tables are not a subset of
+frame.
+
+IMHO frames and table have a very different behavior, both the way they look
+and their underlying implementation. 
+Perhaps we can come with a common page structure (ex DwPage ?), that would have
+the ability to be both a full html page (part of a frameset) or a table cell.
+I'm not sure this will be the best way : most table cells contain only an image
+or a text paragraph. Building a whole html page for that will be a big waste
+(think about those >1000k tables ;-).
+
+I'd prefer to split the current DwPage in two widgets : one for the html
+rendering only (say DwRenderedHtml) which would do what the current DwPage do
+with lines, words ; one just like DwPage, but without what's done by
+DwRender : only links, gc, attrs, anchors, ... This DwPage would of course
+point to a DwRenderedHtml
+
+For frames, we use GtkContainers with DwPages.
+
+For tables, a new widget DwTable would contain the structure of the table and
+pointers to DwRenderedHtml widgets, one for each cell.
+DwTable would be a word widget, just like an image is now.
+
+... that's it ;-)
+
+(and we should wait for Sebastian's new Dw widgets)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 08-Oct-2000 a 11:00:26
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]What can I do?
+
+From: Allan Clark <shark@bl...> - 2000-10-07 21:24
+
+<snip>
+> How are tables that different? Netscape/Mozilla used
+> to render tables as complete HTML documents within a
+> larger one. After all, tables can also have images,
+> text, and everything else a complete HTML document
+> has.
+That's the exact point that I made, I don't see how tables and frames are
+really any different. 
+
+
+
+Re: [Dillo-dev]What can I do?
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-07 21:15
+
+--- Sebastian Geerken <S.Geerken@pi...> wrote:
+
+> Gzw was written (afaik) mainly because of the size
+> limitation for X windows (and so Gtk+ widgets),
+> otherwise pure Gtk+ widgets could be used. It can
+> embed Gtk+ widgets, but that does not work
+perfectly,
+> so there had been some discussion on eleminating Dw,
+> but that will make dealing with the size limitation
+> quite complicated. (This is my personal opinion.
+> Jorge did not decide yet, what will be used in
+> future, so I tried to implement and test my ideas.)
+
+Mozilla faced the same problem, both in the Motif and
+the GTK+ ports. They ended up using a GTKLayout
+widget instead of a GTKDrawingArea for the page layout
+area, IIRC. Problem with this however, was that they
+then had a constant battle to fight with the GTKLayout
+widget's want to do its own layout things... So they
+wrote this whole new library/widget (with the help of
+Owen Tayler of GTK+ fame) set called GTKSuperWin. 
+Could we perhaps use this, BTW?
+
+> Dw embeds Dw already now, e.g. bullets and images
+> are Dw widgets embedded in a DwPage. Embedding a
+> DwPage in a DwPage is also possible, and if they
+> share the same html document (as in tables), the
+html
+> parser has to be extended, e.g . by a stack. I did
+> already hack something like that which worked
+> halfway, it should not be too hard.
+
+Sounds good.
+
+> Tables and frames are quite different, the only
+> thing they have in common is, that they contain
+text,
+> so IMO the simplest way should be to write them as
+> containers for pages.
+
+How are tables that different? Netscape/Mozilla used
+to render tables as complete HTML documents within a
+larger one. After all, tables can also have images,
+text, and everything else a complete HTML document
+has.
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
+http://photos.yahoo.com/ 
+
+
+
+Re: [Dillo-dev]What can I do?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-07 12:01
+
+Daniel Roberts wrote:
+> Okay. Well, for starters, does the UI need anything?
+> I'd like to experiment with GTK+ a bit if I can... I
+> am trying to learn GTK+, so if anyone can give some
+> pointers on using it (other than the tutorial, which I
+> am already actively reading), I would appreciate it.
+> Translation: I might need to ask lots of questions, if
+> nobody minds. (Boy I wish a class were taught on GTK+
+> somewhere.)
+
+There is also a reference and some mailing lists at http://www.gtk.org. A
+good "tutorial" for using Gtk+ are the sources of Gimp, a good way of
+learning how to write new widgets is reading the sources of Gtk+
+itself.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]What can I do?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-07 12:01
+
+Hi,
+
+Daniel Roberts wrote:
+> It is also interesting that dw (formerly gzw, I
+> assume) is being re-writeen from scratch. Seems like
+> this is rather what Mozilla did with Gecko.
+
+Dw is not completely rewritten, since the other widgets (mainly
+DwPage) will ported to the new Dw.
+
+Gzw was written (afaik) mainly because of the size limitation for X
+windows (and so Gtk+ widgets), otherwise pure Gtk+ widgets could be
+used. It can embed Gtk+ widgets, but that does not work perfectly, so
+there had been some discussion on eleminating Dw, but that will make
+dealing with the size limitation quite complicated. (This is my
+personal opinion. Jorge did not decide yet, what will be used in
+future, so I tried to implement and test my ideas.)
+
+> As to tables/frames, how is it going to be done? I
+> recall some discussions with Armadillo about possibly
+> doing it by embedding dw within dw. Tables are
+> admittedly a little bit different from frames, but I
+> do think they are almost like flip sides of the same
+> coin.
+
+Dw embeds Dw already now, e.g. bullets and images are Dw widgets
+embedded in a DwPage. Embedding a DwPage in a DwPage is also possible,
+and if they share the same html document (as in tables), the html
+parser has to be extended, e.g . by a stack. I did already hack
+something like that which worked halfway, it should not be too hard.
+
+Tables and frames are quite different, the only thing they have in
+common is, that they contain text, so IMO the simplest way should be
+to write them as containers for pages.
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]What can I do?
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-06 19:44
+
+--- Allan Clark <shark@bl...> wrote:
+
+> Glad to hear from you, the above is kind of the
+> implementation I had in mind for tables and frames,
+> my suggestion is that we should have a page being
+> either a list of horizontal subpages, a list of
+> vertical subpages or a page as they are just now
+> implemented with lines, and then each "leaf" page
+can
+> take care of drawing (alignment etc) by itself and
+> all the parent pages need to do is tell all their
+> children to re-draw, re-size etc.
+
+Interesting. But where I can see this getting tricky
+is things like tables nested within tables, or with
+things like inline frames (not to mention re-sizable
+frames). How will this scheme handle those things? 
+For huge tables (like >1000k), won't it get a little
+slow? Yes, there ARE tables >1000k. Mozilla had a
+bug filed on such tables being slow to render. :-)
+
+> As for what you can do, well pick something you
+> think dillo needs and just do it (I hope I won't get
+> into trouble for nicking nike's slogan) I think
+> the main thing is to get Sebastians port of dw
+> working correctly, so if you can help with that it
+> would be great but it is your time so do whatever
+you
+> enjoy the most.
+
+Okay. Well, for starters, does the UI need anything? 
+I'd like to experiment with GTK+ a bit if I can... I
+am trying to learn GTK+, so if anyone can give some
+pointers on using it (other than the tutorial, which I
+am already actively reading), I would appreciate it. 
+Translation: I might need to ask lots of questions, if
+nobody minds. (Boy I wish a class were taught on GTK+
+somewhere.)
+
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
+http://photos.yahoo.com/ 
+
+
+
+RE: [Dillo-dev]What can I do?
+
+From: Allan Clark <shark@bl...> - 2000-10-06 15:42
+
+> Hello all!
+<snip>
+
+> As to tables/frames, how is it going to be done? I
+> recall some discussions with Armadillo about possibly
+> doing it by embedding dw within dw. Tables are
+> admittedly a little bit different from frames, but I
+> do think they are almost like flip sides of the same
+> coin.
+>
+
+Glad to hear from you, the above is kind of the implementation I had in mind
+for tables and frames, my suggestion is that we should have a page being
+either a list of horizontal subpages, a list of vertical subpages or a page
+as they are just now implemented with lines, and then each "leaf" page can
+take care of drawing (alignment etc) by itself and all the parent pages need
+to do is tell all their children to re-draw, re-size etc.
+As for what you can do, well pick something you think dillo needs and just
+do it (I hope I won't get into trouble for nicking nike's slogan) I think
+the main thing is to get Sebastians port of dw working correctly, so if you
+can help with that it would be great but it is your time so do whatever you
+enjoy the most.
+
+Note to Sebastian: would you like me to put up the sources of your dw on the
+web page I'm using to do the dillo news, that way you wouldn't have to mail
+it to everyone who asks? I can also update it pretty much when needed. 
+
+
+
+[Dillo-dev]What can I do?
+
+From: Daniel Roberts <zuperdee@ya...> - 2000-10-06 15:26
+
+Hello all!
+
+I am checking this out because Christopher Reid Palmer
+has effectively admitted that Dillo will probably
+become the real successor to Armadillo, and that
+Armadillo is effectively dead, since he hasn't enough
+time to dedicate to it.
+
+Dillo, IMHO, has definitely already surpassed both of
+its predecessors (Gzilla and Armadillo) in almost
+every aspect. I am hoping it is well on its way to
+competing with the likes of KDE's Konquerer, or maybe
+even Mozilla. Lord knows I worked on Mozilla for
+quite a while (and still use it for everyday browsing,
+cause there ain't any real alternative for GNOME folks
+like me), but I still find Mozilla to be painfully
+bloated, inefficient, slow, and memory-hogging, even
+after their wonderful ground-up re-write based on
+Gecko. Bottom line is, I have come to the same
+conclusion that JWZ did--that is, all the open source
+in the world cannot save Mozilla at this point. 
+Mozilla is pretty much hopeless.
+
+I think Mozilla's biggest problem was XUL. After
+having seen what a cross-platform front-end interface
+like Mozilla's XUL could be like, I am now convinced
+that a native GTK+ interface would definitely be the
+way to go. XUL is too bloated and far to slow for my
+tastes.
+
+Anyway, I am happy to see some progress being made on
+Dillo, and what's more, in the areas that really need
+it the most, like Networking, I/O, and implementing
+tables/frames.
+
+It is also interesting that dw (formerly gzw, I
+assume) is being re-writeen from scratch. Seems like
+this is rather what Mozilla did with Gecko.
+
+As to tables/frames, how is it going to be done? I
+recall some discussions with Armadillo about possibly
+doing it by embedding dw within dw. Tables are
+admittedly a little bit different from frames, but I
+do think they are almost like flip sides of the same
+coin.
+
+Anyway, I unfortunately don't know too much about
+Dillo internals, C/C++, or GTK+. So would somebody
+like to point me to something I can do to help with
+Dillo? I'd like to help if I can.
+
+=====
+Is your JavaScript ready for Nav5 and IE5?
+Get the latest JavaScript client sniffer at
+http://developer.netscape.com/docs/examples/javascript/browser_type.html
+
+Sincerely,
+Daniel
+e-mail: zuperdee@pe...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
+http://photos.yahoo.com/ 
+
+
+
+[Dillo-dev]New Dw
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-06 13:53
+
+Hi!
+
+I've been working on a new Dw, mainly written from scratch. I've given
+up the idea of making all elements GtkWidget's, since any attempt to
+work around the window size limit would be far to complicated, but
+designed and begun to implement a new Dw, which mainly follows the
+goal to be more similar to Gtk, because (i) the design of Gtk+ is
+quite nice and proven to be usable, (ii) that will make embedding Gtk
+widgets simpler, and (iii) it will be simpler to understand for
+someone who knows Gtk.
+
+It's mainly a simple copy of the Gtk structures: there is a DwWidget
+(sorry for the doubled "widget"), derived from GtkObject and with
+similar methods as GtkWidget, a DwContainer, and structures like
+DwRectangle, DwAllocation etc. with 32 bit sizes. Furthermore there is
+a Gtk+ widget GtkDwViewport, which embeds a DwWidget (more directly
+than the old GtkDwView), and is, from the view of Gtk+, parent of all
+Gtk+ widgets that are embedded in the DwWidgets. DwContainers will
+simply have to report all their children (DwWidget's as well as
+GtkWidget's), and GtkDwViewport will recursively sort out the
+GtkWidget's (by the GTK_IS_WIDGET macro), so implementing a
+DwContainer is not more complicated than implementing a GtkContainer.
+
+Currently, there are still many bugs, especially severe expose
+problems for embedded Gtk+ widgets, and DwWidget is still quite
+incomplete. After fixing the most severe bugs, I'll try to integrate
+the new Dw (which currently runs in a testbed) into dillo soon, trying
+to complete it in dillo itself. There is already a halfway working
+DwPage (a port of my Gtk+ port of the old DwPage, to the new Dw).
+
+I'll send the sources to anyone who is interested, and I would be glad
+about help from someone else who knows Gtk+ good.
+
+Sebastian 
+
+
+
+[Dillo-dev]remote url access
+
+From: Sean MacLennan <seanm@ne...> - 2000-10-02 15:49
+
+Attachments: out      
+
+Hi,
+
+I am try to add Mosaic style remote access to dillo. From a unix signal
+handler I want to push an url. The command a_Nav_push works *once*, then
+fails from then on. I have a patch below that shows a very simple
+example of this, plus an attempt to set the text in the location widget.
+I can set the text correctly, but I do not know how to then signal gtk
+to process the line.
+
+Any help at all would be appreciated,
+
+Sean 
+
+
+
+[Dillo-dev]Dillo Weekly News
+
+From: Allan Clark <shark@bl...> - 2000-10-02 00:17
+
+The latest weekly news has been posted, a little light on content this week
+due to the lack of activity on the list and the fact that the first one was
+a little late and hence this week's only has two days worth of news.
+The url is
+http://www.shark.pwp.blueyonder.co.uk/news021000.html
+Allan Clark
+allan@al...
+shark@bl... 
+
+
diff --git a/old/oldmail/200011.txt b/old/oldmail/200011.txt
new file mode 100644
index 0000000..d52880e
--- /dev/null
+++ b/old/oldmail/200011.txt
@@ -0,0 +1,2106 @@
+RE: [Dillo-dev]Re: About bug #60 (transparency in PNG's) 
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-29 10:46
+
+-- En reponse de "[Dillo-dev]Re: About bug #60 (transparency in PNG's)"
+de Livio Baldini Soares, le 29-Nov-2000 :
+> Does anybody know a better/faster solution to turn an guint32 into
+> to three int's representing red, green and blue parts of the color?
+> The solution I've implemented doesn't look too good :-(
+> Tomorrow, after getting some sleep I'll look up my algebra and see if
+> I can do some decent bit manipulation instead of calling strtol(). If
+> anyone has any ideas please send them in.
+> 
+
+IMHO there's several problem with your calculations :
+
+1) the strol part is very inefficient, but that's not a real problem
+because this code is _outside_ the loop. Anyway, here's how to do it :
+(strip all the sprintf)
+bg_blue = (prefs.bg_color0 & 0xFF;
+bg_green = (prefs.bg_color>>8) & 0xFF;
+bg_red = (prefs.bg_color>>16) & 0xFF;
+
+2) The loop is _always_ the sensible part ! You _never_ want to allocate
+local variables like you did : 
+for (...) { 
+gint p,a; 
+(some compiler may optimize this, but you never know)
+As a rule of thumb, it's better to allocate local variables at the
+begining of a function.
+
+3) If you really want to improve speed, do all calculation only once in
+local variables : i*3 is computed three times, it would be better to
+have calculated i3 = i*3 and use i3. (same with i*4 used twice).
+You could also have done i3 += 3 each loop, but on pentium-generation
+cpu (whatever the brand, ppc, arm, ...) multiplications and additions
+cost the same so it doesn't matter, and using i*3 is often more
+readable and more robust (not sensible to initiallisation).
+
+4) Even better : look into a table is a calculation. png->linebuf[3*i]
+is actually *(png + linebuf + 3*i).
+You could have declared 
+guchar *pl = png->linebuf;
+and in the loop :
+if (!a){
+*(pl++) = bg_red;
+*(pl++) = bg_green;
+*(pl++) = bg_blue;
+}
+
+The else part is basically the same, if a little more trickier, and you
+can get rid of the costy for() : I let it to you as an exercise ;-)
+(hint : row_num*png->rowbytes is ugly)
+
+5) Last : if(!a) is more complex than if(a) : invert the if/else.
+
+Hope this helps.
+
+So long Livio :-)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 29-Nov-2000 a 19:19:52
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Re: About bug #60 (transparency in PNG's) (sending patch)
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-29 03:36
+
+Attachments: png_transparent.diff      
+
+Sebastian Geerken writes:
+> Livio Baldini Soares writes:
+> > Hi all,
+> > 
+> > I've been looking into the PNG transparency bug (#60). 
+<snip> 
+
+Ok, so I got a working patch that gets the user preference bg_color
+and sets that as transparent. Since it might take a while before
+`a_Dw_widget_get_bg_color` or mask clipping gets done, this might be a
+good thing to put it for now. The only thing is that this patch didn't
+turn out as good as I'd like it to be...
+
+Does anybody know a better/faster solution to turn an guint32 into
+to three int's representing red, green and blue parts of the color?
+The solution I've implemented doesn't look too good :-(
+Tomorrow, after getting some sleep I'll look up my algebra and see if
+I can do some decent bit manipulation instead of calling strtol(). If
+anyone has any ideas please send them in.
+
+I'm sending the patch as an attachment and should be applyied
+against src/png.c from CVS.
+
+
+bye all, best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Still some problems with the bugtrack engine
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-29 01:37
+
+-- En reponse de "Re: [Dillo-dev]Still some problems with the bugtrack
+engine" de Livio Baldini Soares, le 28-Nov-2000 :
+> Hi Eric, how you doing?
+> 
+
+Hi Livio, nice to see you again in the list (I was afraid you left ;-)
+
+> Eric GAUDET writes:
+>> I have Internal Server errors every time I try.
+>> 
+> 
+> I added the bug for you. It's bug number *102*, check out the
+> bug-track. I think that the problem appears when you leave out one of
+> the fields in blank. I was getting an Internal Error too, but had
+> left
+> in blank the HTReproduce. When I filled it in with `Nothing`, the bug
+> was submitted.
+> 
+
+Hmmm... I just tried it and I think you're right.
+
+Thanks
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 29-Nov-2000 a 10:34:35
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]About bug #60 (transparency in PNG's)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-28 22:11
+
+Livio Baldini Soares writes:
+> Hi all,
+> 
+> I've been looking into the PNG transparency bug (#60). After an
+> hour of searches along src/png.c and libpng-dev thinking that it was
+> an initilization issue I found out it had nothing to do with
+> that. Later I found out that the problem was in
+> `Png_datarow_callback`, in the `case 4:` the alpha channel wasn't
+> being activated (there was even a `todo`, which I missed!). I've made
+> a sketch that works, but I've come to a problem:
+> 
+> Where do I find the current window (page) background color?
+
+Better: the background color of the parent of the image widget. This 
+will be different from the page background color, when tables are 
+implemented.
+
+> I guess
+> this is the same problem with GIF transparency. When you have a
+> transparent GIF and open it with the standard dillorc file, it'll look
+> alright, but if you change the bg_color in your dillorc then the GIF
+> will have in the transparent pixels NOT your background color, but the
+> color for the standard bg_color that was in the original dillorc...
+> 
+> So I guess that's a problem with GIF's and PNG's. Sebastian, is this
+> bg_color integrated to the new Dw your making up? Should I wait for it
+> to sent in the patch for PNG transparency, or should I make it
+> already? (Actually, it's already done and working, but I didn't want
+> to sent it in with this background color issue).
+
+I haven't done much on colors yet, currently there is only a function 
+a_Dw_widget_set_bg_color (which does nothing, but will soon work for 
+top-level widgets), and there will probably (when needed) a function 
+a_Dw_widget_get_bg_color (I'd prefer a function instead of a direct 
+access on structure members). Meanwhile, you may use dummy function 
+with that name (returning DW_PAINT_DEFAULT_BGND or so).
+
+However, I already suggested to Jorge to use clipping masks instead 
+of the parent's background color, since the latter would cause 
+problems with background images (this could be solved, but only 
+complicated and slow). Real alpha (more than 1 bit depth), as 
+supported by pgn (afaik) is not supported by X, but may be 
+implemented by dithered clipping masks (will look a bit ugly, but I 
+did never see a png in a web page which uses this feature).
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Still some problems with the bugtrack engine
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-28 21:10
+
+Hi Eric, how you doing?
+
+Eric GAUDET writes:
+> I have Internal Server errors every time I try.
+> 
+> I wanted to make this entry :
+> - There's no "Copy Link Location" being worked by "egaudet@fr...
+> 100%"
+> 
+> :-/
+
+I added the bug for you. It's bug number *102*, check out the
+bug-track. I think that the problem appears when you leave out one of
+the fields in blank. I was getting an Internal Error too, but had left
+in blank the HTReproduce. When I filled it in with `Nothing`, the bug
+was submitted.
+
+Jorge are you the one who take cares of the dillo's bug-track CGI's?
+Could it be that in Dillo_insert.cgi a blank field could cause an
+error? Maybe it should be tuned for errors and such, and give a
+warning like: "X field left in blank, please fill it in..."... Just a
+guess. 
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Still some problems with the bugtrack engine
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-28 16:40
+
+I have Internal Server errors every time I try.
+
+I wanted to make this entry :
+- There's no "Copy Link Location" being worked by "egaudet@fr...
+100%"
+
+:-/
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 29-Nov-2000 a 01:38:01
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]About bug #60 (transparency in PNG's)
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-28 15:59
+
+Hi all,
+
+I've been looking into the PNG transparency bug (#60). After an
+hour of searches along src/png.c and libpng-dev thinking that it was
+an initilization issue I found out it had nothing to do with
+that. Later I found out that the problem was in
+`Png_datarow_callback`, in the `case 4:` the alpha channel wasn't
+being activated (there was even a `todo`, which I missed!). I've made
+a sketch that works, but I've come to a problem:
+
+Where do I find the current window (page) background color? I guess
+this is the same problem with GIF transparency. When you have a
+transparent GIF and open it with the standard dillorc file, it'll look
+alright, but if you change the bg_color in your dillorc then the GIF
+will have in the transparent pixels NOT your background color, but the
+color for the standard bg_color that was in the original dillorc...
+
+So I guess that's a problem with GIF's and PNG's. Sebastian, is this
+bg_color integrated to the new Dw your making up? Should I wait for it
+to sent in the patch for PNG transparency, or should I make it
+already? (Actually, it's already done and working, but I didn't want
+to sent it in with this background color issue).
+
+best regards to all, 
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-28 13:34
+
+Hi again,
+
+
+I forgot something important, read below.
+
+Livio Baldini Soares writes:
+> Hi again,
+> 
+> think I fixed bug 100 already, read below.
+> 
+> Livio Baldini Soares writes:
+> <snip>
+> > 
+> > > - There's a small bug within a_Url_squeeze. When there're too
+> > > much "/.." sequences in the URL, it removes the server!
+> <snip>
+> 
+> I got to it, and I think I fixed it ok. I thought the original code
+> kind of confusing, but I've done little changes (3 lines). Basically
+> here is my diff (against src/IO/Url.c from CVS, but I think 0.3.0 will
+> be ok too since this hasn't changed, I think):
+
+<snip>
+
+The a_Url_squeeze seems to work fine, but that never gets called for
+user typed URL's. Im my opinion this is wrong, so I have another patch
+which changes a_Nav_push to change the user specified URL to the
+squeezed one. Then you'll be able to see how the a_Url_squeeze changes
+the URL (using the previous patch I sent). Here is the patch against
+src/nav.c, I changed only the a_Nav_push funtion:
+
+*****************************************************
+--- dillo/src/nav.c Mon Nov 13 10:01:55 2000
++++ dillo.new/src/nav.c Tue Nov 28 10:38:20 2000
+@@ -203,20 +203,22 @@ void a_Nav_remove_top_url(BrowserWindow 
+*/
+void a_Nav_push(BrowserWindow *bw, const char *Url)
+{
+- char *p, *url;
++ char *p, *url, *sUrl;
+
+g_return_if_fail (bw != NULL);
+
+- url = g_strdup(Url);
++ sUrl = a_Url_squeeze(g_strdup(Url)); /* get the squeezed Url */
++ url = g_strdup(sUrl);
+if ( (p = strstr(url, "?!POST")) != NULL )
+*p = '\0';
+
+a_Nav_cancel_expect(bw);
+- bw->nav_expect.url = g_strdup(url);
++ bw->nav_expect.url = g_strdup(sUrl);
+bw->nav_expect.title = NULL;
+bw->nav_expecting = TRUE;
+- Nav_open_url(bw, Url, FALSE);
++ Nav_open_url(bw, sUrl, FALSE);
+g_free(url);
++ g_free(sUrl);
+}
+
+/* 
+****************************************
+
+
+that's all, bye,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-28 11:13
+
+Hi again,
+
+think I fixed bug 100 already, read below.
+
+Livio Baldini Soares writes:
+<snip>
+> 
+> > - There's a small bug within a_Url_squeeze. When there're too
+> > much "/.." sequences in the URL, it removes the server!
+<snip>
+
+I got to it, and I think I fixed it ok. I thought the original code
+kind of confusing, but I've done little changes (3 lines). Basically
+here is my diff (against src/IO/Url.c from CVS, but I think 0.3.0 will
+be ok too since this hasn't changed, I think):
+
+************************************************************
+diff -pru dillo/src/IO/Url.c dillo.new/src/IO/Url.c
+--- dillo/src/IO/Url.c Sat Nov 11 01:54:45 2000
++++ dillo.new/src/IO/Url.c Mon Nov 27 23:43:33 2000
+@@ -252,7 +252,10 @@ char *a_Url_squeeze(char *str)
+str[ni++] = s[i];
+if ( nc && ni )
+--ni;
++ nc = ni;
+while ( ni && str[--ni] != '/');
++ if (!ni || (!strncmp(str, ") && ni == 6))
++ ni = nc+1; /* if we couldn't find a parent direcory, restore value */
+s = p = p + 3;
+} else if ( p[2] == '/' || !p[2] ) { /* "/./" or "/." */
+nc = p - s;
+@@ -264,6 +267,8 @@ char *a_Url_squeeze(char *str)
+p += 2;
+}
+}
++
++ if (ni && str[ni-1] == '/') ni--;
+/* Append the rest of 'str' */
+if ( ni == 0 && !*s ) str[ni++] = '/';
+while ( (str[ni++] = *s++) );
+*****************************************************
+
+What I do is when trying to look for a parent directory, prevent it
+from eating up the hostname. That is done in the `if` I inserted. If
+the variable `ni` got back to the beginning of the hostname (==0) or
+found a '/' expect it's the one from " then restore it's
+value... Umm, guess I'm not very good at explaining this.. is any body
+understanding what the hell am I saying? If anybody wants me to
+explain this again, just ask, I won't complain!
+
+I'll change the status to 100% in the bug-track when I get back net
+connection. Oh, and I'm NOT suppossed to put `done`, this is done by
+Jorge when he inserts the patch in the code (IF we agree the code is
+worth putting in), is this correct Jorge?
+
+Another thing, there was a comment in the header of a_Url_squeeze
+made by Jorge, saying the he wasn't sure that it was necessary. Well I
+checked APACHE and it's NOT necessary to squeeze the URL. I sent in a
+request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`,
+and got the /index.html. Seems to work fine with both /../ and /./,
+but I'm not sure if this is true to all HTTP servers. The only time
+APACHE complains is when we send in a request for /FAQ/../../, APACHE
+claims this is a BAD REQUEST, but the new a_Url_squeeze prevents
+this. 
+
+that's enough for now!, any doubts or flames, don't hesitate to
+send,
+
+bye yall,
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Re:
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-28 08:48
+
+-- En reponse de "[Dillo-dev]Re:" de Jorge Arellano Cid, le 27-Nov-2000
+:
+>> A friend of mine as access to several sparc stations (both 32 and 64
+>> bits, under linux and solaris 8). I asked him to test Dillo.
+> 
+> Thanks.
+> Actually dillo works perfectly on a Sparc 32, but the Sparc 64
+> and Solaris architectures haven't been tested. I'll be expecting
+> that info.
+> 
+
+Dillo has been successfully tested under :
+- sparc 5 (32 bits) linux, glibc 2.1.3, gcc 2.95.3
+- sparc ultra 1 (64 bits kernel, 32 bits userspace) linux, glibc 2.1.3,
+gcc 2.95.3
+- sparc ultra 10 (64 bits) solaris 8, gcc 2.95.2
+
+No problem at all : just compile and run :-))))
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Nov-2000 a 17:44:57
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Re:
+
+From: Jörgen Viksell <vsksga@ho...> - 2000-11-28 07:12
+
+>GtkHSeparator doesn't seem to have all the features needed for painting
+>a HR tag with attributes : no line thickness (-> no SIZE attribute),
+>only 3d-rendering (-> no NOSHADE attribute).
+>Will it be a problem ?
+
+If the new Dw handles GTK widget as GTK does itself (resizing and stuff) 
+then it should only be the matter of writing a new function for
+widget->style->klass->draw_hline
+
+I did a quick experiment with that and there were no problems with those 
+attributes.
+I guess reality will prove me to be wrong though... ;-)
+
+// Jörgen Viksell
+_____________________________________________________________________________________
+Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com 
+
+
+
+RE: [Dillo-dev]Re:
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-28 02:22
+
+-- En reponse de "[Dillo-dev]Re:" de Sebastian Geerken, le 27-Nov-2000 :
+> Jorge Arellano Cid writes:
+> > Hrulers
+> > 
+> > I considered patches from Allan, Eric and some progress by
+> > Sebastian.
+> > 
+> > Hrulers will have to be reimplemented for the new Dw, and as
+> > both patches implemented a resize mechanism that's not the one
+> > that current-Dw uses, and because both showed several problems
+> > (incompletness or fails) I'd prefer to wait for the new Dw and
+> > try to construct the hruler based upon the good ideas that both
+> > patches showed.
+> 
+> Both patches will be obsolete, this is already working (very 
+> different) in the new Dw with embedded GtkHSeparator's (but for 
+> support of all attributes of <hr> there is still the need for a new 
+> DwHRuler).
+> 
+> Sebastian
+
+GtkHSeparator doesn't seem to have all the features needed for painting
+a HR tag with attributes : no line thickness (-> no SIZE attribute),
+only 3d-rendering (-> no NOSHADE attribute).
+Will it be a problem ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Nov-2000 a 11:17:54
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Re:
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-28 01:58
+
+-- En reponse de "[Dillo-dev]Re:" de Jorge Arellano Cid, le 27-Nov-2000
+:
+> Pagemarks: This must be moved to the rightmost-button menu and
+> set insensitive when there're no headings in the page.
+> 
+
+I'll do it soon.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Nov-2000 a 10:58:23
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Re:
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-27 23:34
+
+Jorge Arellano Cid writes:
+> Hrulers
+> 
+> I considered patches from Allan, Eric and some progress by
+> Sebastian.
+> 
+> Hrulers will have to be reimplemented for the new Dw, and as
+> both patches implemented a resize mechanism that's not the one
+> that current-Dw uses, and because both showed several problems
+> (incompletness or fails) I'd prefer to wait for the new Dw and
+> try to construct the hruler based upon the good ideas that both
+> patches showed.
+
+Both patches will be obsolete, this is already working (very 
+different) in the new Dw with embedded GtkHSeparator's (but for 
+support of all attributes of <hr> there is still the need for a new 
+DwHRuler).
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-27 18:33
+
+Livio Baldini Soares writes:
+
+<big snip>
+
+> I put in a patch for this, it's bug number is 100. I put in that I
+> was going to work on it.... but I guess I did something wrong and only
+> my name appeared, is it possible for me to change the `Being worked:`
+> field? If not, Jorge could you change it to livio@li..., I
+> think it's much more informative than just `Livio`.
+
+Nevermind, just changed it to show my e-mail, sorry about that...
+
+bye yall,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Livio Baldini Soares <livio@li...> - 2000-11-27 18:17
+
+Jorge Arellano Cid writes:
+> 
+> Hi there!
+> 
+
+Hi Jorge,
+
+I liked the new version (0.3.0) a lot. Nice work. By the way,
+if by any chance I get the chance to patch anything, then I should
+probably patch against CVS, right? Another thing, do you (or anybody
+else) have anything against sending patches to the list, so everyone
+can "pitch" in, and publically(?) discuss them. If not do you want me
+to CC: them to you, Jorge?
+
+> - There's a small bug within a_Url_squeeze. When there're too
+> much "/.." sequences in the URL, it removes the server!
+
+<snip>
+
+> 
+> Patches for these BUGs, and their bug-track-entries, would be
+> appreciated.
+> 
+
+I put in a patch for this, it's bug number is 100. I put in that I
+was going to work on it.... but I guess I did something wrong and only
+my name appeared, is it possible for me to change the `Being worked:`
+field? If not, Jorge could you change it to livio@li..., I
+think it's much more informative than just `Livio`.
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Re:
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-27 16:25
+
+Hi!
+
+
+The code with the Findtext and Pagemarks is in the CVS. The
+server reported no problems when uplading, so I hope its working
+(there were several BUG reports at sourceforge for this; Ah, and
+sourceforge's download counters had gone carzy too!!! Dillo shows
+a negative download rate the day with the highest peak of page
+visits!!! :-)
+
+Back to Findtext: this implementation is a basic one, there's
+still work to do. Most notably stripping of '\n\r\t' and spaces
+when adding to the Text buffer, feedback messages and finally a
+port to the new Dw when it's ready.
+
+Pagemarks: This must be moved to the rightmost-button menu and
+set insensitive when there're no headings in the page.
+
+-----
+Dillo in a 64bit machine:
+
+> Actually it does work on 64-bit systems. I currently run it on an Alpha
+> It isn't my main browser (yet), but it is slowly getting there. FYI I
+> also maintain the Debian dillo package.
+
+I'm very happy to know it works!!! (my efforts haven't been
+wasted!).
+
+In regard to the slow progress, I agree with you, and its
+mostly due to an effort to clean and implement design solutions
+in the code that serve as framework for future enhancement:
+networking has been rewritten, Dw is getting a new design and
+plugins are being developed to simplify several tasks. If we
+succeed with them, I hope we can see faster improvement in the
+future. bear with us and let's get there!
+
+> A friend of mine as access to several sparc stations (both 32 and 64
+> bits, under linux and solaris 8). I asked him to test Dillo.
+
+Thanks.
+Actually dillo works perfectly on a Sparc 32, but the Sparc 64
+and Solaris architectures haven't been tested. I'll be expecting
+that info.
+
+---
+Hrulers
+
+I considered patches from Allan, Eric and some progress by
+Sebastian.
+
+Hrulers will have to be reimplemented for the new Dw, and as
+both patches implemented a resize mechanism that's not the one
+that current-Dw uses, and because both showed several problems
+(incompletness or fails) I'd prefer to wait for the new Dw and
+try to construct the hruler based upon the good ideas that both
+patches showed.
+
+slangley:
+I saw your entry (BUG#62) and I'd prefer you to work it with
+the new Dw (just not to waste your efforts).
+
+---
+
+>> - There a small bug within a_Url_squeeze. When there're too
+>> much "/.." sequences in the URL, it removes the server!
+>
+> How-to reproduce it ... ?
+
+Try something like:
+
+http://some.site.org/../main.html or
+http://some.site.org/../main.html
+
+they should resolve to http://some.site.org/main.html
+
+---
+
+> I'm having the hardest time making bug-track-entries : 99% of the time
+> I'm getting :
+>
+> Internal Server Error ...
+
+I just made an entry from other network, for Find Text (BUG#99).
+If someone else has problems please tell me.
+
+
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Misc.
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-27 14:44
+
+-- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le
+25-Nov-2000 :
+> Patches for these BUGs, and their bug-track-entries, would be
+> appreciated.
+> 
+
+I'm having the hardest time making bug-track-entries : 99% of the time
+I'm getting :
+<<
+Internal Server Error
+
+The server encountered an internal error or misconfiguration and was
+unable to complete your request.
+
+Please contact the server administrator, root@localhost and inform
+them of the time the error occurred, and anything you
+might have done that may have caused the error.
+
+More information about this error may be available in the server error
+log.
+
+Apache/1.3.12 Server at huallepen.inf.utfsm.cl Port 80
+>>
+
+BTW: if comment and howto-reproduce lines are limited to 256 chars, it
+would be easier for everbody to ask for :
+ROWS=4 COLS=64
+instead of the stupid :
+ROWS=5 COLS=80
+('see what I mean ? ;-)
+
+... And since I'm talking about the bug-track engine, it would be nice
+to have a "Wish insertion page" : all unimplemented features are not
+"bugs", and I'm not sure I want to see "I'd like to have SSL", "I'd
+like a single download window" pollute the bug list. 
+I don't want them forgotten when we'll be looking for new features
+implementation and long term projects. 
+(would a poll be hard to implement, for most-wanted features ?)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 27-Nov-2000 a 23:18:12
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Misc.
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-27 01:36
+
+-- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le
+25-Nov-2000 :
+> - A "Copy link location" item (to allow pasting)
+
+I'm going to try that, but I can't promise anything.
+
+> - There's a small bug within a_Url_squeeze. When there're too
+> much "/.." sequences in the URL, it removes the server!
+
+How-to reproduce it ... ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 27-Nov-2000 a 10:35:44
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Ron Farrer <rbf@fa...> - 2000-11-26 16:30
+
+Attachments: Message as HTML      
+
+Eric GAUDET (egaudet@in...) wrote:
+
+> If you know some C, would you mind investigating and trying to fix
+> alpha-specific bug#89 and 90 ? (since you're the only alpha-guy around
+> ;-)
+
+Is there a way of contacting whoever submitted bug#89? I am unable to
+get dillo to segfault on lwn.net. Also, bug#90 is using a non-free
+compiler.. I can't help with that.
+
+Ron
+--=20
+Email: <mailto:rbf@fa...>, <mailto:rbf@de...>
+Home: <http://www.farrer.net/~rbf/>
+Alpha Linux Powered: <http://www.alphalinux.org> 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-26 12:30
+
+-- En reponse de "Re: [Dillo-dev]Misc." de Ron Farrer, le 26-Nov-2000 :
+> Actually it does work on 64-bit systems. I currently run it on an
+> Alpha
+> It isn't my main browser (yet), but it is slowly getting there. FYI I
+> also maintain the Debian dillo package. 
+> 
+
+If you know some C, would you mind investigating and trying to fix
+alpha-specific bug#89 and 90 ? (since you're the only alpha-guy around
+;-)
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Nov-2000 a 21:27:05
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev][ANN]Preferences plugin !
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-26 12:24
+
+Hi,
+I just published my Preferences Dillo-plugin at my now usual address
+(http://www.rti-zone.org/dillo/)
+Fully working : it writes dillorc ! (provided your dillo's patched for
+"dpi" ;-)
+With a screenshot !
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Nov-2000 a 21:19:18
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Ron Farrer <rbf@fa...> - 2000-11-26 05:24
+
+Attachments: Message as HTML      
+
+Eric GAUDET (egaudet@in...) wrote:
+
+> -- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le
+> 25-Nov-2000 :
+> > - Make Dillo work in a 64bit machine! (I worked on this a lot,
+> > but I no longer have access to the machine I was using).
+> >=20
+>=20
+> A friend of mine as access to several sparc stations (both 32 and 64
+> bits, under linux and solaris 8). I asked him to test Dillo.
+
+Actually it does work on 64-bit systems. I currently run it on an Alpha
+It isn't my main browser (yet), but it is slowly getting there. FYI I=20
+also maintain the Debian dillo package.=20
+
+Ron
+--=20
+Email: <mailto:rbf@fa...>, <mailto:rbf@de...>
+Home: <http://www.farrer.net/~rbf/>
+Debian on Alpha: <http://www.debian.org/ports/alpha> 
+
+
+
+[Dillo-dev]Tiny bug in FORM checkboxes
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-26 03:04
+
+Hi,
+There's a tiny bug in the CHECKBOX handling : if no VALUE attribute is
+specified, the checked-box value is an empty string ; the default value
+should be "on" so one can differentiate a checked box with an empty
+TEXT input.
+If it's not a bug, it's definitely annoying for POST parsing.
+
+Here's how to fix it : (dillo v0.3.0)
+in html.c : line 1645
+- init_str = "";
++ init_str = "on";
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Nov-2000 a 11:57:59
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Misc.
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-26 01:29
+
+-- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le
+25-Nov-2000 :
+> - Make Dillo work in a 64bit machine! (I worked on this a lot,
+> but I no longer have access to the machine I was using).
+> 
+
+A friend of mine as access to several sparc stations (both 32 and 64
+bits, under linux and solaris 8). I asked him to test Dillo.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Nov-2000 a 10:28:01
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Misc.
+
+From: Will Newton <will@mi...> - 2000-11-25 14:57
+
+On Sat, 25 Nov 2000, Jorge Arellano Cid wrote:
+
+> Although a bit outdated, there's a "project notes" link that
+> has some hints on this subject. If you want to work on it, let me
+> know, cause I'll have to tune the networking part in order to
+> make it functional.
+
+Have you considered using w3c libwww for networking? It's part of GNOME
+now and is available for most ditros.
+(It does HTTP/1.1, SSL and lots of other nice things) 
+
+
+
+[Dillo-dev]Misc.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-25 14:18
+
+Hi there!
+
+When reading the mailing-list, there were several topics so,
+here go my comments and answers:
+
+> If I hit a slow site, I get no visual clue that dillo is doing
+> anything. To see this first hand, go to bugs.debian.org, and look
+> up the package lintian. dillo seems to hang, then magically load
+> the page.
+
+The Stop button may suggest some activity, but that's certainly
+not enough...
+I thought that a small panel to the left of the progress bars
+can be a good solution. I mean a table like this:
+
+,--------------.
+| Dns | Send | [Image progress bar]
+| Retr | Close | [Text progress bar ]
+`--------------'
+
+Those words in the panel can be highlighted when the
+correspondent activities are taking place.
+
+
+> Robert investigated the problem (bug#97) a little more. It appears to
+> be a gcc 2.95.2 bug for K6 with -O2 option. I heard about that for
+> non-i386 cpu (SH4, ARM). It seems -O2 is not reliable for now, except
+> for intel processors.
+>
+> We should put a warning in the README about this.
+
+OK, that'll be in the README file of our next release.
+
+
+> * Downloads
+> Rather than having loads of dialogs like in Netscape, a single
+> window with a list of downloads and status would be cool (imagine
+> a more simple GetRight style window).
+
+Although a bit outdated, there's a "project notes" link that
+has some hints on this subject. If you want to work on it, let me
+know, cause I'll have to tune the networking part in order to
+make it functional.
+
+---
+
+Some patching suggestions:
+
+- A "Copy link location" item (to allow pasting)
+- There's a small bug within a_Url_squeeze. When there're too
+much "/.." sequences in the URL, it removes the server!
+- Make Dillo work in a 64bit machine! (I worked on this a lot,
+but I no longer have access to the machine I was using).
+
+Patches for these BUGs, and their bug-track-entries, would be
+appreciated.
+
+
+---
+
+Finally, when integrating the Find-text patch, I noticed that
+it only works for the first match, so I got into it and now I
+have a Find-text that does it. I'll send a note to the list when
+I upload the code to the CVS.
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Suggestions
+
+From: Will Newton <will@mi...> - 2000-11-24 15:50
+
+On Thu, 23 Nov 2000, Sean 'Shaleh' Perry wrote:
+
+> I have suggested this. Jorge is not 100% convinced. Plus dillo needs some
+> rework to handle css. html items have no storage of names. So you can't do
+> <div name="foo">.
+
+I'll write a CSS parser if you want (a quick search on google says the
+only C CSS parser is in Amaya... I advise any children watching to avert
+their eyes from that code...). 
+
+
+
+RE: [Dillo-dev]Suggestions
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-24 13:26
+
+-- En reponse de "[Dillo-dev]Suggestions" de Will Newton, le
+24-Nov-2000 :
+> 
+> Here are a few ideas/suggestions I have:
+> 
+> * Errors
+...
+> Also, an error log window would be cool (it could be global so all
+> browser windows could output to it). Then I can see why the image
+> didn't load or get more verbose error messages. You could use
+> simple printfs to the console for this, but I think this way is
+> better.
+> 
+
+Warnings an errors are reported to stderr, so you can read them on
+there term where you launched dillo.
+However, that's true dillo's status indications needs some work.
+
+> * Images
+> Is alpha handled properly on images? I have seen some black borders
+> round icons.
+> 
+
+See bug-track engine : transparency is supported for GIF images, but
+not for PNG.
+
+> * Downloads
+> Rather than having loads of dialogs like in Netscape, a single window
+> with a list of downloads and status would be cool (imagine a more
+> simple GetRight style window).
+> 
+
+There's no download at all for now : where're all thinking about it,
+but the feature and the actual implementation have yet to but discussed.
+Your suggestion seem to be what most people want, though. Netscape
+for macintosh does this.
+
+> * CSS
+> CSS can be used well like in Mozilla for preferences e.g. you store
+> default font/colors in a user.css file and these settings "cascade"
+> down.
+> 
+
+This have been discussed before, and rejected for now for two reasons :
+- CSS support seems very far to be implemented ;
+- CSS can't handle every option we want (page-rendering only).
+
+> There's also no "About" dialog. :)
+> 
+
+Right ! Why don't you make one, just to train your skills on Dillo ? :-)
+
+> Anyway, these are just a few ideas I have, although some of them
+> would obviously be in the future. I'm going to look at adding CSS
+> support as soon as I untangle the source code a little. :)
+> 
+
+You're welcome. Don't hesitate to ask any (stupid or not ;-) question
+to the list, but make sure you've read everything on dillo's homepage,
+documentation and mail list archive.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Nov-2000 a 22:13:29
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev][patch] Dillo-plugins final
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-24 12:12
+
+Hi all,
+I just released the final version of my patch for Dillo-plugins for you
+"I-want-the-last-patch" freaks, and also for those who want to give it
+a try and send me some comments or bug repports.
+
+Visit my dedicated web page, now permanent at :
+http://www.rti-zone.org/dillo/
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Nov-2000 a 21:09:42
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Suggestions
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-24 06:28
+
+> 
+> * CSS
+> CSS can be used well like in Mozilla for preferences e.g. you store
+> default font/colors in a user.css file and these settings "cascade" down.
+> 
+
+I have suggested this. Jorge is not 100% convinced. Plus dillo needs some
+rework to handle css. html items have no storage of names. So you can't do
+<div name="foo">. 
+
+
+
+[Dillo-dev]Suggestions
+
+From: Will Newton <will@mi...> - 2000-11-24 03:31
+
+Here are a few ideas/suggestions I have:
+
+* Errors
+Errors IMO should appear in the main window and not in any dialogs like in
+Nestcape. Dillo does this, I know, but I wanted to make sure it stays like
+that. :)
+Also, an error log window would be cool (it could be global so all browser
+windows could output to it). Then I can see why the image didn't load or
+get more verbose error messages. You could use simple printfs to the
+console for this, but I think this way is better.
+
+* Images
+Is alpha handled properly on images? I have seen some black borders round
+icons.
+
+* Downloads
+Rather than having loads of dialogs like in Netscape, a single window with
+a list of downloads and status would be cool (imagine a more simple
+GetRight style window).
+
+* CSS
+CSS can be used well like in Mozilla for preferences e.g. you store
+default font/colors in a user.css file and these settings "cascade" down.
+
+There's also no "About" dialog. :)
+
+Anyway, these are just a few ideas I have, although some of them would
+obviously be in the future. I'm going to look at adding CSS support as
+soon as I untangle the source code a little. :) 
+
+
+
+RE: [Dillo-dev]Status
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-24 03:17
+
+On 24-Nov-2000 Will Newton wrote:
+> 
+> I got the latest beta of Dillo (0.3.0) and it seems pretty fast, but no
+> tables means it can't render much. Is tables the next feature to be added?
+> CSS support would also be cool. I'm currently looking through the source
+> to see where I can help out.
+> 
+
+Once the new Dw widget appers, I will begin integrating my work on html.c. I
+have nearly all font affecting tags working. All that is left is tables and
+frames, and tags that do not directly affect rendering like abbr. If I recall,
+someone else is working on div.
+
+If you would like to make a css parser, that would be handy. CSS support will
+be a while, there are more pressing issues. 
+
+
+
+FW: RE: [Dillo-dev]dillo 0.3.0 crashes at startup
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-24 01:26
+
+Robert investigated the problem (bug#97) a little more. It appears to
+be a gcc 2.95.2 bug for K6 with -O2 option. I heard about that for
+non-i386 cpu (SH4, ARM). It seems -O2 is not reliable for now, except
+for intel processors.
+
+We should put a warning in the README about this.
+
+-------------------------- FW --------------------------------
+Program received signal SIGSEGV, Segmentation fault.
+Dw_border_size_nego_y (dw=0x8054290, allocation=0x80b0a18) at
+dw_border.c:64
+64 dw->allocation = *allocation;
+</snip>
+
+locals:
+dw = (Dw *) 0x8054290
+allocation = (DwRect *) 0x80b0a18
+
+> -O2 seems to pose problems in 2.95.2. Can you try -O or -O0 (O-zero)
+> with k6 ?
+
+"-O2 -mcpu=pentium" works fine.
+"-O0 -mcpu=k6 -march=pentium -g3" works fine also.
+"-O -mcpu=k6 -march=pentium -g3" works fine as well, but
+"-O2 -mcpu=k6 -march=pentium -g3" doesn't work. Then again
+"-O6 -mcpu=pentium -march=pentium -g3" DOES work.
+
+I think setting -cpu=k6, or ever worse, -march=k6 (had problems with
+this one before..) causes some type of code to be miscompiled in some
+cases when you use -O2. If -O2 fails at compile-time (for me) it starts
+to loop infinitly. In these cases only -O0 works, so 2.95.x is kinda
+buggy. I hope the 3.0 series will be better.
+
+> -g is always a good idea for debugging ;-)
+
+Yes, and you can always strip the binary when your'e done.
+By the way, "-W -Wall" is a LOT better at catching dirty code than just
+-Wall. Try it and see for yourself :).
+
+Put a note of this in some FAQ somewhere so that you can tell the next
+victim of this gcc bug to "read the friendly manual" :).
+
+Thanks, Robert.
+
+--------------End of forwarded message-------------------------
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Nov-2000 a 10:17:57
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Status
+
+From: Will Newton <will@mi...> - 2000-11-24 00:52
+
+I got the latest beta of Dillo (0.3.0) and it seems pretty fast, but no
+tables means it can't render much. Is tables the next feature to be added?
+CSS support would also be cool. I'm currently looking through the source
+to see where I can help out. 
+
+
+
+RE: [Dillo-dev]dillo 0.3.0 crashes at startup
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-23 01:21
+
+What version of dillo ?
+Can you send a stack dump after the crash ? 
+Are you on a i386 arch ? if so, can you send me your dillo binary ?
+
+PS: the list is very low traffic, if you register you won't be annoyed
+by more than 3 or 4 messages a week.
+
+-- En reponse de "[Dillo-dev]dillo 0.3.0 crashes at startup" de Robert
+Holmberg, le 22-Nov-2000 :
+> Ahh..CRAP! Just submitted bug #97 with too many characters and only
+> half the bug description was submitted.. here we go:
+> 
+> Dillo crashes on startup (gcc 2.95.2, glibc 2.1.2) after showing an
+> empty
+> window. It does show contents (menu, toolbar..) in the window if run
+> through gdb:
+> 
+> (gdb) run
+> Starting program: /usr/local/bin/dillo 
+> dillo_dns_init: Here we go!
+> Loading bookmarks...
+> [New Thread 3591 (manager thread)]
+> [New Thread 3590 (initial thread)]
+> [New Thread 3592]
+> 
+> Program received signal SIGSEGV, Segmentation fault.
+> 0x8061c00 in Dw_border_size_nego_y ()
+> 
+> Please CC questions to me, I'm not on the list.
+> 
+> Robert.
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Nov-2000 a 10:17:40
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Dillo 0.3.0 crash on starup.
+
+From: Robert Holmberg <robert.holmberg@he...> - 2000-11-22 21:22
+
+Hust submitted bug #97 w. more than 256 characters in description in the
+bugtarcker. Here's the whole deal:
+
+Dillo 0.3.0, gcc 2.95.2, glibc 2.1.2, linux 2.4-test11:
+
+(gdb) run
+Starting program: /usr/local/bin/dillo 
+dillo_dns_init: Here we go!
+Loading bookmarks...
+[New Thread 3621 (manager thread)]
+[New Thread 3620 (initial thread)]
+[New Thread 3622]
+
+Program received signal SIGSEGV, Segmentation fault.
+0x8061c00 in Dw_border_size_nego_y ()
+
+Dillo does draw it's window first.
+
+I'm NOT suscribed to the list.
+
+Robert. 
+
+
+
+[Dillo-dev]dillo 0.3.0 crashes at startup
+
+From: Robert Holmberg <robert.holmberg@he...> - 2000-11-22 21:17
+
+Ahh..CRAP! Just submitted bug #97 with too many characters and only half
+the bug description was submitted.. here we go:
+
+Dillo crashes on startup (gcc 2.95.2, glibc 2.1.2) after showing an empty
+window. It does show contents (menu, toolbar..) in the window if run
+through gdb:
+
+(gdb) run
+Starting program: /usr/local/bin/dillo 
+dillo_dns_init: Here we go!
+Loading bookmarks...
+[New Thread 3591 (manager thread)]
+[New Thread 3590 (initial thread)]
+[New Thread 3592]
+
+Program received signal SIGSEGV, Segmentation fault.
+0x8061c00 in Dw_border_size_nego_y ()
+
+Please CC questions to me, I'm not on the list.
+
+Robert. 
+
+
+
+[Dillo-dev]BUG#95
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-22 01:27
+
+Hi!
+
+
+I hope you're enjoying the 0.3.0 release!
+(I haven't received complaints)
+
+There're still several things to do, and I'll try them one by
+one...
+
+I'm still concerned with BUG#95, and followed an interesting
+thread at http://www.flora.org/lynx-dev/lynx-dev/9608/0278.html
+
+Even more, further research showed me that this issue is far
+from being easy to solve, but the "trend" seems to use what Fote
+suggested in the previous thread (0283.html).
+
+The page suggested in the bugtrack engine has changed to this
+standard, so now its browsable with dillo without any change! And
+I also remember that some time ago, sourceforge included
+directions for displaying their logo with an image URL that
+included a &amp; sequence, but not anymore!
+
+So it seems that things are getting straight in an attempt to
+keep CGI functionality working ('&' in that context is a reserved
+character to separate name=value pairs, and any use of it for
+other purpose should be hex escaped).
+
+
+Please send me any comments, specially if you can prove it
+MUST be handled in another way, otherwise I'll delete the entry
+within a few days.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Font issues
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-16 01:59
+
+Eric GAUDET wrote:
+> 
+> I've just upgraded Netscape to 4.75 (mandrake RPM) which _needs_ the
+> package mozilla-fonts. These fonts seem to be buggy : the
+> -helvetica-medium-italic- is a bitmap 18pts font looking bold, and it's
+> ugly when resized in 12 by Dillo for regular italic.
+> One way around is to change Dillo to use "oblique" instead of "italic":
+> 
+> in dw_page.c (v0.3.0)
+> in static GdkFont *Dw_page_realize_font(DwPageFont *font)
+> line 1115:
+> - font->italic ? "i" : "r",
+> + font->italic ? "o" : "r",
+
+And a few lines below:
+if (font->font == NULL && font->italic) {
+- /* Some italic fonts (e.g. Courier) use "o" instead of "i". */
+- sprintf(fontname, "-*-%s-%s-o-*-*-%d-*-75-75-*-*-*-*",
++ /* Some italic fonts (e.g. Courier) use "i" instead of "o". */
++ sprintf(fontname, "-*-%s-%s-i-*-*-%d-*-75-75-*-*-*-*",
+font->name,
+font->bold ? "bold" : "medium",
+font->size);
+font->font = gdk_font_load(fontname);
+}
+
+> That looks like an extreme solution to change Dillo when a font is
+> buggy, but it works. (BTW, my adode and urw helvetica don't have italic
+> face, only oblique : X must be switching to oblique when italic's not
+> found ; does any distri have helvetica-oblique ?)
+
+It's dillo, which switches to oblique.
+
+> A better way would be to make that an option in dillorc.
+> Perhaps Sean has something better with his fonts handling (or a better
+> ideas) ?
+
+Oblique and italics are two different variants, actually you get an
+oblique variant by shearing a font, but an italic variant is a totally
+new font. Helvetica Italics is quite unusual, as well as e.g. Times
+Oblique. On my system, only Adobe Courier provides both variants.
+
+However, HTML does not distinguish between these variants, but CSS
+does. Personally I prefer oblique variants, since they are more
+readable at low resolutions. A option letting the user decide which
+variant dillo should prefer, when both are available, would imho be a
+good possibility.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]where did view source go?
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-15 09:20
+
+-- En reponse de "Re: [Dillo-dev]where did view source go?" de
+Sebastian Geerken, le 14-Nov-2000 :
+>> aaarrggghhh, where did view source go? how can I tell why dillo
+>> chose to
+>> render a web page like it did if I can not see the html?
+> 
+> Yes, somehow a complete menu got lost ... commented in
+> a_Menu_mainbar_new.
+
+It's in the popup menu now.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Nov-2000 a 18:19:45
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]where did view source go?
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-15 07:13
+
+> 
+> BTW, never wondered about the term "View Source"? Actually, there
+> *aren't* sources for html documents (except pl, php, asp ...), the
+> menu entry should be named "View As Plain Text".
+>
+
+"source" as an abstraction. It may be cgi generated, static, etc. Perhaps
+"View Markup"? 
+
+
+
+Re: [Dillo-dev]where did view source go?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-14 20:49
+
+Sean 'Shaleh' Perry wrote:
+> 
+> aaarrggghhh, where did view source go? how can I tell why dillo chose to
+> render a web page like it did if I can not see the html?
+
+Yes, somehow a complete menu got lost ... commented in
+a_Menu_mainbar_new.
+
+BTW, never wondered about the term "View Source"? Actually, there
+*aren't* sources for html documents (except pl, php, asp ...), the
+menu entry should be named "View As Plain Text".
+
+Sebastian 
+
+
+
+[Dillo-dev]Bug#95 : not a bug !
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-14 13:07
+
+I just parsed the bugtrack engine, and bug#95 puzzled me : I never
+heard of entities in URLs before, even in the RFC. The only official
+escape mecanism for URLs is %XX where X is hexadecimal ;
+non escaped characters are UTF-8 (which is very close to ISO8859-1 ?).
+HTML4 specs has a note about that : some old browsers accept this
+undocumented URL parsing, and some bad pages rely on that. 
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 14-Nov-2000 a 21:55:49
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]where did view source go?
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-14 12:15
+
+-- En reponse de "[Dillo-dev]where did view source go?" de Sean
+'Shaleh' Perry, le 14-Nov-2000 :
+> aaarrggghhh, where did view source go? how can I tell why dillo
+> chose to render a web page like it did if I can not see the html?
+
+Would somebody be see a problem make view source a Dillo-plugin ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 14-Nov-2000 a 20:21:20
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]where did view source go?
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-14 08:13
+
+aaarrggghhh, where did view source go? how can I tell why dillo chose to
+render a web page like it did if I can not see the html? 
+
+
+
+[Dillo-dev]dillo does not give enough user feedback
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-14 08:07
+
+If I hit a slow site, I get no visual clue that dillo is doing anything. To
+see this first hand, go to bugs.debian.org, and look up the package lintian. 
+dillo seems to hang, then magically load the page. 
+
+
+
+Re: [Dillo-dev]New 0.3.0 release
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-14 07:42
+
+> I downloaded it a few hours ago, and patched the changes into my
+> version (a bit "handwork" was necessary). I already tested
+> third-button-menus and some new tags implemented by Jörgen (<u>,
+> <strike> and <s>), and that seems to work.
+> 
+
+awesome, those were the last three tags. I thing once my changes are merged
+into dillo the only tags not supported are the non display tags (like abbr or
+address) and sub and sup. 
+
+
+
+RE: [Dillo-dev]Font issues
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-14 07:41
+
+> A better way would be to make that an option in dillorc.
+> Perhaps Sean has something better with his fonts handling (or a better
+> ideas) ?
+> 
+
+font handling is actually the next thing on my list. Hmm, I have Xfree 4.0.1
+and all still seems well. 
+
+
+
+[Dillo-dev]Font issues
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-14 02:01
+
+I've just upgraded Netscape to 4.75 (mandrake RPM) which _needs_ the
+package mozilla-fonts. These fonts seem to be buggy : the
+-helvetica-medium-italic- is a bitmap 18pts font looking bold, and it's
+ugly when resized in 12 by Dillo for regular italic.
+One way around is to change Dillo to use "oblique" instead of "italic":
+
+in dw_page.c (v0.3.0)
+in static GdkFont *Dw_page_realize_font(DwPageFont *font)
+line 1115:
+- font->italic ? "i" : "r",
++ font->italic ? "o" : "r",
+
+That looks like an extreme solution to change Dillo when a font is
+buggy, but it works. (BTW, my adode and urw helvetica don't have italic
+face, only oblique : X must be switching to oblique when italic's not
+found ; does any distri have helvetica-oblique ?)
+A better way would be to make that an option in dillorc.
+Perhaps Sean has something better with his fonts handling (or a better
+ideas) ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 14-Nov-2000 a 10:47:37
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]New 0.3.0 release
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-13 14:38
+
+Jorge Arellano Cid wrote:
+> 
+> Hi!
+> 
+> The sourceforge shell acccount server is back and dillo-0.3.0
+> is there, ready for download.
+> 
+> Note that there're still some patches in my queue and they'll
+> have to wait until 0.3.1 (This release is a long delayed one and
+> I didn't wanted to procrastinate it even more).
+> 
+> I hope you enjoy this release, but bear in mind that 0.3.0
+> is an intermediate release before 0.3.1.
+> 
+> Jorge.-
+> 
+> Ps: I'll be expecting some feedback!
+
+I downloaded it a few hours ago, and patched the changes into my
+version (a bit "handwork" was necessary). I already tested
+third-button-menus and some new tags implemented by Jörgen (<u>,
+<strike> and <s>), and that seems to work.
+
+I hope I'll be able to "release" a slow, buggy, but basicly working
+Dw, integrated in dillo 0.3.0, within the next few days.
+
+Sebastian 
+
+
+
+[Dillo-dev]New 0.3.0 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-13 13:01
+
+Hi!
+
+The sourceforge shell acccount server is back and dillo-0.3.0
+is there, ready for download.
+
+Note that there're still some patches in my queue and they'll
+have to wait until 0.3.1 (This release is a long delayed one and
+I didn't wanted to procrastinate it even more).
+
+I hope you enjoy this release, but bear in mind that 0.3.0
+is an intermediate release before 0.3.1.
+
+
+Jorge.-
+
+Ps: I'll be expecting some feedback! 
+
+
+
+[Dillo-dev]dillo-0.3.0
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-12 18:07
+
+Hi!
+
+
+The dillo-0.3.0 version is ready and waiting for release. The
+funny thing is that the sourceforge server (shell accounts)
+refuses foreign connections! I've been trying for a couple of
+days and also wrote the support staff there asking for some news.
+When the server comes up, 0.3.0 will be there.
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]CVS update
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-10 02:51
+
+-- En reponse de "[Dillo-dev]CVS update" de Jorge Arellano Cid, le
+09-Nov-2000 :
+> 
+> Hi!
+> 
+> We're getting closer to 0.3.0 release. I just updated the CVS
+> server (and bug-track engine) with the newest version.
+> 
+
+I'll post the complete/clean Dillo-plugins patch against v0.3.0 then
+(this should make it easier for you)
+
+> - The horizontal rulers patch (worked by Eric and Allan). Which
+> one is the latest patch? Allan says its patch takes into
+> account feedback from Jörgen and Eric. And I also have a
+> patch from Eric :-)
+> Please tell me which one to apply or send me a new one
+> against the CVS code.
+> 
+
+I know nothing about Allan's patch. Mine is dated Aug 26 and I haven't
+touched it since. Mine is complete though : all attributes are
+recognized and redendered, <br> before and after the <hr> (see more
+details on my page). 
+
+> - Bug#80 worked by Eric. The Web site doesn't contain a valid
+> diff file for it (please send me that patch Eric).
+> 
+
+Oops, sorry. Site updated. As it's a tiny patch, it's also in this mail.
+
+> - For BUG#27. Which test pages did you use Eric? Please send me
+> some URLs.
+> 
+
+It's in the Html.testsuite. (There was no link from the index to the
+page, but the page was here along with the images, sorry : updated on
+my page). Link : Image Maps
+
+PS: patch for bug #80: (my mailer is puting some \n in the way,
+prefer my page's version :-/)
+
+diff -pur dillo-0.2.4/src/dw_page.c dillo-0.2.4.bug80/src/dw_page.c
+--- dillo-0.2.4/src/dw_page.c Tue Aug 22 00:54:09 2000
++++ dillo-0.2.4.bug80/src/dw_page.c Sun Aug 27 22:15:18 2000
+@@ -34,7 +34,7 @@
+#include "prefs.h"
+#include "commands.h"
+
+-#define DW_GET_BW(page) (BrowserWindow *)((page)->status_data)
++#define DW_GET_BW(page) (page->status?(BrowserWindow
+*)((page)->status_data):NULL)
+
+/*
+* Set GtkDwScroller::anchor_pos value.
+@@ -670,9 +670,9 @@ static void Dw_page_handle_event(Dw *dw,
+menu_popup.info.url = page->links[link_pressed].url;
+gtk_menu_popup(GTK_MENU(menu_popup.menu_over_link), NULL,
+NULL,
+NULL, NULL, button->button, button->time);
+- } else {
+- if (bw->nav_stack_size == 0)
+- return;
++ } else if (bw) {
++ if (bw->nav_stack_size == 0)
++ return;
+
+menu_popup.info.title =
+bw->nav_stack[bw->nav_stack_ptr].title;
+menu_popup.info.url = bw->nav_stack[bw->nav_stack_ptr].url;
+
+
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Nov-2000 a 11:34:29
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]CVS update
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-09 16:45
+
+Hi!
+
+We're getting closer to 0.3.0 release. I just updated the CVS
+server (and bug-track engine) with the newest version.
+
+Please note how important is to use the bug-track engine and
+not to do silent patching. The new Changelog (in CVS) shows a lot
+of small patches some of whom were not recorded in the bug-track.
+Please avoid this kind of situation.
+
+On the progress side, the new code hasn't solved all the
+problems related with link-following before the page arrives, but
+certainly will not crash if you follow a different link while
+still downloading the referer page! (I hope to finish that in
+0.3.1 release).
+
+I also started moving the patch queue, and I have a few doubts:
+
+- The horizontal rulers patch (worked by Eric and Allan). Which
+one is the latest patch? Allan says its patch takes into
+account feedback from Jörgen and Eric. And I also have a
+patch from Eric :-)
+Please tell me which one to apply or send me a new one
+against the CVS code.
+
+- Bug#80 worked by Eric. The Web site doesn't contain a valid
+diff file for it (please send me that patch Eric).
+
+- The Find text patch (originally from Sam, patched by
+Sebastian and repatched by Allan). Allan, is your final
+version a stable feature. I ask because Sam warned us of some
+bugs in the patch. I guess they were worked out by following
+patches, and you being the last one to work out the code, and
+most probably the one who has tested it more extensively,
+may have the best informed answer.
+
+- For BUG#27. Which test pages did you use Eric? Please send me
+some URLs.
+
+
+Jorge.-
+
+
+PS1: Having a user manual (an HTML page) has started to be
+necessary. A very concise guide. Volunteers?
+
+PS2: There's a small bug within a_Url_squeeze. When there're
+too much "/.." sequences in the URL, it removes the server!
+(a patch for this BUG, and its bug-track-entry would, be highly
+appreciated too).
+
+PS3: If someone takes the time to update the bug-track with the
+missing entries (found in the CVS-Changelog) that'd be very
+helpful too. 
+
+
+
+[Dillo-dev]Dillo Weekly News
+
+From: Allan Clark <shark@bl...> - 2000-11-05 15:45
+
+Just posted you can view it here
+http://www.shark.pwp.blueyonder.co.uk/news/news051100.html
+
+
+Allan Clark
+allan@al...
+shark@bl... 
+
+
+
+[Dillo-dev]Internal release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-03 22:49
+
+Hi!
+
+The internal release has a new code layer that's expected to
+ease the fix of the reloading, double clicking and every related
+problem. Those fixes are not there yet!
+
+I just wanted to give this prototype a little testing before
+adopting it. It was a 100Kb diff file!
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Internal release
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-02 14:48
+
+Hi!
+
+I finished a first version of dillo, with the new Dw integrated. It
+compiles, and runs halfway, with thousands of warnings and criticals
+(but no crash), furthermore some features are still missing (mouse
+events, colors etc).
+
+Eric GAUDET wrote:
+> I can't say I found it more stable yet on the multiple click on links
+> side : still crashing. Wasn't it supposed to fix this ? (or is it that
+> it's suppose to _ease_ the fixing of this ?)
+
+I wrote a test php3 page (I'll send it Eric, if you wish to), which
+prints the current time (to check wheater reloading works), and has a
+few delays in it (to simulate a slow connection), and tested it with
+three versions: 0.2.4, 0.3.0-pre1, and 0.3.0-pre1 with the new Dw
+integrated. Testing results have been always the same.
+
+Reloading after transmission is complete, works perfectly for all
+versions, interrupting transmission by reloading didn't work correctly
+in any version: 0.3.0-pre1 crashed, and 0.2.4 as well as 0.3.0-pre1 +
+new Dw *both* did not crash, but displayed the old page (with the old
+time).
+
+When debugging 0.3.0pre1, I found that the segmentation fault happens
+in a_Dw_page_update_begin, with argument page == NULL. I wasn't able
+to examine it more, since the stack was destroyed, but this reminds me
+somehow of bug #77 (where there was somewhere a NULL pointer, and the
+crash could be prevented by a simple check). When anchors work in the
+new Dw, it could be a good idea to check whether bug #77 still arises.
+
+BTW, I tried to insert a few checks, but didn't get it run neither.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Internal release
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-11-02 10:36
+
+Jorge Arellano Cid wrote:
+> [...]
+> Sebastian: you can use this version in your effort to integrate
+> the new Dw (or if you prefer, you can wait the testing news).
+> Anyway, from Dw's perspective, changes to the interface are
+> pretty minimal!)
+
+Ok, I'll integrate it into 0.3.0. (Should not be too hard to patch it
+into any version.)
+
+> --
+> 
+> Sean:
+> 
+> > Jorge, would you like for this to happen after Sebastian's
+> > Dw changes?
+> 
+> Yes, please wait until Sebastian integrates the new Dw.
+> An entry in dillorc to disable FONT processing looks OK to
+> me. (FONT tag is still a tricky issue: please be careful).
+
+I suppose, Sean's changes are mainly in the Html module, and since
+there aren't much changes in the interface of DwPage, that should not
+matter.
+
+Anyway, after integration, there will be still much to do, my current
+plan is:
+1. integration (will not take too much time), then
+2. add missing features, and 
+3. bugs fixing, optimization, comments etc.
+
+I could send you a unfinished version after 2, which will be stable,
+with defined interfaces, but still a bit buggy and slow.
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Internal release
+
+From: Eric GAUDET <egaudet@in...> - 2000-11-02 03:53
+
+-- En reponse de "[Dillo-dev]Internal release" de Jorge Arellano Cid,
+le 01-Nov-2000 :
+> 
+> Hi!
+> 
+> I just uploaded dillo-0.3.0-pre1 to the sourceforge server.
+> This internal release is mainly intended for testing. If it
+> proves to be at least as stable as 0.2.4, it will be the base for
+> 0.3.0 release.
+> 
+
+I can't say I found it more stable yet on the multiple click on links
+side : still crashing. Wasn't it supposed to fix this ? (or is it that
+it's suppose to _ease_ the fixing of this ?)
+
+> Those of you that feel interested, please download it and let
+> me know what you think about it (compared with 0.2.4). I'd
+> appreciate your comments, specially if new BUGs arise.
+> 
+> Most probably 0.3.0 will be this code-base plus a few patches,
+> and a couple of weeks later 0.3.1 will integrate the rest of the
+> patch queue.
+> 
+
+I'll update the Html.testsuite indications when 0.3.1 comes out then.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 02-Nov-2000 a 12:44:29
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Internal release
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-11-02 02:48
+
+> 
+> Sean:
+> 
+> > Jorge, would you like for this to happen after Sebastian's
+> > Dw changes?
+> 
+> Yes, please wait until Sebastian integrates the new Dw.
+> An entry in dillorc to disable FONT processing looks OK to
+> me. (FONT tag is still a tricky issue: please be careful).
+> 
+
+will wait for Sebastian then. Gives me some time for some other touch ups. 
+
+
+
+[Dillo-dev]Internal release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-11-01 16:43
+
+Hi!
+
+
+I just uploaded dillo-0.3.0-pre1 to the sourceforge server.
+This internal release is mainly intended for testing. If it
+proves to be at least as stable as 0.2.4, it will be the base for
+0.3.0 release.
+
+Those of you that feel interested, please download it and let
+me know what you think about it (compared with 0.2.4). I'd
+appreciate your comments, specially if new BUGs arise.
+
+Most probably 0.3.0 will be this code-base plus a few patches,
+and a couple of weeks later 0.3.1 will integrate the rest of the
+patch queue.
+
+Source code location: 
+
+http://dillo.so....net/dillo-0.3.0-pre1.tgz
+
+--
+
+Sebastian: you can use this version in your effort to integrate
+the new Dw (or if you prefer, you can wait the testing news).
+Anyway, from Dw's perspective, changes to the interface are
+pretty minimal!)
+
+--
+
+Sean:
+
+> Jorge, would you like for this to happen after Sebastian's
+> Dw changes?
+
+Yes, please wait until Sebastian integrates the new Dw.
+An entry in dillorc to disable FONT processing looks OK to
+me. (FONT tag is still a tricky issue: please be careful).
+
+
+Jorge.- 
+
+
diff --git a/old/oldmail/200012.txt b/old/oldmail/200012.txt
new file mode 100644
index 0000000..d692502
--- /dev/null
+++ b/old/oldmail/200012.txt
@@ -0,0 +1,2938 @@
+[Dillo-dev]ALT attribute in `img' tag
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-27 20:17
+
+Hi all!
+
+Recently I've inserted bug #116, to support ALT attributes in `img'
+tags. Starting out the code, I realized that some of the needed
+changes would go in dw_page.c and possibly html.c. Well I just read in
+Allan's News, that Sebastian is planning to release his new Dw...
+
+Sebastian, have you done anything about the ALT attribute? And if
+not should I wait a while for you to release what your doing before
+trying to support ALT?
+
+best regards,
+
+--
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]dillo-0.3.1
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-27 17:54
+
+Surprise!
+
+
+dillo-0.3.1 is ready for download (sourceforge is back :)
+
+Enjoy
+Jorge.- 
+
+
+
+[Dillo-dev]Window geometry (get_size fix and new dillorc option)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-26 06:04
+
+Hi guys,
+
+I've recently joined gtk list at gtk-list@gn..., and learned the
+proper way of finding out a window's dimension. I was getting:
+window->allocation.width
+window->alloction.height
+
+in the patch I sent to make a new windows the same as parent
+one. Seems that the "right" way to do it is calling
+`gdk_window_get_size()`. I've already sent a patch to Jorge fixing
+this up.. sorry guys.
+
+While I was on that "theme", I started to think about making an
+option in dillorc for initial geometry size, because the first thing I
+do when I open Dillo, is resize it...
+
+So that's what I've done. But I'm not sure the patch is good,
+specially the string manipulations I've done to extract width and
+height. The patch is at (I'm not sending it attached since it's 
+5k == 130 lines long):
+http://www.linux.ime.usp.br/~livio/dillo/geometry_pref.diff
+
+The sintax in your dillorc, should be something like:
+
+> geometry="800x600"
+
+The patch changes the following files:
+
+dillorc: added comments and the above example
+commands.c: changes the window size method to `gdk_window_get_size()',
+like described abouve.
+dillo.c: changed window initialization to get the preference size.
+prefs.c: humm... did it! Look at my string stuff to see if I'm doing
+it right
+prefs.h: added
+> #define DW_GEOMETRY_DEFAULT_WIDTH 640
+> #define DW_GEOMETRY_DEFAULT_HEIGHT 550
+
+and `width' and `height' in struct _DilloPrefs.
+
+That's all... hope you like it (I did, don't have to keep resizing
+dillo no more!)
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-25 17:10
+
+-- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Jorge
+Arellano Cid, le 24-Dec-2000 :
+> I'll reply this post even though I know some posts hasn't
+> arrived to my inbox (Is anyone else losing emails from the list?)
+> 
+
+I received Livio's replies to Sam before Sam's messages a couple of
+times a few days ago.
+
+----------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Dec-2000 a 02:08:48
+"I remember Y1K, every abacus had to get another bead"
+---------------------------------------- 
+
+
+
+[Dillo-dev]Dillo Weekly News
+
+From: adc <shark@bl...> - 2000-12-24 23:12
+
+Hi, the latest Dillo Weekly News has been posted.
+You can find it at
+http://www.shark.pwp.blueyonder.co.uk/news/news231200.html
+please note that the links to the archives aren't filled in yet as I can't
+get connected to the sourceforge site, it looks like sadly the problems at
+sourceforge are continuing, I will fill them in as soon as possible.
+
+
+--
+adc 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-24 00:57
+
+Hi,
+
+I'll reply this post even though I know some posts hasn't
+arrived to my inbox (Is anyone else losing emails from the list?)
+
+
+> On Sat, Dec 23, 2000 at 09:33:39AM -0300, Jorge Arellano Cid wrote:
+> >
+> > * When HTML (4.0 or 4.1) was reformulated as a SGML
+> > application, the entities-parsing problem sprung-in. It wasn't
+> > there until this point. SGML say they MUST be parsed. And the URL
+> > rfc says that characters MUST be escaped according to the context
+> > in which they're used.
+> > So, URLs may have entities in them, and we should parse
+> > them.
+>
+> Uh, no. URLs don't have entities in them, it's attributes (SGML sense) that
+> have entities. Parsing entities in URLs would be a dire mistake.
+
+Once again:
+
+URLs don't have entities (as the URI/URL rfc say), but when
+dealing with:
+
+<A HREF=">
+
+in a SGML context, "A" becomes an element "HREF" an atribute
+and " the atribute value.
+
+Entities must be parsed inside atributes values.
+
+If you don't believe me, read [HTML 4.01 Appendix B 2.2]
+
+BTW: I just updated the home site and added a new link: MISC.
+It will drive you to a handful of useful locations (including
+docs, reading, etc; just click it!)
+
+
+Finally, today I tried three times to upload the 0.3.1 version
+to SourceForge, but it didn't work. Also checked the FTP incoming
+directory and found a huge list of uploaded SW (guess there're
+lots of people with the same problem).
+
+
+Have a nice Christmas and hope to see you before 2001.
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #71
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-23 21:27
+
+Jorge Arellano Cid writes:
+> 
+> Hi,
+> 
+> It seems I'm missing some emails from the list :(
+
+That's bad... You can always read from the archives:
+http://www.geocrawler.com/lists/3/SourceForge/702/0/ Call me
+suspicious, but I do that sometimes to check that I'm getting all
+email.
+
+> I haven't seen this one (and some others) until quoted later.
+> Sourceforge warned us that the mailing list was going to be moved
+> with the respective downtime and glitches; just hope this not to
+> continue...
+
+This was about a fix for bug #71 I
+made. (http://www.linux.ime.usp.br/~livio/dillo/bug_71.diff)
+
+<snip>
+
+> 
+> Well, I have the FTP-plugin code here in my machine, and is
+> time to put some work on it. The problem I face is that my todo
+> list is always bigger than the time I have, so the only solution
+> is to work on a priority basis.
+
+Uhh... and I was *"almost"* finishing mine... (about 10% done ;-)
+That's ok, I learned A LOT about Dillo's IO system!
+
+> I know some of you may have noticed that there're three BUGs in
+> the bug-track (taken by me) that haven't had any progress in the
+> past weeks. They were scheduled, but I spent lots of time fixing
+> patches; please help me by designning & reviewing your patches
+> carefully before submitting them, there's no better thing for a
+> maintainer to receive than a clean patch that's just a skim away
+> from integration.
+
+No stress man! 8^)
+Just for curiosity, what types of mistakes come up? What kind of
+reviewing to you wish us to perform to make your work easier? (I mean,
+what are the most common errors?)
+What I do is after making a patch, get a clean copy from CVS and apply
+my patch to it, and see if everything ok... besides always strinving
+to maintain clean codes.
+
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Sam Dennis <sam@ma...> - 2000-12-23 20:30
+
+On Sat, Dec 23, 2000 at 05:59:46PM -0200, Livio Baldini Soares wrote:
+> Jorge Arellano Cid writes:
+> > 
+> > Hi everyone!
+> 
+> Howdy!
+> 
+> <snip>
+> 
+> > So, URLs may have entities in them, and we should parse
+> > them.
+> > 
+> > 
+> > This problem is BUG#114.
+> 
+> Well in that case, a possible patch is at:
+> http://www.linux.ime.usp.br/~livio/dillo/entity_parse_in_url.diff
+> 
+> Humm. I've been thinking about this patch, and what it does is parse
+> entities in ALL attributes strings. Does anybody know if THAT's
+> correct or is entity parsing only allowed in URL's? (Don't mean to
+> start another polemic ;-)
+
+Not specific to URLs at all, honestly! It is specific to attributes
+containing literal character data, though, although we don't actually deal
+with any others yet, I think.
+
+> 
+> bye!
+> 
+> -- 
+> Livio <livio@li...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+-- 
+Sam Dennis <sam@ma...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Sam Dennis <sam@ma...> - 2000-12-23 20:16
+
+On Sat, Dec 23, 2000 at 01:14:10AM -0200, Livio Baldini Soares wrote:
+> Eric GAUDET writes:
+> > -- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio
+> > Baldini Soares, le 23-Dec-2000 :
+> 
+> <snip>
+
+<further snip>
+
+> PS: Just for the hell of it, I'm sending in a patch against today's
+> 0.3.1 version that enables entity parsing in attributes...
+> 
+> best regards to all,
+> 
+> ****************************************************************
+> --- dillo/src/html.c Fri Dec 22 23:45:10 2000
+> +++ dillo.new/src/html.c Sat Dec 23 00:50:21 2000
+> @@ -2484,10 +2484,14 @@ static gint Html_match_attr(const char *
+> * 0 if value is bigger than datasize
+> * (This code is complex, but avoids a second pass over the value --Jcid)
+> */
+> -static gint Html_get_attr_value(const char *tag, gint tagsize,
+> +static gint Html_get_attr_value(const gchar *old_tag, gint old_tagsize,
+> char *data, gint datasize)
+> {
+> - gint i;
+> + gint i, tagsize;
+> + gchar *tag;
+> +
+> + tag = Html_parse_entities((gchar *)old_tag, old_tagsize);
+> + tagsize = strlen(tag);
+> 
+> if (tag[0] == '"'|| tag[0] == '\´ ) {
+> /* copy to end quote or to datasize */
+> @@ -2502,6 +2506,8 @@ static gint Html_get_attr_value(const ch
+> if (i == tagsize - 1 && i >= 1 && tag[i - 1] == '/')
+> i--;
+> }
+> +
+> + g_free(tag);
+> 
+> if ( i < tagsize && i < datasize ) {
+> *--data = '\0';
+
+A bit messy, that would replace entites throughout the entire tag, which is
+not desirable as not even every type (although we treat them the same for
+now) of attribute allows entities.
+
+It would likely work in all cases (use of an ampersand elsewhere in tags
+would be extremely uncommon, even though it is allowed), but that's not the
+point.
+
+-- 
+Sam Dennis <sam@ma...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-23 19:59
+
+Jorge Arellano Cid writes:
+> 
+> Hi everyone!
+
+Howdy!
+
+<snip>
+
+> So, URLs may have entities in them, and we should parse
+> them.
+> 
+> 
+> This problem is BUG#114.
+
+Well in that case, a possible patch is at:
+http://www.linux.ime.usp.br/~livio/dillo/entity_parse_in_url.diff
+
+Humm. I've been thinking about this patch, and what it does is parse
+entities in ALL attributes strings. Does anybody know if THAT's
+correct or is entity parsing only allowed in URL's? (Don't mean to
+start another polemic ;-)
+
+bye!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Sam Dennis <sam@ma...> - 2000-12-23 19:59
+
+On Sat, Dec 23, 2000 at 09:33:39AM -0300, Jorge Arellano Cid wrote:
+> 
+> * When HTML (4.0 or 4.1) was reformulated as a SGML
+> application, the entities-parsing problem sprung-in. It wasn't
+> there until this point. SGML say they MUST be parsed. And the URL
+> rfc says that characters MUST be escaped according to the context
+> in which they're used.
+> So, URLs may have entities in them, and we should parse
+> them.
+
+Uh, no. URLs don't have entities in them, it's attributes (SGML sense) that
+have entities. Parsing entities in URLs would be a dire mistake.
+
+-- 
+Sam Dennis <sam@ma...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-23 13:02
+
+Hi everyone!
+
+
+Once upon a time ;-) there was BUG#95 (Entities parsing within
+URLs) and now there's BUG#114 (basically the same), and a lot of
+email and doc-research had been done.
+
+The fact is somewhat complicated and although I explained it
+before, when re-reading my post I found it less clear to follow
+than when writing it.
+I hope this new explanation to be better...
+
+
+* The URL (URI) RFCs don't say a word about entities. The only
+escaping mechanism allowed there is hexadecimal (i.e. %xx
+sequences). So according to this source, they MUST NOT be parsed.
+
+* Up to HTML 3.2 this wasn't an issue, so no clue was found
+here (AFAIK).
+
+* When HTML (4.0 or 4.1) was reformulated as a SGML
+application, the entities-parsing problem sprung-in. It wasn't
+there until this point. SGML say they MUST be parsed. And the URL
+rfc says that characters MUST be escaped according to the context
+in which they're used.
+So, URLs may have entities in them, and we should parse
+them.
+
+
+This problem is BUG#114.
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Bug #71
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-23 13:02
+
+Hi,
+
+It seems I'm missing some emails from the list :(
+I haven't seen this one (and some others) until quoted later.
+Sourceforge warned us that the mailing list was going to be moved
+with the respective downtime and glitches; just hope this not to
+continue...
+
+> -- En reponse de "[Dillo-dev]Bug #71" de Livio Baldini Soares, le
+> 23-Dec-2000 :
+> > Oh, since I've looked though all the IO code carefully, I was
+> > thinking of adding a FTP handler in Dillo... do we have an interest
+> > for adding this support? Is there any other method that anyone wants
+> > supported? (Should I spend my time doing this stuff, or does anyone
+> > think there are more "pressing" issues to finish first?).
+>
+> Adding ftp would be very nice and is a short term to-do. IMHO a decent
+> web browser have to provide http:, file: and ftp: protocols.
+
+Well, I have the FTP-plugin code here in my machine, and is
+time to put some work on it. The problem I face is that my todo
+list is always bigger than the time I have, so the only solution
+is to work on a priority basis.
+
+I know some of you may have noticed that there're three BUGs in
+the bug-track (taken by me) that haven't had any progress in the
+past weeks. They were scheduled, but I spent lots of time fixing
+patches; please help me by designning & reviewing your patches
+carefully before submitting them, there's no better thing for a
+maintainer to receive than a clean patch that's just a skim away
+from integration.
+
+Sincerely
+Jorge.- 
+
+
+
+[Dillo-dev][ANN] Html.testsuite updated
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-23 09:29
+
+Hi all,
+assuming today's cvs version is the official v0.3.1, I tested it
+against the Html.testsuite and updated the testsuite accordingly.
+
+http://www.rti-zone.org/dillo/
+
+----------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Dec-2000 a 18:27:38
+"I remember Y1K, every abacus had to get another bead"
+---------------------------------------- 
+
+
+
+RE: [Dillo-dev]Bug #71
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-23 07:28
+
+-- En reponse de "[Dillo-dev]Bug #71" de Livio Baldini Soares, le
+23-Dec-2000 :
+> Oh, since I've looked though all the IO code carefully, I was
+> thinking of adding a FTP handler in Dillo... do we have an interest
+> for adding this support? Is there any other method that anyone wants
+> supported? (Should I spend my time doing this stuff, or does anyone
+> think there are more "pressing" issues to finish first?).
+> 
+
+Adding ftp would be very nice and is a short term to-do. IMHO a decent
+web browser have to provide http:, file: and ftp: protocols.
+
+----------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Dec-2000 a 16:23:20
+"I remember Y1K, every abacus had to get another bead"
+---------------------------------------- 
+
+
+
+[Dillo-dev]Bug #71
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-23 07:08
+
+Hi there,
+
+I started to track down bug #71 today. It's the one that when you
+have a HTML as the source of an image then that HTML title gets the
+window's title.
+
+I spent more than an hour going over IO/MIME/Callback
+code... Congratulations on whoever made this IO system, it's pretty
+nice! Ok, then I finally found out what the problem was. After we make
+the image request, when the document arrives there is a MIME lookup to
+see which callback to use to handle the incoming stuff. If we have an
+HTML then it's classified as text/html, which is ok.
+
+But the problem is that mime already calls text/html callback, which
+is `a_Html_text()' (html.c). And then that will set the callback to
+`Html_callback' and start "rendering" the HTML in the page (but we
+don't see anything expect for the window's title changing), and we
+were only expecting an image...
+
+The solution I've implemented is to verify in `a_Html_text' is the
+DilloWeb->flags is actually a WEB_RootUrl, if it's not just bail out.
+
+For you guys that are "Dillo-oldies", is there anything wrong in
+what I'm proposing? Should I initialize `html' in that function, waste
+some time/space, but cleanly exit, or return NULL, saving that
+time/space, but get a GTK_CRITICAL_ASSERT warning? Right now I chose
+the first option.
+
+The patch is really small (3 lines of code), you can get at:
+http://www.linux.ime.usp.br/~livio/dillo/bug_71.diff
+but I'm sending it below.
+
+Oh, since I've looked though all the IO code carefully, I was
+thinking of adding a FTP handler in Dillo... do we have an interest
+for adding this support? Is there any other method that anyone wants
+supported? (Should I spend my time doing this stuff, or does anyone
+think there are more "pressing" issues to finish first?).
+
+
+Here is the patch against 0.3.1 version (CVS 22/December/2000):
+**********************
+diff -pru dillo/src/html.c dillo.new/src/html.c
+--- dillo/src/html.c Fri Dec 22 23:45:10 2000
++++ dillo.new/src/html.c Sat Dec 23 04:17:18 2000
+@@ -72,6 +72,13 @@ Dw *a_Html_text(const char *Type, void *
+DilloWeb *web = P;
+DilloHtml *html = Html_new(web->bw);
+
++ if (!(web->flags & WEB_RootUrl)) {
++ /* Asked for non-RootUrl (image or other mime), and got an 
++ text/html MIME type... just bail out and save our skin. */
++ *Call = a_Cache_null_client;
++ return html->dw;
++ }
++
+*Data = (void *) html;
+*Call = (CA_Callback_t) Html_callback;
+
+***************************
+
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-23 03:14
+
+Eric GAUDET writes:
+> -- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio
+> Baldini Soares, le 23-Dec-2000 :
+
+<snip>
+> 
+> That's not true at all : urls don't have entities parsing mecanism. The
+> only parsing for urls is escaping with % HEX HEX. '&' is a reserved
+> character for separating 'name=value' blocks in an url.
+> Unfortunatly, a few sites use entities in their urls, and some browsers
+> (nestcape at least) allow this (but netscape's entities parsing is
+> admitedly broken).
+> This issue have already been discussed a few weeks ago in the list,
+> please read the archives for more details
+
+Oops your right! Really sorry about that. There are two messages in the
+archive concerning that, seems that this was a deleted "bug" (#95):
+
+http://www.geocrawler.com/archives/3/702/2000/11/0/4658162/
+http://www.geocrawler.com/archives/3/702/2000/11/0/4701809/
+
+I should of read the archives... I think I assumed the Sourceforge
+wouldn't be wrong in making HTML...
+
+Jorge, when you have time, please delete bug #114 (the one I've
+inserted). 
+
+By the way, since version 0.3.1 is out, do you strip out the bugs
+with smileys on them (the `done` fixes)? Or do you keep them on for a
+while, so everyone knows hows Dillo's developing?
+
+PS: Just for the hell of it, I'm sending in a patch against today's
+0.3.1 version that enables entity parsing in attributes...
+
+best regards to all,
+
+****************************************************************
+--- dillo/src/html.c Fri Dec 22 23:45:10 2000
++++ dillo.new/src/html.c Sat Dec 23 00:50:21 2000
+@@ -2484,10 +2484,14 @@ static gint Html_match_attr(const char *
+* 0 if value is bigger than datasize
+* (This code is complex, but avoids a second pass over the value --Jcid)
+*/
+-static gint Html_get_attr_value(const char *tag, gint tagsize,
++static gint Html_get_attr_value(const gchar *old_tag, gint old_tagsize,
+char *data, gint datasize)
+{
+- gint i;
++ gint i, tagsize;
++ gchar *tag;
++
++ tag = Html_parse_entities((gchar *)old_tag, old_tagsize);
++ tagsize = strlen(tag);
+
+if (tag[0] == '"'|| tag[0] == '\´ ) {
+/* copy to end quote or to datasize */
+@@ -2502,6 +2506,8 @@ static gint Html_get_attr_value(const ch
+if (i == tagsize - 1 && i >= 1 && tag[i - 1] == '/')
+i--;
+}
++
++ g_free(tag);
+
+if ( i < tagsize && i < datasize ) {
+*--data = '\0';
+********************************************************
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]0.3.1 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-23 02:01
+
+Hi,
+
+I tryed to make a new release today(dillo-0.3.1), but
+sourceforge servers didn't work. They claim to be under DDOS
+atacks and it seems to be true :-)
+
+I'll try again tomorrow. The new version is in the CVS though.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-23 01:40
+
+-- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio
+Baldini Soares, le 23-Dec-2000 :
+> 
+> Sam Dennis writes:
+>> On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares
+>> wrote:
+> 
+> <snip>
+> 
+>> > 
+>> > And that's exactly what Dillo sends, but Netscape, p.e, parses
+>> > `&amp;' into a `&'. So what is the correct action to perform? Is
+>> > Dillo
+>> > wrong or is Sourceforge wrong?
+>> > 
+> 
+>> We're wrong, according to the specifications, character entities are
+>> allowed
+>> in attributes, and therefore '&amp;' *must* be used in place of just
+>> '&'.
+>> 
+>> It's not just links, it's all string attributes.
+>> 
+> 
+
+That's not true at all : urls don't have entities parsing mecanism. The
+only parsing for urls is escaping with % HEX HEX. '&' is a reserved
+character for separating 'name=value' blocks in an url.
+Unfortunatly, a few sites use entities in their urls, and some browsers
+(nestcape at least) allow this (but netscape's entities parsing is
+admitedly broken).
+This issue have already been discussed a few weeks ago in the list,
+please read the archives for more details
+
+> Thanks for looking this up Sam!
+> 
+> I've put in the bug in the bug-track, it's bug #114. I've already
+> assigned it to me ;^) I'll get to it after Christmas probably.
+> 
+> PS: Jorge, how you doing with 0.3.1 version? Will it come out
+> before
+> Christmas? Hope so!
+> 
+> best regards to all,
+> 
+> -- 
+> Livio <livio@li...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 23-Dec-2000 a 10:36:02
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-23 00:09
+
+Sam Dennis writes:
+> On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote:
+
+<snip>
+
+> > 
+> > And that's exactly what Dillo sends, but Netscape, p.e, parses
+> > `&amp;' into a `&'. So what is the correct action to perform? Is Dillo
+> > wrong or is Sourceforge wrong?
+> > 
+
+> We're wrong, according to the specifications, character entities are allowed
+> in attributes, and therefore '&amp;' *must* be used in place of just '&'.
+> 
+> It's not just links, it's all string attributes.
+> 
+
+Thanks for looking this up Sam!
+
+I've put in the bug in the bug-track, it's bug #114. I've already
+assigned it to me ;^) I'll get to it after Christmas probably.
+
+PS: Jorge, how you doing with 0.3.1 version? Will it come out before
+Christmas? Hope so!
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Entity parsing in links
+
+From: Sam Dennis <sam@ma...> - 2000-12-22 21:30
+
+On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote:
+> Hi yall,
+> 
+> I'm not sure this is a Dillo bug yet, so that's why I haven't added
+> it to the bug-track. Does any one know if entities (like &gt; &nbsp;
+> &amp;) are supposed to be parsed in links (<a href=XXX>).
+> 
+> I was browsing through Dillo's CVS, looking in the Changelog, at:
+> http://cvs.so....net/cgi-bin/cvsweb.cgi/dillo/ChangeLog?cvsroot=dillo
+> 
+> And I clicked on `annotate` for revision 1.19, then I got an
+> error. If you look at that page's source you can see that the link is:
+> <a href="/cgi-bin/cvsweb.cgi/dillo/ChangeLog?annotate=1.19&amp;cvsroot=dillo">annotate</a>
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+> 
+> And that's exactly what Dillo sends, but Netscape, p.e, parses
+> `&amp;' into a `&'. So what is the correct action to perform? Is Dillo
+> wrong or is Sourceforge wrong?
+> 
+> best regards,
+> 
+> -- 
+> Livio <livio@li...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+We're wrong, according to the specifications, character entities are allowed
+in attributes, and therefore '&amp;' *must* be used in place of just '&'.
+
+It's not just links, it's all string attributes.
+
+-- 
+Sam Dennis <sam@ma...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]Entity parsing in links
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-22 03:07
+
+Hi yall,
+
+I'm not sure this is a Dillo bug yet, so that's why I haven't added
+it to the bug-track. Does any one know if entities (like &gt; &nbsp;
+&amp;) are supposed to be parsed in links (<a href=XXX>).
+
+I was browsing through Dillo's CVS, looking in the Changelog, at:
+http://cvs.so....net/cgi-bin/cvsweb.cgi/dillo/ChangeLog?cvsroot=dillo
+
+And I clicked on `annotate` for revision 1.19, then I got an
+error. If you look at that page's source you can see that the link is:
+<a href="/cgi-bin/cvsweb.cgi/dillo/ChangeLog?annotate=1.19&amp;cvsroot=dillo">annotate</a>
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+And that's exactly what Dillo sends, but Netscape, p.e, parses
+`&amp;' into a `&'. So what is the correct action to perform? Is Dillo
+wrong or is Sourceforge wrong?
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Modularization(?) in Dillo
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-18 17:17
+
+Hi Eric,
+
+Eric GAUDET writes:
+> I've been thinking about that some times ago. What I wanted to do is to
+> make a single bookmars menu attached the menubar of each browser
+> window, but it seems to be impossible to attach a menu more than once
+> in gtk, right ?
+
+Yes that's right! That's the whole problem with the bookmark menu
+issue. You can't attach the same menubar to more than one menu... the
+solution will have to be to create a new menubar widget... ok. But
+current `Bookmarks_goto_bookmark` (the callback from choosing a
+particular bookmark menuitem), sees if the selected widget is equal to
+the first created one... that won't work. A fix for this would be to
+pass the widget's index from `DilloBookmark bookmark[]`.
+
+But then we get another problem, we also need the browserwindow, or
+else we won't know which *bw should we give to a_Nav_push().
+
+So we need to pass the callback two arguments, but GTK only supports
+callbacks with one argument (actually two, but the first you don't
+choose, it's always the GTK_OBJECT which generated the event
+signal). The solution GTK recommends for this (which is the obvious
+one), is to create a struct with the desired fields and pass a pointer
+to the struct.
+
+That's what I'm doing now (actually, I'm not since I'm in the middle
+of final exams and they're *killing* me...), but I'll get to it at the
+end of this week. That's why I'm was asking about where to place the
+struct.
+
+So does `put it in bookmark.c` win?
+
+PS: What about the make new window the same size as the current one?
+Did you finally get to resolving that?
+
+see yall,
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Modularization(?) in Dillo
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-18 12:09
+
+I've been thinking about that some times ago. What I wanted to do is to
+make a single bookmars menu attached the menubar of each browser
+window, but it seems to be impossible to attach a menu more than once
+in gtk, right ?
+
+-- En reponse de "[Dillo-dev]Modularization(?) in Dillo" de Livio
+Baldini Soares, le 18-Dec-2000 :
+> 
+> Hi all,
+> 
+> I'm working on bug #110 (the bookmarks menu not appearing in
+> new window) and was checking for the best way to fix this. I figured
+> that all have to create a struct with a pointer to a menuitem (or an
+> array index) and a pointer to the bw, and pass that struct to the
+> callback (it really doesn't matter for now). What I want to get to,
+> is
+> where should I put (define) this new struct?
+> 
+> I've seen that DilloBookmark is defined in browser.h, but should it
+> be there at all? Because that's a struct that has no interest for the
+> other modules, not even BrowserWindow, it is only used in
+> bookmark.c. Since no other module should know, or need to know, what
+> is a DilloBookmark, I suggest we take it out of browser.h and put it
+> in bookmark.h (and I even dare say bookmark.c). And the struct that
+> I'll create? I guess it should go in bookmark.c, since it is not
+> interesting for other modules including bookmark.h to know? Or should
+> I put it in bookmark.h, for cleanliness sake?
+> 
+
+I'll go for everything in bookmark.c, since it's not needed outside.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 18-Dec-2000 a 21:05:24
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Cookies
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-18 12:04
+
+-- En reponse de "Re: [Dillo-dev]Cookies" de Livio Baldini Soares, le
+18-Dec-2000 :
+>> How to
+>> manage persistant cookies, what kind of power the user should have
+>> over
+>> them, including, of course, denial of cookies, etc.
+> 
+> 
+... 
+> Netscape 6, for example, has a type of "cookie manager", where you
+> can define a rule (accept always, accept never) for each separate
+> URL. I thought it very good. So I enabled cookies from sourceforge
+> and
+> disabled for the rest of the world...
+> 
+> I would like Dillo to have something similar, a "cookie manager"
+> with flexible rules for accepting/denying cookies for diferent
+> sites. Maybe this manager could be integrated as a plugin...
+> 
+> Any ideas?
+> 
+
+That would be very nice. What about a cookierc (text) file containing
+all the rules (each line being a rule for an URL). I volunteer to code
+a plugin for the manager (once the cookierc specs are decided).
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 18-Dec-2000 a 20:59:06
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Modularization(?) in Dillo
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-18 11:15
+
+Hi all,
+
+I'm working on bug #110 (the bookmarks menu not appearing in
+new window) and was checking for the best way to fix this. I figured
+that all have to create a struct with a pointer to a menuitem (or an
+array index) and a pointer to the bw, and pass that struct to the
+callback (it really doesn't matter for now). What I want to get to, is
+where should I put (define) this new struct?
+
+I've seen that DilloBookmark is defined in browser.h, but should it
+be there at all? Because that's a struct that has no interest for the
+other modules, not even BrowserWindow, it is only used in
+bookmark.c. Since no other module should know, or need to know, what
+is a DilloBookmark, I suggest we take it out of browser.h and put it
+in bookmark.h (and I even dare say bookmark.c). And the struct that
+I'll create? I guess it should go in bookmark.c, since it is not
+interesting for other modules including bookmark.h to know? Or should
+I put it in bookmark.h, for cleanliness sake?
+
+bye yall,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Cookies
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-18 10:47
+
+Hello Sam,
+
+Sam Dennis writes:
+> I seem to remember someone mentioning haved worked on, or at least having
+> thought about, cookies in dillo. I'd like to bring it up again, as this
+> seems like a good time to start thinking about implementing them. How to
+> manage persistant cookies, what kind of power the user should have over
+> them, including, of course, denial of cookies, etc.
+
+
+I personally really dislike cookies. I only accept them when they're
+really necessary for some service (like when `logging in` at
+Sourceforge's web site). I would really like a finer control over
+ccokies than what Netscape 4.X gives me. 
+
+Netscape 6, for example, has a type of "cookie manager", where you
+can define a rule (accept always, accept never) for each separate
+URL. I thought it very good. So I enabled cookies from sourceforge and
+disabled for the rest of the world...
+
+I would like Dillo to have something similar, a "cookie manager"
+with flexible rules for accepting/denying cookies for diferent
+sites. Maybe this manager could be integrated as a plugin...
+
+Any ideas?
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]A few answers
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-17 17:48
+
+Hi,
+
+Dillo 0.3.1 is almost ready for a release; most probably by
+December 22. It is a very nice upgrade, you'll appreciate...
+In the mean time, SourceForge made the move to their new
+servers, but the download counters problem remain :( Just checked
+a few projects and no one got their file-hits right... Anyway,
+dillo-0.3.1 will be there before Christmas.
+
+
+Jorge.-
+
+-----
+[Bruno]
+
+> I have a rather small monitor, and for my taste dillo
+> displays text in a fontsize too small. It would be nice if
+> you could change fonts/fontsizes in the ~/.dillo/dillorc file.
+> ...
+
+Sometime ago Sebastian suggested a font-factor; that's a very
+good idea to implement. A single number in dillorc that scales
+font sizes (a flash skim through html.c showed that you'll have
+to search some hard coded font-size numbers within the code to
+implement it; not hard though!).
+
+-----
+[Cookies]
+
+J=F6rgen submitted a patch a long time ago. It's not complete and
+the unimplemented part is the cookie sending one. This patch has
+been procrastinated due to:
+
+a) priorities
+b) the url-passing scheme needs a new implementation
+
+Currently, POST and GET do some url-string hacking to get their
+data to the IO part, and then to the remote server. Cookies need
+to send some information too, and the same happens with
+authentication.
+
+This is basically a matter of defining a Url structure and
+passing it to a lot of functions. The complex part is that
+there're lots of functions that expect a URL string, there're
+several workarounds, some hacks also, and last but not the least:
+dillo's code is very tight and dependent on URLs (they are used
+as primary Keys in the cache for instance, and several decisions
+are being made in the URL passing chain from one module into
+another).
+
+Ah, there's also the problem of URL normalization in between.
+
+----
+[Patches]
+
+Please send them with 'diff -pru', that makes it easier for me. 
+
+
+
+[Dillo-dev][ANN] Dillo-pluginsin PHP
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-17 13:50
+
+Hi folks,
+I just posted "a Dillo-plugin for using PHP to build applications using
+the Dillo-plugins mechanism. This is really a wrapper to PHP compiled
+as CGI, not an Apache module. (enclosed in the archive a sample php
+application, and hints for compiling PHP)"
+
+http://www.rti-zone.org/dillo/
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 17-Dec-2000 a 22:45:21
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Fontsize
+
+From: Bruno Widmann <bwidmann@ut...> - 2000-12-15 15:27
+
+Hi,
+
+I have a rather small monitor, and for my taste dillo
+displays text in a fontsize too small. It would be nice if 
+you could change fonts/fontsizes in the ~/.dillo/dillorc file.
+
+I had a look around the sources, and found that in html.c
+the fontsize seems to be hardcoded.
+
+in Html_page_check there is
+
+font.size = 12;
+
+and in Html_tag_open_h there is
+
+gint sizes[] = {24, 18, 18, 14, 12, 10}
+
+which sets fontsizes for text under <H1> - <H6>
+
+I have allready played around with prefs.c/h and it's quite 
+simple to add config items there so that you can change these values
+via dillorc.
+
+But I don't know if this is the "right way" to do it.
+Or maybe thers something else planed for fonthandling? If it's ok
+to add these values to the configfiles i could submit a patch. 
+
+
+
+[Dillo-dev]Cookies
+
+From: Sam Dennis <sam@ma...> - 2000-12-14 22:37
+
+I seem to remember someone mentioning haved worked on, or at least having
+thought about, cookies in dillo. I'd like to bring it up again, as this
+seems like a good time to start thinking about implementing them. How to
+manage persistant cookies, what kind of power the user should have over
+them, including, of course, denial of cookies, etc.
+
+-- 
+Sam Dennis <sam@ma...>
+
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]SourceForge downtime
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-14 12:24
+
+Hi,
+
+There's a downtime scheduled to Friday December 15, it will
+affect: Web site, CVS, mailing lists and mailing aliases.
+
+You have been warned... :-)
+
+Jorge.- 
+
+
+
+[Dillo-dev]Bug #109 <font> tag
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-12 12:17
+
+Hi,
+
+
+Please note that when making the bug-track entry for FONT
+tags, Livio did the right thing (according to the rules); even
+more, when he finally found out that there was someone else
+working on it, he apologized gently (even though it was not his
+fault), and offered his help. --meus parabêns pro senhor.
+
+BUGs are not owned: there's a explicit recommendation to those
+interested in helping the developer that first took them, to
+contact him and to offer any help.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #109 (<font> tag)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-12 05:55
+
+Sean 'Shaleh' Perry writes:
+
+> > 
+> > Would you like me to change the bug-track entry so that the being
+> > `worked on` field points to you? (Of course, you can do it yourself if
+> > you want, it's but #109).
+> > 
+> 
+> I thought I was marked somewhere on that. WIll make sure I own 109.
+
+Ok, I've done this for you. I put in the `Being worked by:` field
+with value "shaleh@vi...". You can change that or add more info in
+the volunteering page (http://dillo.so....net/Dvolunteer.html).
+
+Sorry again for the mix-up,
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]html tag implementations
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:25
+
+Would anyone who has added support for an unsupported tag please mail me your
+patches. I see several new bugs where people claim to have implemented
+some new tag. I would like to integrate that work with my own. 
+
+
+
+RE: [Dillo-dev]Bug #109 (<font> tag)
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:24
+
+> 
+> I think Sean made a patch for all font stuff. He should have made a
+> bugtrack entry too :-/
+> 
+
+yeah, i should use the bug engine more, I just hate it, sorry Jorge. It does
+not order the items at all, I can not easily find new items for old ones, or do
+many other things I am used to from a bug tracking system. Why not use the
+sourceforge one? Or something, anything. 
+
+
+
+Re: [Dillo-dev]Bug #109 (<font> tag)
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:20
+
+> 
+> Would you like me to change the bug-track entry so that the being
+> `worked on` field points to you? (Of course, you can do it yourself if
+> you want, it's but #109).
+> 
+
+I thought I was marked somewhere on that. WIll make sure I own 109. 
+
+
+
+RE: [Dillo-dev]Bug #109 (<font> tag)
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:19
+
+On 10-Dec-2000 Livio Baldini Soares wrote:
+> Hi yall,
+> 
+> I've included bug #109 into the bug-track, when I was looking at a
+> teacher's page when I noticed that some colored text wasn't colored
+>:-( So I checked the src/html.c, func Html_tag_open_font, and I saw:
+> 
+
+hmm, how many mails have I sent saying I had font (and most other font
+touching) tags working quite nicely (-: Would you mind sending me your
+patch so I could integrate your work.
+
+Jorge asked me to keep my html cleanups until after Sebastian releases his Dw
+widget. 
+
+
+
+Re: [Dillo-dev]Bug #96
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-10 20:30
+
+Hellos, forgot to mention something...
+
+Livio Baldini Soares writes:
+
+<BIG snip>
+
+> The patch is in:
+> http://www.linux.ime.usp.br/~livio/dillo/new_window_same_size.diff
+> 
+> If you want I can e-mail it to you personally, so I wouldn't
+> generate extar traffic on the list. Hope this helps you on what you're
+> doing. 
+
+This pacth is to be applied against current CVS version
+(Dec-10). Jorge uploaded a new version (yesterday), and those changes
+are necessary for this patch to work.
+
+
+that's all, bye,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bug #109 (<font> tag)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-10 18:32
+
+Eric GAUDET writes:
+> -- En reponse de "[Dillo-dev]Bug #109 (<font> tag)" de Livio Baldini
+> Soares, le 10-Dec-2000 :
+> > Hi yall,
+> > 
+> > I've included bug #109 into the bug-track, when I was looking at a
+> > teacher's page when I noticed that some colored text wasn't colored
+> >:-( So I checked the src/html.c, func Html_tag_open_font, and I saw:
+> > 
+> 
+> I think Sean made a patch for all font stuff. He should have made a
+> bugtrack entry too :-/
+
+Oops! Sorry for the mix up, you're right. I checked the mailing
+archives and seems like Sean has being doing font stuff for some time
+now... Sorry abou that Sean! 
+
+Would you like me to change the bug-track entry so that the being
+`worked on` field points to you? (Of course, you can do it yourself if
+you want, it's but #109).
+
+I'll discontinue with my version, since your's is probably much
+better, and you have been in to this much longer than I.
+
+>
+> About SIZE, each browser is free to render it as it likes, so your idea
+> of multiplying by 4 is good. 
+> Let me propose something : make new dillorc parameters for these (say
+> default_font_size and default_font_step)
+>
+
+Good idea.
+
+> As for FACE, Jorge doesn't like it, and I agree with him on this point
+> : html is for client-side rendering, the author is not supposed to use
+> his own fonts. We choosed (so far) to ignore it.
+
+Hum... strange. But surelly Dillo will have an option 
+`Render it just like the author intended to be', will it not? I mean,
+it's really nice to have a very flexible rendering system, so the
+client can do all his heart's will, but sometimes the client's heart's
+is willing to see it like the author intended... and then you'd be
+taking away flexibility...
+
+*yeah my english sucks! Did you understand a word I said?*
+
+> (BTW number 1 to 7 is 7 font sizes, not 8 ;-)
+
+Oops... I guess I should catch up on my sleep :-o
+
+<snip>
+> > checking if all chars are valid hex digits [0-9a-fA-F]. Any body
+> > know someway better to do this?
+> > 
+> 
+> If you check first for named colors, then your hex 6-digits scan,
+> you're good.
+> ("0x" is not in HTML specs, only "#")
+
+Like Homer would say: "DOPE" (tap on the head!) Of course!
+
+
+bye all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bug #96
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-10 18:18
+
+Hi Eric,
+
+before anything I would like to say that I really don't want to
+start arguments or flames or anything like that... I just want to help
+you out, like you've always done for me. So sorry if I still disagree
+with you, but I think this kind of stuff is worth discussing so that
+we ALL can learn from (specially me, who knows too little...). If I'm
+being a pest about this issue, let me know and I'll drop it, ok?
+
+With that said let's get to more interesting issues ;-)
+
+Eric GAUDET writes:
+
+<big snip>
+
+> > What do you need this info (focused window) for? Could you use the
+> > solution I've made for your problem too? Maybe I can help out...
+> > 
+> 
+> Well, that's actually why I made this proposal : your solution can't be
+> applied to my problem ;-)
+> But I though mine would solve both (and probably more) at the same time,
+> so it can have some good in it.
+> 
+> (since your want more infos, I needed to know the size and position of
+> the window that was clicked to open a new window and smartly adjust its
+> geometry)
+
+Ok, I've thought a little bit more about this and I think that both
+solutions are ok. But my solution seems easier for bug #96 and your
+solution to the "opening new same sized window" problem (or maybe
+not... read on).
+
+Let me see if I understand correctly this problem ... To use my
+solution on to implement this you'll have to connect a signal to a
+callback with two arguments: (1 = the clicked link, 2= the clicked bw,
+to extract the size). But this is already handled in
+Dw_page_handle_event... and then it calls
+a_Commands_open_link_nw_callback with the bw that was CLICKED by the
+user... (isn't this what you wanted?). So, theoretically, all you'd
+have to is get the size from the `bw` in
+a_Commands_open_link_nw_callback and pass it to a modified
+a_Interface_new_browser_window which takes the size as arguments...
+
+Sorry, if am still missing the point... but it still seems needless
+to have the last_clicked_bw. I think it is totally feasible to use my
+solution... hum, let me see...
+
+<Sometime passes .... >
+
+Ok, I have a patch here that opens new windows the same size as the
+parent window the call came from (wether from the menu `New Window`,
+or clicking with button 2, or clicking with button 3 and selecting
+`Open Link in new window`). Are looking to this something similar?
+
+The patch is in:
+http://www.linux.ime.usp.br/~livio/dillo/new_window_same_size.diff
+
+If you want I can e-mail it to you personally, so I wouldn't
+generate extar traffic on the list. Hope this helps you on what you're
+doing. 
+
+> 
+> I understand, and I would agree on this. Most of the time. But real life
+> coding made me a "get_the_big_picture_and_you_won't_have_to_waste_your_
+> time_fixing_many_similar_problems" kind of guy ;-)
+
+Yeah, you might be right, I lack lots of expericence. I'm still a
+newbie at this open source programming stuff, and you guys are my
+"gurus". So don't ever hesitate to say that I'm doing something wrong,
+or being too stubborn, chances are, I'm completely wrong about what
+I'm saying.
+
+later dude!
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Bug #109 (<font> tag)
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-10 08:00
+
+-- En reponse de "[Dillo-dev]Bug #109 (<font> tag)" de Livio Baldini
+Soares, le 10-Dec-2000 :
+> Hi yall,
+> 
+> I've included bug #109 into the bug-track, when I was looking at a
+> teacher's page when I noticed that some colored text wasn't colored
+>:-( So I checked the src/html.c, func Html_tag_open_font, and I saw:
+> 
+
+I think Sean made a patch for all font stuff. He should have made a
+bugtrack entry too :-/
+
+> 1) `size=absolute' or `size=[+-]relative'. 
+> What W3 says is that we should accept 8 font sizes (numbered from
+> 1-7), but in Dillo we have more granularity, ending up with more
+> numbered sizes (at least 24, which is in the <h1> tag). So how should
+> I deal with this? In my patch I multiply html size value by 4, giving
+> us Dillo size value... of course this isn't the "right" way to
+> convert from font numbering. Anybody has any ideas?
+> 
+
+About SIZE, each browser is free to render it as it likes, so your idea
+of multiplying by 4 is good. 
+Let me propose something : make new dillorc parameters for these (say
+default_font_size and default_font_step)
+As for FACE, Jorge doesn't like it, and I agree with him on this point
+: html is for client-side rendering, the author is not supposed to use
+his own fonts. We choosed (so far) to ignore it.
+(BTW number 1 to 7 is 7 font sizes, not 8 ;-)
+
+> 2) a_Color_parse issues...
+> 
+> There are two issues which I've encountered:
+> 
+> i) color="Aqua" doesn't resolve to anything! It should resolve to
+> "aqua" == 0x00ffff, shouldn't it? This issue seems to me like a
+> Dillo bug... To fix this I changed all words to their lower-case
+> representation. I did this with:
+>> for (i = 0; i < strlen(subtag); i++)
+>> subtag[i] = tolower(subtag[i]);
+> Is there a better/more efficient way of doing this?
+> 
+
+Unfortunatly not.
+
+> ii) color="ff00aa"
+> To read a color as a hex number Dillo requires a "0x" or "#"
+> prefix, but I've found many html's with just color="56abf3", or
+> something like this. Currently, to fix this, I did something
+> TOTALLY wrong! Just checked if (strlen(subtag) == 6). To only
+> real fix which I thought of was to run over `subtag' string
+> checking if all chars are valid hex digits [0-9a-fA-F]. Any
+> body
+> know someway better to do this?
+> 
+
+If you check first for named colors, then your hex 6-digits scan,
+you're good.
+("0x" is not in HTML specs, only "#")
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Dec-2000 a 16:03:49
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Bug #109 (<font> tag)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-10 05:43
+
+Hi yall,
+
+I've included bug #109 into the bug-track, when I was looking at a
+teacher's page when I noticed that some colored text wasn't colored
+:-( So I checked the src/html.c, func Html_tag_open_font, and I saw:
+
+#if 0
+<some_stuff>
+#endif
+Html_push_tag(...)
+
+Does anyone know/remember why this was commented out? Well it didn't
+work anyway, so I started to see if I could get the <font> tag
+working. After sometime I got a pretty good working version (it still
+has a small render bug, but I think it's pretty much working). I
+checked http://www.w3.org to see the qualifiers for the tag <font>, they are:
+`face', `size' and `color'. So those are the one I've implemented.
+
+The current patch is in:
+http://www.linux.ime.usp.br/~livio/dillo/font_tag.diff
+
+It will corretly render HTML like:
+http://www.rti-zone.org/dillo/Html.testsuite/color.html
+or
+http://www.linux.ime.usp.br/~livio/dillo/font-test.html
+
+
+The patch will change two files: src/html.c and src/colors.c.
+There is are two small issues that are pending so I can get this patch
+100% done.
+
+1) `size=absolute' or `size=[+-]relative'. 
+What W3 says is that we should accept 8 font sizes (numbered from
+1-7), but in Dillo we have more granularity, ending up with more
+numbered sizes (at least 24, which is in the <h1> tag). So how should
+I deal with this? In my patch I multiply html size value by 4, giving
+us Dillo size value... of course this isn't the "right" way to convert
+from font numbering. Anybody has any ideas?
+
+2) a_Color_parse issues...
+
+There are two issues which I've encountered:
+
+i) color="Aqua" doesn't resolve to anything! It should resolve to
+"aqua" == 0x00ffff, shouldn't it? This issue seems to me like a
+Dillo bug... To fix this I changed all words to their lower-case
+representation. I did this with:
+> for (i = 0; i < strlen(subtag); i++)
+> subtag[i] = tolower(subtag[i]);
+Is there a better/more efficient way of doing this?
+
+ii) color="ff00aa"
+To read a color as a hex number Dillo requires a "0x" or "#"
+prefix, but I've found many html's with just color="56abf3", or
+something like this. Currently, to fix this, I did something
+TOTALLY wrong! Just checked if (strlen(subtag) == 6). To only
+real fix which I thought of was to run over `subtag' string
+checking if all chars are valid hex digits [0-9a-fA-F]. Any body
+know someway better to do this?
+
+I think that's all my doubts for now... and ideas/critics/support
+are always supported,
+
+bye,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bug #96
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-10 03:41
+
+-- En reponse de "Re: [Dillo-dev]Bug #96" de Livio Baldini Soares, le
+09-Dec-2000 :
+>> BrowserWindow *topmost_bw;
+>> This variable is updated in dw_page.c, GDK_BUTTON_PRESS event.
+>> 
+>> Any thought ?
+> 
+> Humm.. this could work too. But I think this solution is a little
+> more complex. 
+
+I don't quite see how a 3 lines-patch can be complex.
+
+> Not necessarilly, in all window managers/systems, does
+> clicked == focused. I think we might have a long and tiresome battle
+> to get all the cases where the window is focused, so the topmost_bw
+> is always correct and accurate.
+
+Hum, you noticed the question mark. We could change the name for
+last_clicked_bw, if you think it's less confusing.
+What we really need is CLICKED, so our popup menus (which can be used
+only when _click_ing) know what bw we're talking about.
+
+> I don't know, but it seems too tricky to get this to work out, and
+> maybe "unclean"...
+> 
+
+*cough*
+"unclean" is a dangerous concept : it makes you think the code is more
+important that the application.
+"maybe unclean" is even worse : it makes you think the same while
+admitting you didn't investigate the problem.
+
+(don't get me wrong : I'm not advocating dirty-but-cool hacks, I'm more
+like Jorge's "don't over-optimize" topic)
+
+> What do you need this info (focused window) for? Could you use the
+> solution I've made for your problem too? Maybe I can help out...
+> 
+
+Well, that's actually why I made this proposal : your solution can't be
+applied to my problem ;-)
+But I though mine would solve both (and probably more) at the same time,
+so it can have some good in it.
+
+(since your want more infos, I needed to know the size and position of
+the window that was clicked to open a new window and smartly adjust its
+geometry)
+
+> Sorry for the mean critic... but I think college has made me into a
+> "avoid_global_variables,_they_will_give_you_trouble_in_the_future"
+> kind of guy ;-)
+>
+
+I understand, and I would agree on this. Most of the time. But real life
+coding made me a "get_the_big_picture_and_you_won't_have_to_waste_your_
+time_fixing_many_similar_problems" kind of guy ;-)
+
+> best regards,
+> 
+
+likewise,
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Dec-2000 a 12:23:43
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Comments
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-10 03:18
+
+-- En reponse de "[Dillo-dev]Comments" de Jorge Arellano Cid, le
+09-Dec-2000 :
+> you'll notice in the Changelog that almost no patch got clean into
+> the sources, I had to rework most of them; please be more careful
+> before submitting.
+> 
+
+Can you tell us what are the common errors, so we can be more careful ?
+
+> ----
+> Checkboxes [Eric]
+> 
+> Have you checked what the Specs say about it?
+> 
+
+VALUE is a requiered attribute for CHECKBOXES (and RADIO). We're talking
+here about how to deal with faulty tag missing requiered attributes,
+which is not uncommon in web pages.
+Browsers have a different behavior :
+- Dillo sends "name="
+- Netscape and Amaya send "name=on"
+- Opera sends nothing (but renders the checkbox, which is the worse case
+IMHO)
+- (IE not tested)
+
+PS: another FORM related issue : the SUBMIT button's value is not
+POSTed by Dillo. It should.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Dec-2000 a 12:02:55
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Re: Comments (more on GIF bug 98)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-10 02:15
+
+Livio Baldini Soares writes:
+> Jorge Arellano Cid writes:
+
+<big snip>
+
+> > ----
+> > GIF spec [Livio]:
+> > 
+> > http://www.w3.org/Graphics/GIF/spec-gif89a.txt
+> > (thanks for checking)
+> 
+> Oh, should of looked in w3! Thanks, I'll check it later.
+> 
+
+Well I check it out. It *seems* to me that the coordinates from the
+Logical Screen Descriptor are in fact ignorable, but I'm not
+absolutely sure. Here is the part that matters from the GIF
+specification:
+
+**************************************
+> 18. Logical Screen Descriptor. 
+>
+> a. Description. The Logical Screen Descriptor contains the parameters
+> necessary to define the area of the display device within which the
+> images will be rendered. The coordinates in this block are given with
+> respect to the top-left corner of the virtual screen; they do not
+> necessarily refer to absolute coordinates on the display device. This
+> implies that they could refer to window coordinates in a window-based
+> environment or printer coordinates when a printer is used.
+**************************************
+
+Virtual-screen? Printer? It seems to me that it's ignorable, and we
+can really just rely on the coordinates from the Image
+Descriptor. Here's the spec info on the Image Descriptor:
+
+**************************************
+> 20. Image Descriptor.
+> 
+> 
+> a. Description. Each image in the Data Stream is composed of an Image
+> Descriptor, an optional Local Color Table, and the image data. Each
+> image must fit within the boundaries of the Logical Screen, as defined
+> in the Logical Screen Descriptor.
+> 
+> The Image Descriptor contains the parameters necessary to process a
+> table based image. The coordinates given in this block refer to
+> coordinates within the Logical Screen, and are given in pixels. This
+> block is a Graphic-Rendering Block, optionally preceded by one or more
+> Control blocks such as the Graphic Control Extension, and may be
+> optionally followed by a Local Color Table; the Image Descriptor is
+> always followed by the image data.
+*************************************
+
+Well can anybody who's a better english speaker and has more image
+knowledge tell me if I'd doing something wrong in ignoring the Logical
+Screen Descriptor's coordinates? I think it's okay, specially after
+reading this spec and reading xloadimage-4.1 source code (it ignores
+it too).
+
+If there are no objections, then the patch I have completely fixes
+bug #98.. just have to clean it up a bit before sending it in...
+
+Any feedback is appreciated, best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Comments
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-09 19:47
+
+Jorge Arellano Cid writes:
+> 
+> Hi,
+
+Hi Jorge!
+
+Nice work. I've seen that you've updated CVS versions twice after
+the 0.3.0 release. That's really nice, cause we can see dillo change
+dinamically and not in big jumps like before, hope you keep this
+up. If you do intend to keep updating CVS with certain frequency, then
+may I suggest a dillo-cvs-log@so...? I don't know how it's
+done, but I've seen other projects do this, and I thoght it really
+neat. Everytime someone (you) makes a CVS check-in, then the list
+(dillo-cvs-log) receives an e-mail with the the list of modified files
+and your log message, what do you think? If you like the idea, but
+don't know how to do it, I can try and read the sourceforge manuals
+for you and see if I discover something.
+
+<snip>
+
+> ----
+> GIF spec [Livio]:
+> 
+> http://www.w3.org/Graphics/GIF/spec-gif89a.txt
+> (thanks for checking)
+
+Oh, should of looked in w3! Thanks, I'll check it later.
+
+> 
+> Ah, have you finished BUG#96? The bug-track shows 90% and its
+> already integrated into my source tree!
+
+It's not 90% anymore ;-) Yes I have finished! I put 90% cause I was
+waiting to hear back from anybody to see if my bug fix was good
+enough... but thinking it over for a week now, I couldn't come up with
+anything better design, so I think it's good enough. I haven't changed
+anything so the version you integrated is probably up-to-date.
+
+
+> ----
+> Weekly news [Allan]
+> 
+> Huh? :-)
+
+Yeah, where are you Allan? Hope that everything's okay with
+you... (or hope you're travelling trough the world, meeting lots of
+beatiful girls, and that's why you're kind of gone). I miss those
+weekly news!
+
+bye yall,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Comments
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-09 19:17
+
+Hi,
+
+
+Well, it seems that dillo is getting better and improving
+faster than before. The patch queue is also being flooded at a
+higher rate and from different persons. I'm very happy with this,
+and also spent a lot of time integrating the patches; you'll
+notice in the Changelog that almost no patch got clean into the
+sources, I had to rework most of them; please be more careful
+before submitting.
+
+Maybe that's due to what I call "the rush effect": when a
+developer gets into a coding task and hasn't made the entry in
+the bug track, he gets eager to finnish before any one else does.
+Please avoid this situation (Yes, I received repeated patches,
+and had to make some bug-track-entries myself to stop it).
+
+On the other hand, the big patch queue was very interesting
+and after integration has made --no doubt!-- a better dillo;
+Thanks everybody.
+
+Yes, there's enough material for making a new release, I just
+want to test it some more, add a few improvements, wait for
+sourceforge's counters to start working again and it'll be there.
+
+
+Jorge.-
+
+
+----
+GIF spec [Livio]:
+
+http://www.w3.org/Graphics/GIF/spec-gif89a.txt
+(thanks for checking)
+
+Ah, have you finished BUG#96? The bug-track shows 90% and its
+already integrated into my source tree!
+
+
+----
+Checkboxes [Eric]
+
+Have you checked what the Specs say about it?
+
+
+----
+Weekly news [Allan]
+
+Huh? :-) 
+
+
+
+Re: [Dillo-dev]Bug #96
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-12-09 18:03
+
+Livio Baldini Soares writes:
+> [...]
+> Humm.. this could work too. But I think this solution is a little
+> more complex. Not necessarilly, in all window managers/systems, does
+> clicked == focused. I think we might have a long and tiresome battle
+> to get all the cases where the window is focused, so the topmost_bw is
+> always correct and accurate. I don't know, but it seems too tricky to
+> get this to work out, and maybe "unclean"...
+
+Not necessary. There are simpler ways to check which window is 
+focused, but in this case, you indeed want to get the last window the 
+user had clicked into, not the focus window (and a window manager 
+*does not need* to focus this window). Another way would be to store 
+the browser window belonging to the page into the popup menu, just 
+before popping it up.
+
+However, I'd prefer Livius' implementation, there is really no need 
+to make the code kludgier as needed just to save little memory 
+(compared to the memory anyway allocated for a browser window).
+
+> What do you need this info (focused window) for? Could you use the
+> solution I've made for your problem too? Maybe I can help out...
+> 
+> Sorry for the mean critic... but I think college has made me into a
+> "avoid_global_variables,_they_will_give_you_trouble_in_the_future"
+> kind of guy ;-)
+
+The college had reasons for it. ;-)
+
+Sebastian 
+
+
+
+[Dillo-dev]About bug #98 (GIF especification?)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-09 17:02
+
+Hi all!
+
+Since I went trough the png test suite, I couldn't help noticing the
+http://www.rti-zone.org/dillo/Html.testsuite/badgif.html, where
+there's a gif that's not drawn correctly. I've found the problem and
+made a patch to fix this, but I'm not sure I'm doing the "correct"
+thing to fix it... but my fix doesn't seem to break any other GIFs.
+
+The problem is that gif->width and gif->height are supposed to be
+read from 2 distinct places. From the Logical Screen Descriptor 
+(where:
+gif->Width = LM_to_uint(buf[0], buf[1]); 
+gif->Height = LM_to_uint(buf[2], buf[3]);
+)
+
+*and* from the Image Descriptor
+(where:
+gif->Width = LM_to_uint(buf[4], buf[5]);
+gif->Height = LM_to_uint(buf[6], buf[7]);
+)
+
+Currently Dillo is only reading it's width and height from the
+Logical Screen Descritor. I've checked sources from gif2png and
+xloadimage (xview), and they seem to respect only the Image Descriptor
+width and height, and almost ignore and coordinates from Logical
+Screen Desc (which is kind of strange). So what I've done is just
+that, I don't call a_Dicache_set_parms from within Gif_get_descriptor,
+but call it with the "correct" values from Gif_do_img_desc. This seems
+to work fine with all GIF's and should work with all GIF's are
+open-able(?) with xloadimage. (oh the patch is at:
+http://www.linux.ime.usp.br/~livio/dillo/bad_gif.diff).
+
+But I want to make sure I'm doing the correct thing... So does
+anybody know where I can find an GIF especification? Or like GIF-RFC?
+IS there a GIF especification at all for public eyes? If I could get
+one, them I could really make sure that my patch is full proof.
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bug #96
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-09 16:08
+
+Eric GAUDET writes:
+> Hey Livio,
+
+Hi Eric!
+
+> 
+> -- En reponse de "[Dillo-dev]Bug #96" de Livio Baldini Soares, le
+> 01-Dec-2000 :
+> > I started working on patch number 96. It was the bug that when
+> > trying to `View Source` with multiple windows open, Dillo would
+> > always get the last opened window and view that source, no matter on
+> > what window we clicked. 
+> 
+> How did you eventually manage the problem ? 
+
+Like I wrote in the previous e-mail, I've made each bw have it's own
+menu_pop, i.e. make menu_pop a member of the struct
+_BrowserWindow. This way the signal was corretly assigned to the right
+bw. Personally, I think this is a clean fix, which doesn't require a
+lot of rework, and seems to be robust. This way we don't have to worry
+which is the focused or clicked window, since GTK deals corretly with
+this when we connect the signal (right_button on bw -> open menu_pop).
+
+> I had a similar problem, needing to know what was the last clicked (==
+> focused ?) window. The solution I used would help both of us, I think. I
+> added a global variable in dillo.c :
+> BrowserWindow *topmost_bw;
+> This variable is updated in dw_page.c, GDK_BUTTON_PRESS event.
+> 
+> Any thought ?
+
+Humm.. this could work too. But I think this solution is a little
+more complex. Not necessarilly, in all window managers/systems, does
+clicked == focused. I think we might have a long and tiresome battle
+to get all the cases where the window is focused, so the topmost_bw is
+always correct and accurate. I don't know, but it seems too tricky to
+get this to work out, and maybe "unclean"...
+
+What do you need this info (focused window) for? Could you use the
+solution I've made for your problem too? Maybe I can help out...
+
+Sorry for the mean critic... but I think college has made me into a
+"avoid_global_variables,_they_will_give_you_trouble_in_the_future"
+kind of guy ;-)
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Bug #96
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-09 12:28
+
+Hey Livio,
+
+-- En reponse de "[Dillo-dev]Bug #96" de Livio Baldini Soares, le
+01-Dec-2000 :
+> I started working on patch number 96. It was the bug that when
+> trying to `View Source` with multiple windows open, Dillo would
+> always get the last opened window and view that source, no matter on
+> what window we clicked. 
+
+How did you eventually manage the problem ? 
+I had a similar problem, needing to know what was the last clicked (==
+focused ?) window. The solution I used would help both of us, I think. I
+added a global variable in dillo.c :
+BrowserWindow *topmost_bw;
+This variable is updated in dw_page.c, GDK_BUTTON_PRESS event.
+
+Any thought ?
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 09-Dec-2000 a 21:22:34
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Re: *
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-06 00:48
+
+Hi,
+
+> Eric GAUDET <egaudet@in...> writes:
+>
+> > Do you still have this hash function ? I need one and I'm not sure mine
+> > is that good.
+>
+> Doesn't glib include one? At least the header file suggests so. There
+> are several function declarations named 'g_hash_table_*()'. So, this
+> might be worth looking into.
+
+I digged into my archive and didn't find them :(
+(I surely had been so dissapointed that ...!)
+
+Anyway, I was using mph-1.2.tar.gz (22 Kb), an excellent
+package for generating minimal perfect hashes. Once you find a
+function, it can be tuned in steps and table size, very cool
+stuff. I remember that I built a hash function for every
+supported HTML tag in dillo, and tuned it to half the size and 2
+or three steps; it was faster than the binary search, sure (4% or
+so), but the added complexity, was not worth the trouble.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Final PNG transparent, file URI and bug 107
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2000-12-05 10:19
+
+Livio Baldini Soares writes:
+> 2)
+> Sometime ago I sent in a patch to correct, what I considered, a
+> misbehaviour, but since nobody said anything (neither against or in
+> favor), I'll ask again. When I type in the following in Dillo:
+> 
+> /home/livio/
+> 
+> Dillo will then try to resolve http://home/livio/, but that isn't what
+> I wanted him to do. Im my opinion Dillo should consider URL's starting
+> with a '/' (slash) as a file request. What do you guys think?
+
+Yes, since '/' is not allowed in host names, I'd say this is a good 
+idea.
+
+Another idea: With all the plugins in future, how about a common 
+scheme based on regular expressions, configured by the user, e.g:
+
+/^ftp\.[[:alnum:]\.]+\// -> ftp:// (assuming that ftp server names
+often begin with "ftp.")
+/^[[:alnum:]\.]+\// -> http://
+/^\// -> file:
+/^\(.+\)/ -> info:
+/^\w+\(\w+\)$/ -> man:
+
+> I've made a patch to do exactly this. It's small, check it out at:
+> http://www.linux.ime.usp.br/~livio/dillo/file.diff
+> 
+> 3)
+> I tried to reproduce bug #107, but I failed. If anyone on the list
+> registered bug 107, could you please explain how to reproduce it, so I
+> may that a llok at it?
+
+I didn't register it, but just try
+http://download.so....net/dillo/dillo-0.3.0.tar.gz
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Final PNG transparent, file URI and bug 107
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-05 09:53
+
+-- En reponse de "[Dillo-dev]Final PNG transparent, file URI and bug
+107" de Livio Baldini Soares, le 05-Dec-2000 :
+> 1)
+> Just wanted to write to say I've completely finished the png
+> transparency implementation. Including the gamma correction which I
+> didn't implement in the previous patch. So with that I think that the
+> PNG test suite on Eric's site is pretty much complete, or have I
+> skipped something?
+> 
+
+This png test suite is the official png test suite. 
+
+> 2)
+> Sometime ago I sent in a patch to correct, what I considered, a
+> misbehaviour, but since nobody said anything (neither against or in
+> favor), I'll ask again. When I type in the following in Dillo:
+> 
+> /home/livio/
+> 
+> Dillo will then try to resolve http://home/livio/, but that isn't
+> what I wanted him to do. Im my opinion Dillo should consider URL's
+> starting with a '/' (slash) as a file request. What do you guys
+> think?
+> 
+> I've made a patch to do exactly this. It's small, check it out at:
+> http://www.linux.ime.usp.br/~livio/dillo/file.diff
+> 
+
+That's too bad dillo's having a different behavior when getting a URL
+in the command line or in the nav bar. Should be the same.
+
+> 3)
+> I tried to reproduce bug #107, but I failed. If anyone on the list
+> registered bug 107, could you please explain how to reproduce it, so
+> I may that a look at it?
+> 
+
+No negfault for me either. I think it's the same bug with interrupting
+download again. I'm pretty sure whoever made this entry can't reproduce
+it every time.
+IMHO there should be a <b>big</b> warning on the bug insertion page
+asking people to test _several_ time the how-to-reproduce method before
+they submit.
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 05-Dec-2000 a 18:40:59
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+Re: [Dillo-dev]Re: *
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-05 09:39
+
+-- En reponse de "Re: [Dillo-dev]Re: *" de Livio Baldini Soares, le
+05-Dec-2000 :
+> Eric GAUDET writes:
+>> I had a quick look at the sources, and I don't understand why
+>> passing bw isn't enough for finding what page was clicked.
+>> However, I know the bug is there : _I_ did the bugtrack entry !
+> 
+> Well I'll try to explain it in my bad english...
+> 
+> Since there was only one (global) `menu_popup`, everytime a new
+> window was opened the same menu_popup would be (re)initialized (in
+> a_Menu_popup_new). In that initialization the Menu_add (to connect a
+> signal to a callback function), would be written over with the new
+> parameter (the new *bw). So when the signal (event) called the
+> callback, it would send the latest *bw NOT the current *bw.
+> 
+> Ummm, did it get any clearer, or just confused you more?
+> 
+> bye,
+
+I think I'm begining to see the light ;-) What I understand now is when
+registering a call-back, the parameter (bw) is registered too. I though
+the parameter was updated according to the calling widget each time the
+callback was invoked (&bw).
+... I should really read this gkt book I bought a while ago ;-)
+
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 05-Dec-2000 a 18:33:54
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Final PNG transparent, file URI and bug 107
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-05 02:32
+
+Hello again,
+
+Since I'm crowding too much this list lately I'll send in a 3 in 1
+e-mail. Here goes my three topics:
+
+1)
+Just wanted to write to say I've completely finished the png
+transparency implementation. Including the gamma correction which I
+didn't implement in the previous patch. So with that I think that the
+PNG test suite on Eric's site is pretty much complete, or have I
+skipped something?
+
+2)
+Sometime ago I sent in a patch to correct, what I considered, a
+misbehaviour, but since nobody said anything (neither against or in
+favor), I'll ask again. When I type in the following in Dillo:
+
+/home/livio/
+
+Dillo will then try to resolve http://home/livio/, but that isn't what
+I wanted him to do. Im my opinion Dillo should consider URL's starting
+with a '/' (slash) as a file request. What do you guys think?
+
+I've made a patch to do exactly this. It's small, check it out at:
+http://www.linux.ime.usp.br/~livio/dillo/file.diff
+
+3)
+I tried to reproduce bug #107, but I failed. If anyone on the list
+registered bug 107, could you please explain how to reproduce it, so I
+may that a llok at it?
+
+that's about all, see yall latter,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Re: *
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-05 01:39
+
+Eric GAUDET writes:
+> -- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le
+> 01-Dec-2000 :
+
+
+<big snip>
+
+> >> [BUG #96]
+> > 
+> > I'll answer this one when I look up the patch code. I'm
+> > interested cause a similar problem arises when trying to get the
+> > link the mouse was over at click time (for "Save link as").
+> > 
+> 
+> I had a quick look at the sources, and I don't understand why passing bw
+> isn't enough for finding what page was clicked.
+> However, I know the bug is there : _I_ did the bugtrack entry !
+
+Well I'll try to explain it in my bad english...
+
+Since there was only one (global) `menu_popup`, everytime a new
+window was opened the same menu_popup would be (re)initialized (in
+a_Menu_popup_new). In that initialization the Menu_add (to connect a
+signal to a callback function), would be written over with the new
+parameter (the new *bw). So when the signal (event) called the
+callback, it would send the latest *bw NOT the current *bw.
+
+Ummm, did it get any clearer, or just confused you more?
+
+bye,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Re: *
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-05 01:29
+
+Hi Jorge,
+
+Jorge Arellano Cid writes:
+> 
+> Hi!
+> 
+
+<snip>
+
+> 
+> Eric found a good solution by publishing pre-patches in his web
+> site, maybe you can ask him for some space when necessary.
+
+
+Ok, I agree that sometimes it can be annoying and waste of
+bandwidght to have all patches attached to the list. I should of
+thought of having my patches on a web page before :-(
+
+Here is a link to all the patches which I've made (or am currently
+working on):
+
+http://www.linux.ime.usp.br/~livio/dillo/
+
+It's my homepage from the University. It is REALLY slow, and
+sometimes the University has it's backbone down and won't respond at
+all. If anyone is trying to get a particular patch they can e-mail me
+and ask, I'll be happy to provide it.
+
+<snip>
+
+> > [PNG transaparency]
+> 
+> Please send me your last patch (when done) Livio.
+
+I've pretty much finished, and you can get it at:
+http://www.linux.ime.usp.br/~livio/dillo/pang_transparency.diff
+
+But I will sent it to you personally.
+
+<snip>
+
+> > [BUG #96]
+> 
+> I'll answer this one when I look up the patch code. I'm
+> interested cause a similar problem arises when trying to get the
+> link the mouse was over at click time (for "Save link as").
+> 
+
+I've tried it out, and the patch I've made fixes the problem with
+`Save link as...` too. The patch is here:
+
+http://www.linux.ime.usp.br/~livio/menu_pop.diff
+
+
+that's about all... best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Re: *
+
+From: Rafael R. Sevilla <dido@pa...> - 2000-12-03 18:37
+
+
+
+
+
+RE: [Dillo-dev]Re: *
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-03 16:42
+
+he was talking about a minimal perfect hash function, not a hash
+function robust for cryptography purposes. 
+However, I tested the the glib hash function for strings, and it's not
+good _at_all_ : not near perfect (lots of collisions, any XOR-based
+function is better). Almost unsuable.
+
+-- En reponse de "[Dillo-dev]Re: *" de Olaf Dietsche, le 03-Dec-2000 :
+> Eric GAUDET <egaudet@in...> writes:
+> 
+>> Do you still have this hash function ? I need one and I'm not sure
+>> mine
+>> is that good.
+> 
+> Doesn't glib include one? At least the header file suggests so. There
+> are several function declarations named 'g_hash_table_*()'. So, this
+> might be worth looking into.
+> 
+> Regards, Olaf.
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/mailman/listinfo/dillo-dev
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 04-Dec-2000 a 01:38:50
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Re: *
+
+From: Olaf Dietsche <olaf.dietsche@gm...> - 2000-12-03 15:48
+
+Eric GAUDET <egaudet@in...> writes:
+
+> Do you still have this hash function ? I need one and I'm not sure mine
+> is that good.
+
+Doesn't glib include one? At least the header file suggests so. There
+are several function declarations named 'g_hash_table_*()'. So, this
+might be worth looking into.
+
+Regards, Olaf. 
+
+
+
+[Dillo-dev]just subscribed, dillo is faaaast :-)
+
+From: Olaf Grüttner <olaf@se...> - 2000-12-02 13:13
+
+I just wanted to thank you guys. I recognize dillo being work in progress,
+but is so fast it is wonderful and compared
+to things like netscape 6 on linux it is lightning fast.
+
+can´t wait till tables are supported by dillo.
+
+keep up the good work!!!
+
+Olaf 
+
+-- 
+
+
+
+RE: [Dillo-dev]Re: *
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-02 01:32
+
+-- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le
+01-Dec-2000 :
+> Eric found a good solution by publishing pre-patches in his web
+> site, maybe you can ask him for some space when necessary.
+> 
+
+Sure :-) (any free web hosting will do, though)
+
+> The University told us that code optimization was a task to be
+> undertaken by the compiler (mainly peephole opt.), the real world
+> is different!
+> 
+
+I used to code demos in asm-68k, I must still have some in the blood ;-)
+
+> Finally, never try to over-optimize!!!
+> 
+
+right ! But don't stop until your done with sensible loops code.
+
+> Speed opt. is a highly tricky matter. For instance, what seems
+> faster in theory doesn't always show on reality: sometime ago I
+> was tunning a minimal perfect hash function for dillo, and I
+> succeeded!, but profiling revealed that the gain over a simple
+> binary search was around 2%, and the added complexity was
+> impressive.
+> 
+
+Do you still have this hash function ? I need one and I'm not sure mine
+is that good.
+
+> 
+>> [BUG #96]
+> 
+> I'll answer this one when I look up the patch code. I'm
+> interested cause a similar problem arises when trying to get the
+> link the mouse was over at click time (for "Save link as").
+> 
+
+I had a quick look at the sources, and I don't understand why passing bw
+isn't enough for finding what page was clicked.
+However, I know the bug is there : _I_ did the bugtrack entry !
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 02-Dec-2000 a 10:24:24
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+RE: [Dillo-dev]Re: *
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-01 21:44
+
+>> Another thing, there was a comment in the header of a_Url_squeeze
+>> made by Jorge, saying the he wasn't sure that it was necessary. Well I
+>> checked APACHE and it's NOT necessary to squeeze the URL. I sent in a
+>> request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`,
+>> and got the /index.html. Seems to work fine with both /../ and /./,
+>> but I'm not sure if this is true to all HTTP servers. The only time
+>> APACHE complains is when we send in a request for /FAQ/../../, APACHE
+>> claims this is a BAD REQUEST, but the new a_Url_squeeze prevents
+>> this
+> 
+
+if the function is trivial, it probably saves the server some work. plus I
+wonder what IIS does with this?
+
+>> [Code optimization]
+> 
+> Eric's suggestions can be very insightful. I just want to add
+> my two-cents.
+> 
+> The University told us that code optimization was a task to be
+> undertaken by the compiler (mainly peephole opt.), the real world
+> is different!
+> 
+
+one thing I was taught was to profile, profile, profile. There is a nice GNU
+tool called gprof to help with this. You compile the app with profiling turned
+on, run it, then run gprof on the output (gmon.out I think). You get a
+function call tree, time spent in each, etc. Very useful. 
+
+
+
+[Dillo-dev]Re: *
+
+From: Jorge Arellano Cid <jcid@ne...> - 2000-12-01 20:16
+
+Hi!
+
+As usual, here you'll find several answers (batch mode!)
+
+> Another thing, do you (or anybody
+> else) have anything against sending patches to the list, so everyone
+> can "pitch" in, and publically(?) discuss them. If not do you want me
+> to CC: them to you, Jorge?
+
+I don't have an absolute answer for this question.
+Cartainly, final-patches must be sent to me for revision and
+inclusion, but those that can be considered as a "work in
+progress" can be sent to the list for discussion.
+
+This mailing list has a reputation (gained over time) to be low
+traffic and interesting, and I love it that way; maybe the best
+way is hold patches while still polishing them and only request
+some help or feedback when you really need it. Posting the patch
+is a last resource, cause you always have the chance to send it
+privately to the helping party.
+
+Eric found a good solution by publishing pre-patches in his web
+site, maybe you can ask him for some space when necessary.
+
+> [...]
+> I'll change the status to 100% in the bug-track when I get back net
+> connection. Oh, and I'm NOT suppossed to put `done`, this is done by
+> Jorge when he inserts the patch in the code (IF we agree the code is
+> worth putting in), is this correct Jorge?
+
+Absolutely.
+
+
+> Another thing, there was a comment in the header of a_Url_squeeze
+> made by Jorge, saying the he wasn't sure that it was necessary. Well I
+> checked APACHE and it's NOT necessary to squeeze the URL. I sent in a
+> request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`,
+> and got the /index.html. Seems to work fine with both /../ and /./,
+> but I'm not sure if this is true to all HTTP servers. The only time
+> APACHE complains is when we send in a request for /FAQ/../../, APACHE
+> claims this is a BAD REQUEST, but the new a_Url_squeeze prevents
+> this
+
+Thanks for the info.
+
+BTW: Does anyone remember BUG#95? (Whether or not to parse
+entities within URIs) I answered that sometime ago but, ....!!!,
+my last research showed that although the URI RFC doesn't mention
+entities, when the w3c guys decided to define HTML as SGML,
+the entities parsing problem sprung-in, and the recomendation is
+to parse them!!! (HTML 4.01 Appendix B 2.2).
+
+I don't if they changed the recommendation when they decided to
+put-off SGML and defined XHTML as XML :-)
+
+
+> [PNG transaparency]
+
+Please send me your last patch (when done) Livio.
+
+
+> [Code optimization]
+
+Eric's suggestions can be very insightful. I just want to add
+my two-cents.
+
+The University told us that code optimization was a task to be
+undertaken by the compiler (mainly peephole opt.), the real world
+is different!
+
+Some time ago I made some local vars optimizations that yielded
+a bit more than a 100% percent speed gain!!!!! (with gcc :-).
+When I exposed the problem to one of the gcc-tester's team, he
+couldn't believe his eyes.
+
+Finally, never try to over-optimize!!!
+
+Speed opt. is a highly tricky matter. For instance, what seems
+faster in theory doesn't always show on reality: sometime ago I
+was tunning a minimal perfect hash function for dillo, and I
+succeeded!, but profiling revealed that the gain over a simple
+binary search was around 2%, and the added complexity was
+impressive.
+
+
+> [BUG #96]
+
+I'll answer this one when I look up the patch code. I'm
+interested cause a similar problem arises when trying to get the
+link the mouse was over at click time (for "Save link as").
+
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's)
+
+From: Eric GAUDET <egaudet@in...> - 2000-12-01 09:29
+
+-- En reponse de "Re: [Dillo-dev]Re: About bug #60 (transparency in
+PNG's)" de Livio Baldini Soares, le 01-Dec-2000 :
+> By the way, I also had forgotten to add a "composite" support, for
+> when alpha value is between 0 (fully transparent) and 255 (totally
+> opaque). I'm sending the new version, look at it and see if it's more
+> 'decent' or is it still crappy? (Am sending it attached...)
+> 
+
+It's very nice. It's probably faster than the original code too.
+BTW, testing for 0 and 255 is a very nice optimisation over
+png_composite : as these values are more likely to be used, you avoid
+calling a function.
+
+> Oh and I also checked the PNG test suite and compared against
+> netscape 6 for Linux. The only thing that was different was the gamma
+> correction. I guess there isn't any gamma correction with current PNG
+> in dillo. Maybe I'll to do that some other time. Meanwhile, should I
+> put such small problem in the bug-track, or should I leave it alone,
+> hence it's "kind" of documented in the test suite?
+> 
+
+Isn't there a gamma-init function in pnglib ?
+Anyway, IMHO we should all make more bugtrack entries, even for such
+tiny problems, so we don't forget them. Jorge can always remove it if he
+thinks it's not important.
+
+> I still have a doubt though. I currently left alone the outer for:
+> for (i = 0; i < png->width; i++) {
+> but just to acknowledge when to stop, cause I don't use `i` anywhere
+> else. Do you see a better way to detect when png is over with.
+> 
+
+No, that's how it's done. Perhaps png->width can be calculated outside,
+but it shouldn't matter much.
+If it wasn't image processing (we're talking about hundred thousands
+pixels, one loop for each pixel), I wouldn't suggest the following
+(since i is not used) :
+for ( i = png->width ; i ; i-- )
+;-)))
+
+Last thing : you've probably reviewed the gif decoding to learn how
+transparency is delt with. Do you think the code is optimised enough ?
+
+ciao
+
+-----------------------------------
+Eric GAUDET <egaudet@in...>
+Le 01-Dec-2000 a 18:13:57
+"Le verbe inexister ... inexiste !"
+----------------------------------- 
+
+
+
+[Dillo-dev]Bug #96
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-01 04:21
+
+Attachments: menu_pop.diff      
+
+Hi!
+
+I started working on patch number 96. It was the bug that when
+trying to `View Source` with multiple windows open, Dillo would always
+get the last opened window and view that source, no matter on what
+window we clicked. First I went to look for the source of the problem,
+it appears to be the fact the the is only Menu_popup for all the
+windows. And when we open a new window using
+a_Interface_new_browser_window, we re-initilialize menu_popup, with:
+
+> menu_popup.menu = a_Menu_popup_new(bw);
+> menu_popup.menu_over_link = a_Menu_popup_ol_new(bw);
+
+And in a_Menu_popup_new we add the callback for selecting View
+Source, and all other Menu_popup entries. So for every new window, the
+callback are changed to look up it's data from that window, ignoring
+the possibility of other older windows...
+
+So I have thought up of two solutions, and for the first one I'm
+sending in the patch which I've made (almost minimal changes to
+current program):
+
+1) One solution is to have every window have it's own menu_popup. So
+basically I changed struct _BrowserWindow to include a
+DillowMenuPopup, and changed all ocurrences of menu_popup tp
+bw->menu_popup. This is the solution I've implemented and am sending
+the patch.
+
+2) The other soluion would involve more changes to current code, but
+might be more economic. Instead of having each BrowserWindow have it's
+own menu_popup like in (1), continue like current code, having a
+global menu_poup, but use the browser_window[] Vector(? array?) index
+to pass to the callback. So when the callback is called it checks,
+somehow, from what window is the signal coming from and them access
+the window using the browser_window[] array. I didn't like this idea
+so much as it would make the code uglier and even though we would
+economize a mune_popup per new window, we would create overhead to
+find out from what window was the signal coming from and process that
+information accordingly.
+
+
+Any ideas/comments? I would really apreciate, since I still haven't
+convinced myself I've chosen the right choice (or there may be
+others...). 
+
+Oh, and the patch is supposed to be applyied over the whole dillo
+directory (from CVS), but will only affect: src/bookmark.c,
+src/browser.h, src/commands.c, src/dw_page.c, src/interface.c,
+src/menu.c. 
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's)
+
+From: Livio Baldini Soares <livio@li...> - 2000-12-01 03:04
+
+Attachments: png_transparent2.diff      
+
+Gee, thanks, Eric!
+
+Very nice tips you gave on my patch (some of the stuff I already
+knew but was too lazy/sleepy to get things out). Sorry about the
+newbie code... but with all of your suggestions, now I think the patch
+is looking good...
+
+By the way, I also had forgotten to add an "composite" support, for
+when alpha value is between 0 (fully transparent) and 255 (totally
+opaque). I'm sending the new version, look at it and see if it's more
+'decent' or is it still crappy? (Am sending it attached...)
+
+Oh and I also checked the PNG test suite and compared against
+netscape 6 for Linux. The only thing that was different was the gamma
+correction. I guess there isn't any gamma correction with current PNG
+in dillo. Maybe I'll to do that some other time. Meanwhile, should I
+put such small problem in the bug-track, or should I leave it alone,
+hence it's "kind" of documented in the test suite?
+
+Eric GAUDET writes:
+> 
+> IMHO there's several problem with your calculations :
+
+;-)
+
+> 
+> 1) the strol part is very inefficient, but that's not a real problem
+> because this code is _outside_ the loop. Anyway, here's how to do it :
+> (strip all the sprintf)
+> bg_blue = (prefs.bg_color0 & 0xFF;
+> bg_green = (prefs.bg_color>>8) & 0xFF;
+> bg_red = (prefs.bg_color>>16) & 0xFF;
+
+Yeah, this one I knew was really bad...
+
+> 
+> 2) The loop is _always_ the sensible part ! You _never_ want to allocate
+> local variables like you did : 
+> for (...) { 
+> gint p,a; 
+> (some compiler may optimize this, but you never know)
+> As a rule of thumb, it's better to allocate local variables at the
+> begining of a function.
+> 
+
+I agree completely, loops are what makes the code have a higher
+complexity, and everything that can, should be put outside of the
+loop.
+
+> 3) If you really want to improve speed, do all calculation only once in
+> local variables : i*3 is computed three times, it would be better to
+> have calculated i3 = i*3 and use i3. (same with i*4 used twice).
+> You could also have done i3 += 3 each loop, but on pentium-generation
+> cpu (whatever the brand, ppc, arm, ...) multiplications and additions
+> cost the same so it doesn't matter, and using i*3 is often more
+> readable and more robust (not sensible to initiallisation).
+> 
+> 4) Even better : look into a table is a calculation. png->linebuf[3*i]
+> is actually *(png + linebuf + 3*i).
+> You could have declared 
+> guchar *pl = png->linebuf;
+> and in the loop :
+> if (!a){
+> *(pl++) = bg_red;
+> *(pl++) = bg_green;
+> *(pl++) = bg_blue;
+> }
+> 
+
+Liked this option (4) much more than 3.
+
+> The else part is basically the same, if a little more trickier, and you
+> can get rid of the costy for() : I let it to you as an exercise ;-)
+> (hint : row_num*png->rowbytes is ugly)
+
+Well... how is it now? Less uglier?
+
+I still have a doubt though. I currently left alone the outer for:
+for (i = 0; i < png->width; i++) {
+but just to acknowledge when to stop, cause I don't use `i` anywhere
+else. Do you see a better way to detect when png is over with.
+
+> 
+> 5) Last : if(!a) is more complex than if(a) : invert the if/else.
+> 
+> Hope this helps.
+
+Yes! This helps a lot! Thanks a bunch Eric.
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
diff --git a/old/oldmail/200101.txt b/old/oldmail/200101.txt
new file mode 100644
index 0000000..ce8a8fb
--- /dev/null
+++ b/old/oldmail/200101.txt
@@ -0,0 +1,311 @@
+[Dillo-dev]Frames
+
+From: Sam Dennis <sam@ma...> - 2001-01-31 15:24
+
+Apologies to anyone who's thinking of working on frames, but I've started.
+
+Expect patches Very Soon.
+
+-- 
+Sam Dennis <sam@ma...>
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]0.4.0 devel-branch
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-01-29 23:55
+
+--------------------------------------
+This message is from Sebastian Geerken
+--------------------------------------
+
+Hi!
+
+Just a few words: The most important task is now to make 0.4.0
+stable, but in future there will also be a few enhancements, in speed
+and code structure (both esp. in dw_page.c).
+
+Livio, I tried to answer your question, but my mail got lost twice:
+> Recently I've inserted bug #116, to support ALT attributes in `img'
+> tags. Starting out the code, I realized that some of the needed
+> changes would go in dw_page.c and possibly html.c. Well I just read in
+> Allan's News, that Sebastian is planning to release his new Dw...
+>
+> Sebastian, have you done anything about the ALT attribute? And if
+> not should I wait a while for you to release what your doing before
+> trying to support ALT?
+
+There are the signal functions "enter_notify" and "leave_notify"
+which should be used for this. Just insert your code into
+Dw_image_enter_notify and Dw_image_leave_notify.
+
+Sebastian
+
+PS: Bugs No. 1002 and 1003 are no segfaults, I just forgot to change
+the menus in the form. 
+
+
+
+Re: [Dillo-dev]0.4.0 development branch
+
+From: Sam Dennis <sam@ma...> - 2001-01-29 18:29
+
+On Sun, Jan 28, 2001 at 10:30:46AM -0300, Jorge Arellano Cid wrote:
+> The new DwWidget will be the base for TABLE and FRAME support.
+> 
+> 
+> Any questions?, just ask!
+
+Er, just one, really. How will it actually be easier to implement tables and
+frames with the changes than without?
+
+-- 
+Sam Dennis <sam@ma...>
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+[Dillo-dev]0.4.0 development branch
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-01-28 13:36
+
+Hi there!
+
+
+It's been a long time without any posts, but dillo has
+continued evolving silently!
+
+The good news is that finally the new widget set (DwWidget),
+by Sebastian, is available from CVS. It is not yet the main
+branch, but we're strongly working to that goal. Just review the
+updated web site and you'll find the details.
+
+We need all our developing efforts concentrated in making this
+new branch, as stable and featured as dillo-0.3.1 in order to
+make a new release based upon it.
+
+The new DwWidget will be the base for TABLE and FRAME support.
+
+
+Any questions?, just ask!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]New Dw
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-01-11 16:29
+
+Sebastian,
+
+Finally I get news from you!!!
+(I know it is NOT your fault)
+
+
+> Ok, this is the fourth trial. There are a some news: the new Dw is
+> now up-to-date with dillo-0.3.1,
+
+Does it mean that it currently implements the same
+functionallity?
+
+> including the changes in dw_page.c
+> (esp. find text and image maps), and I ported the hruler and the
+> bullet widget.
+
+Good.
+
+------------
+
+> Hi Jorge,
+>
+> did you receive my mail from Dec 14 (which was already a copy of a
+> mail sent at Dec 12)? I send it again, since I know you have had
+> severe problems with your mail server.
+
+I never did receive one until now :(
+
+> ------
+>
+> Hi Jorge,
+>
+> I've come to a point where the new Dw has a final interface, and is
+> already usable enough (although buggy and a bit incomplete, and not
+> very well tested), from outside (e.g. the html parser) as well as for
+> someone who writes a new widget. Currently I'm reviewing the sources,
+> adding comments and writing some documentation. I plan to make this
+> state available for other dillo developers, together with comments
+> about current bugs.
+
+Yes, documentation is a big need because it constitutes
+everyone else's starting point. When you finish the documentation
+it will be the right moment to try the integration.
+
+> [...]
+> My changes outside of Dw are marginal, so coordination with the
+> official release should be possible simply by patches. Dw has mostly
+> been rewritten (except DwPage, but it was heavily modified), but I'll
+> try to include relevant modifications on the old Dw into the new one,
+> at every release (I won't regard the CVS versions).
+>
+> The reason I wrote this is the question "Tarball vs. CVS": I don't
+> have experiences in using CVS and think that updating a tarball from
+> time to time should work well enough. But I don't really prefer one
+> of both. A further problem is the coordination of the further work,
+> should e.g. the bug tracking engine be used? Anyway, I don't think
+> that the problems will be that big, because the work will continue in
+> a quite closed manner, until the Dw becomes part of the official
+> release.
+
+Well, my plan for the integration/polishing process is to
+freeze dillo development into a bux-fixing state (no new-feature
+additions), and try to work out the new Dw until it supports the
+same functionallity (or more) of the 0.3.1 release.
+
+Obviously we need the new-Dw to be potentially capable of
+undertaking all the required functionallity before we start
+merging.
+
+The idea behind this is to keep a single development branch (we
+have little manpower and past experiences had shown that is
+better to keep focused on a single tree...), and to emerge with a
+new source tree that includes the new-Dw and also provides the
+older features with at least the same stability degree that 0.3.1
+has now (that's the way I replaced the whole IO engine, the whole
+cache system, and also the way the new internal layers got into
+the code!).
+
+Once we start with this, we'll all be working the CVS tree
+(You and I with write access), and you reviewing the patches (if
+you accept, of course).
+
+On the coordination effort, I can easily set a new bug-track
+for the CVS branch, so once we finish producing the 0.4.0 release
+we can get back into the older one.
+
+Up to this point, the key questions are:
+
+Is the new Dw able to handle all the current functionallity?
+Is the new-Dw potentially able to handle tables and frames?
+Is it faster or slower than the current one?
+Do you foresee any problems if we start now?
+Is the documentation ready?
+Do you feel like taking responsibility for patch reviewing and
+integration for Dw related code, at least at this integration
+stage?
+
+
+Needless to say, I feel very motivated with this effort and I
+only hope that our scarce, but very appreciated developers join
+us in this big step!
+
+
+Sincerely
+Jorge.- 
+
+
+
+[Dillo-dev]New bug-track
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-01-10 23:36
+
+Hi,
+
+I just finished porting the bug-track to python and moving it
+to sourceforge; I hope this results in better response times for
+everyone.
+
+You may experiment some problems due to intermediate network
+caches. If you receive a message saying that the requested url
+doesn't exist (for a cgi), a simple reload of the previous page
+solves it! i.e. a single reload of the three links in Dbugtrack
+will solve the problem forever.
+
+Unfortunately, dillo does not perform end-to-end reload
+(BUG-64), so you'll need lynx or anyother to do the reloads. Once
+this is done you can keep using dillo.
+
+BTW: Bug-64 is very easy to hack-fix (a few sprinkled lines),
+but the plan is to fix the URL data-passing scheme with a view to
+have the required basis to solve a bunch of related problems
+(We are working with Livio on it).
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]jcid's nettaxi email account
+
+From: Sean 'Shaleh' Perry <shaleh@vi...> - 2001-01-09 04:02
+
+On 08-Jan-2001 Jorge Arellano Cid wrote:
+> 
+> Hi,
+> 
+> Unfortunately jcid*nettaxi.com seems to be down since the
+> first day of 2001; I can send but not receive any email there, if
+> anyone has sent me some emails this year, please resend them to
+> my jcid*ematic.com address.
+> 
+> I'll appreciate it very much because one of the things I
+> really dislike is to loose email, and appear as I'm the one that
+> doesn't answer them.
+> 
+
+I can hear the list and you just fine. 
+
+
+
+[Dillo-dev]jcid's nettaxi email account
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-01-09 00:57
+
+Hi,
+
+Unfortunately jcid*nettaxi.com seems to be down since the
+first day of 2001; I can send but not receive any email there, if
+anyone has sent me some emails this year, please resend them to
+my jcid*ematic.com address.
+
+I'll appreciate it very much because one of the things I
+really dislike is to loose email, and appear as I'm the one that
+doesn't answer them.
+
+
+Thank you very much.
+Jorge.- 
+
+
+
+[Dillo-dev]First post?
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-01-08 18:10
+
+Hi there!
+
+
+I hope you had enjoyed your Christmas and New year festivities.
+For those of us that remeain tuned (not on vacation yet), I would
+like to remind that dillo-0.3.1 was released and that its ready
+for download at the regular place.
+
+Well, it seems that this 2001 year has troubled computers a bit
+more than the so publicited Y2k. Some servers are working partly
+and frankly I don't know if our mailing list is up. BTW: I
+haven't received mail from developers since Dec 2000...
+Particularly, I want to contact Sebastian (I wrote hime twice
+before this mailing-list-try).
+
+Sourceforge still has problems with hit counters (page and
+downloads), but everything else seems fine.
+
+
+Cheers
+Jorge.- 
+
+
diff --git a/old/oldmail/200102.txt b/old/oldmail/200102.txt
new file mode 100644
index 0000000..92a7bf8
--- /dev/null
+++ b/old/oldmail/200102.txt
@@ -0,0 +1,1380 @@
+Re: [Dillo-dev]Bug #1015
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-27 21:42
+
+Hi,
+
+Solving this bug "quick and dirty" (not suitable for arbitrary nested
+widgets, only for this special case) works. I'm now developing a
+common solution.
+
+On Tue, Feb 27, 2001 at 05:27:22PM -0300, Jorge Arellano Cid wrote:
+> 
+> Sebastian,
+> 
+> > I've found the reason and I'm thinking about how to solve it best.
+> >
+> > A few details: When a widget within the page changes its size, this
+> > will (in an idle function) result in a call of
+> > a_Dw_widget_size_request for the page widget, and then
+> > a_Dw_widget_size_allocate, with the requisition becoming a part of
+> > the allocation. The latter checks whether the allocation has changed,
+> > and this is not always the case in the test page, since a few images
+> > cause the page to have its final size.
+> >
+> > So, the condition, when a_Dw_widget_size_allocate can omit sending
+> > the "size_allocate" signal, can be wrong in some cases.
+
+I forgot: emitting the "size_allocate" signal will call
+Dw_page_size_allocate, which then allocates the children. Without
+this, they have zero sizes. This was exactly the case.
+
+> It looks like the problem we have, but why it works sometimes?
+> Because the idle function can be triggered either before or after
+> the page allocation gets its final size? If this is true, then
+> we're very close to 0.4.0 release!
+
+(Actually the idle function may be triggered several times, depending
+on whether data is available from the Cache module or not.) The bug
+does not occur, when all image sizes get known at quite the same
+time. In this case, the idle function is called the last time, after
+the page widget knows the correct sizes of the image widgets.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Bug #1015
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-27 20:47
+
+Sebastian,
+
+> I've found the reason and I'm thinking about how to solve it best.
+>
+> A few details: When a widget within the page changes its size, this
+> will (in an idle function) result in a call of
+> a_Dw_widget_size_request for the page widget, and then
+> a_Dw_widget_size_allocate, with the requisition becoming a part of
+> the allocation. The latter checks whether the allocation has changed,
+> and this is not always the case in the test page, since a few images
+> cause the page to have its final size.
+>
+> So, the condition, when a_Dw_widget_size_allocate can omit sending
+> the "size_allocate" signal, can be wrong in some cases.
+
+It looks like the problem we have, but why it works sometimes?
+Because the idle function can be triggered either before or after
+the page allocation gets its final size? If this is true, then
+we're very close to 0.4.0 release!
+
+> PS: Jorge, what is the matter with your ematic account? I got a
+> failure notice mail, saying: "550 Command RCPT User
+> <jcid@em...> not OK".
+
+Ematic isn't very stable, I have some problems from time to
+time; if this persists, let me know and I'll switch back to
+nettaxi.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #1015
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-27 16:32
+
+Hi!
+
+On Fri, Feb 23, 2001 at 06:00:28PM +0100, Sebastian Geerken wrote:
+> [...]
+> I'll continue to investigate it.
+
+I've found the reason and I'm thinking about how to solve it best.
+
+A few details: When a widget within the page changes its size, this
+will (in an idle function) result in a call of
+a_Dw_widget_size_request for the page widget, and then
+a_Dw_widget_size_allocate, with the requisition becoming a part of
+the allocation. The latter checks whether the allocation has changed,
+and this is not always the case in the test page, since a few images
+cause the page to have its final size.
+
+So, the condition, when a_Dw_widget_size_allocate can omit sending
+the "size_allocate" signal, can be wrong in some cases.
+
+Sebastian
+
+PS: Jorge, what is the matter with your ematic account? I got a
+failure notice mail, saying: "550 Command RCPT User
+<jcid@em...> not OK". 
+
+
+
+Re: [Dillo-dev]Handling of style and script elements
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-27 12:27
+
+On Tue, 27 Feb 2001, Sam Dennis wrote:
+
+> > + DILLO_HTML_PARSE_MODE_STYLE,
+>
+> Do we really need two functionally identical parsing modes? Why not just use
+> DILLO_HTML_PARSE_MODE_SCRIPT?
+
+I agree, and with a short comment that states what _SCRIPT
+parsing mode is being used to.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Handling of style and script elements
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-27 11:06
+
+On Tue, Feb 27, 2001 at 12:24:21AM +0000, Sam Dennis wrote:
+> On Sun, Feb 25, 2001 at 08:55:50PM +0000, Mark McLoughlin wrote:
+> > diff -ur ./dillo-old/src/html.c ./dillo/src/html.c
+> > ...
+> > + /* spec suggests STYLE is only valid inside HEAD */
+> > + if (html->InTag != DILLO_HTML_IN_HEAD)
+> > + return;
+> 
+> The style tag may only be valid inside head, but that doesn't mean that we
+> shouldn't catch it elsewhere, especially as we're just ignoring the content
+> for now.
+> 
+> > + DILLO_HTML_PARSE_MODE_STYLE,
+> 
+> Do we really need two functionally identical parsing modes? Why not just use
+> DILLO_HTML_PARSE_MODE_SCRIPT?
+
+And call it DILLO_HTML_PARSE_MODE_IGNORE? The CSS parser will
+probably read the text from the stash, and in future, we will anyway
+need to ignore parts of the doc (e.g. <noscript>).
+
+Or divide between page writing modes (BODY and PRE) and stashing
+modes (STASH and VERBATIM), and let them be combinable:
+DILLO_HTML_PARSE_MODE_STASH | DILLO_HTML_PARSE_MODE_BODY instead of
+DILLO_HTML_PARSE_MODE_STASH_AND_BODY, and simple 0 for parts totally
+ignored.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Handling of style and script elements
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-27 11:06
+
+On Tue, Feb 27, 2001 at 09:43:26AM +0000, Mark McLoughlin wrote:
+> [...]
+> Also, does anyone have any advice on how I might hunt down BUG #1017?
+
+I don't know the Cache module in detail, but I guess that this bug is
+related to various other bugs in the mail bug-track (69 and 74) Jorge
+is working on.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Handling of style and script elements
+
+From: Mark McLoughlin <mark@cs...> - 2001-02-27 09:42
+
+On Tue, 27 Feb 2001, Sam Dennis wrote:
+
+> The style tag may only be valid inside head, but that doesn't mean that we
+> shouldn't catch it elsewhere, especially as we're just ignoring the content
+> for now.
+>
+> > + DILLO_HTML_PARSE_MODE_STYLE,
+>
+> Do we really need two functionally identical parsing modes? Why not just use
+> DILLO_HTML_PARSE_MODE_SCRIPT?
+
+true, very true. If it turns out that they become functionally different, that
+is the time to add in the new mode. Is the patch below better?
+
+Also, does anyone have any advice on how I might hunt down BUG #1017?
+
+Cheers,
+Mark
+
+=============================================================================
+diff -ur ./dillo-old/src/html.c ./dillo/src/html.c
+--- ./dillo-old/src/html.c Wed Feb 21 01:24:09 2001
++++ ./dillo/src/html.c Tue Feb 27 09:35:36 2001
+@@ -529,7 +529,8 @@
+g_free(Pword);
+}
+
+- if ( parse_mode == DILLO_HTML_PARSE_MODE_STASH ) return;
++ if ( parse_mode == DILLO_HTML_PARSE_MODE_STASH ||
++ parse_mode == DILLO_HTML_PARSE_MODE_SCRIPT ) return;
+
+if ( parse_mode == DILLO_HTML_PARSE_MODE_VERBATIM ){
+if (html->PrevWasCR)
+@@ -738,6 +739,27 @@
+}
+
+/*
++ * Handle open STYLE
++ * store the contents to the stash where (in the future) the style
++ * sheet interpreter can get it.
++ */
++static void Html_tag_open_style(DilloHtml *html, char *tag, gint tagsize)
++{
++ Html_push_tag(html, tag, tagsize);
++ Html_stash_init(html);
++ html->stack[html->stack_top].parse_mode = DILLO_HTML_PARSE_MODE_SCRIPT;
++}
++
++/*
++ * Handle close STYLE
++ */
++static void Html_tag_close_style(DilloHtml *html, char *tag, gint tagsize)
++{
++ /* eventually the stash will be sent to an interpreter for parsing */
++ Html_pop_tag(html, tag, tagsize);
++}
++
++/*
+* <BODY>
+*/
+static void Html_tag_open_body(DilloHtml *html, char *tag, gint tagsize)
+@@ -2503,7 +2525,7 @@
+TagFunct open, close;
+} TagInfo;
+
+-#define NTAGS 54
++#define NTAGS 55
+static TagInfo Tags[NTAGS] = {
+{"a", Html_tag_open_a, Html_tag_close_default}, /* 0 */
+/* abbr */
+@@ -2574,7 +2596,7 @@
+/* span */
+{"strike", Html_tag_open_strike, Html_tag_close_default},
+{"strong", Html_tag_open_strong, Html_tag_close_default},/* 42 */
+- /* style */
++ {"style", Html_tag_open_style, Html_tag_close_style},
+{"sub", Html_tag_open_sub, Html_tag_close_default},
+{"sup", Html_tag_open_sup, Html_tag_close_default},
+/* table */ 
+
+
+
+Re: [Dillo-dev]Handling of style and script elements
+
+From: Sam Dennis <sam@ma...> - 2001-02-27 00:19
+
+On Sun, Feb 25, 2001 at 08:55:50PM +0000, Mark McLoughlin wrote:
+> diff -ur ./dillo-old/src/html.c ./dillo/src/html.c
+> ...
+> + /* spec suggests STYLE is only valid inside HEAD */
+> + if (html->InTag != DILLO_HTML_IN_HEAD)
+> + return;
+
+The style tag may only be valid inside head, but that doesn't mean that we
+shouldn't catch it elsewhere, especially as we're just ignoring the content
+for now.
+
+> + DILLO_HTML_PARSE_MODE_STYLE,
+
+Do we really need two functionally identical parsing modes? Why not just use
+DILLO_HTML_PARSE_MODE_SCRIPT?
+
+-- 
+Sam Dennis <sam@ma...>
+"The strstr() function finds the first occurrence of the substring needle in
+the string haystack." 
+
+
+
+RE: [Dillo-dev]Handling of style and script elements
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-26 01:27
+
+Please make an entry in the bugtrack engine for this, with your email followed
+by '100%', and submit your patch to Jorge.
+This way we'll all keep in mind this has been fixed and avoid duplicate work.
+
+Eric
+
+-- En reponse de "[Dillo-dev]Handling of style and script elements" de Mark
+McLoughlin, le 25-Feb-2001 :
+> Hi all,
+> The html 4.01 spec says that style sheet info shouldn't
+> be displayed if the UA cannot handle it.. I think it can also
+> be assumed that the same is true for SCRIPT elements?
+> 
+> <quote>
+> The STYLE element allows authors to put style sheet rules in the head of
+> the document. HTML permits any number of STYLE elements in the HEAD section
+> of a document.
+> </quote>
+> 
+> Attached is a small patch to do this.
+> 
+> Cheers,
+> Mark
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 26-Feb-2001 a 10:26:40
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]Handling of style and script elements
+
+From: Mark McLoughlin <mark@cs...> - 2001-02-25 20:54
+
+Attachments: HandleStyleElementsAgainst_dillo-0.4.0.update      
+
+Apologies, forgot to take out my debugging info. Attached
+is the real patch ;)
+
+Cheers,
+Mark 
+
+
+
+[Dillo-dev]Handling of style and script elements
+
+From: Mark McLoughlin <mark@cs...> - 2001-02-25 20:33
+
+Attachments: HandleStyleElementsAgainst_dillo-0.4.0.patch      
+
+Hi all,
+The html 4.01 spec says that style sheet info shouldn't
+be displayed if the UA cannot handle it.. I think it can also
+be assumed that the same is true for SCRIPT elements?
+
+<quote>
+The STYLE element allows authors to put style sheet rules in the head of
+the document. HTML permits any number of STYLE elements in the HEAD section
+of a document.
+</quote>
+
+Attached is a small patch to do this.
+
+Cheers,
+Mark 
+
+
+
+RE: [Dillo-dev]Bug #1015
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-24 01:29
+
+Humm ... sometime the page (text only) aren't rendered at all. But it's quite
+rare and I can't reproduce it. Seems to occur at the first paint of a page, not
+when resizing or reloading from the cache. (not sure)
+'Can be the same bug then.
+
+-- En reponse de "[Dillo-dev]Bug #1015" de Sebastian Geerken, le 23-Feb-2001 :
+> Hi Jorge,
+> 
+> I don't know how much you traced down bug #1015, but I've looked a
+> bit at it:
+> 
+> 1. Anything in dw_image.c works fine, the images are created,
+> resized, and get a buffer with the image data.
+> 
+> 2. I've tested a modified version, where I added "width=10%" to
+> every <img>. In this case, the bug occurs, too, but after
+> resizing the window, all images are displayed.
+> 
+> Since in the latter case resizing works different, I guess that the
+> bug lies either in DwPage, or in the resize_queue code of DwWidget.
+> I'll continue to investigate it.
+> 
+> Sebastian
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Feb-2001 a 19:26:30
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Bug #1015
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-23 16:50
+
+Hi Jorge,
+
+I don't know how much you traced down bug #1015, but I've looked a
+bit at it:
+
+1. Anything in dw_image.c works fine, the images are created,
+resized, and get a buffer with the image data.
+
+2. I've tested a modified version, where I added "width=10%" to
+every <img>. In this case, the bug occurs, too, but after
+resizing the window, all images are displayed.
+
+Since in the latter case resizing works different, I guess that the
+bug lies either in DwPage, or in the resize_queue code of DwWidget.
+I'll continue to investigate it.
+
+Sebastian 
+
+
+
+[Dillo-dev]dillo-0.3.2 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-22 22:14
+
+Hi there!
+
+I just finished releasing the code that was in the 0.3.x
+branch. The new code is worth a download and it will probably be
+the last release before 0.4.0 comes out. So, go get it!
+
+Seriously, 0.4.0 is expected to be ready very soon, after
+BUG#1015 is nailed down, and a few more things get added.
+
+
+Cheers
+Jorge.-
+
+
+Ps: Bug#124 (problems compiling png code) was deleted because
+that's a matter of updating the png-library! 
+
+
+
+Re: [Dillo-dev]Menubar & Preferences
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-21 18:58
+
+On Mon, Feb 19, 2001 at 12:49:18PM +0100, Bruno Widmann wrote:
+> 
+> I would love to have a way to quickly change certain
+> preferences Items while dillo is running (eg. force_my_colors).
+> [...] 
+> I would like to add code in dillo for such a Settings menu if nobody
+> raises some serious objections..
+
+Currently, Dw provides no possibility to change change the look of a
+widget (colors, fonts etc.) dynamically. I plan this as a part of the
+common style mechanism (it will e.g. be *one* - probably the simplest
+- step towards an implementation of asynchronously read HTML and
+CSS), but the design and implementation will take a while. So you
+could
+
+1. reread the page from the cache (will be quite fast), or
+2. write a hack to change some values in the DwPage etc, and then
+request a redraw (this would, of course, be a subject of
+change), or
+3. you start the style mechanism ;-).
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Menubar & Preferences
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-20 02:40
+
+Instead of a menu, what do you think of checkboxes in the buttons bar, say
+beside the progress bars ?
+Please keep a room for "run animations".
+
+I like the load images thing, I only hope there will be a default widget in
+place of each unloaded images should be (with a "download image" in an image
+popup-menu ?)
+
+Eric
+
+-- En reponse de "[Dillo-dev]Menubar & Preferences" de Bruno Widmann, le
+19-Feb-2001 :
+> 
+> I would love to have a way to quickly change certain
+> preferences Items while dillo is running (eg. force_my_colors).
+> 
+> I think that the Galeon browser (and also konqueror) has a good way
+> to handle it. A "Settings" Menu in the main Menubar which looks
+> like:
+> 
+> __________________________
+> ... Settings ...
+> ---+--------------------+-
+> | Load images >|
+> | [ ] Use own fonts |
+> | [ ] Use own colors |
+> | [x] other items.. |
+> |--------------------|
+> | Preferences... |
+> `--------------------'
+> 
+> So if you can't read the text on some webpage because of a bad BG
+> color you just bring up the Settings Menu and have solved the
+> problem with two mouseclicks.
+> 
+> I would like to add code in dillo for such a Settings menu if nobody
+> raises some serious objections..
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 20-Feb-2001 a 11:32:01
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Menubar & Preferences
+
+From: Bruno Widmann <bwidmann@ut...> - 2001-02-19 11:48
+
+I would love to have a way to quickly change certain
+preferences Items while dillo is running (eg. force_my_colors).
+
+I think that the Galeon browser (and also konqueror) has a good way
+to handle it. A "Settings" Menu in the main Menubar which looks
+like:
+
+__________________________
+... Settings ...
+---+--------------------+-
+| Load images >|
+| [ ] Use own fonts |
+| [ ] Use own colors |
+| [x] other items.. |
+|--------------------|
+| Preferences... |
+`--------------------'
+
+So if you can't read the text on some webpage because of a bad BG
+color you just bring up the Settings Menu and have solved the
+problem with two mouseclicks.
+
+I would like to add code in dillo for such a Settings menu if nobody
+raises some serious objections.. 
+
+
+
+[Dillo-dev]Font factor
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-18 13:50
+
+Hi there!
+
+
+Sometime ago (not much) I included a patch from Bruno, in the
+040 branch, that allows a font-factor in dillorc to scale font
+sizes in dillo.
+
+I've been playing around with it for some time and frankly,
+I'm very happy. Just download the latest CVS (or the updated
+tarball), test it and enjoy!
+
+I know that FONT size is an issue, specially with high
+screen resolutions, and bad eyes :-).
+
+Ah, some of you may notice that it would be nice to have a
+chance to change font-size on the fly, but let's wait until the
+preferences plugin can handle that...
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Getting 040 branch by CVS
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-18 11:59
+
+EG wrote:
+> [...]
+> Dillo is actually rendering the page correctly if the window is large enough,
+> which is not the case with the default size.
+
+This is a bug ;-)
+
+> It seems that dillo's having problems computing a _new_ page width when <pre>
+> text is larger than the window. Once the longest line have been fully rendered
+> by enlarging the window, shrinking it will make hsliders show when necessary.
+
+This bug occurs in indented lines, the real_width is not calculated
+correctly. Following seems to work (in Dw_page_new_word):
+
+if (new_line)
+page->real_width = MAX(page->real_width,
+line->x_size + Attr->left_indent_first);
+
+instead of
+
+if (new_line)
+page->real_width = MAX(page->real_width, line->x_size);
+
+Expect an upload soon.
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Getting 040 branch by CVS
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-18 02:06
+
+-- En reponse de "[Dillo-dev]Getting 040 branch by CVS" de Jorge Arellano Cid,
+le 18-Feb-2001 :
+> 
+> Hi there!
+> 
+> 
+> The new branch is showing excelent progress and is very close
+> to a new release.
+> 
+> Well, I just fixed a mistake on the directions for anonymous
+> downloading using CVS. I checked it also, but note that dillo
+> doesn't render the page right; you have been warned.
+> 
+
+Dillo is actually rendering the page correctly if the window is large enough,
+which is not the case with the default size.
+It seems that dillo's having problems computing a _new_ page width when <pre>
+text is larger than the window. Once the longest line have been fully rendered
+by enlarging the window, shrinking it will make hsliders show when necessary.
+
+> 
+> Cheers
+> Jorge.-
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 18-Feb-2001 a 11:01:57
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Getting 040 branch by CVS
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-18 00:32
+
+Hi there!
+
+
+The new branch is showing excelent progress and is very close
+to a new release.
+
+Well, I just fixed a mistake on the directions for anonymous
+downloading using CVS. I checked it also, but note that dillo
+doesn't render the page right; you have been warned.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]misc on Dw
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-16 11:19
+
+Jörgen Viksell wrote:
+> BTW, I have some code that moves DwPageWord down to DwPage and just defines 
+> the position in DwPageLine. It makes rewraps a bit faster. Is it something 
+> to continue to work on?
+
+Yes, definitely! I also planned this, and Allan wrote me once about
+this, too. This will not only speed up rewrapping, but also make it
+simpler in future to refer to single words. Send me your patch when
+it is usable.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]misc on Dw
+
+From: Jörgen Viksell <vsksga@ho...> - 2001-02-16 00:44
+
+>Just a few thoughts which I think are worth to share:
+>
+>- While working on bugs #1011 and #1012 (these are identical),
+
+I must have submitted #1012 a couple of seconds after You. Sorry about that! 
+;-)
+
+>- To make all the stuff with attributes and GC's simpler, I thought
+> of a common style scheme, similar to GtkStyle, or CSS styles. There
+> should be a structure DwStyle, which contains attributes and X
+> resources (fonts, colors, GC's) for drawing in a specific way. The
+> creation of such structures should be optimized in that way, that
+> several widgets, words etc. may share the same DwStyle. Memory
+> management could be done simply by reference counters.
+
+A while ago I made an experiment with adding a GC to each DwPageWord. That 
+made my poor computer reboot. So I definitly agree on the sharing! :-)
+
+BTW, I have some code that moves DwPageWord down to DwPage and just defines 
+the position in DwPageLine. It makes rewraps a bit faster. Is it something 
+to continue to work on?
+
+// Jörgen
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+[Dillo-dev]misc on Dw
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-15 13:00
+
+Hi!
+
+Just a few thoughts which I think are worth to share:
+
+- While working on bugs #1011 and #1012 (these are identical), I'm
+also trying to untie Dw from the rest of the code. The code for
+context menus etc. is not anymore inside dw_page.c, but in html.c,
+and they are connected via Gtk+ signals. This will e.g. make unit
+tests easier.
+
+- I'll probably also put the code for image maps into the image
+widget, and the <map>'s will move into the html linkblock.
+
+And two ideas for the future (after the 0.4.0 release):
+
+- Like the old Dw, the page flickers quite much while being loaded. A
+possible solution could be the use of pixmap buffers, so the
+viewport hasn't to be cleared before the redraw.
+
+- To make all the stuff with attributes and GC's simpler, I thought
+of a common style scheme, similar to GtkStyle, or CSS styles. There
+should be a structure DwStyle, which contains attributes and X
+resources (fonts, colors, GC's) for drawing in a specific way. The
+creation of such structures should be optimized in that way, that
+several widgets, words etc. may share the same DwStyle. Memory
+management could be done simply by reference counters.
+
+Furthermore, I think it is useful to distinguish between (i) look
+and (ii) behavior, e.g. a link is something which is (i) blue and
+underlined, and (ii) causes something to happen when you click on
+it. According to (ii), a link could also be used for a possible
+implementation of the <label> tag: if you click on the <label>,
+this event is delivered to the form element specified by the "for"
+attribute. (This is only a silly example, I admit that would huge
+changes in the code were necessary for this. And I don't plan a
+common "behavior scheme" in the near future.)
+
+Any comments? Further ideas? Disagreements?
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-02-14 17:36
+
+Hi,
+
+I hope this mail will arrive the list :-/
+
+Jörgen Viksell writes:
+>I am wondering about a related issue.
+>If You imagine a rectangle around all rendered text. You can't click outside 
+>of that area.
+>In the case of bug #1009 or a page that Dillo can't render, it's impossible 
+>to right click and view the source to determine the problem.
+
+This is the correct behavior of the DwWidget (will e.g. be needed for
+tables). Instead, the button press event should be connected to the
+viewport. I'm working on it.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Just a word about bug #1009
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-13 01:44
+
+-- En reponse de "Re: [Dillo-dev]Just a word about bug #1009" de Livio Baldini
+Soares, le 12-Feb-2001 :
+> Hi Eric!
+> 
+> Eric GAUDET writes:
+>> Ok, my previous patch for bug#1009 and so has problems sometimes. I think
+>> this
+>> one is better:
+> 
+> 
+> This is why I love open-source! You come up with a minimal trace of
+> the problem, and in the next day, someone already has a working patch
+> to fix it!
+> 
+> Nice work!
+> 
+
+That's what you call working around the clock ! ;-)
+
+> By the way the page in
+> http://www.rti-zone.org/dillo/Html.testsuite/jorge/A_tag.html has a
+> missing <BODY> tag after </HEAD>, but I don't know if that's not there
+> on purpose...
+> 
+
+That's because Jorge's pages are mostly live pages (pages he found on the net
+"as-is", not corrected), wether mine are built page where every mistake is made
+on purpose ;-) (there's faulty pages in the testsuite to test missing tags such
+as <body>)
+Anyway, Dillo's great at ignoring such problems.
+
+> best regards,
+> 
+> -- 
+> Livio <livio@li...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 13-Feb-2001 a 10:41:38
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]Just a word about bug #1009
+
+From: Livio Baldini Soares <livio@li...> - 2001-02-12 17:11
+
+Hi Eric!
+
+Eric GAUDET writes:
+> Ok, my previous patch for bug#1009 and so has problems sometimes. I think this
+> one is better:
+
+
+This is why I love open-source! You come up with a minimal trace of
+the problem, and in the next day, someone already has a working patch
+to fix it!
+
+Nice work!
+
+By the way the page in
+http://www.rti-zone.org/dillo/Html.testsuite/jorge/A_tag.html has a
+missing <BODY> tag after </HEAD>, but I don't know if that's not there
+on purpose...
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-12 15:39
+
+-- En reponse de "RE: [Dillo-dev]Just a word about bug #1009" de Jvrgen
+Viksell, le 12-Feb-2001 :
+>>Ok, my previous patch for bug#1009 and so has problems sometimes. I think 
+>>this
+>>one is better:
+> <snip>
+> 
+> Works great here!
+> 
+> I am wondering about a related issue.
+> If You imagine a rectangle around all rendered text. You can't click outside 
+> of that area.
+> In the case of bug #1009 or a page that Dillo can't render, it's impossible 
+> to right click and view the source to determine the problem.
+> 
+
+You're right: there's definitely a problem here. please make a bug entry for
+this.
+
+> Cheers,
+> Jvrgen
+> _________________________________________________________________________
+> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 13-Feb-2001 a 00:39:15
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Jörgen Viksell <vsksga@ho...> - 2001-02-12 15:04
+
+>Ok, my previous patch for bug#1009 and so has problems sometimes. I think 
+>this
+>one is better:
+<snip>
+
+Works great here!
+
+I am wondering about a related issue.
+If You imagine a rectangle around all rendered text. You can't click outside 
+of that area.
+In the case of bug #1009 or a page that Dillo can't render, it's impossible 
+to right click and view the source to determine the problem.
+
+Cheers,
+Jörgen
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-12 14:01
+
+Attachments: patch.dillo-0.4.0pl2.bug#1009.2      
+
+Ok, my previous patch for bug#1009 and so has problems sometimes. I think this
+one is better:
+
+--- dillo-0.4.0pl2/src/dw_page.c Tue Feb 6 23:44:05 2001
++++ dillo-0.4.0pl2.bug#1009/src/dw_page.c Mon Feb 12 22:58:09 2001
+@@ -782,6 +783,9 @@ static void Dw_page_rewrap(DwPage *page)
+g_free(old_line->words);
+}
+g_free(old_lines);
++
++ if(page->num_lines == 1)
++ page->real_width = page->lines[0].x_size;
+}
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Feb-2001 a 23:00:06
+"In theory, there's no difference between theory and
+practice; in practice, there is.
+------------------------------------ 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-12 09:11
+
+Attachments: patch.dillo-0.4.0pl2.bug#1009      
+
+Ok, here's a patch for fixing bug#1009 and bug#1010 and bugs related to 1-line
+painting.
+I'm not sure it's the right way to do this, because I didn't look very closely
+to new_line and new_word pages, and it's quite possible I don't understand
+everything in this code.
+Anyway it seems better to compute real_witdh in new_line, after each line, than
+in new_word, after some strange tests of new_line being either hard or soft.
+
+cheers,
+Eric
+
+--- dillo-0.4.0pl2/src/dw_page.c Tue Feb 6 23:44:05 2001
++++ dillo-0.4.0pl2.bug#1009/src/dw_page.c Mon Feb 12 17:57:29 2001
+@@ -628,9 +628,6 @@ static DwPageWord *Dw_page_new_word(DwPa
+new_line = TRUE;
+}
+}
+- 
+- if (new_line)
+- page->real_width = MAX(page->real_width, line->x_size);
+}
+
+if (new_line) {
+@@ -775,6 +772,8 @@ static void Dw_page_rewrap(DwPage *page)
+} 
+}
+
++ page->real_width = MAX(page->real_width,
+page->lines[page->num_lines-1].x_size);
++
+if (old_line->hard) {
+a_Dw_page_linebreak(page);
+page->lines[page->num_lines - 1].y_space = old_line->y_space;
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Feb-2001 a 17:59:23
+"In theory, there's no difference between theory and
+practice; in practice, there is.
+------------------------------------ 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-12 08:23
+
+Ok, I've been testing a lot, and it appears that two bugs #1009 and #1010
+didn't exist in the first release of dillo 'Dw-040' tarball (d040b.tgz). 
+There was almost no change in html.c between d040b and d040d2.
+The only major difference I see is the change in the scrollers code, which is
+closely related to the pagemarks Livio was talking about: I think the page is
+parsed correctly, but for whatever reason it never paints. Or it paints but the
+scrollers are not initialized correctly and the page is painted outside the
+visible area of the viewport (but then we should be able to have a popup menu
+to see the source, and we don't, so it's probably not that).
+Anyway, I think the changes in the scroller code removed some important init
+(or miss some that weren't needed before). And it seems that a single pagemark
+(called by a H tag) or anchor does what's needed so the init is done.
+Sebastian, do you have a clue ?
+
+... hum ... maybe it's not that after all. Let's try this:
+<html>
+Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla
+</html>
+
+The page isn't drawn ... because the text fits on only one line ! Just resize
+the browser so the text is rewrapped in a second line, and the text is painted
+!!
+
+... more on this in a couple of hours ;-)
+
+
+-- En reponse de "RE: [Dillo-dev]Just a word about bug #1009" de Eric GAUDET,
+le 12-Feb-2001 :
+> 
+> All these pages are very look-alike. It seems that not all html tags do
+> what's
+> needed for the page to render. As you noticed, H1 seems to do the job! I'm
+> investigating this right now.
+> ... more on this in a couple of hours ;-)
+> 
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Feb-2001 a 16:50:24
+"In theory, there's no difference between theory and
+practice; in practice, there is.
+------------------------------------ 
+
+
+
+RE: [Dillo-dev]Just a word about bug #1009
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-12 07:26
+
+-- En reponse de "[Dillo-dev]Just a word about bug #1009" de Livio Baldini
+Soares, le 12-Feb-2001 :
+> Hi guys!
+> 
+Hi Livio, good to see you again.
+
+...
+> 
+> Just a thought about bug #1009; the bug doesn't seem to be related
+> to A-tag splitting, but worst. CVS Dw-040 doesn't even render this
+> page:
+> 
+> ----------------
+> <html>
+> <body>
+> Hello!
+> </body>
+> </html>
+> -----------------
+> 
+...
+> 
+> I can't yet tell what this means, but by the looks of things,
+> something's not being initialized correctly and that's why a "simple"
+> HTML (without <h1>, etc) doesn't render correctly. I'm pretty sure
+> that's what's causing bug #1009, and not the A-tag splitting suggested
+> in that bug report.
+> 
+
+Since you found that, I think this is _exactly_ the same with bug#1010 ! (I did
+the two entries for these bugs, only by looking at each page of the testsuite,
+no investigation in the sources)
+I did a corrected version of A_tag.html, the page that gives errors for
+bug#1009, and the bug remains.
+(see all sources of this pages at the end of this mail)
+
+All these pages are very look-alike. It seems that not all html tags do what's
+needed for the page to render. As you noticed, H1 seems to do the job! I'm
+investigating this right now.
+... more on this in a couple of hours ;-)
+
+
+
+PS: Here are the involved pages source:
+BUG#1009:(jorge/A_tag.html)
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+<TITLE>Test Page for Apache Installation on Web Site</TITLE>
+</HEAD>
+<P>
+The Apache
+<A
+HREF="manual/index.html"
+>documentation</A>
+has been included with this distribution.
+</P>
+</BODY>
+</HTML>
+
+BUG#1010:(jorge/fool_raw.html)
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<BODY>
+<IMG SRC="maj00s.gif">
+</BODY>
+
+Corrected page:(jorge/A_tag2.html)
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+<TITLE>Test Page for Apache Installation on Web Site</TITLE>
+</HEAD>
+<P>
+The Apache
+<A HREF="manual/index.html">documentation</A>
+has been included with this distribution.
+</P>
+</BODY>
+</HTML>
+
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Feb-2001 a 16:10:37
+"In theory, there's no difference between theory and
+practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Just a word about bug #1009
+
+From: Livio Baldini Soares <livio@li...> - 2001-02-12 05:07
+
+Hi guys!
+
+I'm sorry about the long time absent, but I ran into some time
+consuming problems, and I think I'm finally getting rid of them. In a
+while (less then a month), I'll have some time to put into Dillo.
+
+Just a thought about bug #1009; the bug doesn't seem to be related
+to A-tag splitting, but worst. CVS Dw-040 doesn't even render this
+page:
+
+----------------
+<html>
+<body>
+Hello!
+</body>
+</html>
+-----------------
+
+But strangely adding a loose <h1> will fix things up. So this page
+Dillo will render ok:
+
+-----------
+<html>
+<body>
+Hello!
+<h1>
+</body>
+</html>
+-----------
+
+Strange, eh? I've tracked down to a call in H1 which makes the
+`Hello!' show.
+
+It seems to be the a_Menu_pagemarks_add() in
+html.c:Html_tag_open_h:(around line 766).
+
+Which calls a_Dw_page_add_anchor() in
+menu.c:a_Menu_pagemarks_add:(around line 261).
+
+And then inside in a_Dw_page_add_anchor, the "important" call seems to
+be Dw_page_new_word() (which is too long for me to trace tonight...)
+
+I can't yet tell what this means, but by the looks of things,
+something's not being initialized correctly and that's why a "simple"
+HTML (without <h1>, etc) doesn't render correctly. I'm pretty sure
+that's what's causing bug #1009, and not the A-tag splitting suggested
+in that bug report.
+
+Any one got any ideas? I'm too tired and sleepy to think
+anymore... when I have time I'll take a better look.
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Readings
+
+From: Eric GAUDET <egaudet@in...> - 2001-02-09 03:57
+
+This was on slashdot, but I think everyone of us wants to read what a good
+browser should do:
+
+http://www.w3.org/TR/2001/NOTE-cuap-20010206
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 09-Feb-2001 a 12:55:22
+"I remember Y1K, every abacus had to get another bead"
+------------------------------------ 
+
+
+
+[Dillo-dev]Dw [Message from Sebastian]
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-07 01:39
+
+Hi!
+
+A few words about two bugs:
+
+- Bug #1007 seems to be a bug of Gtk+ (tested with version 1.2.8),
+not of Dw. I've attached an example which demonstrates it. Button
+"baz" has a position > 2**31, and isn't focusable correctly.
+
+I'll submit this bug to the the Gtk+ developers, and perhaps think
+about a workaround or so.
+
+- Bug #1006 is somehow caused by the decrease of the width when the
+right scrollbar appears (this will change the allocation of the
+viewport). I've committed a workaround which sets the right
+scrollbar always visible, so this problem does not occur, but I
+think, there should be a better solution. A starting point for
+someone who wants to examine this bug, is to add some debug
+messages into Dw_gtk_size_allocate.
+
+And I've commented the line to connect the "key_press_event" signal
+of the URI location entry, so you can only scroll the viewport by
+keys by focusing it. It is simple to deactivate the old
+functionality, and, unlike in 0.3.1, focusing the viewport by keys
+works. This breaks a bit the "standard behavior" of Gtk+ GUIs, so
+what is your opinion about it?
+
+Sebastian 
+
+
+
+[Dillo-dev]Re: about dillo + libc5 (fwd)
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-02-05 13:28
+
+Hi,
+
+I'm answering this email to the list because I received it twice...
+
+Jorge.-
+
+---------- Forwarded message ----------
+Date: Thu, 1 Feb 2001 18:59:34 -0300 (CLST)
+From: Jorge Arellano Cid <jcid@in...>
+To: nikolaos roumbos <nikroub@ho...>
+Subject: Re: about dillo + libc5
+
+
+Nikolaos,
+
+Hi, I noticed you in the mailing list a long time ago, and now
+you show!
+
+> Hi my name is nikos
+> and i'm writting you from athens, greece.I'm following dillo since last
+> summer, in fact i subscribed to the list in the middle of july
+> and as this is the first time that i'm contacting with someone from this
+> project i would like to say a grate bravo to all of you for this application
+> and espacially to you the hard maintainer.
+
+Thanks indeed.
+
+> I count myself quite familiar with dillo but in general i'm supposed to be a
+> newby in the Linux world.
+> Recently i managed to compile dillo-0.3.0 statically under Red Hat 6.0 which
+> is a libc6 distribution, and afterwards i've ported it in a custom tiny
+> distribution supported with libc5 libraries.
+> Everything works fine except that dillo can't resolve domain names, it works
+> only if i give in the url entry IP adresses.
+> For example it can't resolve http://localhost but works fine
+> with http://127.0.0.1.
+> Today i found out that the problem is in the source file
+> dns.c. I commented out line 47 (as you mention in the readme file)
+> and compiled dillo but a get an error in dns.c in fuction "Dns_server".
+> My question is if it's possible to compile dillo with libc6
+> now that i've edited dns.c and then port it to a libc5 distribution,
+> or should i to compile it in libc5 distribution so as to work
+> with a libc5 distribution.
+
+OK, several things:
+
+- Use 0.3.1 or even better, the 0.3.2-pre from CVS. This will
+not solve your problem, but you'll get a better dillo ;-)
+
+- You have problems because libc5 and libc6 differ in the
+domain resolving function (reentrancy) concerns.
+
+There're two ways around it:
+
+I) Statically compile your version in a libc5 system
+(Define: G_DNS_THREADED and LIBC5; lines 46 and 51)
+or
+
+II) Leave line 46 uncommented and set 1 server on line 56.
+(and compile as you explained)
+
+Of both I) is better cause you'll have a multiple channel
+(faster) dns solver. With II) it will work but somewhat slower.
+
+
+
+> Your help will be valuable.
+> Thanks in advance, and keep up this grate work.
+
+Hope this helps
+Jorge.- 
+
+
diff --git a/old/oldmail/200103.txt b/old/oldmail/200103.txt
new file mode 100644
index 0000000..ed715a4
--- /dev/null
+++ b/old/oldmail/200103.txt
@@ -0,0 +1,1492 @@
+[Dillo-dev]Dpi1 Development
+
+From: <sirver@gm...> - 2001-03-31 23:06
+
+Attachments: dpi1.first.test.tar.gz      
+
+Hi there,
+
+i started implementing the dpi1 plugins.
+With the patch and the files included in the tar.gz (is it ok to attach
+files on this list, when they <50k ??) dillo searches the paths
+"(all listed in rcfile under plugins_dirs):~/.dillo/plugins:/usr/local/share/dillo/plugins" for files named *.dpi1. Those are treated as plugins.
+the plugin engine already registers Prefix plugins.
+I also included DNS support throu dillo (for caching).
+I ran into problems with HTML output: a dpiSendData should have some
+HTML tags in his data field. Now, dillo should read them and treat them
+like a normal HTML site. I tried this (see the Answer_handling
+functions), but dillo coredumps (in cache.c, callback function). I don't
+know why and how to change this. Do somebody know a better/working way?
+In the attachement ist also a perl script which is my testing plugin. I
+hope it will help you.
+
+Thanks.
+Holger 
+
+
+
+Re: [Dillo-dev]Font modifying tags
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-31 13:14
+
+Hi,
+
+I intended to post this in a few days, since I'm currently working on
+attributes. I wondered what has happened with the implementation of
+the <font> tag.
+
+I'll soon upload a few changes, which are a first simple step towards
+my (currently still a bit vague) idea of a common style scheme. Some
+time ago, Sean posted a problem to the list: handling lists of fonts
+(as "Arial, Helvetica, sans-serif") is quite difficult with the
+current code. This will solved by the change, the font loading code
+will be rewritten to handle lists quite simply.
+
+More on this after finishing the code, and please look at the changes
+in a few days.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Update on Alt patch
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-31 13:14
+
+Hi,
+
+I've committed the patch, after making some changes, extensions, and
+cleanups:
+
+- I've made an own submodule of it, so it can be also used for
+other purposes.
+
+- I copied the drawing code from gtktooltip.c, so the tooltips look
+(but do not behave) exactly like Gtk+ tooltips. This includes
+drawing functions and tooltip size.
+
+I also fixed two bugs in Dw:
+
+1. It sometimes happened that a leave_notify "event" was sent to a
+widget already destroyed.
+
+2. Crossing events of the viewport are now recognized (this was
+mentioned as a "todo" in the sources).
+
+On Fri, Mar 30, Livio Baldini Soares wrote:
+> [...]
+> * I tried adding a Dw_image_destroy function, and in the end adding a
+> parent_class->destroy (initializing parent_class in
+> Dw_image_class_init), but I must have done something wrong because I
+> couldn't get it to work... all I got was Segmentation Fault :-(
+
+This may also have been by the first bug I mentioned above?
+
+> [...]
+> * Now to tooltip "feels" better. It takes almost one second to appear
+> (if the cursor is stoped), and it will disappear immediately when
+> you move it.
+
+I changed the delay to 500 ms, this is the standard of Gtk+.
+
+> Well I think that's all. The only problem (at least in my opinion)
+> is that the placement of the tooltip inside the image should be better
+> chosen then (x+10, y+10) like I currently do. I looked at
+> gtktooltips.c and it kind of sucks (at least this part about chosing
+> tooltip position). It considers that widget's size is small, but
+> working with images is a totally diferent issue (they are too big, and
+> can sometimes cover up more than half the screen, and in these case
+> Gtk's toolips do badly).
+
+Yes, this is true. I did not change it, since I don't have a better
+idea.
+
+On Fri, Mar 30, Jorge Arellano Cid wrote:
+> [...]
+> - ALT for the IMG element is an alternative for non visual user
+> agents. i.e. there's no need to show the ALT text and the image.
+> I know that some users like it, just add the necessary toggle in
+> dillorc and send me the patch when done.
+
+Yes, the tooltip implementation is indeed not what ALT is intended
+for. Nevertheless the code might be used for other purposes, and the
+changes in dw_image.c are minimal.
+
+However, ALT may also used by visual user agents, e.g. the text could
+be drawn before the image data is retrieved, what is especially useful
+if the image URI is broken.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Bug #116 (alt tags for images)
+
+From: Livio Baldini Soares <livio@li...> - 2001-03-31 08:46
+
+Hi Jorge and all!
+
+Jorge Arellano Cid writes:
+> 
+> Hi,
+> 
+> This issue seems to be almost done, but I just wanted to add a
+> couple of comments:
+> 
+> - ALT for the IMG element is an alternative for non visual user
+> agents. i.e. there's no need to show the ALT text and the image.
+> I know that some users like it, just add the necessary toggle in
+> dillorc and send me the patch when done.
+
+Ok, done! New features are:
+
+* "show_alt"=[Yes/No] option in dillorc as preference.
+
+* Fixed Dw_image_motion_notify() return value. Seems that I had to
+return FALSE and not TRUE, otherwise I could break the detection of
+motion events of other widgets which you need them (like in
+viewport, to detect if there's motion in an image which is also a
+link, and therefore draw a "hand" cursor).
+
+* Finally got right the Dw_image_destroy() function. The problem I had
+before was that was freeing image->buffer, but, as I saw later,
+that's a pointer to a Dicache entry :-(
+
+> - The Cache is not related to widget allocations/deallocations,
+> it just caches URL contents, and nothing else!
+
+Yes, you're right! Thanks for the tip.
+
+I've sent my patch to Jorge, but the eager ones can always get my
+Dillo patches at: http://www.linux.ime.usp.br/~livio/dillo/
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Re: Dillo UI
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:50
+
+Terry,
+
+> Jorge:
+>
+> You seem to be the man in charge...
+>
+> Below is a quick, _clean_ addition to the UI that is half of what Dillo is
+> missing. It adds four lines to the
+> file menu.c,
+> function a_Menu_popup_new,
+> line 177:
+>
+> This adds Ctrl-H and Alt-H as Back and Forward hot keys:
+>
+> Menu_add(menu, "Back", "<ctrl>H", bw,
+> a_Commands_back_callback, bw);
+> Menu_add(menu, "Forward", "<alt>H", bw,
+> a_Commands_forw_callback, bw);
+>
+> This was a 'quick' fix and took at least several hours to track down. Could
+> NOT figure out how to get that fscking BackSpace key to work so I used Ctrl-H
+> instead. Hint hint :-)
+
+I'll check that and try to find out a mnemonic key combination
+(Maybe Ctrl + '<' and Ctrl + '>') Please be patient because I'm
+working on several areas...
+
+
+> The other thing that is needed from a basic UI perspective is for the Web page
+> position to be stacked for recall upon return. Really hate it when I have a
+> 1/4 meg web page up, am half way down it, hit a link and then have to find
+> where I was all over again after a Back operation. I would contemplate trying
+> to fix it, but in view of how long it took just to add a
+> couple of accelerator keys,
+> you guys will have it fixed before I could even figure it out. But all of this
+> is just a
+> _minor_ quibble.
+
+Yes, this has being going in my mind from a long time too.
+I think a good implementation is to keep the vertical scrolling
+position within the history record (within the URL structure that
+we're working with Livio). From there it will be a simple matter
+to implement. We're working on it now. BTW: I'll try to answer
+Livio's request tomorrow (Yes Livio, I've made some progress!).
+
+
+> Really Fine Work! This is what a browser is supposed to be. Don' need no
+> steenkin' key clicks, this is fast enough to make its own sonic crack (Slack
+> 7.05 [7.0+2.2.18 kernel] 233Mhz PIII, 64 Meg RAM). Keep up the good work, and
+> the speed, and the small size and...oh what the hell, _keep_ producing a
+> miracle.
+>
+> Regards,
+> Terry Loveall
+
+Thanks a lot for your comments Terry.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Re: dillo
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:49
+
+Jon,
+
+> Hello, I've been using dillo for the past couple of months. The dillo
+> browser is absolutely great, it does not crash, and it is very fast on any
+> machine I run it on. I beleive the 0.4.0 version is more stable then my
+> netscape.
+>
+> I just thought I'd put in a good word for the browser because I like it
+> alot. One thing I'd like to see, although, is a way to use the mailto:
+> command. I use Balsa GNOME email client, it has a command to just bring up
+> a 'new message' and let you compose. The command is 'balsa
+> --compose=user@ho...' the entire program does not come up, just the 'new
+> message' window... Would it not be easy enough to add this feature to
+> dillo, allowing to write a responce to a mailto:?
+
+It will be easy when plugins get implemented. A simple task
+really. We're working on the plugins implementattion, and I hope
+it to begin working soon, at least with the basic functionality.
+You'll have to wait until then.
+
+> Thanks again for creating the dillo browser!
+
+You're welcome.
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug #116 (alt tags for images)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:49
+
+Hi,
+
+This issue seems to be almost done, but I just wanted to add a
+couple of comments:
+
+- ALT for the IMG element is an alternative for non visual user
+agents. i.e. there's no need to show the ALT text and the image.
+I know that some users like it, just add the necessary toggle in
+dillorc and send me the patch when done.
+
+- The Cache is not related to widget allocations/deallocations,
+it just caches URL contents, and nothing else!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]IO progress
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:49
+
+Hi again,
+
+The last weeks I've been trying to devote most of my time to
+finishing the IO engine error control design. This had been a
+several times procrastinated task, and I wish to push it forward
+as much as I can this time.
+
+The good news is that I've progressed a lot. The whole
+querying branch of the browser has been checked, re-structured
+and modified to integrate the concomitant control-chain (CCC)
+that manages and defines all the data-passing and messaging
+between modules.
+
+This is working pretty good on my machine, and solves the
+overcaching bug.
+
+I haven't commited my changes to the CVS yet, because I want
+to work with the answering branch before I make definitive
+changes.
+
+
+Please be patient.
+Jorge.- 
+
+
+
+[Dillo-dev]Update on Alt patch
+
+From: Livio Baldini Soares <livio@li...> - 2001-03-30 08:39
+
+Hi everyone!
+
+Thanks so much for all the feedback (learned a lot ;-)!
+Now I have a new version (hopefully improved) for you guys to try
+out. It's in the same place:
+http://www.linux.ime.usp.br/~livio/dillo/alt.diff 
+
+I'll comment the changes, hopefully including everyone's remarks and
+opinions: 
+
+Jörgen, your patch worked nicely so I included it along with mine!
+
+Sebastian,
+
+* I replicated "somewhat" the timeout function used in gtktooltips.c
+and it worked nicely! With that I even enabled
+Dw_image_motion_notify events to remove the timeout (this goes along
+with Eric's suggestion to remove the alt if the cursor has motion).
+The timeout "slice" I put is 700 miliseconds which feels fine in my
+computer.
+
+* I tried adding a Dw_image_destroy function, and in the end adding a
+parent_class->destroy (initializing parent_class in
+Dw_image_class_init), but I must have done something wrong because I
+couldn't get it to work... all I got was Segmentation Fault :-(
+
+Eric,
+
+* Now the tooltip has borders (and almost looks like a shadows...)
+Seems that the correct function to call was gtk_paint_box() and not
+gtk_paint_flat_box() which I was using before :-( gtk's
+documentation sucks!).
+
+* I removed tooltips arraising when no "alt" is defined.
+
+* Now to tooltip "feels" better. It takes almost one second to appear
+(if the cursor is stoped), and it will disappear immediately when
+you move it.
+
+
+Well I think that's all. The only problem (at least in my opinion)
+is that the placement of the tooltip inside the image should be better
+chosen then (x+10, y+10) like I currently do. I looked at
+gtktooltips.c and it kind of sucks (at least this part about chosing
+tooltip position). It considers that widget's size is small, but
+working with images is a totally diferent issue (they are too big, and
+can sometimes cover up more than half the screen, and in these case
+Gtk's toolips do badly).
+
+Any ideas or comments about anything said is always appreciated!
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Font modifying tags
+
+From: Livio Baldini Soares <livio@li...> - 2001-03-30 04:39
+
+Hi all, hi Sean,
+
+I accidently started implementing font tags again :-( I was looking
+through Eric's new Html.testsuite when I noticed some tags weren't
+implemented, so I eagerly starting hacking...
+Then I remembered: "Shit! Sean is doing that already...". 
+So Sean, if it isn't any trouble, could you list the tags that you've
+already implemented? (The ones I did were the <big> and <small>... I
+cheated and implemented then both under one Html_tag_open_*() function
+;-)
+
+Please don't think I'm rushing you to finish or commit your code!
+I'm just curious to what you've already done and also it will help me
+not forget to stay away from certain places in Dillo... :^P
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bug #116 (alt tags for images)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-29 14:43
+
+Hi Livio, Eric, and all.
+
+A few answers about the patch.
+
+First of all, tooltips may be used also in other contexts, e.g. for
+the "title" attribute of several tags, so I'll perhaps move the code
+to a lower level. More on this later.
+
+On Wed, Mar 28, Livio Baldini Soares wrote:
+> [...]
+> I was going to implement the alt text as a simple tooltip, but after
+> trying a little I realized that that would take more time/trouble than
+> creating my own little "tooltip" window. So I did it from
+> scrap...
+
+Gtk+ tooltips are intended for Gtk+ widgets, so adopting them is hard.
+After trying this, too, I think I'll agree you, that it is simpler to
+reimplement them.
+
+> [...]
+> The first is that on other browsers the alt takes a while to show,
+> but the way I've made it, it shows up immediately. What should we do?
+> I didn't even bother to think up a way to have this "wait" time before
+> activating alt text, but I guess it could be done...
+
+It should be simple, you just have to add a timeout function, and take
+care to remove it when the pointer leaves the image before the tooltip
+is shown. I think the best way is simply to imitate the behavior of
+Gtk+ tooltips, and copy code from gtktooltips.c.
+
+> The second thing is that in Dw_image_enter_notify() I alloc() a new
+> alt-window and in Dw_image_leave_notify() I free() it. It might not
+> sound good, but I've got a (crude) reason. Generally, what we think to
+> do in this case is on Dw_image_init(), alloc() everything we need and
+> in Dw_image_{enter,leave}_notify() we just call
+> gtk_window_{show,hide}(). But the problem is, when do we destroy it?
+> As a matter of fact this is a problem I've seen in Dillo... there
+> seems to be more *_new() functions than *_destroy(). But of course
+> this would have to be associated with the Cache scheme getting rid of
+> unwanted (old-)structs and therefore calling those destroys. My
+> question is, what to do now? Leave it the way I did it, or is it
+> better to prepare it for when the Cache starts doing some struct
+> (data) destruction?
+
+You can add a Dw_image_destroy function. Note that
+Dw_image_leave_notify may not have been called when the image widget
+is destroyed, so this is a memory leak.
+
+On Wed, Mar 28, Eric GAUDET wrote:
+> [...]
+> - tooltips are generally drawn in pale yellow, grey looks strange. What about a
+> dillorc option for that ?
+
+Livio called the widget "Image alt", so you can modify your ~/.gtkrc.
+Perhaps the name should be changed to "gtk-tooltips", like Gtk+ tooltips.
+
+> - I'd prefer the tooltip window to have a border so it looks detached from the
+> page. (better yet: if you could draw a shadow, it would be perfect)
+
+This should be the purpose of gtk_paint_flat_box, but it somehow does
+not work. Replacing it with
+
+gdk_draw_rectangle (image->img_alt->window,
+style->fg_gc[GTK_STATE_NORMAL],
+FALSE, 0, 0, width + 7, ascent + descent + 7);
+
+works, but won't honor different themes.
+
+> [...]
+> - A tooltip window can hide another image on the right and prevent it to catch
+> enter_notify (see the "screenshot" below ;-). If you mouve the mouse cursor
+> from "img1" to "img2" passing over the "tooltip" window, the tooltip for img2
+> will show only when crossing the rightmost border of the "tooltip" (dran with
+> '#'). 
+> 
+> +-------+ +---------+
+> | | | |
+> | +---------+ |
+> | | tooptip # |
+> | +---------+ |
+> | | | |
+> | | | |
+> +-------+ +---------+
+> img1 img2
+
+This is because some events get lost, they are sent to the tooltip,
+not to the viewport (which is furthermore *not* the parent of the
+tooltip window).
+
+If you look at Gtk+ tooltips, you'll notice that this problem does not
+occur, since the tooltips are placed outside the widgets. Perhaps this
+is a useful possibility.
+
+Furthermore, the Dw event mechanism isn't complete yet.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Bug #116 (alt tags for images)
+
+From: Jörgen Viksell <vsksga@ho...> - 2001-03-28 23:27
+
+Attachments: patch-alt      
+
+>.... Well the only trouble I was having was to transform strings
+>sizes into pixel sizes... it depends on the case, the font and
+>sometimes even the letter (like, "i" is narrower than "w").. but then
+>browsing through gtk's 1.2.7 source code, I discovered
+>gdk_string_{width,height}(), and my life got much better ;-)
+
+I believe you should use gdk_string_extents() instead.
+The ascent you get from that function is the strings and thus makes the 
+string middle-aligned.
+The attached patch does that. (I hope! :-))
+
+>--
+> Livio <livio@li...>
+>
+
+Cheers,
+Jörgen
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+RE: [Dillo-dev]Bug #116 (alt tags for images)
+
+From: Eric GAUDET <egaudet@in...> - 2001-03-28 05:59
+
+Hi Livio :-)
+
+-- En reponse de "[Dillo-dev]Bug #116 (alt tags for images)" de Livio Baldini
+Soares, le 28-Mar-2001 :
+> Hi guys!
+> 
+> Finally I got the time to make the alt text for images like I
+> promised. I had already done them (but badly) before Sebastian's new
+> Dw, but wanted to wait for it. Now I'm glad I did... it was so much
+> easier and it's more stable... thanks Sebastian!
+> 
+
+Ok, I "carefully reviewed" this feature ;-) and here's what I think (you may
+or may not agree with each):
+- tooltips are generally drawn in pale yellow, grey looks strange. What about a
+dillorc option for that ?
+- I'd prefer the tooltip window to have a border so it looks detached from the
+page. (better yet: if you could draw a shadow, it would be perfect)
+- a tooltip is drawn even if there's no "atl" attribute for the image ! It
+shows "png for a png image, etc. I don't like it so much. (If you print the
+image size, 320x200 (png), I could like it ;-)
+- A tooltip window can hide another image on the right and prevent it to catch
+enter_notify (see the "screenshot" below ;-). If you mouve the mouse cursor
+from "img1" to "img2" passing over the "tooltip" window, the tooltip for img2
+will show only when crossing the rightmost border of the "tooltip" (dran with
+'#'). 
+
++-------+ +---------+
+| | | |
+| +---------+ |
+| | tooptip # |
+| +---------+ |
+| | | |
+| | | |
++-------+ +---------+
+img1 img2
+
+...
+> 
+> The first is that on other browsers the alt takes a while to show,
+> but the way I've made it, it shows up immediately. What should we do?
+> I didn't even bother to think up a way to have this "wait" time before
+> activating alt text, but I guess it could be done...
+> 
+
+I'd prefer the tooltip to appear only when the mouse cursor hasn't moved for
+one seconde or so over an image, and disapear as soon as the mouse is moved.
+This would solve the above issue with tooltip overlapping an image.
+
+...
+> 
+> The patch can be found at:
+> http://www.linux.ime.usp.br/~livio/dillo/alt.diff
+> 
+> Please send any comments on it. If you have trouble downloading,
+> tell me and I can send it by email.
+> 
+
+Best,
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Mar-2001 a 14:41:04
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Bug #116 (alt tags for images)
+
+From: Livio Baldini Soares <livio@li...> - 2001-03-28 04:01
+
+Hi guys!
+
+Finally I got the time to make the alt text for images like I
+promised. I had already done them (but badly) before Sebastian's new
+Dw, but wanted to wait for it. Now I'm glad I did... it was so much
+easier and it's more stable... thanks Sebastian!
+
+I was going to implement the alt text as a simple tooltip, but after
+trying a little I realized that that would take more time/trouble than
+creating my own little "tooltip" window. So I did it from
+scrap... Well the only trouble I was having was to transform strings
+sizes into pixel sizes... it depends on the case, the font and
+sometimes even the letter (like, "i" is narrower than "w").. but then
+browsing through gtk's 1.2.7 source code, I discovered
+gdk_string_{width,height}(), and my life got much better ;-)
+The final result is that my code is simpler then the tooltip one (but
+I guess tooltip must be more robust...), and I think it's ok, except
+for the details I bring up below.
+
+The first is that on other browsers the alt takes a while to show,
+but the way I've made it, it shows up immediately. What should we do?
+I didn't even bother to think up a way to have this "wait" time before
+activating alt text, but I guess it could be done...
+
+The second thing is that in Dw_image_enter_notify() I alloc() a new
+alt-window and in Dw_image_leave_notify() I free() it. It might not
+sound good, but I've got a (crude) reason. Generally, what we think to
+do in this case is on Dw_image_init(), alloc() everything we need and
+in Dw_image_{enter,leave}_notify() we just call
+gtk_window_{show,hide}(). But the problem is, when do we destroy it?
+As a matter of fact this is a problem I've seen in Dillo... there
+seems to be more *_new() functions than *_destroy(). But of course
+this would have to be associated with the Cache scheme getting rid of
+unwanted (old-)structs and therefore calling those destroys. My
+question is, what to do now? Leave it the way I did it, or is it
+better to prepare it for when the Cache starts doing some struct
+(data) destruction?
+
+The patch can be found at:
+http://www.linux.ime.usp.br/~livio/dillo/alt.diff
+
+Please send any comments on it. If you have trouble downloading,
+tell me and I can send it by email.
+
+By the way, I've also been busy doing a new URL-passing scheme,
+which Jorge asked for some time ago... This was really tough to do and
+is still very bad :-( But anyway I got a "working" patch.
+Jorge did you receive the e-mail I sent to you last weekend (I think
+Saturday)? I send it to jcid@em... and attached the patch (it's
+big). If you haven't then tell me and I'll repost it. (I mean no rush
+in sending a comment, it's just that you said you were having emails
+problems lately).
+
+Anyone interested and bave enough ;-) can get it at:
+http://www.linux.ime.usp.br/~livio/dillo/urlparse.diff
+http://www.linux.ime.usp.br/~livio/dillo/urlparse.c
+http://www.linux.ime.usp.br/~livio/dillo/urlparse.h
+
+That's all for now. Best regards to all and I promise I'll try to
+write shorter posts from now on :^P
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Re: dillo developing
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-03-28 02:06
+
+Holger,
+
+> Hey there
+>
+> my name is holger rapp. lookibg around for alternatives. I was
+> mentally ready to start a new browser project of the ground.
+
+Oh, that's a big enterprise to undertake!
+
+> but
+> then, i found dillo, which is not yet great but it shows good
+> ideas.
+
+What ideas do you like of it?
+
+> Now, i'm asking if i might join in development.
+
+That's simple. It a matter of expertise and respecting the
+development model we're following (described in the web site).
+
+> I read throu the source and i'm intrested in getting the
+> plugins done. especially the ftp plugin is a mustdone for
+> useability.
+
+Yeah, sure. Don't miss the plugin draft:
+http://dillo.so....net/dpi1.txt
+
+Ah, as for the FTP plugin, I wrote that code a long time ago,
+and it worked nicely with the former plugin scheme. Now, after
+the new scheme is implemented, it would be a matter of adding the
+datagram encapsulation and cleanning it a bit.
+If you're willing to do that, I'd gladly send you the code I
+have.
+
+> I saw in the code, that the plugins are searched in
+> /usr/local/bin which is not useable, methinks. But b4 i start
+> doing anything that wouldn't fit in the ideas of other plugin
+> developers i thought, i better drop you a note.
+
+You'll probably find the answers in dpi1.txt.
+I'm not sure, but Eric was willing to review the draft and
+start implementing the protocolo. He may have informed you
+better though.
+
+> Thanks a lot for dillo.
+> Holger
+
+you're welcome
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Introduce myself
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-03-28 02:06
+
+Holger,
+
+> ...
+> For this i have some questions:
+> a) in IO/proto.c a_Proto_get_url: After forking the process there is this strange lines:
+> io = g_new(IOData_t, 1);
+> io->Op = IORead;
+> io->IOVec.iov_base = g_malloc(4096);
+> io->IOVec.iov_len = 4096;
+> io->Callback = a_Cache_callback;
+> io->CbData = (void *) Url;
+> io->FD = filedes[0];
+> a_IO_submit(io);
+> I got, that those lines should install a callback for when data
+> is there to read. But a_Chache_callback doesn'tz define an action
+> for IORead. Is this callback just a placeholder for a usefull
+> plugin callback, who cares about the communication with the
+> plugin.
+
+a_Chache_callback defines explicit actions for IOClose and
+IOAbort, but if neither the case, IORead is assumed and the
+control flow continues within the function.
+
+i.e. this is the function that handles the incoming data.
+
+> And the seconde question:
+> the forked process stdout gets connected to the parents FD for
+> this io with a unnamed pipe. But this way, the parents proecess
+> is not able to send any data to the client, just the client can
+> send. How should a good plugin run without the voice of his
+> master?
+
+That's why we're definning a new protocol. The answer to your
+question can be found at http://dillo.so....net/dpi1.txt.
+
+> I'm thinking of implementing plugins over named sockets, like
+> xmms does (/tmp/dilloXXXXXX or so). It's not secure andjust
+> portable under *Xes, but, well, it's something to start with.
+
+Portability is very important in this project.
+
+> Would really like to know, what you think about this all.
+
+I hope this helps.
+
+
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Introduce myself
+
+From: Eric GAUDET <egaudet@in...> - 2001-03-27 01:45
+
+Hi,
+I've been working on a patch for plugins with the previous design. This patch
+answers some of you questions. This can be a good start for you, as it already
+have the callback mecanism and pipes working.
+I plan to start from here when the plugin design is completely discussed: I
+still have some suggestions I want to submit to Jorge.
+
+Here's where you can download the patch and some explanations:
+http://www.rti-zone.org/dillo/
+
+Note that this patch and plugin protocol are deprecated and the new plugin
+design submitted by Jorge is what we want to implement.
+
+Feel free to contact me if you have any question.
+
+Best,
+Eric
+
+-- En reponse de "[Dillo-dev]Introduce myself" de Holger Rapp, le 26-Mar-2001 :
+> Hi,
+> 
+> my name is holger. I'm new at dillo development. I plan to hack the simple
+> plugins, especially the ftp plugin is in my interest.
+> For this i have some questions:
+> a) in IO/proto.c a_Proto_get_url: After forking the process there is this
+> strange lines:
+> io = g_new(IOData_t, 1);
+> io->Op = IORead;
+> io->IOVec.iov_base = g_malloc(4096);
+> io->IOVec.iov_len = 4096;
+> io->Callback = a_Cache_callback;
+> io->CbData = (void *) Url;
+> io->FD = filedes[0];
+> a_IO_submit(io);
+> I got, that those lines should install a callback for when data is there to
+> read. But a_Chache_callback doesn'tz define an action for IORead. Is this
+> callback just a placeholder for a usefull plugin callback, who cares about
+> the communication with the plugin.
+> And the seconde question:
+> the forked process stdout gets connected to the parents FD for this io with a
+> unnamed pipe. But this way, the parents proecess is not able to send any data
+> to the client, just the client can send. How should a good plugin run without
+> the voice of his master? 
+> I'm thinking of implementing plugins over named sockets, like xmms does
+> (/tmp/dilloXXXXXX or so). It's not secure andjust portable under *Xes, but,
+> well, it's something to start with.
+> 
+> Would really like to know, what you think about this all.
+> Greets
+> Holger
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 27-Mar-2001 a 10:39:31
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Introduce myself
+
+From: Holger Rapp <sirver@us...> - 2001-03-26 18:26
+
+Hi,
+
+my name is holger. I'm new at dillo development. I plan to hack the simple plugins, especially the ftp plugin is in my interest.
+For this i have some questions:
+a) in IO/proto.c a_Proto_get_url: After forking the process there is this strange lines:
+io = g_new(IOData_t, 1);
+io->Op = IORead;
+io->IOVec.iov_base = g_malloc(4096);
+io->IOVec.iov_len = 4096;
+io->Callback = a_Cache_callback;
+io->CbData = (void *) Url;
+io->FD = filedes[0];
+a_IO_submit(io);
+I got, that those lines should install a callback for when data is there to read. But a_Chache_callback doesn'tz define an action for IORead. Is this callback just a placeholder for a usefull plugin callback, who cares about the communication with the plugin.
+And the seconde question:
+the forked process stdout gets connected to the parents FD for this io with a unnamed pipe. But this way, the parents proecess is not able to send any data to the client, just the client can send. How should a good plugin run without the voice of his master? 
+I'm thinking of implementing plugins over named sockets, like xmms does (/tmp/dilloXXXXXX or so). It's not secure andjust portable under *Xes, but, well, it's something to start with.
+
+Would really like to know, what you think about this all.
+Greets
+Holger 
+
+
+
+[Dillo-dev]Html.testsuite Updated
+
+From: Eric GAUDET <egaudet@in...> - 2001-03-24 06:09
+
+Hi all,
+I just updated the Html test suite. New version indicates what's working in
+tarball 0.4.0, and a reference image for all HTML4 named entities.
+
+enjoy !
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 24-Mar-2001 a 15:07:35
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]Simple plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-03-22 16:05
+
+Hi,
+
+For those interested in plugins, the fourth draft is finished,
+you can find it at:
+
+http://dillo.so....net/dpi1.txt
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Miscellanea
+
+From: Ron Farrer <rbf@fa...> - 2001-03-18 16:19
+
+Attachments: Message as HTML      
+
+Jorge Arellano Cid (jcid@em...) wrote:
+
+> Dillo on the Alpha:
+>=20
+> A few days ago, I played with an old Alpha server; the compiler
+> raised some warnings due to different data type-sizes, so I fixed
+> them. That Alpha is still not able to run dillo (it produces the
+> binary, but dillo hangs), so I'll try to check it out next week.
+> If anyone here has an Alpha at hand, please let me know if
+> dillo runs ok on it, and what compiler/version was used.
+
+Yes it runs. I have personally run it on an AS200 (233MHz, 64MB) and
+a Ruffian (600MHz, 256MB). Runs great on both. 0.4.0 works VERY well
+(kudos).
+
+gcc version 2.95.2 20000220 (Debian GNU/Linux)
+
+Ron
+--=20
+Email: <rbf@fa...> or <rbf@de...>
+Home: <http://www.farrer.net/~rbf/>
+Alpha Linux Powered: <http://www.alphalinux.org> 
+
+
+
+[Dillo-dev]Miscellanea
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-03-18 16:06
+
+Hi!
+
+
+Here's a miscellanea by topic:
+------------------------------
+
+Dillo weekly news:
+
+A long time ago, Allan wrote me telling he was going on
+holidays to Australia, and that he could not maintain the dillo
+weekly news of our site. He should be back in June, so if anyone
+here wants to take charge of that while he travels, just drop me
+a note please (Dillo weekly news is a very appreciated thread).
+
+
+Dillo on the Alpha:
+
+A few days ago, I played with an old Alpha server; the compiler
+raised some warnings due to different data type-sizes, so I fixed
+them. That Alpha is still not able to run dillo (it produces the
+binary, but dillo hangs), so I'll try to check it out next week.
+If anyone here has an Alpha at hand, please let me know if
+dillo runs ok on it, and what compiler/version was used.
+
+
+URIs with entities:
+
+Finally I got into the problem of entities-parsing inside
+SGML-URI-attribute-values. As you may remember, the URI/URL rfc
+says nothing about entities, but when an URI appears as an
+attribute value inside a SGML application (HTML 4.01), they must
+be parsed.
+In brief, dillo parses them inside the "href" attribute-value
+in <A>, <BASE> and <AREA> elements, and inside "src" for <IMG>.
+
+
+Plugins:
+
+Eric sent me his latest draft (on the plugin design), and I'm
+studying it in detail. There'll be two types of plugins, a simple
+one that is very similar to CGIs, and a full blown that
+interacts with widgets.
+We're working on the first type, and the second one will have
+to wait, at least, until dillo renders TABLES and FRAMES.
+Eric: The the draft is better than my first impression. I'll
+simplify it, and make the new draft available ASAP.
+
+
+IO Error control:
+
+Yes, I've been busy, but I made some progress anyway! I hope to
+work on it full time after I finish the simple-plugins draft.
+
+
+
+That's all folks!
+Jorge.-
+
+
+PS [Pablo]: Did you receive my email on BUG#78 and the quoted
+parsing problem? 
+
+
+
+RE: [Dillo-dev]bug in some pages
+
+From: Eric GAUDET <egaudet@in...> - 2001-03-16 02:37
+
+The problem is you page uses tables, and Dillo doesn't support tables yet.
+Several people are working on it, and Dillo is likely to support tables for
+version 0.5, which might be in a couple of monthes.
+
+Best,
+Eric
+
+
+-- En reponse de "[Dillo-dev]bug in some pages" de lqx, le 16-Mar-2001 :
+> Hi,Eric
+> 
+> Did you received the page I sent you?Did you see the bug in it? Does anybody
+> to fix it?
+> 
+> regards,
+> 
+> Qiaoxia Li
+> 
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 16-Mar-2001 a 11:38:48
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]bug in some pages
+
+From: lqx <liqx@st...> - 2001-03-16 02:14
+
+Attachments: Message as HTML      
+
+Hi,Eric
+
+Did you received the page I sent you?Did you see the bug in it? Does =
+anybody to fix it?
+
+regards,
+
+Qiaoxia Li 
+
+
+
+Re: [Dillo-dev]Newcomer
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-13 11:46
+
+On Sun, Mar 11, Xavier Ordoquy wrote:
+> [...]
+> However, the rendering engine has not been documented until now.
+> I've start browsing the code, I think I'm going to document what I
+> understand and you'll check this after.
+
+There is doc/Dw*.txt describing a rendering framework mainly
+independent of (although, of course, designed for) dillo, based on
+Gtk+. The widgets provided by Dw are fed by several other modules
+(Html, Plain, Image ...), but do not refer to the other modules
+(well, there is one reference, but my goal is to remove it in
+future). If it is incomplete, I'll ask your questions, on the list or
+privately.
+
+There are several layers, which I don't know that detailed, and they
+are indeed not perfectly well documented. Track down the functions,
+starting in the Nav module.
+
+> Moreover I'll closly looking for
+> the table implementation. I really want to see it done very soon ;)
+
+I recently posted some ideas about it. I'm currently not working on
+it, but instead involved in cleaning up the page widget.
+
+A note if you want to start: I plan to implement margins, borders,
+and padding at the level of DwWidget, quite close to the CSS spec.
+They will anyway needed for other purposes (except CSS in future:
+e.g. floating objects).
+
+> Another point the about plugins. I'm going to have a look a the way the
+> are implemented in mozilla and konqueror.
+> I do understand that one will not be able to use the netscape plugin
+> system for other processor than x86, but I'de like to see this implemented
+> for the architecture so that I can remove netsape/mozilla/konqueror from
+> my desktop ;)
+
+There is already a simple framework: functions for creating
+DwWidget's, and for feeding them with data, look at mime.c for
+details. The plugin scheme should be bound to this. The simplest
+solution could be .so files, with the disadvantage of decreasing
+stability (AFAIK Netscape does this). Any other system could perhaps
+be included by wrappers, however, there are several free
+implementations we could use.
+
+> I fully agree it's another issue, but it might be very interessting to
+> have a full gtk browser for gnome for ex.
+
+Dillo is already mostly capable of rendering pages conforming to
+"typical" recommendations (no frames, no dependences on javascript,
+embedded objects etc.), except that tables are rendered different
+(which is IMHO only a real handicap when tables are used as
+_tables_). ;-)
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]jpeg images
+
+From: Eric GAUDET <egaudet@in...> - 2001-03-12 10:01
+
+-- En reponse de "[Dillo-dev]jpeg images" de lqx, le 12-Mar-2001 :
+> Hi,
+> 
+> I found a bug when dillo dealt with more than two jpeg images in a
+> line,please visit http://startman.start.com.cn and you will see the
+> fault.Will anybody fix this bug?I used dillo v0.4.0.
+> 
+> regards,
+> 
+
+Unfortunatly, I can't acces the page. It seems there's a route loop in the way:
+7 205.158.0.71 (205.158.0.71) 9.846 ms 9.600 ms 9.742 ms
+8 fe9-1-0.core1.scl-ca.us.xo.com (207.88.3.193) 9.605 ms 11.087 ms 22.777
+ms
+9 205.158.0.71 (205.158.0.71) 11.273 ms 10.330 ms 16.958 ms
+
+Did you see the error with other pages ?
+Can you send me the page (along with the images) by email, so I can include it
+in the testsuite and developpers can investigate the problem ?
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 12-Mar-2001 a 19:00:57
+"In theory, there's no difference between 
+theory and practice; in practice, there is.
+------------------------------------ 
+
+
+
+[Dillo-dev]jpeg images
+
+From: lqx <liqx@st...> - 2001-03-12 09:21
+
+Attachments: Message as HTML      
+
+Hi,
+
+I found a bug when dillo dealt with more than two jpeg images in a =
+line,please visit http://startman.start.com.cn and you will see the =
+fault.Will anybody fix this bug?I used dillo v0.4.0.
+
+regards, 
+
+
+
+Re: [Dillo-dev]Newcomer
+
+From: Xavier Ordoquy <xordoquy@au...> - 2001-03-11 10:45
+
+> Frankly, the best way to get involved, and to know what's dillo
+> project about, is the one I described above (we put a big effort
+> in creating those docs.).
+> 
+> Jorge.-
+
+However, the rendering engine has not been documented until now.
+I've start browsing the code, I think I'm going to document what I
+understand and you'll check this after. Moreover I'll closly looking for
+the table implementation. I really want to see it done very soon ;)
+
+Another point the about plugins. I'm going to have a look a the way the
+are implemented in mozilla and konqueror.
+I do understand that one will not be able to use the netscape plugin
+system for other processor than x86, but I'de like to see this implemented
+for the architecture so that I can remove netsape/mozilla/konqueror from
+my desktop ;)
+I fully agree it's another issue, but it might be very interessting to
+have a full gtk browser for gnome for ex.
+
+---
+Xavier Ordoquy,
+Aurora-linux, http://www.aurora-linux.com 
+
+
+
+Re: [Dillo-dev]Newcomer
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-03-11 01:16
+
+Xavier,
+
+> Hi,
+
+Hi!
+
+> I just tried dillo, and it seems very nive to me because it seems fast.
+> I whish I can join the project and help you.
+> My goal is to make a browser small and usable on desktop as well as
+> embedded devices with netscape plugins.
+
+Be careful. Dillo has a very different rendering engine than
+Netscape. I don't know if currently netscape plugins are
+independent from the invoking program, but sometime ago they were
+based on a Netscape protocol that was specific to that browser.
+
+We're just defining a way of implementing simple plugins (as
+described in the [Project Notes] link), and full blown plugins
+(those that integrate with rendering functions) are far away in
+the future...
+
+On the other hand, dillo has been reported to run on the IPaq
+and StrongArm based machines.
+
+> Can I have more information about the ongoing developpements ??
+
+Sure, just take a look at the bug track, skim the mailing list
+and read what's inside the doc/ directory.
+
+> What about joining the team ?
+
+That's free!
+
+Frankly, the best way to get involved, and to know what's dillo
+project about, is the one I described above (we put a big effort
+in creating those docs.).
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Tables
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-09 15:49
+
+On Tue, Mar 06, 2001 at 06:58:32PM -0300, Jorge Arellano Cid wrote:
+> 
+> Hi!
+> 
+> On 4 Mar 2001, Sebastian Geerken wrote:
+> 
+> > [...]
+> > This should make it possible to render tables incrementally, the
+> > basic mechanism is the same as the one currently used for simple
+> > pages: when the page widget grows, this will delivered to the table
+> > widget, which will then recalculates its size. It may be (an
+> > approximation is difficult, the best is to test the final
+> > implementation) that this takes quite much CPU time, in this case, it
+> > may be convenient to find an other priority mechanism instead of Gtk+
+> > idle functions. But we'll see ...
+> 
+> As an alternative, the rendering can be tuned with timeout
+> functions (e.g. Table rendering with a 3 seconds interval).
+
+Rendering of tables will be done in the "main" (i.e. the GUI) thread.
+If it gets too slow two, two problems arise:
+
+1. it blocks the user interface, and
+2. it hogs the CPU in an unreasonable way.
+
+2 could be solved by a timeout, but 1 won't, the only way to solve it
+is to do some parts in another thread.
+
+> The problem of rendering cached pages can be solved with an
+> idle rendering that's triggered when the whole page has been
+> parsed;
+
+... or the </table> tag was read ...
+
+> the idle rendering request must cancel any queued
+> timeout. That way, if the page has completed downloading, and the
+> timeout is still waiting, no noticeable delays would be perceived
+> by the user.
+
+If the page is read from the cache, rendering will only be done once,
+since idle functions have a lower priority. So, the timeout function
+should not be started when the table has been finished. Instead, the
+current mechanism via idle functions is used. However, there may be
+changes after the table/page has been finished, e.g. by images, which
+will cause the table to be resized.
+
+Anyway, the resizing mechanism may be changed without modifying the
+widgets itself, so I don't bother about it, but will see whether a
+change is really necessary after implementing the table widget.
+
+Sebastian 
+
+
+
+[Dillo-dev]Newcomer
+
+From: Xavier Ordoquy <xordoquy@au...> - 2001-03-09 13:24
+
+Hi,
+
+I just tried dillo, and it seems very nive to me because it seems fast.
+I whish I can join the project and help you.
+My goal is to make a browser small and usable on desktop as well as
+embedded devices with netscape plugins.
+
+Can I have more information about the ongoing developpements ??
+What about joining the team ?
+
+Xave.
+
+---
+Xavier Ordoquy,
+Aurora-linux, http://www.aurora-linux.com 
+
+
+
+Re: [Dillo-dev]Tables
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-03-06 22:06
+
+Hi!
+
+On 4 Mar 2001, Sebastian Geerken wrote:
+
+> [...]
+> This should make it possible to render tables incrementally, the
+> basic mechanism is the same as the one currently used for simple
+> pages: when the page widget grows, this will delivered to the table
+> widget, which will then recalculates its size. It may be (an
+> approximation is difficult, the best is to test the final
+> implementation) that this takes quite much CPU time, in this case, it
+> may be convenient to find an other priority mechanism instead of Gtk+
+> idle functions. But we'll see ...
+
+As an alternative, the rendering can be tuned with timeout
+functions (e.g. Table rendering with a 3 seconds interval).
+The problem of rendering cached pages can be solved with an
+idle rendering that's triggered when the whole page has been
+parsed; the idle rendering request must cancel any queued
+timeout. That way, if the page has completed downloading, and the
+timeout is still waiting, no noticeable delays would be perceived
+by the user.
+
+Just an idea...
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Tables
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-04 20:57
+
+Hi!
+
+Just a few words about tables. The implementation should be tricky,
+but quite interesting, and if nobody else feels a strong desire to do
+this ;-), I'll start with it soon (aside from some other things).
+
+So far, this is the current state of what I've thought about it.
+
+A simple overview what to do:
+
+1. Write a table widget. It will be a general purpose Dw container,
+but will indeed only used for DwPage's.
+
+2. Extend the HTML parser by a page stack, so that it can write
+into different DwPage's. This is quite simple, and I already
+have the code somewhere lying around on my harddisk.
+
+This should make it possible to render tables incrementally, the
+basic mechanism is the same as the one currently used for simple
+pages: when the page widget grows, this will delivered to the table
+widget, which will then recalculates its size. It may be (an
+approximation is difficult, the best is to test the final
+implementation) that this takes quite much CPU time, in this case, it
+may be convenient to find an other priority mechanism instead of Gtk+
+idle functions. But we'll see ...
+
+Table rendering is not trivial. I've made a few thoughts about it,
+and later found notes how it is implemented in w3m
+(http://ei5nazha.yz.yamagata-u.ac.jp/~aito/w3m/eng/STORY.html,
+section "Table rendering algorithm in w3m"), which are quite similar
+to my ideas.
+
+For nested tables, there is the need for minimizing the number of
+calculations of the real column widths. It should be possible to do
+this by knowing only the minimal/maximal width of cells (which are
+widgets), and calculating the latter should be quite fast.
+
+Integrating this idea into Dw will look like following:
+
+1. There will be an other way how DwPage allocates the child
+widgets. The current is suitable for simple widgets like images
+and hrules, but the table widget will have to know the page
+width, an extended scheme will make use of set_width etc.
+
+2. DwWidget will be extended by signals returning the minimum and
+maximum width. For most widgets, this will be simple and will
+done by Dw_widget_real_... implementations. For DwPage's without
+child widgets, this is mainly the width of the widest word, and
+the width of the widest line, respectively (both should be
+stored in DwPage for speed). When there are child widgets, the
+minimum/maximum widths of them have to be regarded.
+
+The minimal/maximal width of a table is simply the sum of all
+minimal/maximal column widths, and the minimal/maximal column
+width are the maxima of all minimal/maximal column cell widths.
+
+Sebastian 
+
+
+
+[Dillo-dev]dillo CVS
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-03-04 16:24
+
+Hi!
+
+Today I succeded merging back 0.4.0 branch into the main trunk
+of the CVS.
+
+What does that mean? Simply stated, that what we used to call
+0.4.0 branch (or "Dw-040") has become our main line of
+development, and that it has to be accessed at the main trunk (in
+other words: no more '-r Dw-040' arguments).
+
+How to get it from CVS? Just:
+
+cvs -d:pserver:anonymous@cv...:/cvsroot/dillo login
+cvs -z8 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo
+
+That's all!
+
+
+Cheers
+Jorge.-
+
+
+Ps: [Sebastian]: Needless to say, any new changes
+go in the main trunk now! 
+
+
+
+[Dillo-dev]0.4.0 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-03-04 01:42
+
+Hi there!
+
+I'm exhausted, but finally dillo-0.4.0 is there, ready for
+download!!!
+
+The web site was updated, also project notes, primary concerns
+and documentation inside the tarball.
+
+040 bugtrack will not be used anymore, just keep using the main
+one because 0.4.0 is now our main development branch. That's it!
+
+Eric: Please submit me (or to Sebastian) your HR patch, because
+none of us received it.
+
+Well, I'll try to merge 0.4.0 branch into the main trunk of the
+CVS tomorrow.
+
+Mark: There's a short overview of the plugin scheme that's to
+be implemented in [Project Notes] link.
+
+
+
+Good night!
+Jorge.- 
+
diff --git a/old/oldmail/200104.txt b/old/oldmail/200104.txt
new file mode 100644
index 0000000..324010f
--- /dev/null
+++ b/old/oldmail/200104.txt
@@ -0,0 +1,1303 @@
+Re: [Dillo-dev]Font modifying tags
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-04-28 15:10
+
+Hi.
+
+On Wed, Apr 18, I wrote:
+> [...]
+> > I'll soon upload a few changes, [...]
+
+Done. Read doc/DwStyle.txt for informations about it.
+
+I've added the face attribute to <font>, but as before, it is
+currently completely deactivated. There should probably a new dillorc
+option force_my_font.
+
+About bug #118: This bug has two aspects. The first (li_test.html) is
+that there is an extra line break, this is (I think so) the same bug
+as #78 (<p> in <li>). Second, headers were always positioned at the
+left, this was because the style of the first word in the line (a
+pagemark anchor) was wrong. The latter has been fixed, therefore the
+"50% done" in the WorkedBy field.
+
+> [...]
+> And a question:
+> 
+> Eric implemented visualization of visited links by calling
+> a_Cache_url_read when the page is _drawn_. This has the strange effect
+> that sometimes the links are updated when a page is loaded in another
+> window (e.g. when you open a link in a new window) - this is indeed
+> very useful -, but first after they have been redrawn (e.g. caused by
+> an expose events) - quite inconsistent.
+> 
+> I've made a few changes, two points are (more on the reasons later):
+> (i) I moved the a_Cache_url_read call into html.c, and (ii) I'll add
+> the possibility to change the style of words dynamically. However, the
+> only simple possibility I see is to change a link when the user clicks
+> on them. (Which makes perhaps sense, since a broken "visited" link is
+> also a visited link.) Any suggestions?
+
+My current solution looks like this:
+
+- I've removed vcolor from DwPageAttr/DwStyle. In future, there
+will be one style for each "state", instead of one style for all
+states.
+
+- When the page is read, a_Cache_url_read is called to determine
+whether to use the "link" or the "vlink" color.
+
+- If the user clicks on a link, it is changed to "vcolor". There is
+some code in Dw_page_button_release to handle this, but this is
+definitely supposed as a workaround, and will change in future.
+
+
+Sebastian 
+
+
+
+[Dillo-dev]BUG 147 & BUG 148
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-25 12:39
+
+Hi!
+
+These entries (147 & 148) are not bugs in dillo, but a problem
+with shell character escaping! If you use:
+
+dillo http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&amp;item=1230283536
+
+in the command line, the shell will stop at the '&' and try to
+run that in background, and the rest of the line will be parsed
+as a different thing.
+
+Just try:
+
+dillo 'http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&amp;item=1230283536'
+
+and it will be fine.
+
+Please acknowledge me this info (or prove me wrong! :) before I
+delete those entries.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Menu Button Question
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-24 11:53
+
+Hello Andrew!
+
+andew ecu writes:
+> Hi i have just compiled the dillo-0.4.0 source code, and the binary program 
+> that i got runs. However the only menu options that i get are File and 
+> Bookmarks and Help. I noticed on the screen shots and also in the source 
+> code of commands.c that there is meant to be a Document menu and a Browse 
+> menu.
+> 
+> Have i compiled the program wrong? Why cant i get the full menu
+> options?
+
+No, you haven't compiled the wrong program. You *are* getting the
+full menu options (as of now). Those screenshots are somewhat old and
+most of user options are availvable through mouse pop-up menus
+(right-click on a page or on a link and you'll get 2 diferent pop-ups
+with some interesting options).
+
+We can update those screenshots, but besides those two menus from
+the menu bar, everything else in Dillo's apperaence seems to be quite
+the same.
+
+By the way, I suggest you try out Dillo from CVS. It includes some
+changes which make browsing much more stable! (new Concomitant Control
+Chain design).
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Menu Button Question
+
+From: andew ecu <andrewecu@ho...> - 2001-04-24 02:56
+
+Hi i have just compiled the dillo-0.4.0 source code, and the binary program 
+that i got runs. However the only menu options that i get are File and 
+Bookmarks and Help. I noticed on the screen shots and also in the source 
+code of commands.c that there is meant to be a Document menu and a Browse 
+menu.
+
+Have i compiled the program wrong? Why cant i get the full menu options?
+
+Please Help :)
+Thanks
+Andrew
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+Re: [Dillo-dev]thinggies
+
+From: Holger Rapp <sirver@gm...> - 2001-04-22 17:18
+
+Jorge,
+
+> > i've got a short question to dillo.
+> > why are white backgrounds disallowed in the dillorc file? I couldn't see
+> > the useability for this.
+> > Please explain.
+> 
+> Some of us suffer from extra sensitivity in our eyes, and to
+> keep looking at white backgrounds for an extended time can lead
+> to headaches and eye pain. That's all.
+> 
+A well, ok. But wouldn't it be better to allow white bgs by default and
+to turn them off as a feature? SOme sites just don't look with a other
+color then white.
+> > Also, i would like to know im someone succeeded in getting the dpi1
+> > plugins up and running. I saw in the log that some loaded it down. What
+> > do you think of it?
+> 
+> Well, I haven't checked your latest version yet, but I'm
+> willing to. Now I'm working on other areas, but the time will
+> come sooner or later; please be patient, or send me some notes
+> about your progress.
+> 
+Ok, i will. I have to reimplement change some things because of the new
+URL Scheme, which i haven't understood yet. But i will. Expect to hear
+from me somewhen in the following week.
+> Ah, I have asked you a couple of times if I have sent you my
+> old version of the FTP plugin; have I?
+Sorry, didn't i answer this? Yes, you have. when you take a look at the
+code you'll recognize big party of your code, I guess.
+
+So long
+Holger 
+
+
+
+Re: [Dillo-dev]thinggies
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-22 14:14
+
+Holger,
+
+> i've got a short question to dillo.
+> why are white backgrounds disallowed in the dillorc file? I couldn't see
+> the useability for this.
+> Please explain.
+
+Some of us suffer from extra sensitivity in our eyes, and to
+keep looking at white backgrounds for an extended time can lead
+to headaches and eye pain. That's all.
+
+> Also, i would like to know im someone succeeded in getting the dpi1
+> plugins up and running. I saw in the log that some loaded it down. What
+> do you think of it?
+
+Well, I haven't checked your latest version yet, but I'm
+willing to. Now I'm working on other areas, but the time will
+come sooner or later; please be patient, or send me some notes
+about your progress.
+
+Ah, I have asked you a couple of times if I have sent you my
+old version of the FTP plugin; have I?
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]News
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-22 02:07
+
+Hi!
+
+Sorry if I seemed a bit unresponsive, but I was dedicated to
+the new prototype and its integration with current CVS.
+Today I uploaded the merged code to the CVS; there're plenty of
+changes, summarized in the Changelog. The good news is that the
+new CCC-scheme is working good, and that several other things can
+be built on top of it!
+
+The most noticeable effects are better status messages, a bit
+more of stability, improved error handling and the beloved fast
+Back (or Forward) test! Here I'm a little puzzled, although it
+works quite fast, sometimes the toolbar buttons get into an
+insensitive state (more accurately: the mouse events are not
+passed to the underlying widgets). The funny thing is that the
+main page (viewport) keeps responsive to the keyboard, and
+Shift+TAB rolls focus as usual, so it's possible to write a new
+URL, go there, and after a little struggling, normal work can be
+resumed (I don't know exactly how).
+Ah, the other thing that may help is that before Sebastian's
+last patch to event passing code, there were segfaults instead...
+
+How2reproduce: Load a few (local) pages, and keep going back
+and forward as fast as you can until it happens.
+
+
+Cheers
+Jorge.-
+
+
+Ps: Deleted BUG#141 
+
+
+
+[Dillo-dev]thinggies
+
+From: Holger Rapp <sirver@gm...> - 2001-04-21 09:52
+
+Hello,
+
+i've got a short question to dillo.
+why are white backgrounds disallowed in the dillorc file? I couldn't see
+the useability for this.
+Please explain.
+Also, i would like to know im someone succeeded in getting the dpi1
+plugins up and running. I saw in the log that some loaded it down. What
+do you think of it?
+
+Greets.
+Holger 
+
+
+
+Re: [Dillo-dev]Font modifying tags
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-04-18 18:38
+
+Hi.
+
+On Fri, Mar 30, Livio Baldini Soares wrote:
+> I accidently started implementing font tags again :-( I was looking
+> through Eric's new Html.testsuite when I noticed some tags weren't
+> implemented, so I eagerly starting hacking...
+> Then I remembered: "Shit! Sean is doing that already...". 
+> So Sean, if it isn't any trouble, could you list the tags that you've
+> already implemented? (The ones I did were the <big> and <small>... I
+> cheated and implemented then both under one Html_tag_open_*() function
+> ;-)
+
+On Sat, Mar 31, I wrote:
+> I intended to post this in a few days, since I'm currently working on
+> attributes. I wondered what has happened with the implementation of
+> the <font> tag.
+> 
+> I'll soon upload a few changes, [...]
+
+"Soon" has taken a bit longer, but at least the interface and the
+modifications of html.c and dw_page.c are finished. The implementation
+of styles (which are currently mainly the same) is still buggy (but
+stable, mainly only memory leaks), and I'll test several variations of
+implementation details for speed and memory usage.
+
+However, if someone wants to implement several related html elements
+(<font color=...> and <font face=...> already work - except checking
+preferences), I'll send him a patch for working on html.c.
+
+And a question:
+
+Eric implemented visualization of visited links by calling
+a_Cache_url_read when the page is _drawn_. This has the strange effect
+that sometimes the links are updated when a page is loaded in another
+window (e.g. when you open a link in a new window) - this is indeed
+very useful -, but first after they have been redrawn (e.g. caused by
+an expose events) - quite inconsistent.
+
+I've made a few changes, two points are (more on the reasons later):
+(i) I moved the a_Cache_url_read call into html.c, and (ii) I'll add
+the possibility to change the style of words dynamically. However, the
+only simple possibility I see is to change a link when the user clicks
+on them. (Which makes perhaps sense, since a broken "visited" link is
+also a visited link.) Any suggestions?
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]RE: Dpi1 Plugins
+
+From: Holger Rapp <sirver@gm...> - 2001-04-16 17:41
+
+Hi,
+
+doing well with the dpi1 stuff and the FTP-Plugin. Working quite stable
+now. I realease a new version tonight. A high priority is the to write
+what i did in a other way then the dpi1.txt suggests. I will send my
+version as soon as possible. 
+The ftp plugin is now able to list dirs on other Servers and the dpi1
+engine is fully workable, even if there is stuff missing. I guess we
+could implement it in the next stable version of dillo.
+Check the new source at http://microkosmos.mine.nu at about 24:00 CEST,
+i really like to here what you're thinking.
+
+Greets
+Holle 
+
+
+
+Re: [Dillo-dev]Patch for File Selection (Discussion about User-Interface)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-16 15:13
+
+Hi!
+
+
+> > I also plan to make window to fix the second of my brother's
+> > complaint (no feed back during download), with updated status on the
+> > download. But this comes back to what I wanted to discuss about UI.
+> I also dislike this in dillo. While i really like the non linear way
+> dillo handels lookups/transfers i prefer if it would be more verbose
+> (ex: looking up blah blah, getting blahblah (30%)) so one could see that
+> it's still alive and working.
+
+Please read the [Project Notes] link.
+
+> >
+> > User Interface
+> > --------------
+> Here i've got to add a thing. I'm currently working at the ftp module
+> and the dpi1 plugin stuff.
+
+[Holger]: Did I send you my old ftp plugin-program code?
+
+> And i've got no idea how a plugin should
+> inform the user about it's progress. There could be those ways:
+> 1) the plugin makes it's own progress dialog
+> 2) the plugin creates on question a HTML page which shows the progress
+> 3) the plugin permanently passes it's progress to dillo and it updates
+> a progress dialog.
+>
+> I personally like the 3 one the most. But this is also a UI thingy, so
+> what do you thing?
+
+The number of bytes passed to the browser (download progress
+info when retireving a file via FP), is got by the browser as a
+side effect of the IO activity.
+"Contacting host", "Login in" type of messages will be passed
+back to the browser using dpi1 protocol; later on, those messages
+are routed to the sttus bar with the a_Interface_status function.
+
+You can review the save-as functionality to get the picture.
+BTW, I implemented it just for that!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]RE: Dpi1 Plugins
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-16 15:13
+
+Holger,
+[this email has interesting information for everyone]
+
+> > [Plugins bugs]
+> > There're zombies after calling PI-programs, no reload, ...
+> I found some. I'm not sure how to handle the memory leak throu the IO
+> engine (the code which you wrote), cuz i don't want to stick around in
+> the IO engine, because i don't won't to get trouble with the one
+> responsible for it.
+
+Don't worry about the IO, I'm developing the error control now,
+and my prototype has plenty of changes and improvements, so it's
+pointless to change the old IO now.
+
+> The others are just some search-and-destroy bugs.
+> I finally tracked down the bug with the parsing of the pluginsrc file...
+> hope to get this fixed tomorrow.
+
+Let me know when you have a polished prototype.
+
+> Another point is the new URL sheme. It is nessesary to make a difference
+> between plugins, that should cache and plugins that shouldn't. Is this
+> planed?
+
+There're a couple of ideas floating around this issue. By now,
+it is safe not to make any difference.
+In the future it could be handled by a no-cache directive in
+the HTTP header, or by a specific request in the dpi1 protocol.
+
+
+> Now, for something completly different: Dillo crashed after entering a
+> new URL while another one is already loaded. I didn't found the bug in
+> the source, but this is a known problem. I would like to know if there
+> is a progress in this, because this makes it really annoying to use
+> dillo sometimes. And i want to get rid of netscape 8).
+
+Yes, progress has been made (some of it is recorded in the
+bugtrack).
+As I wrote before, I'm developing an IO prototype that's
+currently working better than the former! I'll polish it a bit
+more and integrate it to the CVS tree, even knowing that it is
+not complete yet.
+There're several bugs, some rocorded and some not, that will be
+fixed with the new control framework. Progress seems very slow
+because I'm not working in a single bug, but with a whole family
+of bugs that stem from a common root.
+The problem is complex due to the innovative concept of never
+blocking interface that dillo uses. In other words: Has anyone
+seen a busy mouse-cursor in dillo? :-)
+The good news is that the new CCC (concomitant control chain)
+looks able to cope with that complexity in the prototype.
+
+In what regards to Netscape or Mozilla, it will not be easy to
+forget about them :(. Mainly due to sites using java, javascript,
+flash and related encumbered technologies.
+
+I don't plan to support those things in dillo. At least not
+within the main program, but if someone else develops a plugin
+that's able to cope with them, and there's a will to use it even
+knowing about all the security problems it can bring, I will not
+fight against them, and let them use it.
+
+HTTPS and W3C standards are a different thing, and they will
+have its place within dillo (when priorities point on them).
+
+I beleive we can get dillo to a point where it becomes our main
+browser of choice, and Mozilla or Netscape as a last resource.
+From there and on, only the lords of destiny can tell.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Bug #141 ???
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-11 20:20
+
+Hi folks!
+
+Is the person who inserted bug #141 on the list? If you are, the bug
+isn't entirely true... Please use Dillo and render this page:
+http://www.rti-zone.org/dillo/Html.testsuite/entities.html
+
+Dillo *does* render "special HTML-chars". There are two things to be
+said here. First, are you forgetting the ';' after the named entity?
+This can have mislead you... and I think that the guys here on the
+list have discussed about error recovery on these cases (or am I
+mistaken???), look at the `Faulty entities' section on the above URL.
+
+Secondly, it *is* true that Dillo does not render correctly ALL
+named entities correctly. So the bug entry #141 could either be
+changed to:
+
+* Dillo doesn't render named entities without ';', even though that's
+wrong ;-)
+
+* Dillo doesn't render ALL named entities correctly...
+
+Or we can just foget about it, and erase the entry.
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Patch for File Selection (Discussion about User-Interface)
+
+From: Holger Rapp <sirver@gm...> - 2001-04-10 14:07
+
+everyone,
+
+
+> Ok, with that said, you can get the patch (against today's,
+> 10Apr2001, CVS version) at:
+> http://www.linux.ime.usp.br/~livio/dillo/file_select.diff
+The patch worked well, and i really like it. But what i dislike is, that
+the selection is modal. i would prefer that dillo should stay
+responsive.
+
+> I also plan to make window to fix the second of my brother's
+> complaint (no feed back during download), with updated status on the
+> download. But this comes back to what I wanted to discuss about UI.
+I also dislike this in dillo. While i really like the non linear way
+dillo handels lookups/transfers i prefer if it would be more verbose
+(ex: looking up blah blah, getting blahblah (30%)) so one could see that
+it's still alive and working.
+
+> 
+> User Interface
+> --------------
+Here i've got to add a thing. I'm currently working at the ftp module
+and the dpi1 plugin stuff. And i've got no idea how a plugin should
+inform the user about it's progress. There could be those ways:
+1) the plugin makes it's own progress dialog
+2) the plugin creates on question a HTML page which shows the progress
+3) the plugin permanently passes it's progress to dillo and it updates
+a progress dialog. 
+
+I personally like the 3 one the most. But this is also a UI thingy, so
+what do you thing? 
+
+Greets
+Holger
+> 
+
+
+
+[Dillo-dev]Patch for File Selection (Discussion about User-Interface)
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-10 09:19
+
+Hi guys!
+
+My little kid brother started using Dillo this weekend, and he
+complained that it was "hard" for him to save (download) files. Mainly
+for two reasons. First, the entry box he said was just plain ugly,
+unfriendly, and unbrowsable. Secondly, he wanted some feedback from
+Dillo to see how the download was doing (percentage of the file
+already downloaded, etc).
+
+I totally agree with him... One thing Dillo is very bad at is User
+Interface (UI). Sometime ago, I was thinking of sending a message to
+open up a discussion about User Interface, but before I didn't have
+any time. But before I get into that, let me show you guys a patch to
+fix the first of my brother's complaint.
+
+File Selection
+--------------
+
+I made a patch to use gtk_file_selection when trying to "Save Page
+As..." and "Save Link As...". Currently it was only used for "Open
+File...". This made file selection MUCH better (easier for the
+end-user) than the simple text entry-box.
+
+To do this I reorganized some of interface.c and killed some widgets
+for dialogs boxes in browser.h. Mainly there are two things to be
+noticed:
+
+[1] Now there is only *one* dialog window for all three
+functions. Therefore you *can not* access more than one at a time. To
+me, this makes a lot of sense, because if you're going to choose a
+file for whatever reason, then CHOOSE the file, OR close the
+window. After that you can go on doing what you were doing... So
+that's why I set the File_Selection window to MODAL. The main bw
+window will seem to be dead, until you close the file_selection.
+
+[2] I have made a generic function,
+Interface_make_choose_file_dialog(), which is similar to the
+previously used Interface_make_dialog(). You pass, as arguments, the
+window's name, and most importantly, the call function to use to
+connect to the signal "clicked" on the ok_button. This means that
+this is and *should* be reusable. If this is needed anywhere, than an
+a_Command type hook is supposed to be set in commands.c, and in that
+make a call to an a_Interface function which can use the
+choosefile_dialog I've created. (Eric, this may help you with bug #128
+with the file selection part).
+
+Ok, with that said, you can get the patch (against today's,
+10Apr2001, CVS version) at:
+http://www.linux.ime.usp.br/~livio/dillo/file_select.diff
+
+I would really be happy to hear back on this patch. And any requests
+for improvement are very welcome.
+
+I also plan to make window to fix the second of my brother's
+complaint (no feed back during download), with updated status on the
+download. But this comes back to what I wanted to discuss about UI.
+
+User Interface
+--------------
+
+Has anyone given much thought about Dillo's interface? Or is it NOT a
+priority for the moment? If it's not, than I can delay/postpone this
+discussion for a better occasion. But if it's time to discuss it,
+better do it now before the UI starts to get too complicated.
+
+First of all, about the code organisation, we seem to be using gtk's
+default structure which menus.c/commands.c/interface.c.
+With some projects using glade I've done, this seems to have worked
+well, but I'm not sure it will with Dillo. If the UI starts to grow,
+then this type of structure tends to be bad (confusing).
+
+So now we get to the most important part: HOW do we want Dillo's user
+interface? If the goal is to keep it simple, than we might as well
+keep current structure. I don't exactly know how you guys picture
+Dillo when it's finished, or better yet, how you guys would *like* to
+see/use Dillo.
+
+I have some ideas of my own, but they seem a little too wild :^P
+
+For example, I like Emacs' buffers idea. In only ONE window you can
+have as many buffers (in our case, Viewport's) as you like. So you
+download 2 or 3 pages concurrently, and look at one at a time (or
+browse through the viewports by clicking on a button, which beats
+managing 3 or more separate windows on your desktop). There is a
+browser that "somewhat" does this which is Opera (has anyone tried
+it?). What Opera lacks though, is the option to split the window, and
+have 2 separate windows, because sometimes that's useful too (like
+Emacs has). So we could do a merge between tradicional mutilple
+windows, and a "buffering" system (multiple viewports in each window).
+
+Of course everyone of us will come up with diferent ideas, and I would
+like you guys (us) to discuss about User Interface to start making a
+plan for future (and some not so future, too) implementation for UI.
+
+Well, that's all for now. Best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Bug #139
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-08 09:41
+
+Hi guys!
+
+I've inserted and fixed bug #139. It seems that when you try to
+access URL's with ANCHORS *directly*, then the View Source command
+shows up empty. And even if you erase the anchor part of the URL, it
+still has an empty source.
+
+But if you try to access the URL without the anchor part before the
+URL with the anchor part, then everything is ok. The problem is due to
+how the URL gets registered in Cache (with a_Cache_open_url, and
+a_Cache_url_read). I've made a quick & dirty fix for this, and I think
+it's not worthwhile spending time fixing this cleanly because Jorge
+and I are working on a new URL scheme which will try to eliminate
+these problems.
+
+Here is the two line patch (on top of src/commands.c from todays
+CVS): 
+*******************************
+diff -pru dillo/src/commands.c dillo.new2/src/commands.c
+--- dillo/src/commands.c Sun Mar 4 16:21:21 2001
++++ dillo.new2/src/commands.c Sun Apr 8 06:15:59 2001
+@@ -96,7 +96,7 @@ void a_Commands_exit_callback(GtkWidget 
+void a_Commands_viewsource_callback (GtkWidget *widget, gpointer client_data)
+{
+BrowserWindow *bw = (BrowserWindow *) client_data;
+- char *buf;
++ char *buf, *hash;
+gint size;
+static GtkWidget *window = NULL;
+GtkWidget *box1;
+@@ -137,6 +137,8 @@ void a_Commands_viewsource_callback (Gtk
+
+gtk_text_freeze (GTK_TEXT (text));
+
++ if ( (hash = a_Url_parse_hash(bw->nav_stack[bw->nav_stack_ptr].url)) )
++ *hash = '\0';
+buf = a_Cache_url_read(bw->nav_stack[bw->nav_stack_ptr].url, &size);
+
+gtk_text_insert (GTK_TEXT (text), NULL, NULL,
+**************************
+
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]ematic mail
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-08 02:03
+
+Hi,
+
+I lost a couple of emails with ematic, if it was from someone
+here, please resend them to my nettaxi account.
+
+Thanks
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Interesting HTML Suite
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-07 19:17
+
+Hi,
+
+On Sat, 7 Apr 2001, Livio Baldini Soares wrote:
+
+> Hi,
+>
+> I ran into this and I thought it very interesting:
+> http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/
+>
+> It's a HTML suite which does "evil tests". Plus, there are links for
+> ther Html suite's.
+>
+> I tried a view tests, and they seemed nice... I didn't like that he
+> complained about a missing HTTP_REFERER field... but as far as I can
+> tell, it's an optional field :-(
+
+Remember that dillo doesn't try to render malformed HTML code,
+not even non standar extensions. Anyway, the "wet blanket" pages
+(standar compliance tests) can be interesting, but please always
+check Eric's suite first, because it is specially tailored to our
+needs.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Re: Dillo and Mime types
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-07 19:17
+
+Robert,
+
+> I'm interested in being able to open RealMedia files in the RealVideo
+> Player program. Is there a way to do MIME types in Dillo? Basically, I
+> would like to click on a link and get the RealPlayer to fire up and load
+> the media file. I can do this with Netscape, but Dillo is a far sexier
+> browser. It's interesting that the Dillo binary is smaller than Lynx and
+> yet can display inline images!
+>
+>
+> Please let me know if there is a way to specify handling of MIME types in
+> Dillo. I appreciate your efforts ... this is a fine browser.
+
+Yes, there is a way, but in the future this will be handled
+more easily with dillo plugins (a different thing from Netsacpe
+plugins).
+
+The basic idea is to stream the incoming data to the PI and let
+it pass it to the apropriate viewer. If your RealPlayer accepts
+incoming data through its stdin, then, a simple dillo-plugin can
+be the solution.
+
+We're working on plugins now, but this extension is not
+currently spported by dillo.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Interesting HTML Suite
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-07 09:36
+
+Hi,
+
+I ran into this and I thought it very interesting:
+http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/
+
+It's a HTML suite which does "evil tests". Plus, there are links for
+ther Html suite's. 
+
+I tried a view tests, and they seemed nice... I didn't like that he
+complained about a missing HTTP_REFERER field... but as far as I can
+tell, it's an optional field :-(
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Dillo on sparc && Broken proxy query
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-05 03:35
+
+Hi again!
+
+I've done some more research and made a cleaner patch. I've tested
+it under both proxies (it seems that my professor's network uses Squid
+2.2STABLE4) and using no proxy.. all of them work fine now with my
+patch ;-)
+
+Eric GAUDET writes:
+> 
+> A few question you didn't mention in your email because the answer is probably
+> "obviously yes", but I gotta ask ;-)
+
+(...)
+
+> - Does your patch follow the requirements of the relevant RFCs about http and
+> proxying ?
+
+Well, what I *understtod* from HTTP/1.1 RFC (number 2616, from June
+1999) is that yes, the hostname SHOULD be what the user (client)
+wants, not the intermediate gateway or proxy. But I may well have
+misunderstood. Here's the snip from rfc-2616, section 14.23
+
+****************************************************
+> 14.23 Host
+> 
+> The Host request-header field specifies the Internet host and
+> port number of the resource being requested, as obtained from the
+> original URI given by the user or referring resource (generally
+> an HTTP URL, as described in section 3.2.2). The Host field value
+> MUST represent the naming authority of the origin server or
+> gateway given by the original URL. This allows the origin server
+> or gateway to differentiate between internally-ambiguous URLs,
+> such as the root "/" URL of a server for multiple host names on a
+> single IP address.
+> 
+> Host = "Host"":"host [ ":"port ] ; Section 3.2.2
+> 
+> A "host" without any trailing port information implies the
+> default port for the service requested (e.g., "80"for an HTTP
+> URL). For example, a request on the origin server for
+> <http://www.w3.org/pub/WWW/> would properly include:
+> 
+> GET /pub/WWW/HTTP/1.1
+> Host: http://www.w3.org
+> 
+> A client MUST include a Host header field in all HTTP/1.1 request
+> messages . If the requested URI does not include an Internet host
+> name for the service being requested, then the Host header field
+> MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure
+> that any request message it forwards does contain an appropriate
+> Host header field that identifies the service being requested by
+> the proxy. All Internet-based HTTP/1.1 servers MUST respond with
+> a 400 (Bad Request) status code to any HTTP/1.1 request message
+> which lacks a Host header field.
+> 
+> See sections 5.2 and 19.6.1.1 for other requirements relating to
+> Host.
+**************************************************************
+
+I've read secions 5.2 and 19.6.1.1 and there seems to be nothing
+relevant concerning this issue.
+
+Ok, so did anyone understand the RFC in a different manner?
+
+I've implemented the "correct" (or not ;-) hostname in the Host
+request-header field while using proxy. The patch is at:
+
+http://www.linux.ime.usp.br/~livio/dillo/proxy.diff
+
+Comments are always appreciated!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Dillo on sparc && Broken proxy query
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-04 17:57
+
+Hi Eric!
+
+Yeah, I forgot to mention a few things, and it seems my patch breaks
+things on non-proxy systems.
+
+Eric GAUDET writes:
+> -- En reponse de "[Dillo-dev]Dillo on sparc && Broken proxy query" de Livio
+> Baldini Soares, le 03-Apr-2001 :
+> > Hi all,
+> > 
+> > I have some good (and bad ;-) news! I got Dillo to work on a Linux
+> > sparc box here at the University. ALSO I got it to work on a Sparc
+> > running:
+> > 
+> ...
+> > 
+> > Comments for the patch are *very* appreciated:
+> > 
+> 
+> A few question you didn't mention in your email because the answer is probably
+> "obviously yes", but I gotta ask ;-)
+> - you turned on the "proxy" dillorc option, right ?
+
+Yes. (And ALSO there is a environment variable $http_proxy correctly
+set). Oh, I and I forgo to mention that it works on the proxy in the
+network I help to administrate (student's network). Here I use squid
+version 2.2.5 and everything works fine... The one which doesn't work
+fine is in the professor's network. I don't know how their sysadmin
+has set up squid, and which version it is (altough it is 2 or above).
+
+> - I assume the patched dillo still works in a non-proxy environement, have you
+> test it ?
+
+No :-( I forgot to add an `if' clause... but I'll fix this on the next
+version of the patch...
+
+> - Does your patch follow the requirements of the relevant RFCs about http and
+> proxying ?
+
+I have no idea... I guess I should check the RFC first on how to
+correctly make the query.
+
+I'll answer this in a few days after I do some reasearch ;-)
+
+best regards.
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Dillo on sparc && Broken proxy query
+
+From: Eric GAUDET <egaudet@fr...> - 2001-04-03 13:22
+
+-- En reponse de "[Dillo-dev]Dillo on sparc && Broken proxy query" de Livio
+Baldini Soares, le 03-Apr-2001 :
+> Hi all,
+> 
+> I have some good (and bad ;-) news! I got Dillo to work on a Linux
+> sparc box here at the University. ALSO I got it to work on a Sparc
+> running:
+> 
+...
+> 
+> Comments for the patch are *very* appreciated:
+> 
+
+A few question you didn't mention in your email because the answer is probably
+"obviously yes", but I gotta ask ;-)
+- you turned on the "proxy" dillorc option, right ?
+- I assume the patched dillo still works in a non-proxy environement, have you
+test it ?
+- Does your patch follow the requirements of the relevant RFCs about http and
+proxying ?
+
+------------------------------------
+Eric GAUDET <egaudet@fr...>
+Le 03-Apr-2001 a 22:18:53
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]Dillo on sparc && Broken proxy query
+
+From: Livio Baldini Soares <livio@li...> - 2001-04-03 13:07
+
+Hi all,
+
+I have some good (and bad ;-) news! I got Dillo to work on a Linux
+sparc box here at the University. ALSO I got it to work on a Sparc
+running:
+
+$ uname -a
+SunOS jaca 5.7 Generic_106541-04 sun4u sparc
+
+It compiled ALMOST ok. First I got some warnings while compiling 
+
+In file included from /usr/local/include/netdb.h:97,
+from dns.c:19:
+/usr/local/include/sys/bitypes.h:26: warning: redefinition of ìnt8_t'
+/usr/include/sys/int_types.h:62: warning: ìnt8_t'previously declared here
+/usr/local/include/sys/bitypes.h:27: warning: redefinition of ìnt16_t'
+/usr/include/sys/int_types.h:68: warning: ìnt16_t'previously declared here
+/usr/local/include/sys/bitypes.h:28: warning: redefinition of ìnt32_t'
+/usr/include/sys/int_types.h:69: warning: ìnt32_t'previously declared here
+
+But that's all. It ran alright, except for the fact that there is a
+strange proxy running on the the intranet the that machine runs.
+It looks that when you have a `Host: ' part of the the query == proxy
+host, then the proxy thinks that you've made a bad query or something
+and forwards me the a default page, whichever Url I try to access.
+
+The proxy running there is proxy 2 (I don't know which version). The
+hack fix for this would be to remove `Host: ' from the query. Instead
+I've changed which hostname we put in the query (the way I did it,
+hostname in the query can be diferent from hostname which we make the
+query to). This fixes the proxy problem.
+
+Comments for the patch are *very* appreciated:
+
+---------------------------------------------------------------
+diff -pru dillo/src/IO/http.c dillo.new/src/IO/http.c
+--- dillo/src/IO/http.c Tue Apr 3 08:38:15 2001
++++ dillo.new/src/IO/http.c Tue Apr 3 09:54:12 2001
+@@ -184,6 +184,7 @@ static void Http_dns_callback(int Op, gu
+gint a_Http_get(const char *Url, void *Data)
+{
+gint fd;
++ gchar hostname[256];
+SocketData_t *S = g_new(SocketData_t, 1);
+
+/* Reference Web data */
+@@ -192,7 +193,8 @@ gint a_Http_get(const char *Url, void *D
+/* Hacked-in support for proxies, inspired by Olivier Aubert */
+S->port = 80;
+if (HTTP_Proxy && !(No_Proxy && strstr(Url, No_Proxy) != NULL)) {
+- a_Url_parse(HTTP_Proxy, S->hostname, sizeof(S->hostname), &S->port);
++ a_Url_parse(HTTP_Proxy, hostname, sizeof(hostname), &S->port);
++ a_Url_parse(Url, S->hostname, sizeof(S->hostname), NULL);
+S->tail = (char *) Url;
+} else {
+S->tail = a_Url_parse(Url, S->hostname, sizeof(S->hostname),
+&S->port);
+@@ -221,7 +223,7 @@ gint a_Http_get(const char *Url, void *D
+/* Let the DNS engine solve the hostname, and when done,
+* we'll try to connect the socket */
+fd = S->SockFD;
+- a_Dns_lookup(S->hostname, Http_dns_callback, (void *) S);
++ a_Dns_lookup(hostname, Http_dns_callback, (void *) S);
+/* Http_dns_callback() frees 'S', so if it finishes before this function
+* resumes, S->SockFD is lost; that's why we use 'fd'instead. --Jcid */
+return fd;
+--------------------------------------------------------------
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]patch image maps
+
+From: Eric GAUDET <egaudet@fr...> - 2001-04-03 11:13
+
+Hi all,
+Here's a tiny patch (3 lettres ;-) so dillo can handle f... err ... pages
+using incorrect arguments for their image maps area. (namely, yahoo maps'
+"Compass" image and its "shape=polygon" instead of "poly")
+
+Best,
+Eric
+
+
+diff -pur dillo-0.4.0/src/html.c dillo-0.4.0.imgmaps.fix/src/html.c
+--- dillo-0.4.0/src/html.c Wed Feb 28 10:01:58 2001
++++ dillo-0.4.0.imgmaps.fix/src/html.c Tue Apr 3 20:07:32 2001
+@@ -1111,7 +1111,7 @@ static void Html_tag_open_area(DilloHtml 
+type = DW_PAGE_SHAPE_RECT;
+} else if( strcmp(tmp, "circle") == 0 ) {
+type = DW_PAGE_SHAPE_CIRCLE;
+- } else if( strcmp(tmp, "poly") == 0 ) {
++ } else if( strncmp(tmp, "poly",4) == 0 ) {
+type = DW_PAGE_SHAPE_POLY;
+} else {
+type = DW_PAGE_SHAPE_RECT;
+
+------------------------------------
+Eric GAUDET <egaudet@fr...>
+Le 03-Apr-2001 a 20:08:30
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]Errata
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-02 23:39
+
+Hi!
+
+
+In my previous post, where it says:
+
+> BTW: I'll reply your posts in a few hours.
+
+I intended:
+
+> BTW: I'll reply Holger posts in a few hours.
+
+:-)
+
+
+Ah, and sometime ago, when I wrote:
+
+> The last weeks I've been trying to devote most of my time to
+> finishing the IO engine error control design. This had been a
+> several times procrastinated task, and I wish to push it forward
+> as much as I can this time.
+
+I meant that I want to advance with it as much as I can.
+
+
+Sorry for the confusion it could have produced.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Re: dpi1 comments
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-04-02 16:45
+
+Eric,
+
+Please excuse my delays but I have lots of work, on several
+areas, and I'm devoting all of my time to it.
+
+> [Nav in menubar]
+> here's a small patch to change dillo's interface: it saves the
+> height of the nav (location) bar by building it in the same
+> handlebox as the menubar. It looks like this: ...
+
+You may be surprised, but this is exactly what I was looking
+forward when I began to remove menubar entries. I'm pleased to
+know I have this patch and although I haven't had the time to
+test and integrate it yet, I wanted to aknowledge you this good
+reception.
+
+> [patch] back history
+> here's a patch that adds a mouse button 2 or 3 callback to the
+> toolbar buttons ...
+
+Sometime ago I considered the idea of adding right-button-menus
+to the toolbar buttons (as for specifying reload options for
+instance). Obviously the idea also applies to BACK and FORWARD,
+and has several potential posibilities.
+It'll have to wait though, at least until we finish plugins, IO
+engine error control and particularly the new URL struct scheme
+we're developing with Livio. After that, integration and
+implementation should be straightforward.
+
+
+
+On Fri, 30 Mar 2001, Eric GAUDET wrote:
+
+> Hi Jorge,
+> I've been reviewing dpi1.txt and here're my comments.
+>
+> - you disgarded everything you though was only for dpi2. I think we should keep
+> them and add them step by step.
+
+By now I'm aiming to a quick implementation of basic
+functionality of the PI stuff. That's why some of the parts
+aren't specified enough, and why some issues remain open, but at
+least with what's currently there, the most basic scheme can be
+implemented.
+
+> - you disgarded most of the possible requests in DpiRequestInfo: don't you want
+> to list them as much as possible ? I gave some anyway.
+
+I tried to group related request and to eliminate data that's
+not requires (for instance, I prefer the browser window to be
+transparent for dpi1).
+
+> - Some commands embed the client ID, some not. Can dillo know from what client
+> the command comes from without it (in the IO engine) ? I think it's needed each
+> time. If not, why provide it ?
+
+Yes it can. The ID is provided just in case a resident PI needs
+to identify different requesting channels (as long as I remember)
+
+> - the command field are 2 bytes long each. Not a word about byte significance ?
+
+Yes, I do make mistakes.
+That needs to be specified.
+
+
+> - I like the pluginrc thing. But you haven't told much about the
+> initialisation.
+
+That's an open issue.
+Currently I don't have a definitive idea of what's to be done
+here, but at least I know that each PI-program must not be run
+every time dillo is launched. That's how the pluginrc idea sprung
+into the draft.
+
+
+> I tried to provide all details in my draft: one might think it
+> as complex, but this was built from the problems I encountered when coding it.
+> I can imagine you don't like the key-challenge/response mecanism, though.
+> Anyway, I was proposing DILLO_HELLO and DILLO_WELCOME, answer with "undefined"
+> DpiRegister and DpiSendRegister doing the almost same thing ? I don't get it
+> really.
+
+To me it seems that we agree on this, but with a communication
+problem in between :-). (maybe by my side...)
+
+Maybe the solution is to add this command to the protocol:
+
+dillo -> dpi:
+
+CMD : DpiInit
+D1 : Client ID
+D2 : { Any pertinent data }
+Length: Data length
+Data : <data>
+::
+Where data is the challenge.
+
+and from dpi->dillo:
+
+CMD : DpiInitAnswer
+D1 : Client ID
+D2 : { Any pertinent data }
+Length: Data length
+Data : <data>
+::
+Where data is the answer to the challenge.
+
+(Note that the challenge can also be coded in D2, eliminating the
+need of 'data' and 'Length').
+
+As I said before, we seem to agree on this, unless I had missed
+the whole point of this issue ;-)
+
+
+> Also, I think you have the order backward, it should be:
+> * dillo forks the plugin
+> * the plugin answers with DpiSendRegister and its information
+> * dillo acknoledges with DpiRegister containing the client ID
+
+No.
+
+The draft is right, the point is that this operation is carried
+on with the only purpose of registering a new PI into dillorc.
+After that's done, the PI ends.
+If sometime in the future the PI is needed, it's forked and run
+again, this time, to perform its task.
+Note that with this scheme, after a second launch of dillo,
+that PI would be already registered inside pluginsrc, so there's
+no need to register it again.
+
+
+> - also, whilst coding the first patch, I found that using a command line option
+> (--dillo-hello) was very convenient to debug a plugin form the command line by
+> making it answer from outside dillo.
+
+Agreed, feel free to specify it (as simply as you can).
+
+> - you don't want to keep the dpi:<plugin-name> calling mecanism, you prefer to
+> make the prefix mandatory. May I ask why ?
+
+No :-)
+
+Of course you can!
+I don't remember making an explicit denial of it (and if I did,
+I don't remember why :-).
+
+Seriously, it probably doesn't appear in the draft, due to the
+above metioned reasons, but it can be easily added, provided it
+conforms with the protocol.
+
+> - nothing about how to install a plugin. I was proposing:
+> <<
+> $HOME/.dillo/plugins
+> /usr/local/share/dillo/plugins/
+> If a Dillo-plugin is found more than once, only the first one is registered,
+> the other ones are ignored: users can install their own plugins in their home
+> directory to prevent default Dillo-plugins to be used by Dillo.
+> >>
+> What's wrong with that ?
+
+Nothing Eric, I just wanted to simplify the protocol, and to
+provide an easily understandable definition with a view to a fast
+implementation of the basic PI framework. Fortunately I seem to
+have succeeded, because Holger had started working.
+
+
+BTW: I'll reply your posts in a few hours.
+
+
+Jorge.- 
+
diff --git a/old/oldmail/200105.txt b/old/oldmail/200105.txt
new file mode 100644
index 0000000..35b1ab9
--- /dev/null
+++ b/old/oldmail/200105.txt
@@ -0,0 +1,2469 @@
+Re: [Dillo-dev]authentification
+
+From: Alexey F. Bekish <admin@of...> - 2001-05-31 17:09
+
+How from all it nsubscribe????
+----- Original Message ----- 
+From: "Didier Bretin" <dbr@in...>
+To: <dillo-dev@li...>
+Sent: Thursday, May 31, 2001 6:32 PM
+Subject: [Dillo-dev]authentification
+
+
+> Hello,
+> 
+> Dillo looks good :o). Go on !!!!
+> Have you planned to deal with authentification ?
+> 
+> Regards
+> -- 
+> .------------------------------------------------.
+> .^. | Didier Bretin, France | dbr@in... |
+> /V\ |-----------------------| http://www.informactis.com |
+> // \\ | `------------------------|
+> /( )\ | Visit: http://www.linuxfr.org/ |
+> ^^-^^ `------------------------------------------------'
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]authentification
+
+From: Didier Bretin <dbr@in...> - 2001-05-31 14:32
+
+Hello,
+
+Dillo looks good :o). Go on !!!!
+Have you planned to deal with authentification ?
+
+Regards
+-- 
+.------------------------------------------------.
+.^. | Didier Bretin, France | dbr@in... |
+/V\ |-----------------------| http://www.informactis.com |
+// \\ | `------------------------|
+/( )\ | Visit: http://www.linuxfr.org/ |
+^^-^^ `------------------------------------------------' 
+
+
+
+[Dillo-dev]0.5.1 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-05-30 18:40
+
+Hi!
+
+dillo-0.5.1 is ready for download!
+
+Note that this version doesn't have tables (delayed to 0.6.0),
+but it carries a bunch of enhancements that make it worth a
+download.
+
+
+Good luck
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Tables!
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-28 14:59
+
+On Sun, May 27, I wrote:
+> [...]
+> A major bug is that image maps often don't work, there will
+> have to be some changes in the structure of DwPage and DilloHtml (see
+> my posting "Image Maps" some weeks ago), this is what I'll do next.
+
+Oh, and the find function does not work, it has to search
+recursively. Another reason to deactivate tables ... :-(
+
+Sebastian 
+
+
+
+[Dillo-dev]Tables!
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-27 11:07
+
+Hi all.
+
+A first version of table implementation is in the CVS! As promised, it
+is completely incremental, no waiting for huge-page-layout-tables is
+necessary.
+
+It is still incomplete, especially borders, colors etc. are not
+supported at all, read the comments at the beginning of
+dw_table.c. Furthermore, there are few pages which do not render as
+expected. A major bug is that image maps often don't work, there will
+have to be some changes in the structure of DwPage and DilloHtml (see
+my posting "Image Maps" some weeks ago), this is what I'll do next.
+
+All table parsing is currently done within #ifdef directives, so you
+can simply deactivates tables by commenting the line "#define
+USE_TABLES" at the beginning of html.c.
+
+
+Sebastian 
+
+
+
+[Dillo-dev]M17n (was: Re: Hi.)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-26 11:16
+
+On Fri, May 25, Jorge Arellano Cid wrote:
+> [...]
+> Some time ago, I received a small patch to enable Korean!, but
+> it required a True Type X server, and the proper fonts intalled.
+> Most probably it doesn't work with forms.
+
+The patch won't work for dillo >= 0.5.0. You'll have to change
+Dw_style_font_realize in dw_style.c. It should be simple to adjust,
+but I cannot test it since I only have latin fonts installed.
+
+> [...]
+> Dillo is small browser, and adding support for every single
+> posibility is certainly not its goal. When it comes to character
+> sets, the situation is: if there's a simple way of supporting at
+> least a certain range, it will most probably be done.
+
+Since Gtk+ 2.0 depends anyway on Pango, there should be no problem to
+use it. I haven't looked at it at all, but as I've understood, Gtk+
+2.0 plus Pango will provide an abstraction layer to handle all
+problems (encoding, rendering, text direction etc.) as simple as
+possible. There are some changes necessary, perhaps in the html
+parser, and definitely in the rendering (e.g. text directions). My
+first idea is to use Pango as much as possible, and otherwise, copy
+ideas from Pango and Gtk+ 2.0.
+
+BTW, there is Gtk+ 1.3, which is (AFAIK) feature frozen, so you can
+already start with it.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Hi.
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-05-25 18:37
+
+Hi folks!
+
+
+On Wed, 23 May 2001, Michael Govorun wrote:
+>
+> > > I'm Korean. Do you know Korea?
+> > > Korea is in asia.
+> > > Of course, my charset is 'euc-kr'
+> > > It is 2 byte.
+>
+> Hi, I'm Russian. Of course, I'm not using 2-byte charset, but I'm also
+> interesting in ability to work with international content in Dillo.
+>
+> I made some minor changes to Dillo and it work nicely with most of
+> russian sites. But all of my changes are hacks. There has to be more
+> universal scheme.
+
+Yes, probably the best solution is to write a single universal
+solution for it. Character encoding is not a simple matter, and
+very often becomes a nightmare in e-mail.
+
+I tend to think as Sebastian, and let the lower layers or
+libraries handle the problem. As you can see, GTK will work with
+Pango someday...
+
+An although I'm not an expert in character encodings, it seems
+that sometimes a True Type enabled X server is also required for
+some fonts.
+
+I've also had problems with Netscape on Japanese sites! And I
+don't want to bundle dillo with a huge font set as the do...
+
+
+> What I did:
+>
+> 1. First of all, I've inserted "Accept-Charset: koi8-r" in request
+> headers. After that step most of russian sites gives me pages in
+> koi8-r.
+>
+> 2. I have koi8-r fonts installed in X before others and Dillo renders
+> good russian text for me.
+>
+> 3. I encounter a problem inputing russian text in forms. Then I've
+> inserted gtk_set_locale(); before gtk_init(&argc, &argv);
+> in main(). And it works for me.
+>
+> But there is some problems at least with russian sites:
+> A. Some sites sending windows-1251 pages despite of my Accept-Charset
+> and such behavior is not RFC violation.
+> B. There is some broken sites sending me pages with charset not
+> corresponding to specified one. Many russian sites not specify
+> charset at all.
+> C. In russia we have more than 5 different charsets and (in theory)
+> each can be used by web-server. Oh.
+
+Some time ago, I received a small patch to enable Korean!, but
+it required a True Type X server, and the proper fonts intalled.
+Most probably it doesn't work with forms.
+
+(The patch is appended to this mail, just in case it proves
+useful for someone. The author is Yong-iL Joh, and can be reached
+at: tolkien __ mizi.com. He wasn't very wordy when I asked
+though, but he pointed me to: http://www.li18nux.org/)
+
+:)
+
+> I'm not a gtk+ expert :( and just started to learn it (with problem
+> N3). Also I'm newbie in Linux C programming. And I had no C/C++
+> programming practice for 3 years. (Last time PHP mostly). So I can't
+> solve all problems right now by myself quickly and in the best
+> universal way :(
+
+I believe the best way to go is, first, to check what GTK has
+to offer us (i.e. Pango), go there, read the docs, find out the
+whats and whys, and then reconsider the problem.
+
+In the short term, a hacked dillo may be the fastest solution.
+
+> Charset-related problems are not in "primary concerns" and not in
+> "Future Goals". What Dillo developers think about it?
+
+Just that!
+
+> Is it will be
+> easy to solve them in the future without reconstructing of Dillo
+> internals? I'm meaning all charsets, including CJK. Wouldn't it be
+> simplier to make some steps now? Or this question requires study?
+
+Dillo is small browser, and adding support for every single
+posibility is certainly not its goal. When it comes to character
+sets, the situation is: if there's a simple way of supporting at
+least a certain range, it will most probably be done.
+
+
+Jorge.-
+
+
+PS: patch follows:
+
+--- dillo.orig/src/dw_page.c Mon Mar 5 23:38:06 2001
++++ dillo/src/dw_page.c Tue Mar 13 12:23:34 2001
+@@ -1403,12 +1403,12 @@
+while (current && (font->font == NULL)) {
+comma = strchr(current, ',');
+if (comma) *comma = 0;
+- sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*",
++ sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*",
+font->name,
+font->bold ? "bold" : "medium",
+font->italic ? ItalicChar : "r",
+font->size);
+- font->font = gdk_font_load(fontname);
++ font->font = gdk_fontset_load(fontname);
+
+if (comma) {
+current = comma + 1;
+@@ -1419,22 +1419,22 @@
+g_free(name);
+
+if (font->font == NULL && font->italic) {
+- sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*",
++ sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*",
+font->name,
+font->bold ? "bold" : "medium",
+(*ItalicChar == 'o') ? "i" : "o",
+font->size);
+- font->font = gdk_font_load(fontname);
++ font->font = gdk_fontset_load(fontname);
+}
+if (font->font == NULL) {
+/* Can't load the font - substitute the default instead. */
+font->font =
+- gdk_font_load("-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-*-*");
++ gdk_fontset_load("-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-*-*,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*");
+}
+if (font->font == NULL) {
+/* Try another platform-font that should be available. (iPaq) */
+font->font =
+- gdk_font_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1");
++ gdk_fontset_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*");
+}
+if (font->font == NULL) {
+g_print("Can't load any fonts!\n"); 
+
+
+
+[Dillo-dev]dillo 0.5.0 configure problem
+
+From: Finlay Dobbie <finlay.dobbie@bt...> - 2001-05-24 20:10
+
+[ note: i am not subscribed to the list, any replies will have to go 
+directly back to me :-) ]
+configure ignores with --with-jpeg-inc parameter. I have a tree of 
+software inside /sw, and setting --with-jpeg-inc=/sw/include still 
+doesn't find the headers. they ARE there.
+
+Also, it says *** disabling jpeg support, and goes ahead to compile it 
+in anyways. it then dies with a link error later on because it didn't 
+add -ljpeg to the linker flags.
+
+so, basically, 2 errors. 1) --with-jpeg-inc ignored, 2) jpeg support 
+disablement doesn't actually work.
+
+my quick fix is this patch:
+
+diff -ru dillo-0.5.0/configure.in dillo-0.5.0-patched/configure.in
+--- dillo-0.5.0/configure.in Sat Apr 21 23:46:44 2001
++++ dillo-0.5.0-patched/configure.in Thu May 24 20:38:57 2001
+@@ -48,10 +48,11 @@
+if test -z "$LIBJPEG_LIB"; then
+AC_CHECK_LIB(jpeg, jpeg_destroy_decompress, jpeg_ok=yes, jpeg_ok=no
+AC_MSG_WARN(*** JPEG support will not be included ***))
+- if test "$jpeg_ok" = yes; then
+- AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h,
+- jpeg_ok=yes, jpeg_ok=no)
+- fi
++dnl *** THIS IS BROKEN ***
++dnl if test "$jpeg_ok" = yes; then
++dnl AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h,
++dnl jpeg_ok=yes, jpeg_ok=no)
++dnl fi
+AC_MSG_RESULT($jpeg_ok)
+if test "$jpeg_ok" = yes; then
+JPEG='jpeg'; LIBJPEG_LIB='-ljpeg'
+
+which then works, but that's of no use to you, obviously :)
+
+-- Finlay 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-23 13:24
+
+Michael, I think I'll freeze the discussion at this point. I'll start
+with a simple implementation, which will halfway usable, and later
+check it for compliance with the HTML spec.
+
+In the future, "width" and "height" attributes will be equivalent to
+the CSS attributes, so I'll check this, too. But this will probably
+take a while.
+
+Thanks for your ideas.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Killed Bug #160 (memory leak detection)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-23 13:24
+
+On Tue, May 22, Jorge Arellano Cid wrote:
+> This doesn't happen with cached images! So it is probably in
+> the DwPage code.
+
+It *does* also happen with plain text pages, so it could be either
+DwPage, or DwStyle (DwImage has no style when the URL is the image
+itself).
+
+I looked at all g_new, g_free, and friends in dw_page.c and
+dw_style.h, and fixed one leak in Dw_style_font_remove. Anything else
+seems ok, although there is no code opposed to gdk_color_alloc, but
+AFAIK, only X resources are allocated in this case.
+
+However, when I repeated the test with plain texts, the differences in
+memory usage remained the same, before and after the fix
+(Dw_style_font_remove was probably not called).
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Hi.
+
+From: Kim Jonguk <bjkju@ya...> - 2001-05-23 13:23
+
+On Wed, 23 May 2001, Michael Govorun wrote:
+
+> Hi, I'm Russian. Of course, I'm not using 2-byte charset, but I'm also
+> interesting in ability to work with international content in Dillo.
+>
+
+Nice to meet you.
+
+> I'm not a gtk+ expert :( and just started to learn it (with problem
+> N3). Also I'm newbie in Linux C programming. And I had no C/C++
+> programming practice for 3 years. (Last time PHP mostly). So I can't
+> solve all problems right now by myself quickly and in the best
+> universal way :(
+
+You are better than me. I'm novice at gtk+ & os..
+(I'm a FreeBSD user. I've heard FreeBSD is popuar in Russia. is it true?)
+I have no power.
+
+So, I request that dillo-developers take care of charset problem.
+Thank you very much.
+
+-- end. --
+
+Kim Jonguk. Korea.
+/--) --- /_ --- Band Jinsil Leader.
+/___) ) /\ ) /_) Ajou Univ. CS. THiS. 
+
+
+
+Re: [Dillo-dev]Hi.
+
+From: Michael Govorun <mike@sh...> - 2001-05-23 08:31
+
+> > I'm Korean. Do you know Korea?
+> > Korea is in asia.
+> > Of course, my charset is 'euc-kr'
+> > It is 2 byte.
+
+Hi, I'm Russian. Of course, I'm not using 2-byte charset, but I'm also
+interesting in ability to work with international content in Dillo.
+
+I made some minor changes to Dillo and it work nicely with most of
+russian sites. But all of my changes are hacks. There has to be more
+universal scheme. What I did:
+
+1. First of all, I've inserted "Accept-Charset: koi8-r" in request
+headers. After that step most of russian sites gives me pages in
+koi8-r.
+
+2. I have koi8-r fonts installed in X before others and Dillo renders
+good russian text for me.
+
+3. I encounter a problem inputing russian text in forms. Then I've
+inserted gtk_set_locale(); before gtk_init(&argc, &argv);
+in main(). And it works for me.
+
+But there is some problems at least with russian sites:
+A. Some sites sending windows-1251 pages despite of my Accept-Charset
+and such behavior is not RFC violation. 
+B. There is some broken sites sending me pages with charset not
+corresponding to specified one. Many russian sites not specify
+charset at all.
+C. In russia we have more than 5 different charsets and (in theory)
+each can be used by web-server. Oh.
+
+I'm not a gtk+ expert :( and just started to learn it (with problem
+N3). Also I'm newbie in Linux C programming. And I had no C/C++
+programming practice for 3 years. (Last time PHP mostly). So I can't
+solve all problems right now by myself quickly and in the best
+universal way :(
+
+Anyway I'm trying to expirement with charset recoding now.
+I've added charset pointer to DilloHtml struct. I wrote function
+for charset extraction from Content-Type header and I've inserted this
+extraction to a_Html_text(). Next version of Glib will contain
+g_convert() function for charset recoding. But now I'm using
+iconv(). I've inserted recoding to Html_write() function, only from
+windows-1251 to koi8-r. It works nicely.
+Now I recieved next problem with forms: some servers don't properly
+recode my input.
+
+
+> > 
+> > I saw that dillo will be able to show us frame & table.
+> > but, I could not see that dillo will be able to show me multibyte
+> > characters.
+> > There is no font selection....
+> > 
+> > Can you help me?
+> 
+> Personally, I'd like it if dillo could be able to render different
+> character sets, this will increase the amount of possible users quite
+> much :-). In Gtk+ 1.2, this is quite hard to implement, but Gtk+ 2.0
+> will depend on the Pango library, which purpose is to handle all
+> different kinds of languages. I haven't taken a look at it yet, but I
+> think that using Pango is indeed an option.
+
+As I understand GTK+ 2.0 should come out before the end of the
+year. Is it true? 
+
+Charset-related problems are not in "primary concerns" and not in
+"Future Goals". What Dillo developers think about it? Is it will be
+easy to solve them in the future without reconstructing of Dillo
+internals? I'm meaning all charsets, including CJK. Wouldn't it be
+simplier to make some steps now? Or this question requires study?
+
+-- 
+-Michael Govorun 
+
+
+
+[Dillo-dev]More leaks (Html linkblock)
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-23 06:36
+
+Hello!
+
+I think I've found a couple of more of leaks in the html linkblock
+codes. The main problem is that html->linkblock isn't freed
+automatically (on Html_close), because the info for FORMS and their
+respective callbacks need to be around in case the form is used
+(i.e. clicked). On the other hand, they *do* need to be expunged at
+some time...
+
+After hours of experimenting a best solution, I think I've found a
+very stable and "clean" one. Also there was a small leak in Html_close
+(it wasn't freeing linkblock->base_url).
+
+Finally I removed a check from a_Web_free():web.c, which (to me)
+doesn't make sense. Since the patch has more than 20 lines, I'm not
+sending it attached, but you can get it at:
+
+http://www.linux.ime.usp.br/~livio/dillo/linkblock_leak.diff
+
+The good news os that on pages with forms it leaks less than it used
+to, but the bad news is Dillo is still not 100% consistent with it's
+memory management. I'll keep hunting for more... (but not tonight :-)
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Michael Govorun <mike@sh...> - 2001-05-22 22:19
+
+> and DwTable. But what about this example:
+> 
+> <table>
+> <tr>
+> <td><img width="100%"></td>
+> <td><img width="100%"></td>
+> </tr>
+> </table>
+> 
+
+At first I wrote here the letter about normalizing that has to be
+there. 
+But then I understand that there must be no limit to viewport size!
+And no normalizing at all.
+Some sites use horizontal scrolling scheme and they need to rule
+it! 100%+100% must be 200% and there has to be horizontal scrolling in
+this case.
+
+One use 100%+100% in case of:
+1. He need it.
+2. He made mistake.
+
+> In this case, it makes more sense that both images get 50% of the
+> viewport width (I think so).
+> 
+> I've played with the code, and changed Dw_page_extremes to return (so
+> to say) infinity as maximal width in this case (equivalent to 1fil in
+> Tex), and got indeed this result:
+> 
+> ,---------------------.
+> | |<- viewport
+> |########## ##########|
+> |########## ##########<-- images
+> |########## ##########|
+> | |
+> `---------------------'
+
+there has to be
+
+,---------------------.
+| image 1 | image 2
+|#####################|#####################
+|#####################|#####################
+|#####################|#####################
+| |
+`---------------------'
+<=---- scroller ---=> 
+
+> 
+> The following:
+> 
+> <table>
+> <tr>
+> <td><img width="10%"></td>
+> <td><img width="100%"></td>
+> </tr>
+> </table>
+> 
+> will result in
+> 
+> ,- empty space
+> ,-----|---------------.
+> | | |
+> |# V ##########|
+> |# ##########|
+> |# ##########|
+> | |
+> `---------------------'
+
+and there has to be:
+
+,---------------------.
+| |
+|# ###################|#
+|# ###################|#
+|# ###################|#
+| |
+`---------------------'
+<=---- scroller ---=> 
+
+
+
+-- 
+-Michael Govorun 
+
+
+
+Re: [Dillo-dev]Killed Bug #160 (memory leak detection)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-22 16:56
+
+On Tue, May 22, Jorge Arellano Cid wrote:
+> [memory leaks]
+> On Apr 18, Sebatian wrote
+> > "Soon" has taken a bit longer, but at least the interface and the
+> > modifications of html.c and dw_page.c are finished. The implementation
+> > of styles (which are currently mainly the same) is still buggy (but
+> > stable, mainly only memory leaks), and I'll test several variations of
+> > implementation details for speed and memory usage.
+> 
+> So this is the place to start hunting.
+
+I just fixed one (GCs were not freed) :-), but the problem is still
+there, and I meant something different in the mail you quoted.
+
+DwStyle has a built-in check for memory leaks, all structures are
+either stored in a hashtable, or counted. a_Dw_style_freeall tests if
+some are not removed properly, and prints a warning in this case.
+
+From time to time, I get this warning; fonts and colors are always ok
+(note that the remaining styles hold references on them), only styles
+are left. From the leaks I fixed in the last time, most were referred
+to widgets, so I guess that this is still buggy.
+
+However, this occurs rather rarely, and the problem also arises if all
+styles are removed properly.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Hi.
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-22 16:56
+
+Hi Kim,
+
+On Wed, May 23, Kim Jonguk wrote:
+> [...]
+> I installed 'Dillo-0.4.0'. 5 min before.
+
+I'd suggest to install 0.5.0, it provides some advantages. There are
+no "instable" versions of dillo.
+
+> [...]
+> I'm Korean. Do you know Korea?
+> Korea is in asia.
+> Of course, my charset is 'euc-kr'
+> It is 2 byte.
+> 
+> I saw that dillo will be able to show us frame & table.
+> but, I could not see that dillo will be able to show me multibyte
+> characters.
+> There is no font selection....
+> 
+> Can you help me?
+
+Personally, I'd like it if dillo could be able to render different
+character sets, this will increase the amount of possible users quite
+much :-). In Gtk+ 1.2, this is quite hard to implement, but Gtk+ 2.0
+will depend on the Pango library, which purpose is to handle all
+different kinds of languages. I haven't taken a look at it yet, but I
+think that using Pango is indeed an option.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Killed Bug #160 (memory leak detection)
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-05-22 15:36
+
+Hi there!
+
+
+> Hello people!
+>
+> After long hours of bug hunting, I've finally found bug #160 (dillo
+> caches the same file more than once). Well, is doesn't!
+> [...]
+> So here's the tiny patch , which fixes a big problem:
+
+> [...]
+
+> Have I missed something?
+>
+> It seems that Dillo's memory usage has become a lot better now, but
+> I fear some more leaks are still around :-(
+
+Yes they are.
+
+> Does anyone know of a good/usable library or tool for memory profiling
+> or memory leak detection? I've heard of libsafe from AmayaLabs, but it
+> seems to be designed for buffer overflow detection. And I'be also
+> heard of others like mpatrol, memprof, Electric Fence, ccmalloc, and
+> even glib is supposed to support memory profiling, but I've never
+> worked with any of them (and it's about time I do :-). So before I
+> choose one, I'd like to here your opinions on these. Hopefully using
+> one these will make make leak chasing a lot easier. I'll be glad to
+> here any suggestions!
+
+We can use g_mem_check and g_mem_profile among others.
+BTW: there's code in dillo modules for freeing their resources
+in order to make more sense out of this functions. Anyway, you
+can use what suits better to you.
+
+Regarding the memory leak problem, a small leak remains: if you
+go BACK and then FORWARD on a page, it will show.
+
+Just try: 'ps aux | grep dillo' to check it.
+
+This doesn't happen with cached images! So it is probably in
+the DwPage code. Even more:
+
+On Apr 18, Sebatian wrote
+> "Soon" has taken a bit longer, but at least the interface and the
+> modifications of html.c and dw_page.c are finished. The implementation
+> of styles (which are currently mainly the same) is still buggy (but
+> stable, mainly only memory leaks), and I'll test several variations of
+> implementation details for speed and memory usage.
+
+So this is the place to start hunting.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Hi.
+
+From: Kim Jonguk <bjkju@ya...> - 2001-05-22 15:02
+
+Nice to meet you.
+
+First. understand my poor english.
+I'm Korean.
+
+This is my first mail to you.
+I installed 'Dillo-0.4.0'. 5 min before.
+
+It's very nice & fast.
+Because my computer is very slow, I become to favor.
+
+but...
+
+I'm Korean. Do you know Korea?
+Korea is in asia.
+Of course, my charset is 'euc-kr'
+It is 2 byte.
+
+I saw that dillo will be able to show us frame & table.
+but, I could not see that dillo will be able to show me multibyte
+characters.
+There is no font selection....
+
+Can you help me?
+
+Thank you for reading my mail.
+Enjoy my poor english. :)
+
+-- end. --
+
+Kim Jonguk. Korea.
+/--) --- /_ --- Band Jinsil Leader.
+/___) ) /\ ) /_) Ajou Univ. CS. THiS. 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-22 14:20
+
+On Tue, May 22, Michael Govorun wrote:
+> > At toplevel: yes (the latter). The width of the viewport is passed as
+> > width hint to the DwPage. This width is used by DwPage for (i) word
+> > wrapping, and (ii) for calculating percentages. The real width of the
+> > page is, of course, different in most cases. The question is how to
+> > calculate (ii) in further nested widgets.
+> 
+> introduce "available_space" parameter (available_width)
+> and pass it with hint from parent to child. It can be used in cases: 
+> 1. to calculate percentages when there is no defined width.
+> 2. for word wraping when there is no defined width.
+> 
+> in our lovely example there is no self-referring:
+> <table> available_width=600 (from parent)
+> <tr>
+> <td> available_width=600 (-border -margins) 
+> <img width="100%"> available_width=600 (-padding) => width=600
+> </td>
+> </tr>
+> </table>
+
+This available_width already exists, look at the definitions of DwPage
+and DwTable. But what about this example:
+
+<table>
+<tr>
+<td><img width="100%"></td>
+<td><img width="100%"></td>
+</tr>
+</table>
+
+In this case, it makes more sense that both images get 50% of the
+viewport width (I think so).
+
+I've played with the code, and changed Dw_page_extremes to return (so
+to say) infinity as maximal width in this case (equivalent to 1fil in
+Tex), and got indeed this result:
+
+,---------------------.
+| |<- viewport
+|########## ##########|
+|########## ##########<-- images
+|########## ##########|
+| |
+`---------------------'
+
+The following:
+
+<table>
+<tr>
+<td><img width="10%"></td>
+<td><img width="100%"></td>
+</tr>
+</table>
+
+will result in
+
+,- empty space
+,-----|---------------.
+| | |
+|# V ##########|
+|# ##########|
+|# ##########|
+| |
+`---------------------'
+
+This seems halfway plausible, IMHO. The code I sent you will instead
+show nothing.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Michael Govorun <mike@sh...> - 2001-05-22 11:22
+
+> At toplevel: yes (the latter). The width of the viewport is passed as
+> width hint to the DwPage. This width is used by DwPage for (i) word
+> wrapping, and (ii) for calculating percentages. The real width of the
+> page is, of course, different in most cases. The question is how to
+> calculate (ii) in further nested widgets.
+
+introduce "available_space" parameter (available_width)
+and pass it with hint from parent to child. It can be used in cases: 
+1. to calculate percentages when there is no defined width.
+2. for word wraping when there is no defined width.
+
+in our lovely example there is no self-referring:
+<table> available_width=600 (from parent)
+<tr>
+<td> available_width=600 (-border -margins) 
+<img width="100%"> available_width=600 (-padding) => width=600
+</td>
+</tr>
+</table>
+
+-- 
+-Michael Govorun 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-21 20:12
+
+Hi Michael,
+
+I fear this has become more complicated than really needed ... ;-)
+
+First of all, widgets are mostly resized from top to down. There are
+only few exceptions (e.g. if an image has an unspecified size which
+gets known later), but this is also delivered to the toplevel
+widget. Of course, the parent widget may honor size requests of the
+child.
+
+On Mon, May 21, Michael Govorun wrote:
+> [...]
+> > However, for calculating the column widths, the minimal and maximal
+> > width has to be known (this is done by an additional function, for
+> > efficiency), and if an image is embedded in the page, with a size of
+> > 100%, the maximal width is of course infinitive, but this would
+> > confuse the algorithm. Furthermore, n1 * infinity equals n2 *
+> > infinity, also if n1 and n2 are different. A good solution would
+> > perhaps to adapt the idea how TeX deals with different "levels" of
+> > infinity.
+
+I meant this "fil" could be useful as a "mathematical unit".
+
+> I think percentage means "Look at size of parent". And so if we have
+> percentage in size of child we should get it's maximum
+> width from it's parent.
+
+The problem is, that this is often self-referring. *Maximum* could be
+an option. I'll think about it.
+
+> As I understand, there has to be two ways of size info interchange:
+> from parent to child when we have undefined child size, and way to
+> calculate size of parent when we have undefined parent size and know
+> sizes of childs.
+
+Yes, see above. But this case (and most other cases) is the first you
+mentioned.
+
+> [...]
+> How can we pass what we don't know yet!!? We can only pass info about
+> the fact that width of DwPage [1] is not defined yet. Or(and?) pass
+> default maximum (it can be size of visible area or whatever?).
+
+At toplevel: yes (the latter). The width of the viewport is passed as
+width hint to the DwPage. This width is used by DwPage for (i) word
+wrapping, and (ii) for calculating percentages. The real width of the
+page is, of course, different in most cases. The question is how to
+calculate (ii) in further nested widgets.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Michael Govorun <mike@sh...> - 2001-05-21 17:25
+
+Hi Sebastian
+
+> I haven't uploaded anything until now. My current work is very
+> unstable, and committing it to the CVS would disturb developers
+> working on other parts. However, I can send a patch to anyone who is
+> interested.
+Yes, I'm interesting.
+
+> The table structure in short:
+> 
+> - The HTML parser is extended to write text into different DwPage
+> widgets.
+> 
+> - There is a new widget DwTable, embedding other DwPage
+> widgets. (So you have a widget structure halfway close to the
+> document structure, see also my other posting, "Ideas on CSS".)
+> 
+> - The DwPage widget gets a new mode to deal with embedded widgets.
+> 
+> A widget can define how to deal with "size hints". Currently, the
+> viewport size is used to set the size of the toplevel DwPage widget
+> _by_hints_ (by the set_... functions), not directly (this would be
+> done by size_allocate), and DwPage uses this to recalculate its size
+> (returned by size_request). There is some documentation in the doc/
+> directory, start with Dw.txt.
+> 
+> DwPage knows two modes now how to deal with children:
+> 
+> - For simple widgets, like images, the size is set directly via
+> size_allocate.
+> 
+> - For more complex images, like tables, hints are used.
+> 
+> The DwTable widget itself calculates the column widths from the hinted
+> width, and passes them further to the child widgets.
+> 
+> However, for calculating the column widths, the minimal and maximal
+> width has to be known (this is done by an additional function, for
+> efficiency), and if an image is embedded in the page, with a size of
+> 100%, the maximal width is of course infinitive, but this would
+> confuse the algorithm. Furthermore, n1 * infinity equals n2 *
+> infinity, also if n1 and n2 are different. A good solution would
+> perhaps to adapt the idea how TeX deals with different "levels" of
+> infinity.
+
+I think percentage means "Look at size of parent". And so if we have
+percentage in size of child we should get it's maximum
+width from it's parent.
+
+As I understand, there has to be two ways of size info interchange:
+from parent to child when we have undefined child size, and way to
+calculate size of parent when we have undefined parent size and know
+sizes of childs.
+
+
+> 
+> (BTW, the algorithm to calculate the column widths is quite
+> uninteresting, I've already modified it a few times.)
+> 
+> About the examples: The first one will result in
+> 
+> DwPage [1]
+> `-DwTable
+> `-DwPage [2]
+> `-DwImage
+> 
+> where the DwPage [1] passes its width as a hint to DwTable, but
+
+How can we pass what we don't know yet!!? We can only pass info about
+the fact that width of DwPage [1] is not defined yet. Or(and?) pass
+default maximum (it can be size of visible area or whatever?). Then
+when we reach last child and if there is still indefinite size of
+parent - we can use it.
+Otherwize, if we need to start rendering earlier than all sizes will
+be set we can use that default maximum (or minimum?) and later do
+resizing. What do you think about it?
+
+
+> DwTable does not know what width DwPage [2] should have. The second
+> will look like
+> 
+> DwPage [1]
+> _____`-DwTable [1]_________
+> `-DwPage [2]
+> `-DwTable [2]
+> `-DwPage [3]
+> `-DwImage
+> 
+> and DwTable [1] will probably pass 70% of its width (received by
+> DwPage [1]) to DwPage [2]. So the problem is equivalent, the part
+> below the line equals the example above.
+
+
+
+> I haven't looked at the CSS spec in detail, but it contains much more
+> about this problem. I'll have to take a more comprehensive look at it.
+> 
+> BTW, I plan indeed to implement any attributes, which are deprecated
+> and will replaced by CSS equivalents, quite close to the CSS spec. In
+> the near future (i.e. before starting with CSS implementation), I'll
+> extend more and more the structure DwStyle for this. Later, it becomes
+> a fundamental structure for CSS. Deprecated attributes will only
+> mapped on the CSS implementation.
+I think, it is good plan.
+
+-- 
+-Michael Govorun 
+
+
+
+Re: [Dillo-dev]Killed Bug #160 (memory leak detection)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-21 15:10
+
+On Mon, May 21, Livio Baldini Soares wrote:
+> [...]
+> So here's the tiny patch , which fixes a big problem:
+> [...]
+
+Done, together with another leak (page->shapes[i].data.poly).
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Which space is available in a table cell?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-21 14:42
+
+Hi Michael,
+
+On Mon, May 21, Michael Govorun wrote:
+> > Hi,
+> >
+> > I wonder how to calculate lengths, specified by percentages, within
+> > table cells, e.g. for images. The HTML spec only says that it should
+> > be calculated from the "available space".
+> >
+> > Currently, such lengths are calculated from the viewport
+> > size. Calculating element sizes from the sizes of the containing
+> > elements is self-referring, and so hardly defined. E.g. in
+> >
+> > <table>
+> > <tr><td><img src="maj00s.gif" width="100%"></td></tr>
+> > </table>
+> >
+>
+> I think we should calculate it from available space in next outer layer
+> (img->td->table->...->viewport) where it defined.
+> In the example above it defined at viewport level.
+>
+> But in this example:
+>
+> <html>
+> <table width="70%"><tr><td>
+> <table>
+> <tr><td><img src="maj00s.gif" width="100%"></td></tr>
+> </table>
+> </td></tr></table>
+> </html>
+>
+> available space for image defined in level of the outer table, but in
+> turn, width of the outer table must be calculated from viewport width.
+
+There is currently no support for the width attribute (I've just
+started), but this will (probably) result in the same problem, see
+below.
+
+> I can contribute my ideas of full algoritm, but I have no info about
+> current table structure :(
+> and I'm pretty new to dillo development
+
+I haven't uploaded anything until now. My current work is very
+unstable, and committing it to the CVS would disturb developers
+working on other parts. However, I can send a patch to anyone who is
+interested.
+
+The table structure in short:
+
+- The HTML parser is extended to write text into different DwPage
+widgets.
+
+- There is a new widget DwTable, embedding other DwPage
+widgets. (So you have a widget structure halfway close to the
+document structure, see also my other posting, "Ideas on CSS".)
+
+- The DwPage widget gets a new mode to deal with embedded widgets.
+
+A widget can define how to deal with "size hints". Currently, the
+viewport size is used to set the size of the toplevel DwPage widget
+_by_hints_ (by the set_... functions), not directly (this would be
+done by size_allocate), and DwPage uses this to recalculate its size
+(returned by size_request). There is some documentation in the doc/
+directory, start with Dw.txt.
+
+DwPage knows two modes now how to deal with children:
+
+- For simple widgets, like images, the size is set directly via
+size_allocate.
+
+- For more complex images, like tables, hints are used.
+
+The DwTable widget itself calculates the column widths from the hinted
+width, and passes them further to the child widgets.
+
+However, for calculating the column widths, the minimal and maximal
+width has to be known (this is done by an additional function, for
+efficiency), and if an image is embedded in the page, with a size of
+100%, the maximal width is of course infinitive, but this would
+confuse the algorithm. Furthermore, n1 * infinity equals n2 *
+infinity, also if n1 and n2 are different. A good solution would
+perhaps to adapt the idea how TeX deals with different "levels" of
+infinity.
+
+(BTW, the algorithm to calculate the column widths is quite
+uninteresting, I've already modified it a few times.)
+
+About the examples: The first one will result in
+
+DwPage [1]
+`-DwTable
+`-DwPage [2]
+`-DwImage
+
+where the DwPage [1] passes its width as a hint to DwTable, but
+DwTable does not know what width DwPage [2] should have. The second
+will look like
+
+DwPage [1]
+_____`-DwTable [1]_________
+`-DwPage [2]
+`-DwTable [2]
+`-DwPage [3]
+`-DwImage
+
+and DwTable [1] will probably pass 70% of its width (received by
+DwPage [1]) to DwPage [2]. So the problem is equivalent, the part
+below the line equals the example above.
+
+> > the image can have any width. The same with other examples.
+> >
+> > Should we refer to the CSS specification?
+> My opinion: yes, and we should take into account all margins,
+> paddings, borders, etc.
+
+I haven't looked at the CSS spec in detail, but it contains much more
+about this problem. I'll have to take a more comprehensive look at it.
+
+BTW, I plan indeed to implement any attributes, which are deprecated
+and will replaced by CSS equivalents, quite close to the CSS spec. In
+the near future (i.e. before starting with CSS implementation), I'll
+extend more and more the structure DwStyle for this. Later, it becomes
+a fundamental structure for CSS. Deprecated attributes will only
+mapped on the CSS implementation.
+
+
+Sebastian 
+
+
+
+[Dillo-dev]Killed Bug #160 (memory leak detection)
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-21 14:24
+
+Hello people!
+
+After long hours of bug hunting, I've finally found bug #160 (dillo
+caches the same file more than once). Well, is doesn't!
+Actually it's a (not so small ;-) memory leak in dw_page.c
+(Dw_page_destroy).
+The patch actually is very simple. (It's impressive how *after* hunting
+a bug with a small patch, it seems soooo easy and obvious :-)
+
+So here's the tiny patch , which fixes a big problem:
+
+********************
+--- dillo/src/dw_page.c Mon May 21 10:35:03 2001
++++ dillo.new/src/dw_page.c Mon May 21 10:52:26 2001
+@@ -277,7 +277,7 @@ static void Dw_page_destroy (GtkObject *
+
+g_free(page->lines);
+page->num_words = 0; /* make sure we don't own widgets anymore */
+-
++ g_free(page->words);
+g_free(page->shapes);
+
+for (link_index = 0; link_index < page->num_links; link_index++) {
+************************
+
+Have I missed something? 
+
+It seems that Dillo's memory usage has become a lot better now, but
+I fear some more leaks are still around :-( 
+Does anyone know of a good/usable library or tool for memory profiling
+or memory leak detection? I've heard of libsafe from AmayaLabs, but it
+seems to be designed for buffer overflow detection. And I'be also
+heard of others like mpatrol, memprof, Electric Fence, ccmalloc, and
+even glib is supposed to support memory profiling, but I've never
+worked with any of them (and it's about time I do :-). So before I
+choose one, I'd like to here your opinions on these. Hopefully using
+one these will make make leak chasing a lot easier. I'll be glad to
+here any suggestions!
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Which space is available in a table cell?
+
+From: Michael Govorun <mike@sh...> - 2001-05-21 12:39
+
+> Hi,
+> 
+> I wonder how to calculate lengths, specified by percentages, within
+> table cells, e.g. for images. The HTML spec only says that it should
+> be calculated from the "available space".
+> 
+> Currently, such lengths are calculated from the viewport
+> size. Calculating element sizes from the sizes of the containing
+> elements is self-referring, and so hardly defined. E.g. in
+> 
+> <table>
+> <tr><td><img src="maj00s.gif" width="100%"></td></tr>
+> </table>
+> 
+
+I think we should calculate it from available space in next outer layer
+(img->td->table->...->viewport) where it defined.
+In the example above it defined at viewport level.
+
+But in this example:
+
+<html>
+<table width="70%"><tr><td>
+<table>
+<tr><td><img src="maj00s.gif" width="100%"></td></tr>
+</table>
+</td></tr></table> 
+</html>
+
+available space for image defined in level of the outer table, but in
+turn, width of the outer table must be calculated from viewport width.
+
+I can contribute my ideas of full algoritm, but I have no info about
+current table structure :( 
+and I'm pretty new to dillo development
+
+
+> the image can have any width. The same with other examples.
+> 
+> Should we refer to the CSS specification?
+My opinion: yes, and we should take into account all margins,
+paddings, borders, etc. 
+
+
+-- 
+-Michael Govorun 
+
+
+
+Re: [Dillo-dev]Bug in IO_read's
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-05-21 06:47
+
+Livio,
+
+>
+> I've discovered some more about this...
+> > [...]
+> > IO_read ERROR: Resource temporarily unavailable
+> >
+> > Not only has this error been systematic but now causes a Segv on my
+> > system, because when it happens while `reading', we get thrown into
+> > a_Cache_ccc with OpAbort (and since we're reading, we're in Branch
+> > 2... as I see it writing is Branch 1 and reading Branch 2, right
+> > Jorge?). From there we get thrown into a_Cache_callback(IOAbort,
+> > NULL). And in a_Cache_callback, we do: const DilloUrl * Url =
+> > io->CbData... except io is NULL :-(
+>
+> Ok, this error seems to manifest itself only on SMP systems, and not
+> in UP systems. The patch I sent (in the previous e-mail) definately
+> fixes this misbehaviour. For the unbeliever I have copied a compiled
+> copy (*with* debugging symbols, i.e. not stripped) to
+> shell.so....net (usw-pr-shell1.so....net is a SMP, with 2
+> CPUs).
+
+Actually, the problem MAY manifest on single processors too,
+that depends on several things. The EAGAIN error, or EWOULDBLOCK
+on BSDs, is meant for a temporary delay on the operation (for
+instance while the kernel waits for a stopped HD to resume its
+available condition --this may vary on different OSs though...).
+
+I was thinking that threads in the detached state, freeing
+their allocated resources upon end, may be temporarily blocking
+file descriptors activity. That's good, the problem was that the
+code was not handling EAGAIN, as the 'todo:' stated!
+
+I'll check the code after fixing the new Url handling issues.
+
+Good research Livio, that will surely improve dillo's stability
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Cache question (about process queue)
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-05-21 06:47
+
+Livio,
+
+> Hello!
+>
+> Does anybody know why {a_}Cache_open_url(), uses
+> Cache_delayed_process_queue(), instead of calling
+> Cache_process_queue()?
+
+Yes man: a_Cache_open_url returns a client-key (identifier) to
+the calling function. The caller MUST receive the key before the
+client queue is processed. That's the delay for.
+
+> I mean, is there any use in making a 1 second
+> timeout before retrieving the desired data, besides making the user
+> wait longer? ;-)
+
+No, there's no need for the 1 second wait!
+(except for what's stated above)
+
+> Can anybody help me?
+
+Keep on reading...
+
+> I tried to get rid of it, and Dillo "feels" faster (root-url and
+> images seem to load faster). The only reason I can guess the delay is
+> there is to avoid concurrency in ClientQueue, but I don't think that
+> that's a good way to do it. If that's the reason then we can device a
+> better way to eliminate concurrency. I made a "hack" for this, which
+> seems better then what we have now, but maybe a better solution can be
+> discussed? Any ideas?
+
+Thinking twice about it, and assuming that the GTK idle
+functions are processed in the main GTK cycle, after all the
+other "normal" functions are done, and considering that delayed
+processing is used only for cached answers, using a plain idle
+function seems to be a good solution.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Which space is available in a table cell?
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-20 16:49
+
+Hi,
+
+I wonder how to calculate lengths, specified by percentages, within
+table cells, e.g. for images. The HTML spec only says that it should
+be calculated from the "available space".
+
+Currently, such lengths are calculated from the viewport
+size. Calculating element sizes from the sizes of the containing
+elements is self-referring, and so hardly defined. E.g. in
+
+<table>
+<tr><td><img src="maj00s.gif" width="100%"></td></tr>
+</table>
+
+the image can have any width. The same with other examples.
+
+Should we refer to the CSS specification?
+
+I'm hoping on hints and ideas.
+
+Sebastian 
+
+
+
+[Dillo-dev]Ideas on CSS
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-20 14:45
+
+Hi all,
+
+although I'm currently working mainly on tables, I've tried to
+summarize my ideas on an implementation of CSS. It is not a detailed
+design, but only a collection of vague ideas. Any kind of comments are
+welcome.
+
+Sebastian
+
+----------------------------------------------------------------------
+
+Ideas on an Implementation of CSS
+=================================
+
+Document Tree, Widget Tree, Document-Widget Interface
+-----------------------------------------------------
+The HTML parser is extended to build a tree, which should be
+consistent all the time (i.e. between two calls of Html_write).
+Furthermore, there will be an interface to the Dw widget structure,
+mapping document elements on lists of widgets or parts of widgets. A
+simple, incomplete example could look like this:
+
+HTML Document Widget Structure
+
+<html>
+<head>
+<title>
+Simple Example
+</title>
+</head>
+<body> ----------------------> DwPage
+<h1>Simple Example</h1> ----> { +- DwPageWord
+{ +- DwPageWord
+<table> -------------------> `- DwTable
+<tr> |
+<td>No. 1</td> --------> +- DwPage
+| `- ...
+<td>No. 2</td> --------> +- DwPage
+| `- ...
+</tr> |
+<tr> |
+<td>No. 3</td> --------> +- DwPage
+| `- ...
+<td>No. 4</td> --------> `- DwPage
+`- ...
+</tr>
+</table>
+
+[This is very incomplete, this interface has to be worked out
+completely.]
+
+Note that the interface also includes _parts_ of a widget, because
+this may make more efficient implementations possible (example:
+DwPageWord instead of a widget DwWord). Widgets get consistent
+interface to access parts of a widget, e.g. referencing and applying
+style attributes. (Idea: perhaps this can be simplified, by making
+widgets a special case of widget parts.)
+
+
+CSS
+---
+Of course, there is the need for a CSS parser. It can be as simple as
+possible (e.g. generated by yacc), there is no need for an incremental
+parser, as used for HTML. Instead, the CSS text can be written into a
+buffer, and then parsed as a whole.
+
+In this text, "CSS" means the internal representation of the CSS text,
+after parsing.
+
+
+Styles and Blocks
+-----------------
+There is already now the structure DwStyle, used as a uniform
+structure for presentation attributes of widgets and parts of
+widgets. It is extended, by attributes, as well as by general
+rendering functions for borders, backgrounds etc. (Although the
+DwStyle structure is uniform, it is probably not possible to achieve
+the same for the code.)
+
+A CSS block is represented by a style and a bit mask containing
+specified attributes. The CSS module will provide a function for
+calculating the style of a specific HTML element, by evaluating rules
+and combining blocks, to get a DwStyle.
+
+
+Applying a CSS to the Document/Widget Tree
+------------------------------------------
+There are two methods necessary:
+
+1. Incrementally, while the HTML document is read. In this case,
+the styles are calculated, when the widgets/widget parts are
+created.
+
+2. Instantly, by applying styles to all widgets/widget parts of the
+(currently existing) document/widget tree.
+
+Each HTML document has a CSS. Initially, it is the user defined
+one. The HTML parser will modify it in two cases:
+
+- When <style ...> is read: in this case, the text is stored in the
+stash, and then parsed. After this, styles are applied
+incrementally.
+
+- When <link ref="style" ...> is read: in this case, the CSS
+document is retrieved and stored in a buffer, while the HTML
+parser continues to use the old CSS for rendering. After the
+CSS text has been read and parsed, the new CSS is applied on the
+HTML document instantly. After then, styles are applied
+incrementally. 
+
+
+
+[Dillo-dev]Cache question (about process queue)
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-20 00:14
+
+Hello!
+
+Does anybody know why {a_}Cache_open_url(), uses
+Cache_delayed_process_queue(), instead of calling
+Cache_process_queue()? I mean, is there any use in making a 1 second
+timeout before retrieving the desired data, besides making the user
+wait longer? ;-)
+
+Can anybody help me?
+
+I tried to get rid of it, and Dillo "feels" faster (root-url and
+images seem to load faster). The only reason I can guess the delay is
+there is to avoid concurrency in ClientQueue, but I don't think that
+that's a good way to do it. If that's the reason then we can device a
+better way to eliminate concurrency. I made a "hack" for this, which
+seems better then what we have now, but maybe a better solution can be
+discussed? Any ideas?
+
+My patch can be found at:
+http://www.linux.ime.usp.br/~livio/dillo/no_delay.diff
+
+
+best regards!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bug in IO_read's
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-19 19:38
+
+Hi,
+
+I've discovered some more about this...
+
+Livio Baldini Soares writes:
+> Hi all (Jorge)!
+> 
+
+(...)
+
+> IO_read ERROR: Resource temporarily unavailable
+> 
+> Not only has this error been systematic but now causes a Segv on my
+> system, because when it happens while `reading', we get thrown into
+> a_Cache_ccc with OpAbort (and since we're reading, we're in Branch
+> 2... as I see it writing is Branch 1 and reading Branch 2, right
+> Jorge?). From there we get thrown into a_Cache_callback(IOAbort,
+> NULL). And in a_Cache_callback, we do: const DilloUrl * Url =
+> io->CbData... except io is NULL :-(
+
+Ok, this error seems to manifest itself only on SMP systems, and not
+in UP systems. The patch I sent (in the previous e-mail) definately
+fixes this misbehaviour. For the unbeliever I have copied a compiled
+copy (*with* debugging symbols, i.e. not stripped) to
+shell.so....net (usw-pr-shell1.so....net is a SMP, with 2
+CPUs). 
+
+For anyone who has an account in sourceforge (and you've got a pretty
+good internet connection), just do:
+
+$ cd ~livio/tmp
+$ gdb ./dillo
+
+And browse to hosts "far away" from sourceforge,
+http://www.rti-zone.org/dillo, for example. I get:
+
+> Cache CCC (OpEnd) [0]
+> IO_read ERROR: Resource temporarily unavailable
+> [Switching to Thread 1270 (initial thread)]
+> Program received signal SIGSEGV, Segmentation fault.
+> 0x80529ce in a_Cache_callback (Op=4, VPtr=0x0) at cache.c:412
+
+90% of the time.
+
+I also copied a fixed version (with EAGAIN in
+DILLO_TEMP_FAILURE_RETRY, like in my patch). You can try it:
+
+$ gdb ./dillo.fixed
+
+I can't get that version to make a Segv :-)
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Bookmarked pages
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-05-18 01:31
+
+Hi!
+
+> I think doing a fflush() on the file _should_ fix this. For me it
+> did. Jorge what do you think? Here's the diff:
+> [...]
+
+Done.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Bookmarked pages
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-17 21:01
+
+Hi all!
+
+Sometimes while I'm testing Dillo, I have to bookmark a page to test
+it faster. But right after I bookmark it, and follow a link, *if*
+Dillo gets a Segv, my bookmark aren't commited to the bookmark file,
+therefore I have to open Dillo again, go to the page, bookmark it, and
+close dillo to make sure the bookmark is saved (or edit bookmarks.html
+by hand :-P).
+
+I think doing a fflush() on the file _should_ fix this. For me it
+did. Jorge what do you think? Here's the diff:
+
+******************
+--- dillo/src/bookmark.c Sat May 12 21:29:19 2001
++++ dillo.new/src/bookmark.c Thu May 17 17:54:15 2001
+@@ -268,6 +268,7 @@ static void Bookmarks_save_to_file(FILE 
+D_QUOTE, url_str);
+}
+fwrite(buf, strlen(buf), 1, fp);
++ fflush(fp);
+g_free(buf);
+g_free(url_str);
+}
+******************
+
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Bug in IO_read's
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-17 14:33
+
+Hi all (Jorge)!
+
+I found a little bug in IO_read (well, not actually IO_read, but
+DILLO_TEMP_FAILURE_RETRY). This bug has been following me from time to
+time. But it was *very* occasional, so I ignored it. But after CVS
+changes today in IO and pthread, this problem has become
+systematic. The problem was the following error:
+
+IO_read ERROR: Resource temporarily unavailable
+
+Not only has this error been systematic but now causes a Segv on my
+system, because when it happens while `reading', we get thrown into
+a_Cache_ccc with OpAbort (and since we're reading, we're in Branch
+2... as I see it writing is Branch 1 and reading Branch 2, right
+Jorge?). From there we get thrown into a_Cache_callback(IOAbort,
+NULL). And in a_Cache_callback, we do: const DilloUrl * Url =
+io->CbData... except io is NULL :-(
+
+I printed out the number of the error that the IO thread was
+getting. It was 11 (on my system), and it corresponds to EAGAIN.
+#define EAGAIN 11 /* Try again */
+And here is a snippet from {read,write}v:
+
+EAGAIN Non-blocking I/O had been selected in the open()
+call, and reading or writing could not be done
+immediately.
+
+So that's what I did, changed DILLO_TEMP_FAILURE_RETRY to accept
+EAGAIN. Here's the diff:
+
+********************
+--- dillo/src/IO/IO.c Thu May 17 10:08:54 2001
++++ dillo.new/src/IO/IO.c Thu May 17 11:27:34 2001
+@@ -36,7 +36,7 @@
+
+# define DILLO_TEMP_FAILURE_RETRY(st, expression) \
+{ do st = (glong) (expression); \
+- while (st == -1L && errno == EINTR); }
++ while (st == -1L && (errno == EINTR || errno == EAGAIN) ); }
+
+/*
+* Forward declarations
+***********************
+
+I've been browsing now for a good half hour and everything seems
+fine. Except that I think that Dillo initialization seems slower after
+Jorge's changes in IO and pthreads... but it might just be the
+University computer (low funds for grad students :-(((
+
+What do you guys think?
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Historical Question ;-)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-16 15:12
+
+Hi!
+
+Once (I think it was a 0.3.x version), someone changed the rendering
+of lists: before, the rendering looked like:
+
+* There's a dillorc file within the tarball; copy it to
+~/.dillo/ directory.
+^
+aligned
+
+and now it is:
+
+* There's a dillorc file within the tarball; copy it to
+~/.dillo/ directory.
+^
+same indent
+
+I think the problem was that following paragraphs were not rendered
+correctly, like:
+
+* There's a dillorc file within the tarball; copy it to
+~/.dillo/ directory.
+
+Imagine more and more and more and more and more and more and
+more and more and text.
+^
+paragraph should start here
+
+since the left_indent_first attribute was also applied on this
+paragraph, so the current solution is probably the "minor evil". As a
+side-effect, left_indent_first and left_indent_rest have now always
+the same values.
+
+I don't like the current rendering very much, and will try to find a
+fix for this (with the "<li><p>" problem in mind). However, I'd like
+to remove the distinction of left_indent_first and left_indent_rest,
+and simply replace it by left_indent, this would make many things
+simpler. I just post this to receive some objections, in case that it
+could have a purpose I did not note.
+
+
+Sebastian 
+
+
+
+[Dillo-dev]about bug #157 (another bug :-(
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-15 19:51
+
+Hi,
+
+if anyone wants to check out the site in bug #157
+(http://www.wotsit.org/download.asp?f=afm), they'll have to apply this
+patch to current CVS code (or use 0.5.0 vanilla version). I have
+introduced a bug in the redirection scheme, namely when the
+redirection is a /relative/ URL. I'll fix this soon with Jorge. But
+first I guess I have to make a series of "improvements" in the current
+URL module, sorry guys... 
+
+Here's the patch (to be applied against src/cache.c).
+
+*************
+--- cache.c Tue May 15 16:35:49 2001
++++ ../../dillo/src/cache.c Sun May 13 19:21:20 2001
+@@ -322,7 +322,7 @@ char *Cache_parse_field(const char *head
+void Cache_parse_header(CacheData_t *entry, IOData_t *io, gint HdrLen)
+{
+gchar *header = entry->Header->str;
+- gchar *Length, *Type, *location_str, *url_str;
++ gchar *Length, *Type, *location_str;
+
+/* Get Content-Type */
+Type = Cache_parse_field(header, "Content-Type");
+@@ -335,9 +335,7 @@ void Cache_parse_header(CacheData_t *ent
+/* 301 Moved Permanently */
+entry->Flags |= CA_ForceRedirect;
+location_str = Cache_parse_field(header, "Location");
+- url_str = a_Url_string(entry->Url);
+- entry->Location = a_Url_new(location_str, url_str, 0, 0);
+- g_free(url_str);
++ entry->Location = a_Url_new(location_str, NULL, 0, 0);
+g_free(location_str);
+
+} else if ( strncmp(header + 9, "404", 3) == 0 ) {
+****************
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Support for gzipped html
+
+From: Sam Dennis <sam@ma...> - 2001-05-15 16:07
+
+On Mon, May 14, 2001 at 10:41:48PM -0300, Livio Baldini Soares wrote:
+> > It would be nice to support it all the same, though.
+> 
+> I agree! Right now I have some bug fixes to remove from the URL
+> module which are pending. As soon as I'm done, and nobody's in the
+> mood, I'll give it a shot.
+> 
+> Jorge, how do you think encondings would be handled in Dillo. I was
+> thinking of adding a layer between IO and Cache, so the cached data is
+> already "clean" (unencoded). I think that another approach would be to
+> add the encoding layer between Cache and mime_viewer_funtion. But I
+> think the first choice is cleaner to implement and should be more
+> generic. What do you think?
+
+Just my opinion, but it seems to me that it should go in the IO system, as
+it's actually part of HTTP... except that for some reason, the header parsing
+code is in the cache. Something to change, maybe? Especially with the handling
+of more protocols. 
+
+
+
+Re: [Dillo-dev]Support for gzipped html
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-15 01:41
+
+Sam Dennis writes:
+> On Sat, May 12, 2001 at 05:24:30PM -0300, Livio Baldini Soares wrote:
+
+<snip>
+
+> > Boy was I surprised! I had no knowledge that this type of thing
+> > existed... gzipped htmls!?!?! 
+> 
+> Indeed, encodings are defined in both RFC 1945 and 2616 (HTTP/1.[01])
+> 
+> We can probably blame sourceforge for this particular problem, though. It
+> responds with a compressed file even if you specifically exclude the
+> gzip/x-gzip encodings.
+
+Yeah, I read RFC 2616 concerning this issue. Looks like Sourceforge's
+WebServer is ignoring the existence of Accept-Enconding field. The
+RFC specifies that if no Accept-Enconding field is given on the
+header, the server should respond with `identity` encoding (i.e. no
+encoding). Futhermore Itried to explicitly ask for no gzip enconding,
+using:
+
+Accept-Encoding:
+and
+Accept-Encoding: identity; q=1.0, *;q=0
+
+And nothing seemed to work. My guess is that it's ignoring it.
+
+> It would be nice to support it all the same, though.
+
+I agree! Right now I have some bug fixes to remove from the URL
+module which are pending. As soon as I'm done, and nobody's in the
+mood, I'll give it a shot.
+
+Jorge, how do you think encondings would be handled in Dillo. I was
+thinking of adding a layer between IO and Cache, so the cached data is
+already "clean" (unencoded). I think that another approach would be to
+add the encoding layer between Cache and mime_viewer_funtion. But I
+think the first choice is cleaner to implement and should be more
+generic. What do you think?
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Support for gzipped html
+
+From: Sam Dennis <sam@ma...> - 2001-05-14 17:37
+
+On Sat, May 12, 2001 at 05:24:30PM -0300, Livio Baldini Soares wrote:
+> Hi folks!
+> 
+> I've been working hard with Jorge these past few weeks to implement
+> a new URL parsing module in Dillo. While I was testing a version that
+> I thought seemed to be stable I innocently entered Sourceforge's home
+> page (so....net), and dillo rendered a bunch of garbage (random
+> chars)... And I thought "Damn! My code is that bad :-(". After
+> thoroughly searching IO/caching/rendering modules for any changes
+> (bugs ;-) I could have introduced, I tried to make a telnet on port 80
+> and make the request myself... I got garbage too!
+> 
+> So my last alternative was to use `wget http://so....net/`. I
+> got an index.html, but when I `file index.html`:
+> index.html: gzip compressed data, deflated, last modified: Wed Dec 31 21:00:00 1969,
+> 
+> Boy was I surprised! I had no knowledge that this type of thing
+> existed... gzipped htmls!?!?! 
+
+Indeed, encodings are defined in both RFC 1945 and 2616 (HTTP/1.[01])
+
+We can probably blame sourceforge for this particular problem, though. It
+responds with a compressed file even if you specifically exclude the
+gzip/x-gzip encodings.
+
+It would be nice to support it all the same, though. 
+
+
+
+[Dillo-dev]Support for gzipped html
+
+From: Livio Baldini Soares <livio@li...> - 2001-05-12 20:24
+
+Hi folks!
+
+I've been working hard with Jorge these past few weeks to implement
+a new URL parsing module in Dillo. While I was testing a version that
+I thought seemed to be stable I innocently entered Sourceforge's home
+page (so....net), and dillo rendered a bunch of garbage (random
+chars)... And I thought "Damn! My code is that bad :-(". After
+thoroughly searching IO/caching/rendering modules for any changes
+(bugs ;-) I could have introduced, I tried to make a telnet on port 80
+and make the request myself... I got garbage too!
+
+So my last alternative was to use `wget http://so....net/`. I
+got an index.html, but when I `file index.html`:
+index.html: gzip compressed data, deflated, last modified: Wed Dec 31 21:00:00 1969,
+
+Boy was I surprised! I had no knowledge that this type of thing
+existed... gzipped htmls!?!?! 
+
+Apparently the header field Content-Type comes as regular text/html,
+but the Content-Encoding field comes as `gzip'. I know netscape does
+support gzipped htmls. Just try it on a local html.gz (-:
+
+This is just a message to let all of you guys (like me) who were
+ignorant about this fact. I left a bug in the bugtrack (#156). Maybe
+I'll get to doing this if I have some time later. We can probably use
+zlib, right? It's pretty `standard' under Unices, isn't it?
+
+Oh, and should this and other MIME types be implemented as plugins?
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]!!
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-05-11 16:32
+
+Sebastian,
+
+> On Thu, May 10, Jorge Arellano Cid wrote:
+> >
+> > Ladies and Gentleman:
+> >
+> > I just finished releasing dillo 0.5.0!!!
+>
+> A few notes:
+>
+> - I noticed sometimes rendering problems in older versions, which
+> caused areas to be cleared suddenly. My last fix on the CVS
+> version, included in the release, is a *possible* fix of this
+> (modification of a_Dw_widget_queue_draw,
+> a_Dw_widget_queue_draw_area, a_Dw_widget_queue_clear and
+> a_Dw_widget_queue_clear_area), but I haven't examined the problem
+> enough to be sure that this is *the* solution. From a few "field
+> tests" this seems to be true. Feedback is very welcome.
+
+I made some tests with it too, but found no problems. Although
+I didn't know exactly what to look for, I assumed it could be
+drawing problems due to badly calculated intersection areas.
+Sometime ago, in older versions, making a sudden jump to a
+distant position in a large page, it may produce a black page; I
+haven't seen this in months.
+
+> - Jorge, what happened with bug #154? I've attached a test page to
+> reproduce it. Dillo 0.5.0 only renders the word "foo".
+
+I tried to reproduce the bug, but unsuccessfuly. When using
+dillo-0.4.0 it happened, so I thought It was fixed. Now I know it
+happens when the page doesn't have the ending tags nor a final
+newline (pretty weird!). Anyway, I fixed it :-), but haven't
+commited it yet.
+
+> - BTW, the splash pages are quite strange. After having started the
+> 0.5.0-pre version numerous times, dillo 0.5.0 (release) starts
+> with a "Version 0.5.0-pre". I had to remove
+> ~/.dillo/Splash050.html to get the correct version number (aside
+> from the growing ~/.dillo dir ;-).
+
+Yes, that's true.
+Everybody (that has played with CVS versions):
+
+rm ~/.dillo/Splash050.html
+
+Everything will be fine then. Amen!
+
+> What about adding an
+> "about:splash", and passing the text to the html parser, instead
+> of writing it into a file? Just an idea ...
+
+That's a good idea, but when I first chose the file method, it
+wasn't easy to do it otherwise. Now it's time to change it.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]!!
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-11 12:30
+
+Attachments: bug2.html      
+
+On Thu, May 10, Jorge Arellano Cid wrote:
+> 
+> Ladies and Gentleman:
+> 
+> I just finished releasing dillo 0.5.0!!!
+
+A few notes:
+
+- I noticed sometimes rendering problems in older versions, which
+caused areas to be cleared suddenly. My last fix on the CVS
+version, included in the release, is a *possible* fix of this
+(modification of a_Dw_widget_queue_draw,
+a_Dw_widget_queue_draw_area, a_Dw_widget_queue_clear and
+a_Dw_widget_queue_clear_area), but I haven't examined the problem
+enough to be sure that this is *the* solution. From a few "field
+tests" this seems to be true. Feedback is very welcome.
+
+There is an other rendering bug occurring with tooltips. How to
+reproduce: Go to a page, focus the viewport, move the pointer
+over an image, wait until the tooltip pops up, and move the
+viewport by the arrow keys. Or move the pointer over a button in
+the button bar, this is the same for Gtk+ tooltips. At a first
+thought, this may be a Gtk+ bug, I'll try to reproduce it in a
+small test program, and in the case of a positive result, send it
+to the Gtk+ developers.
+
+- Jorge, what happened with bug #154? I've attached a test page to
+reproduce it. Dillo 0.5.0 only renders the word "foo".
+
+- BTW, the splash pages are quite strange. After having started the
+0.5.0-pre version numerous times, dillo 0.5.0 (release) starts
+with a "Version 0.5.0-pre". I had to remove
+~/.dillo/Splash050.html to get the correct version number (aside
+from the growing ~/.dillo dir ;-). What about adding an
+"about:splash", and passing the text to the html parser, instead
+of writing it into a file? Just an idea ...
+
+Sebastian 
+
+
+
+[Dillo-dev]!!
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-05-11 00:22
+
+Ladies and Gentleman:
+
+I just finished releasing dillo 0.5.0!!!
+
+Enjoy!
+Jorge.- 
+
+
+
+[Dillo-dev]Voice Interface
+
+From: andew ecu <andrewecu@ho...> - 2001-05-10 02:21
+
+Yes Sebastian, I'm in my final year at university studying computer science 
+and i'm seeing if i can implementing a voice recognition interface on an 
+internet browser for my final year project:)
+
+I was orginally going to use Mozilla, but after looking at the code it was 
+too complicated for what i wanted to do, so i decided to changed it to 
+dillo.
+
+Playing around with dillo, i've learnt a great deal about how web browsers 
+actually work, and also how much more functionality is needed for disabled 
+people to use software without a mouse and keyboard.
+
+Thanks for the help guys, especially Sebastian :)
+Later
+Andrew
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+Re: [Dillo-dev]current bw
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-08 19:27
+
+On Tue, May 08, andew ecu wrote:
+> Since there are several browser windows that can be open at the same time, 
+> is there a way to find out which is the browser window that is currently 
+> "active".. ie user is using it?
+
+All windows are active all the time. ;-)
+
+All commands are called after specific events have been received, and
+the browser window is passed as an argument to these functions.
+
+> Also is there a way to switch between the different browser windows? or is 
+> there a way to implement it?
+
+This is under the control of the window manager. There are probably
+ways to influence this, this is a X11/Gtk+ question.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Y location and coordinates of a link
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-08 19:27
+
+Hi Andrew,
+
+just a question: does this have to do with your posting to
+gtk-app-devel-list (voice recognition interface)?
+
+On Tue, May 08, andew ecu wrote:
+> Hi just got a few questions :)
+> 
+> Firstly..
+> I asked previously about scrolling up and down the current viewport. I was 
+> wondering is there a way to find out the current Y position that the 
+> viewport is currently, and also would it be possible to do this if i wanted 
+> to say go down 10 down(this would be in a module in a_DW_widget)?
+> 
+> current_y_loc = get current y location
+
+You can use
+
+current_y_loc = GTK_SCROLLED_WINDOW (bw->doc_win)->vadjustment->value;
+
+> Dw_gtk_viewport_scroll_to (GTK_Dw_viewport(widget->viewport), current_y_loc 
+> + 10 )
+
+Dw_gtk_viewport_scroll_to is intended for internal use, if you want to
+hack on dw_*. There is indeed a difference between internal changes
+(anchors), and changes caused by the user (scrollbars, keys, and mouse
+button 2 dragging). In the latter case, Dw_gtk_viewport_remove_anchor
+must be called, to stop queued changes of the former case (see
+dw_gtk_scrolled_window.c).
+
+Simple example: If you load a page foo.html#bar, you'll first see the
+text from the beginning. As soon as the <a name="bar"> tag is read,
+the text is scrolled to this position. *Except*: If you move the text
+down, before <a name="bar"> has been read, the position won't change
+anymore automatically.
+
+I'd suggest to use some not yet existing higher level functions, like:
+
+current_y_loc = GTK_SCROLLED_WINDOW (bw->doc_win)->vadjustment->value;
+a_Dw_scrolled_window_set_vadjustment_value (
+GTK_DW_SCROLLED_WINDOW (bw->doc_win), current_y_loc + 10);
+
+a_Dw_scrolled_window_set_vadjustment_value is very simple to add.
+
+> Second question is..
+> Is there a way to find out the x,y coordinates of a link on the page? and if 
+> so is it then possible to find the url from the x,y coordinates?
+
+To find the coordinates of a link (index in DwPage::links), you'll
+have to search in the lines and words. To find a link from the
+coordinates, there is an internal function, Dw_page_find_link, but
+(currently) no external interface.
+
+Sebastian 
+
+
+
+[Dillo-dev]current bw
+
+From: andew ecu <andrewecu@ho...> - 2001-05-08 18:06
+
+Since there are several browser windows that can be open at the same time, 
+is there a way to find out which is the browser window that is currently 
+"active".. ie user is using it?
+
+Also is there a way to switch between the different browser windows? or is 
+there a way to implement it?
+
+thanks again
+andrew over and out :)
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+[Dillo-dev]Y location and coordinates of a link
+
+From: andew ecu <andrewecu@ho...> - 2001-05-08 17:49
+
+Hi just got a few questions :)
+
+Firstly..
+I asked previously about scrolling up and down the current viewport. I was 
+wondering is there a way to find out the current Y position that the 
+viewport is currently, and also would it be possible to do this if i wanted 
+to say go down 10 down(this would be in a module in a_DW_widget)?
+
+current_y_loc = get current y location
+Dw_gtk_viewport_scroll_to (GTK_Dw_viewport(widget->viewport), current_y_loc 
++ 10 )
+
+
+
+Second question is..
+Is there a way to find out the x,y coordinates of a link on the page? and if 
+so is it then possible to find the url from the x,y coordinates?
+
+
+
+thanks heaps :)
+andrew
+
+
+
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+Re: [Dillo-dev]Html Source Code
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-05-05 16:02
+
+Andrew,
+
+> Just another quick question.
+>
+> Is there an array of char in dillo that stores the entire source code of the
+> html file? What is it called?
+
+You can get it with a_Cache_url_read(), just get sure the whole
+page has been got before calling it.
+
+Jorge.- 
+
+
+
+[Dillo-dev]Html Source Code
+
+From: andew ecu <andrewecu@ho...> - 2001-05-03 18:52
+
+Just another quick question.
+
+Is there an array of char in dillo that stores the entire source code of the 
+html file? What is it called? If not then where does it store it once it 
+recieves the requested webpage?
+
+Thanks
+Andrew
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
+
+
+Re: [Dillo-dev]Interface Questions..
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-03 16:57
+
+Hi Andrew,
+
+I don't have any idea what you want to do :-), but here are some
+answers.
+
+On Thu, May 03, andew ecu wrote:
+> Hi i'm new to dillo and i've been playing around with it. Which has been a 
+> big learning experience.
+> 
+> But i have a few questions.
+> 
+> Firstly i wanted to know if i had a string of the url how would i display it 
+> on the location text area? This is where it says "new". I want to know where 
+> abouts that a string is passed to a function to display it, but not 
+> necessarily executing it. (I HOPE THAT MADE SENSE :)
+
+If you have a BrowserWindow, (either in an Interface callback, or as
+html->bw etc.), you can simply call
+
+gtk_entry_set_text(GTK_ENTRY(bw->location), url);
+
+"Executing" is done by a_Nav_push.
+
+> Next i want to know what actually happens when a scroll is done on the page 
+> of the main window. How would i adjust the vertical and horizontal, which 
+> functions deal with this.
+
+There are several functions: a_Dw_widget_scroll_to is used if you want
+to scroll to a specific position within a widget. If your position is
+absolute, use Dw_gtk_viewport_scroll_to. The latter should only be
+used in the Dw module (see doc/NC_design.txt in the distribution).
+
+Furthermore, there are are several functions dealing with anchors,
+document-wide named positions which may change (used for <a name="...">
+and headers).
+
+All these functions only affect the vertical scroll position, there is
+currently nothing for horizontal adjustments, simply because it isn't
+needed, but if you can convince me that it is necessary, it should be
+simple to add it. ;-)
+
+I hope this helps.
+
+Sebastian 
+
+
+
+[Dillo-dev]Image Maps
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-05-03 16:57
+
+Hi.
+
+Does anyone plan to implement client-side image maps fully, i.e. also
+urls different of the url of the doc containing the image? This
+doesn't seem that widely supported, the only browser I found (but I
+didn't test the newest versions), was -- lynx ;-). And probably it is
+_used_ even less often.
+
+If yes, the implementation will require large changes, if no, I'll do
+the following changes in the near future:
+
+1. This step is necessary for step 2:
+
+The link list will move into the Html linkblock, and the
+"link_..." signals will only pass an integer, perhaps also the
+DwPageWord(s). In future, these signals may then also be used
+for event handling of other words than links, currently the
+workaround for changing the color of visited links prevents
+this.
+
+2. The list of image maps will move into the linkblock, too, and
+probably the handling of image maps will be done by the image
+widget (the latter should make the code a bit more simple).
+
+The current implementation will not work for documents like:
+
+<map name="foo">...</map>
+<table>
+<tr>
+<td><img src="bar.jpg" usemap="#foo"></td>
+</tr>
+</table>
+
+since the <map> and the <img> are in two different DwPage's.
+
+Sebastian 
+
+
+
+[Dillo-dev]Interface Questions..
+
+From: andew ecu <andrewecu@ho...> - 2001-05-03 11:31
+
+Hi i'm new to dillo and i've been playing around with it. Which has been a 
+big learning experience.
+
+But i have a few questions.
+
+Firstly i wanted to know if i had a string of the url how would i display it 
+on the location text area? This is where it says "new". I want to know where 
+abouts that a string is passed to a function to display it, but not 
+necessarily executing it. (I HOPE THAT MADE SENSE :)
+
+Next i want to know what actually happens when a scroll is done on the page 
+of the main window. How would i adjust the vertical and horizontal, which 
+functions deal with this.
+
+I hope these questions aren't ambigous :)
+Thanks
+Andrew
+
+
+_________________________________________________________________________
+Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 
+
diff --git a/old/oldmail/200106.txt b/old/oldmail/200106.txt
new file mode 100644
index 0000000..2273d18
--- /dev/null
+++ b/old/oldmail/200106.txt
@@ -0,0 +1,1433 @@
+[Dillo-dev]Dillo for the ipaq
+
+From: Eduardo Marcel Macan <macan@co...> - 2001-06-29 17:48
+
+Guys thank you for the *wonderful* work you are doing with dillo.
+I am working with the guys of the familiar distribution 
+(familiar.handhelds.org) and dillo is becoming the best choice for
+use in a limited storage device like the ipaq.
+
+I have just made a package for dillo out of today's snapshot,
+and I must say It is just *GREAT* .
+
+here is the .ipk package of dillo for the ipaq using 
+the familiar GNU/Linux distribution.
+
+http://www.metainfo.org/macan/ipaq/dillo_20010629-1_arm.ipk
+
+And here is the screenshot of dillo on an iPAQ displaying slashdot:
+http://www.metainfo.org/macan/ipaq/10-ipaq-dillo_slashdot.png
+
+I am leaving for a 10 day break now, but when I am back I
+hope to start contributing more to the dillo web browser! :)
+
+Thank you all!
+-- 
+"If you have an apple and I have an apple and we exchange apples then you 
+and I will still each have one apple. But if you have an idea and I have 
+an idea and we exchange these ideas, then each of us will have two ideas."
+George Bernard Shaw 
+
+
+
+[Dillo-dev]Feature
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-27 13:45
+
+Hi iPAQ users (and others).
+
+Since tables may be used to set the width at which words are wrapped
+(either explicitly by the "width" attribute, or implicitly by images
+and long words), the text may become unreadable on small screens.
+
+Dillo could change the rendering to prevent this, one simple
+possibility is new option, "limit_text_width", which limits the word
+wrap width (but not necessary the final page width) to the viewport
+width. I've implemented this, it is available via CVS.
+
+I've tested it a bit, browsing with a small window size. It is
+probably a bit better than before, but don't expect too much, you
+loose the overview over the page easily. There may be new options
+(e.g. factors for size specification and images), but they will not be
+part of the (soon released) version 0.6.0.
+
+Please post your comments. Does this feature make sense? Any further
+ideas? Should dillo try to render such pages at all in a "readable"
+way? Etc.
+
+Sebastian 
+
+
+
+[Dillo-dev]Dillo-ssl (patch)
+
+From: <torkel@ly...> - 2001-06-26 21:27
+
+Attachments: dillo-ssl.patch.gz      https.c.gz      
+
+Hi all.
+
+Nice work with dillo! About the only browser that is lightweight enough
+for my iPAQ. However... i kinda need cookies, https and auth for it to be
+really useable. I hacked together some kind of SSL support for it, and
+tested against apache/mod_ssl. Seems to be functional.
+
+Included are two files, a cvs diff against yesterdays cvs, and a new file
+"https.c" which goes in IO/. Add the -I's and -l's for openssl (in my case
+0.9.5a, yeah, it's old, i know ;)
+
+Since it's my first attempt at both dillo and ssl hacking, the approach
+might be a bit off. Basically it's a combination of about: and http:
+backends with some SSL inbetween.
+
+Now all i gotta do is to find a place in the GUI for a padlock ;)
+
+...and ofcourse implement cookies and auth.
+
+Best regards,
+T-Å 
+
+
+
+Re: [Dillo-dev]locale
+
+From: Martynas Jocius <atthis@de...> - 2001-06-23 16:50
+
+Hi, Sebastian
+
+On Sat, Jun 23, 2001 at 03:35:33PM +0200, Sebastian Geerken wrote:
+
+> gtk_set_locale is intended for the user interface, but it probably
+> works for this purpose, if your "system" language ($LANG and $LC_...)
+> and the language of the documents you are viewing are the same.
+>
+
+I am not talking about the documents.
+Bug 173 was inserted by me :). I am from Lithuania, small country in Europe
+near the Baltic Sea. Native charset is iso-8859-13. I have no problems on
+viewing any documents with lithuanian characters. But I was talking about
+Dillo. For example, I bookmark a page and set a title with lithuanian
+characters. I can't see them. 
+Or I have to type some text with my native characters into the entry in 
+the html page. I can't do that too...
+Well, now it's ok, I fixed this :)
+
+> BTW, there has been a discussion on the list, you can find it in the
+> archive at:
+[some addresses] 
+Yes, discussian was about documents with Korean/Russian characters. As I
+said, I have no problems at this point ;)
+
+> Perhaps we can already implement a simple scheme dealing with 8-bit
+> fonts, looking at what Gtk+ 1.2 already provides. Extending
+> DwStyleFont by an encoding attribute might works. (Sorry, I'm no
+> expert on this topic at all.)
+
+So what about gtk_set_locale()? I think it's a good way. Maybe someday we
+will make Dillo to understand i18n for the translations. 
+
+
+--
+Martynas 
+
+
+
+Re: [Dillo-dev]locale
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-23 13:30
+
+On Fri, Jun 22, Martynas Jocius wrote:
+> Bug #173. Can't see/write native characters. Insert gtk_set_locale() into
+> src/dillo.c line 80. :-)
+
+gtk_set_locale is intended for the user interface, but it probably
+works for this purpose, if your "system" language ($LANG and $LC_...)
+and the language of the documents you are viewing are the same.
+
+BTW, there has been a discussion on the list, you can find it in the
+archive at:
+
+http://www.geocrawler.com/archives/3/702/2001/5/0/5805536/
+http://www.geocrawler.com/archives/3/702/2001/5/0/5806440/
+http://www.geocrawler.com/archives/3/702/2001/5/0/5811325/
+http://www.geocrawler.com/archives/3/702/2001/5/0/5812833/
+http://www.geocrawler.com/archives/3/702/2001/5/0/5830229/
+http://www.geocrawler.com/archives/3/702/2001/5/0/5833416/
+
+Perhaps we can already implement a simple scheme dealing with 8-bit
+fonts, looking at what Gtk+ 1.2 already provides. Extending
+DwStyleFont by an encoding attribute might works. (Sorry, I'm no
+expert on this topic at all.)
+
+Sebastian 
+
+
+
+[Dillo-dev]DwStyle memory leaks
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-22 16:13
+
+Hi,
+
+just a hint on warnings like "** WARNING **: 1 styles left": It seems
+that the memory management works, except if the HTML parser is
+interrupted. In this case, Html_close is not called, which will
+normally unref all styles left in DilloHtml.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]HTML/CSS question
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-22 16:13
+
+On Fri, Jun 22, Jörgen Viksell wrote:
+> >does someone know how to replace the NOSHADE attribute of <hr> by CSS
+> >attributes? In HTML4, it's deprecated, but there is no hint how to get
+> >the same effect using CSS.
+> 
+> This would make it look similar:
+> border: none; background-color: grey
+
+I believe the ruler itself is the content, so it won't work.
+
+Test the following in Amaya (I've installed 3.1):
+
+<hr>
+<hr style="border-style: none; background-color: #808080">
+<hr style="border-style: none; background-color: #808080; padding: 5mm">
+
+The first two look equally, the third has a gray rectangle *around*
+the ruler.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]HTML/CSS question
+
+From: Viksell <jorgen.viksell@te...> - 2001-06-22 12:23
+
+>does someone know how to replace the NOSHADE attribute of <hr> by CSS
+>attributes? In HTML4, it's deprecated, but there is no hint how to get
+>the same effect using CSS.
+
+This would make it look similar:
+border: none; background-color: grey
+
+// J=F6rgen 
+
+
+
+[Dillo-dev]locale
+
+From: Martynas Jocius <atthis@de...> - 2001-06-22 12:07
+
+Hi,
+
+Bug #173. Can't see/write native characters. Insert gtk_set_locale() into
+src/dillo.c line 80. :-)
+
+--
+Martynas 
+
+
+
+[Dillo-dev]HTML/CSS question
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-22 11:29
+
+Hi,
+
+does someone know how to replace the NOSHADE attribute of <hr> by CSS
+attributes? In HTML4, it's deprecated, but there is no hint how to get
+the same effect using CSS.
+
+(I'm working on bug #168 (colors of <hr>'s), this could be solved
+simple by DwStyle boxes, but I thought of making it already compliant
+with a future CSS implementation, which will be based on DwStyle.)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev][patch] File -> Close Window
+
+From: Sam Dennis <sam@ma...> - 2001-06-21 16:12
+
+On Thu, Jun 21, 2001 at 02:04:48PM +0300, Martynas Jocius wrote:
+> I made another close window patch, maybe identical with last one. But I saw,
+> that the memory is freed when destroying the window. Interface_quit()
+> function is called when I do gtk_widget_destroy(). How does this work?
+
+There's this little line in interface.c which reads:
+
+gtk_signal_connect(GTK_OBJECT(bw->main_window), "destroy",
+GTK_SIGNAL_FUNC(Interface_quit), bw);
+
+So when the window is destroyed, gtk calls Interface_quit. 
+
+
+
+Re: [Dillo-dev][patch] File -> Close Window
+
+From: Martynas Jocius <atthis@de...> - 2001-06-21 12:00
+
+Attachments: dillo-cvs-06-21-close_window.patch      
+
+On Mon, Jun 18, 2001 at 09:22:38AM -0400, Jorge Arellano Cid wrote:
+> Is very encouraging to see new people trying to get involved
+> into dillo development, please don't get discouraged if you fail
+> at your first attempts; it was the same for everyone of us ;-)
+
+Thanks Jorge :)
+I made another close window patch, maybe identical with last one. But I saw,
+that the memory is freed when destroying the window. Interface_quit()
+function is called when I do gtk_widget_destroy(). How does this work?
+
+--
+Martynas 
+
+
+
+[Dillo-dev]RGBA data (was: Misc)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-20 15:48
+
+On Tue, Jun 19, I wrote:
+> - Image transparency 2: If you have something like
+> 
+> <table>
+> <tr>
+> <td bgcolor=red><img src="foo.png">
+> <td bgcolor=green><img src="foo.png">
+> </table>
+> 
+> the first image will, correctly, have have a red background, but
+> the second, incorrectly, too, since they share the same dicache
+> buffer. So the transparency should somehow stored in the dicache
+> buffer, instead of replaced by a background color.
+
+If there are no objections, I'll start to modify the image code to use
+RGBA data instead of RGB.
+
+Sebastian 
+
+
+
+[Dillo-dev]Misc
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-19 16:45
+
+Hi all,
+
+I have been working on borders and colors, now they work for table
+(just uploaded), although a bit polishing is needed. However, some
+notes:
+
+- What happened to the <font> implementation? I've now activated
+<font color> (but not face), of course inside an "if
+(!prefs.force_my_colors)", since this makes some colored tables
+more readable.
+
+- Image transparency 1: I've modified Png_datarow_callback to use
+the background color passed to a_Image_new, by replacing
+prefs.bg_color by png->Image->bg_color. I don't know very much
+about image processing, but this seems the way this should be
+handled (?).
+
+- Image transparency 2: If you have something like
+
+<table>
+<tr>
+<td bgcolor=red><img src="foo.png">
+<td bgcolor=green><img src="foo.png">
+</table>
+
+the first image will, correctly, have have a red background, but
+the second, incorrectly, too, since they share the same dicache
+buffer. So the transparency should somehow stored in the dicache
+buffer, instead of replaced by a background color.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev][patch] File -> Close Window
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-06-18 13:52
+
+Martynas,
+
+
+> There was a bug #87 about closing window. There's a small patch which fixes
+> this.
+
+Is very encouraging to see new people trying to get involved
+into dillo development, please don't get discouraged if you fail
+at your first attempts; it was the same for everyone of us ;-)
+
+I ask, at the web page, to be sent information about personal
+skills, but I understand if they don't send any. That's just to
+know in which part of dillo their knowledge would fit better, and
+also to guide or hint their progress.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-14 22:58
+
+On Thu, Jun 14, Sam Dennis wrote:
+> On Thu, Jun 14, 2001 at 06:59:05PM +0200, Sebastian Geerken wrote:
+> [...]
+> > Fixed and committed.
+> >
+> > Sebastian
+>
+> I'm sorry but it doesn't look very fixed to me, I'm getting almost exactly the
+> same results here.
+
+What images do you use? I tested it with
+
+<table>
+<tr>
+<td colspan=2><img src="maj00s.gif" width=200 height=100>
+<td rowspan=2><img src="maj00s.gif" width=100 height=200>
+<tr>
+<td rowspan=2><img src="maj00s.gif" width=100 height=200>
+<td><img src="maj00s.gif" width=100 height=100>
+<tr>
+<td colspan=2><img src="maj00s.gif" width=200 height=100>
+</table>
+
+and got
+
++---------+ +---+
+| | | |
++---------+ | |
++---+ +---+ | |
+| | | | | |
+| | +---+ +---+
+| | +---------+
+| | | |
++---+ +---------+
+
+With some certain image sizes, the result is indeed not perfect, see
+example in doc/DwTable.txt.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sam Dennis <sam@ma...> - 2001-06-14 21:35
+
+On Thu, Jun 14, 2001 at 06:59:05PM +0200, Sebastian Geerken wrote:
+> On Wed, Jun 13, Sam Dennis wrote:
+> > It may have been a while since I wrote any real HTML, but I think I'd be
+> > correct in thinking that the following table shouldn't be rendered as
+> > illustrated:
+> > [...]
+> 
+> Fixed and committed.
+> 
+> Sebastian
+
+I'm sorry but it doesn't look very fixed to me, I'm getting almost exactly the
+same results here. 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-14 16:54
+
+On Wed, Jun 13, Sam Dennis wrote:
+> It may have been a while since I wrote any real HTML, but I think I'd be
+> correct in thinking that the following table shouldn't be rendered as
+> illustrated:
+> [...]
+
+Fixed and committed.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev][patch] File -> Close Window
+
+From: Sam Dennis <sam@ma...> - 2001-06-14 11:59
+
+On Thu, Jun 14, 2001 at 01:39:05PM +0300, Martynas Jocius wrote:
+> On Thu, Jun 14, 2001 at 11:56:38AM +0100, Sam Dennis wrote:
+> 
+> > When a window is closed, significantly more needs to be done than simply
+> > destroying the window. Interface_quit performs all the necessary actions and
+> > should almost certainly be called when the close window function is used.
+> 
+> Ok, sorry. I'll try to fix it. Just I'm very new in Dillo sources.
+> What about adding:
+> if (bw->main_window != NULL)
+> gtk_widget_destroy(bw->main_window);
+> 
+> into Interface_quit? And then call Interface_quit when the menu item is
+> clicked? This will require a lot more changes in sources. 
+
+Sorry about this, but ignore everything I said, I'm not at my sharpest today :)
+
+Interface_quit is the handler for destroying the main window, so you don't
+have to worry about calling it. 
+
+
+
+Re: [Dillo-dev][patch] File -> Close Window
+
+From: Martynas Jocius <atthis@de...> - 2001-06-14 11:35
+
+On Thu, Jun 14, 2001 at 11:56:38AM +0100, Sam Dennis wrote:
+
+> When a window is closed, significantly more needs to be done than simply
+> destroying the window. Interface_quit performs all the necessary actions and
+> should almost certainly be called when the close window function is used.
+
+Ok, sorry. I'll try to fix it. Just I'm very new in Dillo sources.
+What about adding:
+if (bw->main_window != NULL)
+gtk_widget_destroy(bw->main_window);
+
+into Interface_quit? And then call Interface_quit when the menu item is
+clicked? This will require a lot more changes in sources. 
+
+--
+Martynas 
+
+
+
+Re: [Dillo-dev][patch] File -> Close Window
+
+From: Sam Dennis <sam@ma...> - 2001-06-14 10:47
+
+On Thu, Jun 14, 2001 at 12:28:57PM +0300, Martynas Jocius wrote:
+> Hi,
+> 
+> There was a bug #87 about closing window. There's a small patch which fixes
+> this. 
+> 
+> --
+> Martynas
+
+> /*
+> - * ?
+> + * Close single window. Exit Dillo if only one window is. 
+> */
+> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data)
+> {
+> + BrowserWindow *bw = (BrowserWindow *)client_data;
+> + Interface_destroy_window(bw->main_window);
+> }
+
+When a window is closed, significantly more needs to be done than simply
+destroying the window. Interface_quit performs all the necessary actions and
+should almost certainly be called when the close window function is used. 
+
+
+
+[Dillo-dev][patch] File -> Close Window
+
+From: Martynas Jocius <atthis@de...> - 2001-06-14 10:25
+
+Attachments: dillo-cvs-close_window.atthis.patch      
+
+Hi,
+
+There was a bug #87 about closing window. There's a small patch which fixes
+this. 
+
+--
+Martynas 
+
+
+
+Re: [Dillo-dev]table algorithm (was: tables: COLSPAN)
+
+From: Sam Dennis <sam@ma...> - 2001-06-14 10:10
+
+On Fri, Jan 05, 1990 at 01:34:08AM -0900, Jon Bradley wrote:
+> 
+> It is impossible to access the CVS. I have done it before, back when
+> 0.3.0 was release. But it appears all information about the CVS is gone
+> from the website AND the knownledge base.
+> 
+> Have you closed down the CVS to the public? I would like to see how
+> dillo is looking with frames.
+
+AFAIK, anonymous CVS is working perfectly, and I'm afraid that you won't be
+seeing frames yet, only tables. Although my frames code should be ready in the
+not-so-distant future... 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-14 09:15
+
+On Wed, Jun 13, Sam Dennis wrote:
+> I was going to congratulate you on actually making that system work, but now,
+> having actually seen its output, I've decided that it needs a bit more work.
+
+This is what bug reports are for. :-)
+
+> It may have been a while since I wrote any real HTML, but I think I'd be
+> correct in thinking that the following table shouldn't be rendered as
+> illustrated:
+> [...]
+
+This one is fixed, but I've not yet uploaded the change, there are
+still a few more bugs.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]dillo CVS
+
+From: Jon Bradley <kreator@mo...> - 2001-06-13 21:58
+
+Please disgrad the last message I just sent about an impossible CVS.
+
+=-=-=-=-=-=-=-=-=-=-=-=
+Email: kreator@gc...
+bbs: telnet://toga.cx
+=-=-=-=-=-=-=-=-=-=-=-=
+
+
+On 13 Jun 2001, Sebastian Geerken wrote:
+
+> On Thu, Jan 04, Jon Bradley wrote:
+> >
+> > Hi,
+> >
+> > I am trying to login to the dillo CVS, so I searched the dillo website,
+> > where I found no info on the CVS. I then got to the knowledge base of
+> > Mail Archives, where I found a message showing how to login to the CVS,
+> > although, the knowledge base has some type of filter for email addresses?
+> > So again, I was not able to login.
+> >
+> > I am a novice at CVS, can someone please describe what I am suppose to do,
+> > or atleast what my CVSROOT var is suppose to be? Thanks.
+>
+> The commands are:
+>
+> cvs -d:pserver:anonymous@cv...:/cvsroot/dillo login
+> cvs -z8 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo
+>
+> There is also information at the SourceForge side, at
+> http://so....net/cvs/?group_id=603. Perhaps this should added to
+> home page, Jorge?
+>
+> Sebastian
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]table algorithm (was: tables: COLSPAN)
+
+From: Jon Bradley <kreator@mo...> - 2001-06-13 21:56
+
+It is impossible to access the CVS. I have done it before, back when
+0.3.0 was release. But it appears all information about the CVS is gone
+from the website AND the knownledge base.
+
+Have you closed down the CVS to the public? I would like to see how
+dillo is looking with frames.
+
+=-=-=-=-=-=-=-=-=-=-=-=
+Email: kreator@gc...
+bbs: telnet://toga.cx
+=-=-=-=-=-=-=-=-=-=-=-=
+
+
+On 13 Jun 2001, Sebastian Geerken wrote:
+
+> On Tue, Jun 12, I wrote:
+> > Optimal := what you would have as a result, according to the
+> > autolayout algorithm suggested in Appendix B of the HTML
+> > spec, for tables *without* COLSPAN.
+>
+> Well, sorry, I was a bit sloppy in reading the text. My code is (as
+> most other web browsers) based on an other definition:
+>
+> 1. All columns have have the same width W, except:
+>
+> - W is less than the minimal column width, or
+> - W is greater than the maximal column width.
+>
+> Furthermore, W is
+>
+> - less than all minimal widths of columns not having W as
+> width, and
+> - greater than all maximal widths of columns not having W as
+> width.
+>
+> 2. The table tries to use exactly the whole available width, except
+> if it is not possible, because the available width is
+> less/greater than the minimal/maximal table width.
+>
+> (BTW, there is a bug in the CVS, but I've fixed this, and will upload
+> it soon.)
+>
+> A simple example: The table
+>
+> <table>
+> <tr>
+> <td>
+> Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah
+> <td>
+> Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah
+> Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah
+> </table>
+>
+> would, by the W3C algorithm, rendered as:
+>
+> +------------+----------------------+
+> | Blah Blah | Blah Blah Blah Blah |
+> | Blah Blah | Blah Blah Blah Blah |
+> | Blah Blah | Blah Blah Blah Blah |
+> | Blah Blah | Blah Blah Blah Blah |
+> | Blah Blah | Blah Blah Blah Blah |
+> +------------+----------------------+
+>
+> while most browsers render this:
+>
+> +-----------------+-----------------+
+> | Blah Blah Blah | Blah Blah Blah |
+> | Blah Blah Blah | Blah Blah Blah |
+> | Blah Blah Blah | Blah Blah Blah |
+> | Blah | Blah Blah Blah |
+> | | Blah Blah Blah |
+> | | Blah Blah Blah |
+> | | Blah Blah |
+> +-----------------+-----------------+
+>
+> Note that the W3C algorithm may have very "unaesthetical" results when
+> the columns differ quite much in there maximal length, while having
+> comparable content length (number of characters), e.g. if one column
+> consists of many small paragraphs, whereas another consists of few
+> long paragraphs.
+>
+> I think we should follow the common implementations, which authors may
+> have in mind, instead of the W3C recommendation. Different opinions?
+>
+>
+> Sebastian
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sam Dennis <sam@ma...> - 2001-06-13 19:33
+
+On Wed, Jun 13, 2001 at 08:29:08PM +0200, Sebastian Geerken wrote:
+> > Currently, I'm working on COLSPAN. [...]
+> 
+> Just uploaded, together with some bugfixes.
+> 
+> Sebastian
+
+I was going to congratulate you on actually making that system work, but now,
+having actually seen its output, I've decided that it needs a bit more work.
+
+It may have been a while since I wrote any real HTML, but I think I'd be
+correct in thinking that the following table shouldn't be rendered as
+illustrated:
+
+<table>
+<tr>
+<td colspan=2><img src=1.png></td>
+<td rowspan=2><img src=2.png></td>
+</tr>
+<tr>
+<td rowspan=2><img src=3.png></td>
+<td><img src=4.png></td>
+</tr>
+<tr>
+<td colspan=2><img src=5.png></td>
+</tr>
+</table>
+
++-------+ +---+
+| | | |
++-------+ | |
++---++---+ | |
+| || | +---+
+| |+---+
+| |+-------+
++---+| |
++-------+
+
+But don't take this the wrong way, I'm impressed that you managed to get that
+approach working at all! 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-13 18:22
+
+> Currently, I'm working on COLSPAN. [...]
+
+Just uploaded, together with some bugfixes.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]dillo CVS
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-06-13 14:27
+
+Hi!
+
+> [CVS]
+> The commands are:
+>
+> cvs -d:pserver:anonymous@cv...:/cvsroot/dillo login
+> cvs -z8 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo
+>
+> There is also information at the SourceForge side, at
+> http://so....net/cvs/?group_id=603. Perhaps this should added to
+> home page, Jorge?
+
+Done, in [Links] section.
+
+
+Jorge. 
+
+
+
+[Dillo-dev]table algorithm (was: tables: COLSPAN)
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-13 13:34
+
+On Tue, Jun 12, I wrote:
+> Optimal := what you would have as a result, according to the
+> autolayout algorithm suggested in Appendix B of the HTML
+> spec, for tables *without* COLSPAN.
+
+Well, sorry, I was a bit sloppy in reading the text. My code is (as
+most other web browsers) based on an other definition:
+
+1. All columns have have the same width W, except:
+
+- W is less than the minimal column width, or
+- W is greater than the maximal column width.
+
+Furthermore, W is
+
+- less than all minimal widths of columns not having W as
+width, and
+- greater than all maximal widths of columns not having W as
+width.
+
+2. The table tries to use exactly the whole available width, except
+if it is not possible, because the available width is
+less/greater than the minimal/maximal table width.
+
+(BTW, there is a bug in the CVS, but I've fixed this, and will upload
+it soon.)
+
+A simple example: The table
+
+<table>
+<tr>
+<td>
+Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah
+<td>
+Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah
+Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah
+</table>
+
+would, by the W3C algorithm, rendered as:
+
++------------+----------------------+
+| Blah Blah | Blah Blah Blah Blah |
+| Blah Blah | Blah Blah Blah Blah |
+| Blah Blah | Blah Blah Blah Blah |
+| Blah Blah | Blah Blah Blah Blah |
+| Blah Blah | Blah Blah Blah Blah |
++------------+----------------------+
+
+while most browsers render this:
+
++-----------------+-----------------+
+| Blah Blah Blah | Blah Blah Blah |
+| Blah Blah Blah | Blah Blah Blah |
+| Blah Blah Blah | Blah Blah Blah |
+| Blah | Blah Blah Blah |
+| | Blah Blah Blah |
+| | Blah Blah Blah |
+| | Blah Blah |
++-----------------+-----------------+
+
+Note that the W3C algorithm may have very "unaesthetical" results when
+the columns differ quite much in there maximal length, while having
+comparable content length (number of characters), e.g. if one column
+consists of many small paragraphs, whereas another consists of few
+long paragraphs.
+
+I think we should follow the common implementations, which authors may
+have in mind, instead of the W3C recommendation. Different opinions?
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]dillo CVS
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-13 13:34
+
+On Thu, Jan 04, Jon Bradley wrote:
+> 
+> Hi,
+> 
+> I am trying to login to the dillo CVS, so I searched the dillo website,
+> where I found no info on the CVS. I then got to the knowledge base of
+> Mail Archives, where I found a message showing how to login to the CVS,
+> although, the knowledge base has some type of filter for email addresses?
+> So again, I was not able to login.
+> 
+> I am a novice at CVS, can someone please describe what I am suppose to do,
+> or atleast what my CVSROOT var is suppose to be? Thanks.
+
+The commands are:
+
+cvs -d:pserver:anonymous@cv...:/cvsroot/dillo login
+cvs -z8 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo
+
+There is also information at the SourceForge side, at
+http://so....net/cvs/?group_id=603. Perhaps this should added to
+home page, Jorge?
+
+Sebastian 
+
+
+
+[Dillo-dev]dillo CVS
+
+From: Jon Bradley <kreator@mo...> - 2001-06-13 01:38
+
+Hi,
+
+I am trying to login to the dillo CVS, so I searched the dillo website,
+where I found no info on the CVS. I then got to the knowledge base of
+Mail Archives, where I found a message showing how to login to the CVS,
+although, the knowledge base has some type of filter for email addresses?
+So again, I was not able to login.
+
+I am a novice at CVS, can someone please describe what I am suppose to do,
+or atleast what my CVSROOT var is suppose to be? Thanks.
+
+=-=-=-=-=-=-=-=-=-=-=-=
+Email: kreator@gc...
+bbs: telnet://toga.cx
+=-=-=-=-=-=-=-=-=-=-=-= 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-12 18:49
+
+On Tue, Jun 12, Sam Dennis wrote:
+> It seems to me that your algorithm may have some problems with tables using
+> combinations of ROWSPAN and COLSPAN, to take an extreme example:
+> 
+> +-------+---+
+> | A | |
+> +---+---+ B +
+> | | D | |
+> | C +---+---+
+> | | E |
+> +---+-------+
+> 
+> Would your algorithm handle this well? The description you've given doesn't
+> suggest so.
+
+Tested ... works. :-)
+
+Table rendering is (in both implementations) done in three steps:
+
+1. Calculating minimal and maximal column widths,
+2. calculating the column widths, and
+3. calculating the column heights.
+
+Only step 1 and 2 (which are changed) deal with COLSPAN, and only step
+3 deals with ROWSPAN, so there is no problem. Note that when rendering
+documents (as opposed to GUIs), both dimensions are not symmetric,
+most is determined by the viewport width, the height plays a much less
+important role.
+
+> Also, there is perhaps the issue of what `optimal' means in table layout
+> anyhow.
+
+Optimal := what you would have as a result, according to the
+autolayout algorithm suggested in Appendix B of the HTML
+spec, for tables *without* COLSPAN.
+
+(BTW, this is what led me to the idea of recursive tables: if COLSPAN
+is a problem, try to find subtables and so eliminate COLSPAN.)
+
+E.g., the following layout is optimal:
+
++------+-------------------------------+
+| Blah | Blah Blah Blah Blah Blah Blah |
+| | Blah Blah Blah Blah |
++------+-------------------------------+
+
+|------------ viewport width ------------|
+
+while the following, trivial, is not:
+
++------------------+-------------------+
+| Blah | Blah Blah Blah |
+| | Blah Blah Blah |
+| | Blah Blah Blah |
+| | Blah |
++------------------+-------------------+
+
+This should also work for COLSPAN:
+
++--------------------------------------+
+|BlahBlahBlahBlahBlahBlahBlahBlahBlah |
++------+-------------------------------+
+| Blah | Blah Blah Blah Blah Blah Blah |
+| | Blah Blah Blah Blah |
++------+-------------------------------+
+
+instead of:
+
++--------------------------------------+
+|BlahBlahBlahBlahBlahBlahBlahBlahBlah |
++------------------+-------------------+
+| Blah | Blah Blah Blah |
+| | Blah Blah Blah |
+| | Blah Blah Blah |
+| | Blah |
++------------------+-------------------+
+
+Note that my algorithm isn't optimal in some cases, an alternative
+would be "real" optimization, but this will be even more complicated
+and slow.
+
+> Finally, your solution looks _very_ awkward to code. I don't like the idea of
+> a recursive algorithm for table layout in the first place and it might present
+> more problems than it solves, mightn't a little thought go towards a simpler
+> algorithm? (Not that I've got one...)
+
+I don't think that recursion is complex per se, often problems can
+solved much simpler that way. In this case, the code (it is nearly
+complete) isn't much more complex than before (and not slower),
+although I must admit that the idea might be a bit strange.
+
+Maybe a look at other browsers might be useful, but I'll complete it
+now, it can anyway changed in the future.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sam Dennis <sam@ma...> - 2001-06-12 15:03
+
+It seems to me that your algorithm may have some problems with tables using
+combinations of ROWSPAN and COLSPAN, to take an extreme example:
+
++-------+---+
+| A | |
++---+---+ B +
+| | D | |
+| C +---+---+
+| | E |
++---+-------+
+
+Would your algorithm handle this well? The description you've given doesn't
+suggest so.
+
+Also, there is perhaps the issue of what `optimal' means in table layout
+anyhow.
+
+Finally, your solution looks _very_ awkward to code. I don't like the idea of
+a recursive algorithm for table layout in the first place and it might present
+more problems than it solves, mightn't a little thought go towards a simpler
+algorithm? (Not that I've got one...) 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-11 18:02
+
+On Mon, Jun 11, Sam Dennis wrote:
+> Sorry if this may mean that a lot of time has been wasted in reinventing the
+> wheel, but there are quite extensive notes on tables in general and layout algorithms in
+> particular in the HTML specs.
+
+I use, more or less, the algorithm described in the spec, but I handle
+cells spanning several columns in a different way, since the described
+algorithm is sufficient for tabled data, but not for "layout tables".
+Not that that tables are the best way for page layout, but some pages
+would be unreadable otherwise.
+
+This is the part in the spec about the problem:
+
+For cells that span multiple columns, a simple approach consists of
+apportioning the min/max widths evenly to each of the constituent
+columns. A slightly more complex approach is to use the min/max
+widths of unspanned cells to weight how spanned widths are
+apportioned. Experiments suggest that a blend of the two approaches
+gives good results for a wide range of tables.
+
+But I'm aiming towards perfect, not just good, results. ;-)
+
+Suppose the following table:
+
+<table>
+<tr>
+<td colspan="2"><img src="banner.gif" width="500" height="50">
+<tr>
+<td>
+Links:<br>
+...
+<td>
+A long text over several lines blah blah blah ...
+</table>
+
+An optimal layout (what my algorithm does indeed :-) would result in:
+
+,----------------------------------------.
+| Banner |
+`----------------------------------------'
+
+Links: A long text over several lines blah blah blah
+... blah blah ...
+|--------------------- viewport width ---------------------|
+
+
+The result of the simple algorithm in the spec:
+
+,--------------------------------------------------.
+| Banner |
+`--------------------------------------------------'
+
+Links: A long text over several lines blah
+... blah blah ...
+|--------------------- viewport width ---------------------|
+
+
+The complex approach would have a similar effect, since the minimal
+widths of both text cells are quite similar, this would make both
+weights for the minimum nearly equal, and so (in this case) determine
+the same column widths.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sam Dennis <sam@ma...> - 2001-06-11 14:41
+
+On Fri, Jun 08, 2001 at 02:14:47PM +0200, Sebastian Geerken wrote:
+> Hi,
+> 
+> first, FYI: there have been some updates of the table implementation,
+> image maps and COLSPAN now work. For finding text, the best solution
+> is probably to add a new method DwWidget::find_text, which searches
+> recursively in DwContainer's.
+> 
+> Currently, I'm working on COLSPAN. As you may have noticed, the
+> current implementation does not work well for large spanning
+> columns. The approach I'm using is to divide the table recursively
+> into subtables. This is not always possible, so sometimes the cells
+> have to be "divided", which makes the rendering not optimal, but
+> reasonable, the effect should be small in most cases. An optimal
+> solution would otherwise be complicated and slow.
+
+Sorry if this may mean that a lot of time has been wasted in reinventing the
+wheel, but there are quite extensive notes on tables in general and layout algorithms in
+particular in the HTML specs.
+
+http://www.w3.org/TR/html4/appendix/notes.html#notes-table might be worth a
+look. 
+
+
+
+Re: [Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-08 12:43
+
+On Fri, Jun 08, I wrote:
+> first, FYI: there have been some updates of the table implementation,
+> image maps and COLSPAN now work.
+^^^^^^^
+Of course, I meant ROWSPAN.
+
+Sebastian 
+
+
+
+[Dillo-dev]tables: COLSPAN
+
+From: Sebastian Geerken <S.Geerken@pi...> - 2001-06-08 12:13
+
+Hi,
+
+first, FYI: there have been some updates of the table implementation,
+image maps and COLSPAN now work. For finding text, the best solution
+is probably to add a new method DwWidget::find_text, which searches
+recursively in DwContainer's.
+
+Currently, I'm working on COLSPAN. As you may have noticed, the
+current implementation does not work well for large spanning
+columns. The approach I'm using is to divide the table recursively
+into subtables. This is not always possible, so sometimes the cells
+have to be "divided", which makes the rendering not optimal, but
+reasonable, the effect should be small in most cases. An optimal
+solution would otherwise be complicated and slow.
+
+I'm not sure if this is the simplest approach, I've also had other
+ideas, but did not succeed in developing them further to an algorithm.
+I've appended an extract of the new documentation, I'm now working on
+the implementation. If someone knows a better approach, let me know
+it!
+
+Sebastian
+
+----------------------------------------------------------------------
+
+A table is divided into subtables, until single columns are
+left. Cells spanning the whole width are removed before dividing
+further. Example:
+
++---+-------+---+
+| A | B | C |
++---+-------+---+
+| D | E |
++---+-------+---+
+| F | G | H |
++---+-------+---+
+' ' ` `
+' ' ` `
++---+-------+ +---+
+| A | B | | C |
++---+-------+ +---+
+removed --> | D | | E |
++---+-------+ +---+
+| F | G | | H |
++---+-------+ +---+
+' ' ` ` final
+' ' ` `
++---+ +-------+
+| A | | B | <-.
++---+ +-------+ >- removed
+| F | | G | <-' 
++---+ +-------+
+final ' ' ` `
+' ' ` `
+[empty] [empty]
+final final
+
+If table cells overlap horizontally, they are (virtually) divided
+(resulting in a non optimal layout):
+
++-------+---+---+
+| A | B | C |
++---+---+---+---+
+| D | E |
++---+-----------+
+' ' ` `
+' ' ` `
++-------+ +---+---+
+| A | | B | C |
++---+---+ +---+---+
+| D |1/3| | 2/3 E |
+| | E | | |
++---+---+ +-------+
+
+Calculating extremes
+--------------------
+minimal/maximal width (sub table) =
+- for single column: maximum of all minimal/maximal widths
+- otherwise: maximum of
+- all minimal/maximal widths of cells spanning
+the whole width, and
+- the sum of the minimal/maximal widths of the sub
+tables
+
+Calculating column widths
+-------------------------
+The calculation is based on an available width, which is, at the top,
+the width set by a_Dw_widget_set_width, corrected by the minimal and
+maximal width of the whole table. At each level, the available width
+is always between the minimal and the maximal width of the subtable.
+
+For single columns, the width is the available width. Otherwise, use
+the simple iteration [described in the old DwTable.txt] on the
+subtables, excluding the columns spanning the whole subtable width, to
+get the width of the subtables. After this, apply this recursively on
+all subtables, with the subtable width as available width. 
+
+
+
+Re: [Dillo-dev]can not visit dillo.so....net
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-06-04 19:05
+
+Li,
+
+> [...]
+> Why can I not visit http://dillo.so....net now?
+
+You SHOULD be able to see it!!! (I can)
+
+If you can't visit it for an extended period, you can blame
+your Internet Service Provider (ISP). Just as Livio said, source
+forge has been under some troubles lately, but AFAIK that's over.
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]can not visit dillo.so....net
+
+From: Livio Baldini Soares <livio@li...> - 2001-06-04 14:31
+
+Hi liqx!
+
+Qiaoxia,Li writes:
+> Hi,
+> Where can I download dillo-0.5.1,Why can I not visit http://
+> dillo.so....net now?
+
+Sourceforge is sometimes down... specially nowadays... But when
+it's not you can get dillo-0.5.1 at:
+
+http://download.so....net/dillo/dillo-0.5.1.tar.gz
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]can not visit dillo.so....net
+
+From: Qiaoxia,Li <liqx@st...> - 2001-06-04 00:46
+
+Attachments: Message as HTML      
+
+SGksDQpXaGVyZSBjYW4gSSBkb3dubG9hZCBkaWxsby0wLjUuMSxXaHkgY2FuIEkgbm90IHZpc2l0
+IGh0dHA6Ly9kaWxsby5zb3VyY2Vmb3JnZS5uZXQgbm93Pw0KcmVnYXJkcywNCmxpcXgNCg0K 
+
+
+
+[Dillo-dev]File selection patch (again :)
+
+From: Livio Baldini Soares <livio@li...> - 2001-06-03 04:54
+
+Hello!
+
+I'm sending (again) my updated patch for file selection while saving
+pages or links. As Holger Rapp suggested, I have removed the modal
+type windows, now they're like any dialog window.
+
+The patch is simple (against 02-Jun CVS), and it's at:
+http://www.linux.ime.usp.br/~livio/dillo/file_select_new.diff
+
+Also, I think I'm willing to implement the Downloads scheme
+described in [Project Notes], becasue in my opinion it's another great
+TODO... Has anybody started anything on this?
+
+PS: Sebastian, nice work on the tables! I was really happy when I saw
+sourforge.net being rendered in a "readable way! I know it's still a
+it buggy, but we'll work it out with time... Thanks!
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]authentification
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-06-01 09:44
+
+Hi!
+
+
+On Thu, 31 May 2001, Didier Bretin wrote:
+
+> Hello,
+>
+> Dillo looks good :o). Go on !!!!
+
+Thanks!
+
+> Have you planned to deal with authentification ?
+
+Sure, I have an ancient patch from Marcos Ram=EDrez that was
+waiting for DilloUrl... If you're willing to work on it, I can
+send you the patch so you can start from there.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]authentification
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-06-01 04:22
+
+Hi!
+
+On Thu, 31 May 2001, Alexey F. Bekish wrote:
+
+> How from all it nsubscribe????
+
+???
+
+How to unsubscribe?
+
+Go to dillo's home page, follow the [Mailing List] link, click
+on the "Visit subscribers list" button, click your entry, enter
+your password and click "unsubscribe" button!
+
+Maybe sending an email with "unsubscribe" as subject could also
+do the trick.
+
+
+Jorge.- 
+
diff --git a/old/oldmail/200107.txt b/old/oldmail/200107.txt
new file mode 100644
index 0000000..dc51c06
--- /dev/null
+++ b/old/oldmail/200107.txt
@@ -0,0 +1,593 @@
+RE: [Dillo-dev]Scaling and new panel_size...
+
+From: Mondesir, Raphael <raphael.mondesir@tf...> - 2001-07-30 13:33
+
+Thanks, alot, Pigeon.
+
+-----Original Message-----
+From: Pigeon [mailto:pigeon@fo...]
+Sent: Monday, July 30, 2001 9:17 AM
+To: 'dillo-dev@li...'
+Subject: RE: [Dillo-dev]Scaling and new panel_size...
+
+
+
+
+> How do you get Dillo to work on the IPaq? Is it framebuffered device? I'd
+> like to know this because I would like to put together a bootable floppy
+> that runs Dillo and I have plans for purchasing an IPaq in the near
+future.
+
+
+A short answer will be, have a look at http://www.handhelds.org/
+:)
+
+Yes, it's running X frame buffer. Basically the anything that is
+compiled for the ipaq (strongarm processor) will run on the ipaq running
+linux.
+
+I cross compiled dillo myself from my machine. Some other people
+have cross compiled and put binaries onto the net too. Here is one of them
+at http://www.geocities.com/glenn65535/
+
+
+
+Pigeon.
+
+
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+http://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+RE: [Dillo-dev]Scaling and new panel_size...
+
+From: Pigeon <pigeon@fo...> - 2001-07-30 13:17
+
+> How do you get Dillo to work on the IPaq? Is it framebuffered device? I'd
+> like to know this because I would like to put together a bootable floppy
+> that runs Dillo and I have plans for purchasing an IPaq in the near future.
+
+
+A short answer will be, have a look at http://www.handhelds.org/
+:)
+
+Yes, it's running X frame buffer. Basically the anything that is
+compiled for the ipaq (strongarm processor) will run on the ipaq running
+linux.
+
+I cross compiled dillo myself from my machine. Some other people
+have cross compiled and put binaries onto the net too. Here is one of them
+at http://www.geocities.com/glenn65535/
+
+
+
+Pigeon. 
+
+
+
+RE: [Dillo-dev]Scaling and new panel_size...
+
+From: Mondesir, Raphael <raphael.mondesir@tf...> - 2001-07-30 12:50
+
+Hi Pigeon,
+
+How do you get Dillo to work on the IPaq? Is it framebuffered device? I'd
+like to know this because I would like to put together a bootable floppy
+that runs Dillo and I have plans for purchasing an IPaq in the near future.
+
+Thanks,
+Raphael
+
+-----Original Message-----
+From: Pigeon [mailto:pigeon@fo...]
+Sent: Sunday, July 29, 2001 7:44 AM
+To: dillo-dev@li...
+Subject: [Dillo-dev]Scaling and new panel_size...
+
+
+
+Hi all.
+
+I've done a little patch to basically add two features that are
+really useful I reckon when I use dillo on my ipaq.
+
+First thing is a new panal_size called "tinydouble", which is basically
+based on tiny, but a bit more friendly under a small resolution under
+ipaq.
+
+Second thing is a scaling functionality. With this I can scale up and down
+a web page (kind of like zooming in and out). Again this is kind of handy
+when viewing webpages on a handheld device. The patch given here will
+scale images only. I have actually tested with scaling fonts as well, but
+the problem comes to when the text is scaled to an unreadable size. And
+also I will the scaling for fonts should be hooked to the font_factor of
+the preferences.
+
+There are a few issues with this scaling feature.
+
+Firstly, right now the image scaling works in the Html_add_widget function,
+and that means it will work not only for images, but everything that uses
+that
+function. So far from the source code only <img> and <hr> tags make use of
+that function. I didn't look at other codes in depth yet, but what is
+cool will be the ability to scale anything in a webpage (like table,
+forms, etc). I have a feeling there's a better way to handle this.
+(I've read and tried doing the scale in image.c and dw_image.c too, but I
+cannot get it to work yet.)
+
+Second issues is, the scaling will not scale images with not width and
+height attribute. Again, I think the scaling should be done in the image
+part.
+
+Third issue is, I tried hooking the spin button changes to reload the
+page, it works but it's far more easier to crash dillo (and basically
+keep on clicking reload can crash dillo quite quickly, too). And so I've
+commented that bit for now.
+
+BTW, screenshots for this patch at:
+http://pigeond.net/ipaq/dillo1.jpg
+http://pigeond.net/ipaq/dillo2.jpg
+http://pigeond.net/ipaq/dillo3.jpg
+http://pigeond.net/ipaq/dillo4.jpg
+
+And the patch:
+http://pigeond.net/ipaq/dillo-scale-tinydouble.patch
+(Based on dillo-0.5.1 tarball)
+
+Last but not least, this is the first time I patch dillo, so please excuse
+my code if I've put anything weird or out of the coding standard :)
+
+And, the tinydouble and scaling feature aren't actually related, but
+they're quite tied up together, so I've put them into one patch, instead
+of two.
+
+Pigeon.
+
+
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+http://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]Scaling and new panel_size...
+
+From: Pigeon <pigeon@fo...> - 2001-07-29 11:44
+
+Hi all.
+
+I've done a little patch to basically add two features that are
+really useful I reckon when I use dillo on my ipaq.
+
+First thing is a new panal_size called "tinydouble", which is basically
+based on tiny, but a bit more friendly under a small resolution under
+ipaq.
+
+Second thing is a scaling functionality. With this I can scale up and down
+a web page (kind of like zooming in and out). Again this is kind of handy
+when viewing webpages on a handheld device. The patch given here will
+scale images only. I have actually tested with scaling fonts as well, but
+the problem comes to when the text is scaled to an unreadable size. And
+also I will the scaling for fonts should be hooked to the font_factor of
+the preferences.
+
+There are a few issues with this scaling feature.
+
+Firstly, right now the image scaling works in the Html_add_widget function,
+and that means it will work not only for images, but everything that uses that
+function. So far from the source code only <img> and <hr> tags make use of
+that function. I didn't look at other codes in depth yet, but what is
+cool will be the ability to scale anything in a webpage (like table,
+forms, etc). I have a feeling there's a better way to handle this.
+(I've read and tried doing the scale in image.c and dw_image.c too, but I
+cannot get it to work yet.)
+
+Second issues is, the scaling will not scale images with not width and
+height attribute. Again, I think the scaling should be done in the image
+part.
+
+Third issue is, I tried hooking the spin button changes to reload the
+page, it works but it's far more easier to crash dillo (and basically
+keep on clicking reload can crash dillo quite quickly, too). And so I've
+commented that bit for now.
+
+BTW, screenshots for this patch at:
+http://pigeond.net/ipaq/dillo1.jpg
+http://pigeond.net/ipaq/dillo2.jpg
+http://pigeond.net/ipaq/dillo3.jpg
+http://pigeond.net/ipaq/dillo4.jpg
+
+And the patch:
+http://pigeond.net/ipaq/dillo-scale-tinydouble.patch
+(Based on dillo-0.5.1 tarball)
+
+Last but not least, this is the first time I patch dillo, so please excuse
+my code if I've put anything weird or out of the coding standard :)
+
+And, the tinydouble and scaling feature aren't actually related, but
+they're quite tied up together, so I've put them into one patch, instead
+of two.
+
+Pigeon. 
+
+
+
+Re: [Dillo-dev]Close to 0.6.0 release
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-07-26 13:45
+
+On Wed, Jul 18, 2001 at 06:20:10AM -0700, Aaron Lehmann wrote:
+> On Sat, Jul 07, 2001 at 05:21:22PM -0400, Jorge Arellano Cid wrote:
+> > Some things to be included:
+> > 
+> > - The main window is scrollable with:
+> > 
+> > The arrow keys,
+> > [Ctrl] + {PgUp | PgDn | Home | End}]
+> > Pressing the middle mouse-button
+> 
+> I would love hjkl vi-style scrolling too. But that could possibly
+> interfere with forms.
+
+This is possible, Dw_gtk_scrolled_frame_key_press has to be modified
+for this. Gtk+ always delivered key press events from bottom to top,
+so it does not conflict with entries etc.
+
+> Ultimately, it would be awesome to have vi-style
+> editing within the forms, but that's not a very high priority item.
+
+This is the task of Gtk+, send a bug report ;-)
+
+
+Sebastian 
+
+
+
+[Dillo-dev]Find Text
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-24 14:48
+
+Hi,
+
+
+I've started implementing "find text". This is important
+because it IS the main reason for the 0.6.0 release hold-back.
+
+Sebastian: I know this was in your schedule, but as your
+abscence is taking longer that I thought, and as I devised a way
+of implementing, I just decided to start (this will also let you
+work on the other couple of bugs you told me). Please contact me
+ASAP.
+
+I have a prototype running (it works with words within tables).
+Some details:
+
+* It adds a 'findtext' method to DwContainer (table and page).
+* It uses a stack to keep track of current position.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]News
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-19 18:02
+
+Hi there!
+
+
+0.6.0
+-----
+Don't think all of this waiting time has been wasted, there're
+plenty of changes to the source that I'll commit very soon.
+
+
+User manual
+-----------
+Among misc. patches, I received the first attempt to a user
+manual (mainly hints) for dillo (thanks to Kristian A. Rink). I
+worked it out and set a new copy in the main site ([Help] link).
+The idea is to improve it. Anything that helps (from purely
+aesthetics to content improvement). I'll be expecting patches!
+
+Please remember that it is expected to be lean, useful and not
+detailed to the extremes.
+
+As I was reading it, the idea of making it more interactive,
+as happens with the file links, looked very appealing to me;
+maybe a table layout would help also.
+
+Including some hints stated in the splash screen would
+probably help.
+
+
+gtk_set_locale
+--------------
+Martynas: I saw your bug-track entry, and read the email, but
+I'm not sure still: do you mean that just adding gtk_set_locale
+(at init time) solves the problem for you?
+
+
+Dw patches
+----------
+
+Sebastian: I'll commit a truck-load of changes from my source
+tree very soon. The patch on Dw remains identical to what I sent
+you some time ago. Feel free to revert 'cum_height' to 'y_top' if
+you prefer it that way.
+
+
+That's all, cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Delayed release
+
+From: Kristian A. Rink <afterimage@gm...> - 2001-07-18 14:17
+
+Attachments: Message as HTML      Message as HTML      
+
+
+
+
+
+Re: [Dillo-dev]Close to 0.6.0 release
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-07-18 13:20
+
+On Sat, Jul 07, 2001 at 05:21:22PM -0400, Jorge Arellano Cid wrote:
+> Some things to be included:
+> 
+> - The main window is scrollable with:
+> 
+> The arrow keys,
+> [Ctrl] + {PgUp | PgDn | Home | End}]
+> Pressing the middle mouse-button
+
+I would love hjkl vi-style scrolling too. But that could possibly
+interfere with forms. Ultimately, it would be awesome to have vi-style
+editing within the forms, but that's not a very high priority item.
+
+> - Alt + ',' and Alt +'.' serve as shortcuts for Back and
+> Forward. (mnemonic: they're usually the '<' and '>' keys).
+
+Yay! 
+
+
+
+Re: [Dillo-dev]global dillo config file
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-18 01:42
+
+Eduardo,
+
+> This is just a suggestion. I think it would be useful to support
+> a global configuration file for dillo, if the user does not have one in
+> its home directory, so I added these lines to prefs.c . If a ~/.dillo/dillorc
+> is not found it will try to load /etc/dillorc , this way a system wide
+> configuration file can be provided by the packager. It is useful for
+> the ipaq for instance, because it requires different defaults that can
+> be provided in /etc/dillorc , directly in the package.
+
+OK, it's done.
+
+> It was just a
+> copy/paste, maybe it could be done in a more elegant way, but anyway...
+
+Yes, I modified it a bit.
+
+
+Obrigado!
+Jorge.- 
+
+
+
+[Dillo-dev]Delayed release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-14 13:15
+
+Hi!
+
+
+0.6.0 is on delay mainly due to circumstances that are beyond
+our control... (HW failure! ;).
+
+Meanwhile:
+
+- Has anyone reproduced BUG#166?
+
+- I've got the screenshots, but not the manual page :(
+
+
+Sebastian:
+
+I sent you the patches, but nettaxi complains it can
+deliver to 'ping.de' so I forwarded it to 'lilly.ping.de'. In any
+case, if it's easier for you, I can commit the patch and post the
+explanation here.
+
+
+That's all folks
+Jorge.- 
+
+
+
+[Dillo-dev]Leaks
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-12 12:41
+
+Hi!
+
+Sebastian:
+
+Have you received my last emails? (they were about Dw leaks &
+patches). I'm writing to you through the list to let you a chance
+of reading them on the web if your mail server is down.
+
+PD: the patch is finished!!!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]global dillo config file
+
+From: Eduardo Marcel Macan <macan@co...> - 2001-07-11 17:40
+
+Attachments: prefs.c.diff      
+
+This is just a suggestion. I think it would be useful to support
+a global configuration file for dillo, if the user does not have one in
+its home directory, so I added these lines to prefs.c . If a ~/.dillo/dillorc
+is not found it will try to load /etc/dillorc , this way a system wide
+configuration file can be provided by the packager. It is useful for
+the ipaq for instance, because it requires different defaults that can
+be provided in /etc/dillorc , directly in the package. It was just a
+copy/paste, maybe it could be done in a more elegant way, but anyway...
+
+Small diff file attached.
+-- 
+"If you have an apple and I have an apple and we exchange apples then you 
+and I will still each have one apple. But if you have an idea and I have 
+an idea and we exchange these ideas, then each of us will have two ideas."
+George Bernard Shaw 
+
+
+
+[Dillo-dev]screenshots
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-09 12:36
+
+Hi!
+
+I'm glad to inform that Eric sent me the screenshots, so that's
+done. Anyway, if you have a "killer shot", that could improve the
+screenshots page, send it to me.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Close to 0.6.0 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-07-07 21:23
+
+Hi everyone!
+
+
+I haven't posted lately, due to devote work on current code.
+Although this list seems very quiet, 0.6.0-pre has been under a
+stream-flow of patches and improvements! I'm confident that 0.6.0
+will be a great release.
+
+In order to get to it, there're still some pending tasks, but
+we're making progress on them. Among those, I'd like to have
+updated dillo-screenshots for the web site (yes, I'm asking for
+a volunteer!;), and also want to include a help page.
+
+The help page should be small, and in HTML. I'd like to have
+simple dillo tips to offer our users, not a complete manual that
+starts explaining from what BACK-button is!
+
+Some things to be included:
+
+- The main window is scrollable with:
+
+The arrow keys,
+[Ctrl] + {PgUp | PgDn | Home | End}]
+Pressing the middle mouse-button
+
+If unresponssive, focus by clicking it (but not on a link!)
+
+- Alt + ',' and Alt +'.' serve as shortcuts for Back and
+Forward. (mnemonic: they're usually the '<' and '>' keys).
+
+- Http downloads are possible, but the interface hasn't been
+finished (it's described in the project notes). If you
+still want to use it, get to the link you want to download
+and right click it, then select "Save link as...". You'll
+get notified when its done, but nothing else.
+
+- Ftp downloads can be got by getting the full ftp-link (use
+"Copy link location"), get to a terminal and issue 'wget'
+or 'curl -O' and paste the URI (usually middle button).
+
+- Stability: dillo is more stable if you let it load the main
+page before moving on (don't worry about images).
+
+- Directories, you can use:
+
+'file:' to get current directory
+'file:~' to get your home directory
+
+- Framed page don't render, but the progress bar shows
+content. If you need badly to get to that info, then "view
+source" it, try to pick the right link, and copy/paste to
+the location entry (don't close the source viewer before
+pasting).
+
+- There're lots of options in 'dillorc', among them:
+
+font_factor: defaults to 1.0, I love 1.2 and iPAQ use 0.8
+
+panel_size: <read dillorc!>
+
+- Dillo's control panel boxes can be torn off the main window
+by dragging them from the leftmost part.
+
+- Reload button will always request an end-to-end reload, but
+it will not reload embedded images.
+
+- <alike stuff>*
+
+
+Does anyone feel like helping me with it?
+
+
+Ah, finally, can anyone reproduce BUG#166? It works for me.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]set of patches
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-07-01 22:58
+
+Attachments: const.diff      fprintf.diff      prototypes.diff      stringopts.diff      
+
+1) const.diff. marks some tables of constant as const. extremely minor
+and stylistic, may result in some minute optimization by the compiler.
+
+2) fprintf.diff. prefs.c seems to allocate a buffer, sprintf into it,
+and immediately write into a file. that's what fprintf is for! i can't
+see any reason why this change would be bad.
+
+3) prototypes.diff. png.c uses abort() without including stdlib.h.
+gcc 3.0 was nice enough to detect this ANSI violation.
+
+4) stringopts.diff. several miscellaneous string optimizations. some
+strcpys are changed to memcpys (which are often faster) and sprintfs
+were changed to strcpys when this was possible. strcmps were sometimes
+broken down when it made sense. this is the most major change and it
+reduces the size of the binary by a few hundred bytes.
+
+
+the patches applied in alphabetical order with no fuzz for me. they'll
+probably work in any order.
+
+
+thanks! 
+
diff --git a/old/oldmail/200108.txt b/old/oldmail/200108.txt
new file mode 100644
index 0000000..66491be
--- /dev/null
+++ b/old/oldmail/200108.txt
@@ -0,0 +1,2926 @@
+Re: [Dillo-dev]word wrapping / page width
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-31 14:07
+
+On Tue, Aug 28, 2001 at 05:42:50PM -0400, Jorge Arellano Cid wrote:
+> > I thought of a workaround, which ignores the NOWRAP in this
+> > case, in Html_tag_open_table_cell:
+> > [...]
+> 
+> When this message was posted, the HTML parsing policy wasn't
+> yet stated in the "Project Notes". As now it is there, let's
+> apply, and live happily ever after!
+
+Done.
+
+Sebastian 
+
+
+
+[Dillo-dev]Attribute parsing
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-30 21:07
+
+Hi there!
+
+
+There's a very interesting topic around attribute parsing in
+HTML (as SGML). I want to tie three comments I have that stem
+from the same root:
+
+I) Sebastian wrote:
+
+Most of you will remember the discussion on how to parse the HREF
+attribute of the <a> tag. This is a similar problem: in
+
+http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/
+
+you'll find something like
+
+<table width="100&#37;">
+
+Dillo reads this as "100" (pixels) and complains about the garbage at
+the end. I'm not an SGML expert, so I thought to post this to the
+list. Have attributes to be be parsed generally, or is this page
+invalid?
+
+II) Bruno wrote (about BUG#190):
+
+I went to http://validator.w3.org, and it lists 2 Html 4.01
+specs, "Strict" and "Traditional"
+
+I fed a page with newlines in an anchor-string into the
+Validator, and it Validates OK for "Traditional". I admit it does
+not for "Strict"
+
+In fact i did this before i even started coding, because if i
+knew it was "wrong" html i wouldn't have bothered.
+
+Now, i went to
+http://www.w3.org/TR/1999/REC-html401-19991224/types.html
+
+|| The document type definition specifies the syntax of HTML
+|| element content and attribute values using SGML tokens (e.g.,
+|| PCDATA, CDATA, NAME, ID, etc.).
+|| See [ISO8879] for their full definitions. The following is
+|| a summary of key information:
+||
+|| CDATA is a sequence of characters from the document character
+|| set and may include character entities. User agents should
+|| interpret attribute values as follows:
+|| * Replace character entities with characters,
+|| * Ignore line feeds,
+|| * Replace each carriage return or tab with a single space
+
+Notice the: "Ignore line feeds"
+
+Although further down it says:
+For some HTML 4 attributes with CDATA attribute values, the
+specification imposes further constraints on the set of legal
+values for the attribute that may not be expressed by the DTD.
+
+III) Eric sent me an emergency-patch for BUG#197
+
+That bug is NOT related with the cache but with an URL that's
+more than 1024 bytes long.
+
+
+
+
+As currently dillo has fixed limits for attribute values (a
+violation to the standards), and as we are parsing entities only
+in a few places, and as patching current code only adds more
+passes over the same code, the clean solution is to reimplement
+attribute parsing, eliminating the length constraint, and using
+the same function for parsing entities and hexadecimal character
+references, all in the same pass!
+
+The meat of it starts with the Html_get_attr() function. I
+thought that implementing it with a static GString, and returning
+its 'str' contents as 'const gchar *' should do the trick. And
+that way the allocation/deallocation overhead is avoided, and it
+gets easier to make the whole parsing in a single pass.
+
+Note that the calling function may g_strdup the returned
+string when necessary.
+
+That way, we could have something like:
+
+const gchar *Html_get_attr(...)
+{
+
+}
+
+
+This is the gross idea and further refinement is required, but
+considering that the html parsing module is well isolated from
+the rest of dillo, this task is of an intermediate complexity
+degree, and fits perfect for some guys I'll not dare to mention!
+
+Seriously, I'd certainly appreciate some of our developers to
+work on this task; maybe the perfect team is a couple with a main
+developer and a dillo-html-parsing versed consultant.
+
+
+
+Thanks a lot
+Jorge.- 
+
+
+
+Re: [Dillo-dev]About bug #194
+
+From: Bruno Widmann <bwidmann@ut...> - 2001-08-29 08:26
+
+On Tue, Aug 28, 2001 at 10:33:59PM -0300, Livio Baldini Soares wrote:
+> Hi all,
+> 
+> In a couple of minutes, I've made an awful fix. With my patch,
+> a_Url_str_resolve_relative() correctly parses this kind of
+> scheme-absent URL. But I see on the bug-track that this is being
+> worked on. I just want to send this patch to bwidmann@ut...
+> (Bruno, right?), as a basis for his work if he is having any
+> trouble. Also, feel free to ask me anything about URL's in Dillo.
+> 
+> The patch is at:
+> http://www.linux.ime.usp.br/~livio/dillo/url.double.slash.diff
+>
+
+I sent a email to Jorge last week asking him if he wanted a patch 
+for it, but as he said here on this list ATM he has so much
+email to work through so he hasn't reply'd to me yet.
+I also made a patch for it, although it took me a bit
+longer than a few minutes :)
+http://62.178.100.215:8080/~bwidmann/host_path.patch
+(Need to use port 8080 since my ISP seems to filter 80)
+
+I think your patch reads better. Can you take over and send it
+to Jorge so that anoying bug gets fixed?
+
+best wishes,
+Bruno 
+
+
+
+Re: [Dillo-dev]Yesterday commit
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-29 01:53
+
+Hi Jorge!
+
+Jorge Arellano Cid writes:
+> 
+> Hi there!
+
+(...)
+
+> No new features. Comments from those of you testing this new
+> version are very welcomed.
+
+The changes seem to be performing very well! Ever since Dillo
+started supporting tables, I've been using it as my main
+browser. Seldomly I use Netscape for frame viewing... therefore I've
+been testing Dillo a lot. Well, generally the pages I go to don't use
+flash, javascript, etc, so I have no complaints.
+
+Dillo is more stable than ever. I can browse, sometimes for hours
+straight without getting a Seg Fault (right now, for example, it's
+been running for 6 hours.. mainly doing google searches, and reading
+Linux Kernel documentation).
+
+bets regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]About bug #194
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-29 01:34
+
+Hi all,
+
+I was looking at slashdot this weekend, and saw that they used a
+"diferent" URL scheme inside hrefs... they simply leave out the
+scheme, i.e., something like: <a href="//dillo.s...net/">, which looked
+totally bogus at first. But looking through the URI RFC (#2396), I
+think it's ok to leave out the scheme, and hence the URL must be
+interpreted as a relative URL. In this case, therefore, the scheme is
+inheritated from the base URL.
+
+In a couple of minutes, I've made an awful fix. With my patch,
+a_Url_str_resolve_relative() correctly parses this kind of
+scheme-absent URL. But I see on the bug-track that this is being
+worked on. I just want to send this patch to bwidmann@ut...
+(Bruno, right?), as a basis for his work if he is having any
+trouble. Also, feel free to ask me anything about URL's in Dillo.
+
+The patch is at:
+http://www.linux.ime.usp.br/~livio/dillo/url.double.slash.diff
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]word wrapping / page width
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-28 21:47
+
+Hi everybody!
+
+> On Wed, Aug 01, 2001 at 06:14:20PM +0200, Sebastian Geerken wrote:
+> > On Wed, Aug 01, 2001 at 05:34:28PM +0200, Ulrich Schwarz wrote:
+> > > Hi,
+> > >
+> > > since a month or so, the cvs version (including the latest 0.6 release) of
+> > > dillo doesn't wrap the text on http://futurezone.orf.at but instead
+> > > extends the page width to the longest text paragraph of that page so
+> > > that no word wrapping is done and each text paragraph is displayed in
+> > > a single (extremely long) text line.
+> > >
+> > > Is this due to buggy html code on that page or due to a suboptimal
+> > > page width calculation of dillo?
+> >
+> > I've looked at the page, and found
+> >
+> > <TD WIDTH="380" ROWSPAN="2" NOWRAP>
+> >
+> > [...]
+>
+> As far as I've understood, this is not quite conforming to the
+> specifications, but I haven't found anything about word-wrap, only
+> about clipping. However, since IMHO, this HTML code does not make any
+> sense,
+
+Yes, I doesn't make sense...
+
+> I thought of a workaround, which ignores the NOWRAP in this
+> case, in Html_tag_open_table_cell:
+>
+> /* text style */
+> old_style = html->stack[html->stack_top].style;
+> style_attrs = *old_style;
+> - if (Html_get_attr(tag, tagsize, "nowrap", attrbuf, sizeof(attrbuf)))
+> + if (Html_get_attr(tag, tagsize, "nowrap", attrbuf, sizeof(attrbuf)) &&
+> + !Html_get_attr(tag, tagsize, "width", attrbuf, sizeof(attrbuf)))
+> style_attrs.nowrap = TRUE;
+> else
+> style_attrs.nowrap = FALSE;
+>
+> Intended as a subject of further discussions.
+
+
+When this message was posted, the HTML parsing policy wasn't
+yet stated in the "Project Notes". As now it is there, let's
+apply, and live happily ever after!
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Yesterday commit
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-28 19:27
+
+Hi there!
+
+I'm very happy to have finally finished the massive changes I
+was working with; the diff file was 2000 lines long!
+
+The main point of it was stability, completion and extension.
+No new features. Comments from those of you testing this new
+version are very welcomed.
+
+Now is time to restart answering a pile of emails, to review
+and integrate the patches I have in the queue, and to start
+moving a couple of ideas that sprung out while working my last
+commit.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Problems with swedish (international?) characters as entities in forms buttons, lists
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-08-28 14:38
+
+I got problems with swedish (international?) characters in buttons and in lists. The characters for example &auml; shows up properly in the usual text on a page, but no when they are to be added in the dropdownlist in a form or as a button in a submit form.
+I experimented a little and dillo parses the entities correctly, the string puts out nicely in the xterm window, but gtk doesn't seem to like it when it is to add the component(button for example).
+Maybe this has something to do with the gtk_set_locale thing?
+
+http://www.blocket.se is good to test this on. It shows up pretty quickly in the dropdowns.
+It is reported as bug #199.
+
+//Hugo 
+
+
+
+Re: [Dillo-dev]Gtk+ 2.0 Port
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-22 14:02
+
+On Tue, Aug 21, 2001 at 02:27:50PM +0200, xavier ordoquy wrote:
+> [...]
+> On the other hand, I would really appreciate the help of the guys that
+> worked on the widgets.
+
+I guess that most problems will occur with Dw (dw_*.[ch]), so send
+questions, etc. to me, I'll try to answer fast.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]bug tracking engine suggestion
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-21 21:43
+
+Henry,
+
+> The bug-tracking engine in dillo.so....net offers choices of platforms
+> like ``Linux'', ``Alpha'', and ``PPC''. These should be expanded to
+> Linux/i386, Linux/Alpha, Tru64Unix/Alpha, AIX/PPC, etc.
+
+When I first gave the option I thought it could help more, but
+experience has shown it haven't been too useful...
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Currently working on:
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-21 21:43
+
+Hi there!
+
+------
+Status
+------
+
+After some days of silence (and full work), I made some space
+to let you know what I've been working in.
+
+Considering that plugins, https, cookies and authentication
+are very close to implement, and noting that they all depend on
+the Cache/IO layer, I'm trying to fix, extend and finish several
+things there.
+
+Dillo-0.6.0 uses a lot of workarounds to achieve a certain
+stability degree, but it leaves inconsistent states, doesn't
+finish some tasks, and is incomplete.
+
+When the above mentioned features are provided, people will
+start trying to perform more serious tasks with dillo, ant it's
+not ready for that yet, so I'm trying to stabilize those layers.
+
+Currently I have a truck-load of changes to test and merge...
+
+
+------------------------
+Dillo records in the Web
+------------------------
+
+A fast survey for 'dillo browser' on google shows a lot of
+places that "advertise" our project. Unfortunately those records
+are not up to date, and the versions listed are ancient!
+
+Is sad to read that dillo doesn't support tables, that current
+version is 0.2.1 and thing like that.
+
+From time to time I get emails from people willing to help,
+that don't know how to code. THIS is a great chance to
+colaborate, by getting to those sites and providing their
+maintainers with the necessary data for updating their records.
+
+
+--------------------
+Project notes update
+--------------------
+
+Now it states dillo's HTML parsing policy (worth reading).
+
+
+
+Regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Gtk+ 2.0 Port
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-21 21:43
+
+Xavier,
+
+>
+> I got the first results with dillo and gtk+2.0 but there's still work
+> todo.
+> At this point, I can't advance further because I don't have CVS access.
+
+I don't know much of what the port involves; please let me know
+briefly what the main tasks are, and what you shall need. It
+seems I erroneously thought that anonymous access was enough.
+
+> On the other hand, I would really appreciate the help of the guys that
+> worked on the widgets.
+
+Mainly Sebastian and me.
+
+I hope to have the time to answer, cannot guarantee anything
+though, the cache and CCC stuff is consuming all of my time...
+
+
+Regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Gtk+ 2.0 Port
+
+From: xavier ordoquy <xordoquy@au...> - 2001-08-21 12:24
+
+Hi,
+
+I got the first results with dillo and gtk+2.0 but there's still work
+todo.
+At this point, I can't advance further because I don't have CVS access.
+On the other hand, I would really appreciate the help of the guys that
+worked on the widgets.
+
+Regards
+
+--
+Xavier Ordoquy, Aurora-linux
+If NT is the answer, you didn't understand the question.
+Complexity has nothing to do with intelligence. Simplicity does.
+(Larry Bossidy, CEO, Allied Signal) 
+
+
+
+Re: [Dillo-dev]Gtk+ 2.0 Port
+
+From: xavier ordoquy <xordoquy@au...> - 2001-08-20 09:43
+
+On 10 Aug 2001 10:23:57 -0400, Jorge Arellano Cid wrote:
+> Inexisting, but willing to! :-)
+> 
+> If GTK+-2.0 is the one that will use unicode (UTF-8), then it
+> is definitively an step forward. If this is the case, or if the
+> port will be equally required for the later, go ahead!
+
+I've started moving dillo slowly to gtk+2, but working without CVS
+isn't great.
+Is it possible to get a branch from say dillo 6.0 for the port ?
+My sourceforge account is mcarkan.
+
+Regards
+
+--
+Xavier Ordoquy, Aurora-linux
+If NT is the answer, you didn't understand the question.
+Complexity has nothing to do with intelligence. Simplicity does.
+(Larry Bossidy, CEO, Allied Signal) 
+
+
+
+[Dillo-dev]bug tracking engine suggestion
+
+From: Henry House <hajhouse@ho...> - 2001-08-19 22:52
+
+Attachments: Message as HTML      
+
+The bug-tracking engine in dillo.so....net offers choices of platforms
+like ``Linux'', ``Alpha'', and ``PPC''. These should be expanded to
+Linux/i386, Linux/Alpha, Tru64Unix/Alpha, AIX/PPC, etc.
+
+--=20
+Henry House
+OpenPGP key available from http://romana.hajhouse.org/hajhouse.asc 
+
+
+
+[Dillo-dev][patch] Fix for segfault when ~/.dillo is not accessable
+
+From: Amit Vainsencher <amitv@su...> - 2001-08-19 08:16
+
+Attachments: bookmark-noperm-segfault.patch      
+
+This is a simple patch to fix a segfault in dillo when it cannot access ~/.dillo for some reason or another.
+To reproduce: chmod 0 ~/.dillo; dillo;
+
+Dillo kicks major ass, good work guys.
+
+Amit 
+
+
+
+Re: [Dillo-dev]Tiny memory leak with DilloImages (and HRuler proposal)
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-16 16:40
+
+On Mon, Aug 13, 2001 at 12:04:20AM -0300, Livio Baldini Soares wrote:
+> [...]
+> About the HRulers in Dillo, they have been bugging a bit. It seems
+> that they don't create some space around them, and therefore renders
+> some pages in a "tight" manner. Take for instance the Dillo home page
+> (dillo.s...net), the main links are placed within <hr>'s but look too
+> tightly pakced together. Does anyone know what the specs say about
+> <hr>'s?
+
+Yes: "The amount of vertical space inserted between a rule and the
+content that surrounds it depends on the user agent."
+
+
+> Because, I think, normally browsers insert some space before
+> and after the <hr>'s, and that's why nobody does this explicitly.
+> Switching the a_Dw_page_linebreak() with a_Dw_page_parbreak() in the
+> Html_tag_open_hr() code makes the <hr>'s nicer for me.. some thing
+> like:
+> 
+> [patch]
+
+Applied. There is BTW currently still more space between a <hr> and a
+<p> (9 pixels), which IMHO makes sense.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Fwd: dillo patch for Fugly Fonts
+
+From: Viksell <jorgen.viksell@te...> - 2001-08-16 03:30
+
+Den 15 Aug 2001 12:56:53 +0200 skrev Hugo Hallqvist:
+> On Tue, 14 Aug 2001 18:41:28 -0700
+>=20
+> I also get boxes in a few places. Mostly inside <pre> tags. For example o=
+ne before each line in the changelog on dillo's homepage.
+> Is this too a font-based problem?
+
+I'm currently fixing this inside of <PRE> tags. It has to do with
+passing newlines and tabs into the DwPage. They can't be rendered
+correctly and shows up as boxes.
+
+> It didn't show up when using my old Mandrake-distribution, but has begun =
+to show up with my newly installed debian. It also shows up in sylpheed a g=
+tk-based mail-client.
+
+I think I got these errors when I upgrade to XFree86 4.1 on Debian.
+
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Fwd: dillo patch for Fugly Fonts
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-08-15 10:49
+
+On Tue, 14 Aug 2001 18:41:28 -0700
+
+I also get boxes in a few places. Mostly inside <pre> tags. For example one before each line in the changelog on dillo's homepage.
+Is this too a font-based problem?
+
+It didn't show up when using my old Mandrake-distribution, but has begun to show up with my newly installed debian. It also shows up in sylpheed a gtk-based mail-client.
+
+Suggestions, anyone?
+
+/Hugo
+
+Aaron Lehmann <aaronl@vi...> wrote:
+
+> Karsten had told me that without this patch he gets boxes instead of
+> propper text.
+> 
+> ----- Forwarded message from "Karsten M. Self" <kmself@ix.netcom.com> -----
+> 
+> From: "Karsten M. Self" <kmself@ix.netcom.com>
+> Date: Tue, 14 Aug 2001 18:29:11 -0700
+> To: Aaron Lehmann <aaronl@vi...>
+> Subject: dillo patch for Fugly Fonts
+> User-Agent: Mutt/1.3.17i
+> 
+> This is bad coding style -- it's a kluge, not a fix.
+> 
+> The problem is that search sequence for fonts is arbitrary, and ISO10646
+> fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646
+> fonts properly, hence the resolution problems.
+> 
+> The fix I've applied is to hardcode the font encoding into the font
+> search string in dw_style.c. 
+
+
+
+[Dillo-dev]Fwd: dillo patch for Fugly Fonts
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-08-15 01:41
+
+Attachments: dillo-kms.patch      
+
+Karsten had told me that without this patch he gets boxes instead of
+propper text.
+
+----- Forwarded message from "Karsten M. Self" <kmself@ix.netcom.com> -----
+
+From: "Karsten M. Self" <kmself@ix.netcom.com>
+Date: Tue, 14 Aug 2001 18:29:11 -0700
+To: Aaron Lehmann <aaronl@vi...>
+Subject: dillo patch for Fugly Fonts
+User-Agent: Mutt/1.3.17i
+
+This is bad coding style -- it's a kluge, not a fix.
+
+The problem is that search sequence for fonts is arbitrary, and ISO10646
+fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646
+fonts properly, hence the resolution problems.
+
+The fix I've applied is to hardcode the font encoding into the font
+search string in dw_style.c.
+
+Naturally, this is non-portable coding.
+
+I'll leave implementation to you, options might include taking encoding
+data from build options, the environment, or getting a fix into Gtk.
+
+Patch is from 0.6.0.
+
+To apply patch, save to parent of source, cd to source directory, and:
+
+$ patch -p1 < ../dillo-kms.patch
+
+Cheers.
+
+--=20
+Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.c=
+om/
+What part of "Gestalt" don't you understand? There is no K5 ca=
+bal
+http://gestalt-system.so....net/ http://www.kuro5hin.=
+org
+Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.=
+org
+Geek for Hire http://kmself.home.netcom.com/resume.h=
+tml
+
+diff -X ignore -Naur dillo-0.6.0/src/dw_style.c dillo-0.6.0-kms/src/dw_styl=
+e.c
+--- dillo-0.6.0/src/dw_style.c Sun Jul 29 08:40:12 2001
++++ dillo-0.6.0-kms/src/dw_style.c Tue Aug 14 17:29:04 2001
+@@ -247,7 +247,7 @@
+char fontname[256], *ItalicChar;
+=20
+ItalicChar =3D prefs.use_oblique ? "o" : "i";
+- sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*",
++ sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1",
+font->name,
+font->bold ? "bold" : "medium",
+font->italic ? ItalicChar : "r",
+@@ -255,7 +255,7 @@
+font->font =3D gdk_font_load(fontname);
+=20
+if (font->font =3D=3D NULL && font->italic) {
+- sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*",
++ sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1",
+font->name,
+font->bold ? "bold" : "medium",
+(*ItalicChar =3D=3D 'o') ? "i" : "o",
+@@ -268,7 +268,7 @@
+/* Can't load the font - substitute the default instead. */
+font->font =3D=20
+gdk_font_load
+- ("-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-*-*");
++ ("-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-iso8859-1");
+}
+=20
+if (font->font =3D=3D NULL) {
+
+
+
+
+----- End forwarded message -----
+
+--=20
+#define m(i)(x[i]^s[i+84])<< /* I do not condone improper use of this code =
+*/
+unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=3D2048);wri=
+te(1,s
+,n))if(s[y=3Ds[13]%8+20]/16%4=3D=3D1){int i=3Dm(1)17^256+m(0)8,k=3Dm(2)0,j=
+=3Dm(4)17^m(3)9^k
+*2-k%8^8,a=3D0,c=3D26;for(s[y]-=3D16;--c;j*=3D2)a=3Da*2^i&1,i=3Di/2^j&1<<24=
+;for(j=3D127;++j<n
+;c=3Dc>y)c+=3Dy=3Di^i/8^i>>4^i>>12,i=3Di>>8^y<<17,a^=3Da>>14,y=3Da^a*8^a<<6=
+,a=3Da>>8^y<<9,k=3Ds
+[j],k=3D"7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=3Dk^(k=
+&k*2&34)
+*6^c+~y;}}//Please join us in civil disobedience and distribute DeCSS(or ef=
+dtt!) 
+
+
+
+[Dillo-dev]Bookmarks
+
+From: DraX <drax@wh...> - 2001-08-14 22:13
+
+Am i missing something or is their no add bookmark button, i see the
+functions to do it, but no button to do it...
+
+I'm planning to implement a simple bookmark manager and want to get the
+bookmark system working well before i do so. I'm also considering writing
+compatability for Netscape bookmark files. 
+
+
+
+Re: [Dillo-dev]table rendering etc. on the ipaq
+
+From: Bruno Widmann <bwidmann@ut...> - 2001-08-14 09:26
+
+On Tue, Aug 14, 2001 at 02:55:47AM +0300, Sam J. Engstrom wrote:
+> 
+> As some of you have noticed, I've been providing arm binaries of dillo 
+> for use on the ipaq. They can be found along with notes and source at 
+> http://www.hut.fi/~sengstro/ipaq.html . Dillo is widely used on linux 
+> ipaqs because there aren't really that many good alternatives. It's 
+> advantages over konqueror/embedded have been speed, size and the fact 
+> that it has relentlessly mangled pages to fit the screen.
+> 
+> However, with recent table rendering most pages require dubious sideways 
+> scrolling. That's why I propose there should be an option (preferably 
+> selectable on the currently viewed page) to disable table rendering and 
+> fit everything except wide pictures to the window width.
+
+There is a USE_TABLES #define in html.c. I just experimented exchanging
+it with a preferences variable (prefs.render_tables), and it seems to work
+fine. I can change dillo back to old behaivor by editing dillorc. But there 
+is currently no way of changing it on the fly, although
+i would be willing to add a "Settings" menu to dillo where you could 
+change preferences on the fly.
+
+This would change it for all open windows, and i guess that's no a good
+idea. Is there a way to change it for each open window seperatly? 
+
+
+
+[Dillo-dev]table rendering etc. on the ipaq
+
+From: Sam J. Engstrom <sam@ne...> - 2001-08-13 23:56
+
+As some of you have noticed, I've been providing arm binaries of dillo 
+for use on the ipaq. They can be found along with notes and source at 
+http://www.hut.fi/~sengstro/ipaq.html . Dillo is widely used on linux 
+ipaqs because there aren't really that many good alternatives. It's 
+advantages over konqueror/embedded have been speed, size and the fact 
+that it has relentlessly mangled pages to fit the screen.
+
+However, with recent table rendering most pages require dubious sideways 
+scrolling. That's why I propose there should be an option (preferably 
+selectable on the currently viewed page) to disable table rendering and 
+fit everything except wide pictures to the window width. As you can't 
+select text or anything, panning the page by dragging from unlinked 
+areas could also be helpful.
+
+I once wrote a script to translate html pages to wml (for wap phones), 
+and found that it was often usable enough to provide a list of links to 
+different frames from the frameset. This could be a short term solution 
+before actually implementing frame support and it could remain as a 
+useful (at least on the ipaq) option.
+
+I personally would also find support for basic authentication useful 
+because of my intranet, but I assume it's not a very high priority.
+
+The changes I've actually done for the ipaq version:
+- removed the home, save, url clear and progress buttons/boxes from the 
+toolbar to get it to fit on the screen
+- bound mouse button 1 to the popup menu when not on links
+These could maybe be configurable options as well.
+
+I regret my time is consumed by other work and can't pursue these 
+improvements myself.
+
+-- 
+Sam J. Engstrom Tel. +358 400 462442 mail@sa...
+Managing Director Nemesol http://nemesol.fi 
+
+
+
+Re: [Dillo-dev] Off-topic (was:What can I do?)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-13 17:20
+
+Eric,
+
+> BTW, the Changelogs is refering to GPF fixes. Let's call them "segfaults" or
+> segmentation faults: GPF hurts my feelings ;-)
+
+Ouch! (Read as Homer :)
+
+You're absolutely right! I made the changes (will commit later though).
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]word wrapping / page width
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-13 17:01
+
+On Wed, Aug 01, 2001 at 06:14:20PM +0200, Sebastian Geerken wrote:
+> On Wed, Aug 01, 2001 at 05:34:28PM +0200, Ulrich Schwarz wrote:
+> > Hi,
+> > 
+> > since a month or so, the cvs version (including the latest 0.6 release) of
+> > dillo doesn't wrap the text on http://futurezone.orf.at but instead
+> > extends the page width to the longest text paragraph of that page so
+> > that no word wrapping is done and each text paragraph is displayed in
+> > a single (extremely long) text line.
+> > 
+> > Is this due to buggy html code on that page or due to a suboptimal
+> > page width calculation of dillo?
+> 
+> I've looked at the page, and found
+> 
+> <TD WIDTH="380" ROWSPAN="2" NOWRAP>
+> 
+> nearly directly before the text. I'm not quite sure about the
+> specification (or if it is even clear in this case), but at least,
+> this is quite ambiguous. Dillo's current behavior is to use WIDTH
+> attributes only as hints; if the cell is wider (in this case due to
+> the NOWRAP argument), it is (more or less) ignored,
+
+As far as I've understood, this is not quite conforming to the
+specifications, but I haven't found anything about word-wrap, only
+about clipping. However, since IMHO, this HTML code does not make any
+sense, I thought of a workaround, which ignores the NOWRAP in this
+case, in Html_tag_open_table_cell:
+
+/* text style */
+old_style = html->stack[html->stack_top].style;
+style_attrs = *old_style;
+- if (Html_get_attr(tag, tagsize, "nowrap", attrbuf, sizeof(attrbuf)))
++ if (Html_get_attr(tag, tagsize, "nowrap", attrbuf, sizeof(attrbuf)) &&
++ !Html_get_attr(tag, tagsize, "width", attrbuf, sizeof(attrbuf)))
+style_attrs.nowrap = TRUE;
+else
+style_attrs.nowrap = FALSE;
+
+Intended as a subject of further discussions.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Entry point of HTML before the renderer
+
+From: DraX <drax@wh...> - 2001-08-13 16:27
+
+Table support is why I installed dillo instead of laughing at it in
+futility :) Like i have for every other version.
+
+Once you have table support, you're on the way to becoming a functional
+and useful browser.
+
+
+On Mon, 13 Aug 2001, Sebastian Geerken wrote:
+
+> On Sat, Aug 11, 2001 at 09:14:28PM -0700, Eric GAUDET wrote:
+> > [...]
+> > Form elements can be trickier, but the need for them is higher. For test pages:
+> > http://www.rti-zone.org/dillo/Html.testsuite/form.html (see submit button
+> > with image and button), should not be that hard to implement.
+> > http://maps.yahoo.com (search for a city, and you're supposed to see an image
+> > server-side map in an submit button), this one is hard.
+> 
+> I planned some changes to make Gtk-Dw-Gtk-Dw-... embedding simpler,
+> something like
+> 
+> GtkDwViewport
+> `- DwPage
+> `- DwEmbedGtk
+> `- GtkButton
+> `- GtkEmbedGtkSimple
+> `- DwPage
+> 
+> GtkEmbedGtkSimple is then a widget with the same purpose of
+> GtkDwViewport, but without scrolling. I've thought of an interface
+> between the toplevel Dw widget and the Gtk widget embedding it,
+> implemented by GtkDwViewport, GtkEmbedGtkSimple, and perhaps some
+> other widgets, e.g. for the reuse of Dw within a graphical plugin.
+> 
+> Of course, a simple solution could be to omit the GtkButton, and
+> handle the DwPage like a huge link. You can also set an outset border
+> around it, look at Html_open_img for details how to do this.
+> 
+> > You can also try to torture dillo with all sort of tables and see if they are
+> > rendered correctly, and if not submit a patch to Sebastian.
+> 
+> They get less and less ;-)
+> 
+> Sebastian
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Entry point of HTML before the renderer
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-13 16:23
+
+On Sat, Aug 11, 2001 at 09:14:28PM -0700, Eric GAUDET wrote:
+> [...]
+> Form elements can be trickier, but the need for them is higher. For test pages:
+> http://www.rti-zone.org/dillo/Html.testsuite/form.html (see submit button
+> with image and button), should not be that hard to implement.
+> http://maps.yahoo.com (search for a city, and you're supposed to see an image
+> server-side map in an submit button), this one is hard.
+
+I planned some changes to make Gtk-Dw-Gtk-Dw-... embedding simpler,
+something like
+
+GtkDwViewport
+`- DwPage
+`- DwEmbedGtk
+`- GtkButton
+`- GtkEmbedGtkSimple
+`- DwPage
+
+GtkEmbedGtkSimple is then a widget with the same purpose of
+GtkDwViewport, but without scrolling. I've thought of an interface
+between the toplevel Dw widget and the Gtk widget embedding it,
+implemented by GtkDwViewport, GtkEmbedGtkSimple, and perhaps some
+other widgets, e.g. for the reuse of Dw within a graphical plugin.
+
+Of course, a simple solution could be to omit the GtkButton, and
+handle the DwPage like a huge link. You can also set an outset border
+around it, look at Html_open_img for details how to do this.
+
+> You can also try to torture dillo with all sort of tables and see if they are
+> rendered correctly, and if not submit a patch to Sebastian.
+
+They get less and less ;-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev] Off-topic (was:What can I do?)
+
+From: Eric GAUDET <egaudet@in...> - 2001-08-13 15:57
+
+-- En reponse de "Re: [Dillo-dev]What can I do?" de Jorge Arellano Cid, le
+13-Aug-2001 :
+>> _________________________________________________________________
+>> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
+> 
+> ?!!! :-o
+> 
+> I'll pretend I haven't even noticed that! ;-)
+> 
+
+BTW, the Changelogs is refering to GPF fixes. Let's call them "segfaults" or
+segmentation faults: GPF hurts my feelings ;-)
+
+> 
+> Regards (Urbi et orbi)
+> Jorge.-
+> 
+> 
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 13-Aug-2001 a 08:55:34
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]GLib-ERROR in Dw_image_scale()
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-13 15:51
+
+On Sun, Aug 12, 2001 at 04:52:20AM -0300, Livio Baldini Soares wrote:
+> I'm trying to get to the root of an GLib-ERROR (while allocating) in
+> Dw_image_scale(). The problem arises when either h or w become
+> negative (because Dw_style_box_diff_{width,heith} is greater than
+> allocation.{width,ascent+descent}). This will cause a call to g_malloc
+> with a negative value. Since malloc's expect an unsgined value, the
+> negative value translate to a _very_ big allocation.
+> 
+> I noticed this while browsing, and since it has become consistent on
+> a certain page I took the minimal case out of the page. The original
+> page was: http://www.livrariacultura.com.br/ but since it changes with
+> frequency, I copied it to:
+> 
+> http://www.linux.ime.usp.br/~livio/dillo/test-crash/
+> (the offending image is at):
+> http://www.linux.ime.usp.br/~livio/dillo/test-crash/imagem/capas1/590425.jpg
+> 
+> It's kind of awkward how allocation.ascent+allocation.descent==0...
+> I tried to track down the *_size_allocate_request's but I still can't
+> fully understand what's missing :(
+> 
+> Sebastian, do you know what's up? This following patch, prevents the
+> glib error, but doesn't do the right thing :-(
+
+That's indeed a bug lying a bit deeper. When a widget represents a
+HTML element (e.g. DwImage / <IMG>), the allocation of a widget is the
+whole element space, including margin, border, and padding, not only
+the content. What WIDTH and HEIGHT stand for is not very clear in
+
+http://www.w3.org/TR/html401/struct/objects.html#h-13.7.1
+
+but the CSS spec is more precise, as in
+
+http://www.w3.org/TR/CSS2/visudet.html#propdef-width
+
+width and height specify the _content_ size. This was actually handled
+wrong before by Dw, and is fixed now. (At least halfway, there will be
+some changes, and, I hope, simplifications on this topic.)
+
+> Maybe even when this is fixed, a check for negative values here,
+> might be a good idea....
+
+Yes. I've inserted a modified version.
+
+Sebastian
+
+PS: Jorge, needless to say that this also fixes the bug in the page
+you sent me. 
+
+
+
+Re: [Dillo-dev]bug #91 still causing problems
+
+From: DraX <drax@wh...> - 2001-08-13 15:24
+
+I actully fear it's NOT bug#91 and i was just thinking out of place:
+
+I go to any site with only 1 dillo window and while that site is closing
+use my window managers close button, dillo offers a segmentation fault. 
+
+
+
+Re: [Dillo-dev]BIG cache (was: Entry point of HTML before the renderer)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-13 13:05
+
+Hi,
+
+> > This might be a nice feature, a "clear cache" switch which will flush the
+> > cache, for one reason or another.
+>
+> You've touched an issue which I was going to address later on. But
+> here we go! It's been a little while since I've been using Dillo as
+> my main browser, and what I notice is that after a few hours of
+> browsing, Dillo has so much stuff in the cache, it uses as much memory
+> as Netscape at startup (which is a _lot_ :) Right now, for example,
+> Dillo is consuming around 15 Mb. If I start a new Dillo, it consumes
+> around 5 Mb (a little less). So more than 10Mb is being gobbled up by
+> the cache. What I do is exit Dillo and restart it again...
+
+I can't help but feeling quite happy when I read about this;
+long time developers will remember the times when it wasn't an
+issue (at all) because of lack of stability!
+
+> I think that this "clear cache", is a pretty good beginning for
+> resolving this issue... but a better way to do this (maybe later on
+> after discussing this better) is to let the user define the amount of
+> memory he wants Dillo to use _for cache_ (it's too hard and not
+> worthwhile to maintain global memory usage, just cache memory usage is
+> enough, IMHO). I imagine this would only have an affect on cache and
+> dicache modules, and nowhere else in Dillo.
+>
+> Jorge, do you have any thoughts on this?
+
+Sure.
+
+First, beware that current code doesn't have any memory
+management for the cache. Improving it by implementing a memory
+boundary would be an important addition; it requires some
+experience and a significant effort though.
+
+The main contributor to memory usage is the dicache. It holds
+the RGB decodings of the original formats (sometimes near to 3:1
+ratio). Flushing it doesn't lose any images, because they're also
+stored in the original format. It just adds decoding time to the
+next pass.
+
+Easy solution:
+
+* Add an 'use_dicache' item to dillorc (YES/NO), and flush the
+dicache when images are not being displayed (beware of multiple
+browser windows).
+
+Intermediate solution:
+
+* Add a memory boundary for the dicache, and flush it
+accordingly.
+
+Long term solution:
+
+* Add a memory boundary to the cache, and manage it with a
+frequency heuristic (for instance).
+Add a memory boundary to the dicache too.
+Don't cache downloads.
+
+Example dillorc:
+
+cache_size=4Mb
+use_dicache=YES
+dicache_size=5Mb
+
+
+
+Anyone? ;)
+Jorge.- 
+
+
+
+Re: [Dillo-dev]bug #91 still causing problems
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-13 13:05
+
+On Sun, 12 Aug 2001, DraX wrote:
+
+> I just tested to see if bug #91 was really fixed like the ChangeLog says
+> and got a segmentation fault and a core dump.
+>
+> I just went to slashdot :)
+
+Sorry, but I can't reproduce it here.
+Does it happen when closing with the window manager, or with
+Ctrl-W, or both?
+What does dillo report?
+Does it happen only with slashdot or with any page?
+What do you do afterwards?
+
+Is anyone else experiencing similar problems?
+
+> > [Off topic]
+>
+> OpenBSD 2.9, AMD k6 233, 64mb ram
+> and my laptop:
+> OpenBSD 2.9, IBM Thinkpad 760XD
+
+Thanks a lot, I'll add that info.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]What can I do?
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-13 13:05
+
+Ben,
+
+> I wish to help this project in anyway I can. I'm a new C programmer and I'm
+> just learning the GTK toolkit, and I think that this project will help me
+> learn it.
+> I wish to give back to the Open Source community that has given
+> me so much.
+
+Thanks a lot for you helping will, but I'm afraid that dillo
+is not simple even for the experienced C programmer...
+
+[Generic answer]
+
+Anyway, if you can add a vertical scroller to the pagemarks (or
+the same hack of selection boxes), that'd be a good start. Making
+the focus "tend" to the main page is certainly a need.
+
+Most recent emails in the list have several suggestions too;
+read them!
+
+One of the most appreciated things for a developer is a GOOD
+bug report (that's what the Bug-Track is for). If it becomes a
+complain list, is useless, but a careful bug report is a bless;
+and precisely now, we're short of quality entries...
+
+Finally (I assume you read the home page), if you have
+additional skills (as SGML, HTTP, sockets, rpc, threads, ...)
+it'd be good to know in order to suggest a more specific task.
+
+
+Jorge.-
+
+
+> Thanks,
+> Ben Jones
+>
+> _________________________________________________________________
+> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
+
+?!!! :-o
+
+I'll pretend I haven't even noticed that! ;-)
+
+
+Regards (Urbi et orbi)
+Jorge.- 
+
+
+
+[Dillo-dev]What can I do?
+
+From: Ben Jones <appricle@ho...> - 2001-08-13 04:56
+
+I wish to help this project in anyway I can. I'm a new C programmer and I'm 
+just learning the GTK toolkit, and I think that this project will help me 
+learn it. I wish to give back to the Open Source community that has given 
+me so much.
+
+
+Thanks,
+Ben Jones
+
+_________________________________________________________________
+Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp 
+
+
+
+[Dillo-dev]Tiny memory leak with DilloImages (and HRuler proposal)
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-13 03:04
+
+Hello!
+
+Jorge, I've been chasing, what seems to be, a tiny (rare) memory
+leak in the Html_tag_open_img(). It allocates a DilloImage (with
+a_Image_new()). I believe this gets freed with the a_Dicache_close()
+or on abort with a_Dicache_callback(). I was trying local browsing and
+I think this might be causing some leakage, when the image is _not_
+found. If the image is not found, it doens't get an dicache entry,
+right? So this DilloImage is never freed... If my reasoning is
+somewhat correct, than this should free those DilloImages:
+
+----------
+diff -pru dillo.my/src/html.c dillo.test/src/html.c
+--- dillo.my/src/html.c Sun Aug 12 05:21:58 2001
++++ dillo.test/src/html.c Sun Aug 12 22:56:55 2001
+@@ -1563,6 +1563,8 @@ static void Html_tag_open_img(DilloHtml 
+a_Interface_add_client(html->bw, ClientKey, 0);
+a_Interface_add_url(html->bw, url, WEB_Image);
+}
++ else
++ a_Image_close(Image);
+a_Url_free(url);
+}
+
+-----------
+
+Or some other, more generic, mechanism...
+
+About the HRulers in Dillo, they have been bugging a bit. It seems
+that they don't create some space around them, and therefore renders
+some pages in a "tight" manner. Take for instance the Dillo home page
+(dillo.s...net), the main links are placed within <hr>'s but look too
+tightly pakced together. Does anyone know what the specs say about
+<hr>'s? Because, I think, normally browsers insert some space before
+and after the <hr>'s, and that's why nobody does this explicitly.
+Switching the a_Dw_page_linebreak() with a_Dw_page_parbreak() in the
+Html_tag_open_hr() code makes the <hr>'s nicer for me.. some thing
+like:
+
+--------------------
+diff -pru dillo.my/src/html.c dillo.test/src/html.c
+--- dillo.my/src/html.c Sun Aug 12 05:21:58 2001
++++ dillo.test/src/html.c Sun Aug 12 22:56:55 2001
+@@ -1952,11 +1954,11 @@ static void Html_tag_open_hr(DilloHtml *
+if (Html_get_attr(tag, tagsize, ßize", size_str, sizeof(size_str)))
+size_ptr = size_str;
+
+- a_Dw_page_linebreak (DW_PAGE (html->dw));
++ a_Dw_page_parbreak (DW_PAGE (html->dw), 5);
+hruler = a_Dw_hruler_new (shade);
+Html_add_widget(html, hruler, width_ptr, size_ptr,
+html->stack[html->stack_top].style);
+- a_Dw_page_linebreak (DW_PAGE (html->dw));
++ a_Dw_page_parbreak (DW_PAGE (html->dw), 5);
+}
+
+/*
+----------------------
+
+That's all for now! Best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]bug #91 still causing problems
+
+From: DraX <drax@wh...> - 2001-08-12 23:56
+
+I just went to slashdot :)
+
+OpenBSD 2.9, AMD k6 233, 64mb ram
+and my laptop:
+OpenBSD 2.9, IBM Thinkpad 760XD
+
+On Sun, 12 Aug 2001, Jorge Arellano Cid wrote:
+
+> 
+> Hi,
+> 
+> > I just tested to see if bug #91 was really fixed like the ChangeLog says
+> > and got a segmentation fault and a core dump.
+> >
+> > I'm running cvs from less then an hour ago.
+> 
+> On what URL?
+> 
+> [Off topic]
+> Livio told me you got dillo running on OpenBSD, please send me
+> the specs of your machine, OS version, so I can update the
+> compatibility info.
+> 
+> 
+> Jorge.-
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]bug #91 still causing problems
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-12 22:45
+
+Hi,
+
+> I just tested to see if bug #91 was really fixed like the ChangeLog says
+> and got a segmentation fault and a core dump.
+>
+> I'm running cvs from less then an hour ago.
+
+On what URL?
+
+[Off topic]
+Livio told me you got dillo running on OpenBSD, please send me
+the specs of your machine, OS version, so I can update the
+compatibility info.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]bug #91 still causing problems
+
+From: DraX <drax@wh...> - 2001-08-12 22:28
+
+I just tested to see if bug #91 was really fixed like the ChangeLog says
+and got a segmentation fault and a core dump.
+
+I'm running cvs from less then an hour ago. 
+
+
+
+Re: [Dillo-dev]segfault on particular page
+
+From: Henry House <hajhouse@ho...> - 2001-08-12 08:11
+
+Attachments: Message as HTML      
+
+On Thu, Aug 09, 2001 at 03:21:58PM -0300, Livio Baldini Soares wrote:
+[...]
+> Yeah, this is a cache related problem. It appears that the remote
+> server is returning that a the `Content-Length` of an image is 0 (I
+> think it's an advertisement GIF). And Cache_parse_header wasn't
+> expecting a 0 lengthed object.
+>=20
+> This following patch "fixes" this situation (by simply checking for
+> 0 values). And I also replaced the `atol()` to `strtol()`. Sorry
+
+The patch works like charm --- thanks! The new table layout engine works
+really well on this page too :-).
+
+--=20
+Henry House
+OpenPGP key available from http://romana.hajhouse.org/hajhouse.asc 
+
+
+
+[Dillo-dev]GLib-ERROR in Dw_image_scale()
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-12 07:52
+
+Hello!
+
+I'm trying to get to the root of an GLib-ERROR (while allocating) in
+Dw_image_scale(). The problem arises when either h or w become
+negative (because Dw_style_box_diff_{width,heith} is greater than
+allocation.{width,ascent+descent}). This will cause a call to g_malloc
+with a negative value. Since malloc's expect an unsgined value, the
+negative value translate to a _very_ big allocation.
+
+I noticed this while browsing, and since it has become consistent on
+a certain page I took the minimal case out of the page. The original
+page was: http://www.livrariacultura.com.br/ but since it changes with
+frequency, I copied it to:
+
+http://www.linux.ime.usp.br/~livio/dillo/test-crash/
+(the offending image is at):
+http://www.linux.ime.usp.br/~livio/dillo/test-crash/imagem/capas1/590425.jpg
+
+It's kind of awkward how allocation.ascent+allocation.descent==0...
+I tried to track down the *_size_allocate_request's but I still can't
+fully understand what's missing :(
+
+Sebastian, do you know what's up? This following patch, prevents the
+glib error, but doesn't do the right thing :-(
+
+Maybe even when this is fixed, a check for negative values here,
+might be a good idea....
+
+******
+diff -pru dillo/src/dw_image.c dillo.download/src/dw_image.c
+--- dillo/src/dw_image.c Sun Jul 29 01:51:13 2001
++++ dillo.download/src/dw_image.c Sun Aug 12 04:39:29 2001
+@@ -544,9 +544,12 @@ static void Dw_image_scale (DwImage *ima
+}
+
+widget = DW_WIDGET (image);
+- w = widget->allocation.width - Dw_style_box_diff_width (widget->style);
+- h = widget->allocation.ascent + widget->allocation.descent -
+- Dw_style_box_diff_height (widget->style);
++ if ((w = widget->allocation.width - 
++ Dw_style_box_diff_width (widget->style)) < 0)
++ w = widget->allocation.width;
++ if ((h = widget->allocation.ascent + widget->allocation.descent -
++ Dw_style_box_diff_height (widget->style)) < 0)
++ h = widget->allocation.ascent + widget->allocation.descent;
+
+/* Zero size? Ignore. */
+if (w * h == 0)
+*******
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]BIG cache (was: Entry point of HTML before the renderer)
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-12 06:50
+
+Hya Alex,
+
+DraX writes:
+
+> I just patched with the big-small patch. It seems to pass the html
+> suite quite well, and renders why sites that use it mininally well
+> also. I'm also using the case sensitivity patch, sense it's my bug
+> *grin*
+
+Oh, nice. I'm glad to hear... maybe I'll send it to Jorge, after
+looking at it again and convincing myself it'll work. :)
+
+> This might be a nice feature, a "clear cache" switch which will flush the
+> cache, for one reason or another.
+
+You've touched an issue which I was going to address later on. But
+here we go! It's been a little while since I've been using Dillo as
+my main browser, and what I notice is that after a few hours of
+browsing, Dillo has so much stuff in the cache, it uses as much memory
+as Netscape at startup (which is a _lot_ :) Right now, for example,
+Dillo is consuming around 15 Mb. If I start a new Dillo, it consumes
+around 5 Mb (a little less). So more than 10Mb is being gobbled up by
+the cache. What I do is exit Dillo and restart it again...
+
+I think that this "clear cache", is a pretty good beginning for
+resolving this issue... but a better way to do this (maybe later on
+after discussing this better) is to let the user define the amount of
+memory he wants Dillo to use _for cache_ (it's too hard and not
+worthwhile to maintain global memory usage, just cache memory usage is
+enough, IMHO). I imagine this would only have an affect on cache and
+dicache modules, and nowhere else in Dillo.
+
+Jorge, do you have any thoughts on this? 
+
+I was thinking of implementing the cache item list as FIFO (simple
+to implement, but not so good results), or maybe use a LRU algorithm
+(harder to code, but might result in better performance for the user,
+cause the pages are, depending on the user, frequently "revisited"),
+to dispose "old" stuff in the cache. So everytime you get a new
+request which is not cached, and the cache has hit the max memory
+(defined by user), then we throw away the "oldest" cache entry to make
+room for the new stuff. Of course, this wouldn't have to be a _strict_
+limit, just something to aim for.
+
+Well, just throwing some ideas... 
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Entry point of HTML before the renderer
+
+From: DraX <drax@wh...> - 2001-08-12 06:12
+
+I just patched with the big-small patch. It seems to pass the html suite
+quite well, and renders why sites that use it mininally well also. I'm
+also using the case sensitivity patch, sense it's my bug *grin* 
+
+This might be a nice feature, a "clear cache" switch which will flush the
+cache, for one reason or another. 
+
+
+
+Re: [Dillo-dev]Entry point of HTML before the renderer
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-12 05:32
+
+Hello Alex and Eric :-)
+
+DraX writes:
+> On Sat, 11 Aug 2001, Eric GAUDET wrote:
+> > -- En reponse de "RE: [Dillo-dev]Entry point of HTML before the renderer" de
+> > DraX, le 12-Aug-2001 :
+> > > Hmm, see i thought the gzip thing would be easy, which is why i picked it.
+> > > 
+> > > Do you have any suggestions for an "Easier" task?
+> > > 
+
+(...)
+
+> > Unfortunatly (!), almost all tags are now supported, except <big> and <small>,
+> > and some form elements involving images. 
+> > 
+> I might try to add big and small, as i use them *grin*
+
+Well, I have an _old_ implementation of them here if you want to
+take a look at it. I never released them at the time, 'cause I thought
+somebody had a already working patch for that. They seem to work
+pretty well with Eric's font-styles.html test page. But feel free to
+modify them if you like, or start a brand new implementation. Oh, and
+I cheated, and build both the small and big tags in one "general"
+function. 
+
+The patch is at:
+http://www.linux.ime.usp.br/~livio/dillo/big_small_font.diff
+
+I keep a list of my not-yet-inserted-in-Dillo-patches at:
+http://www.linux.ime.usp.br/~livio/dillo/
+
+These aren't in Dillo yet, because they are still too
+crappy^h^h^h^h^h^hexperimental or Jorge hasn't had time to look at
+them.. (or both ;-)
+
+> > One thing I wanted to have for a long time is a popup menu over an image
+> > with the options "view image", "save image", "copy image location", and why not
+> > a "copy image" to paste it into gimp.
+
+Me too, me too! :) And if you do try to this, make a "Refresh Image"
+option.. sometimes the whole isn't downloaded, and I would like to
+refresh that image so it downloads completely, and since at the moment
+refreshing the current page won't refresh the images in the dicache
+(and I'm not really sure that it should.. should it?), this function
+would come in very handy.
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]Entry point of HTML before the renderer
+
+From: DraX <drax@wh...> - 2001-08-12 04:28
+
+On Sat, 11 Aug 2001, Eric GAUDET wrote:
+
+> -- En reponse de "RE: [Dillo-dev]Entry point of HTML before the renderer" de
+> DraX, le 12-Aug-2001 :
+> > Hmm, see i thought the gzip thing would be easy, which is why i picked it.
+> > 
+> > Do you have any suggestions for an "Easier" task?
+> > 
+> 
+> I found that adding new html tags and attributes support be the easiest
+> (especially if you don't know much about gtk), and the io/cache side to be the
+> hardest.
+> 
+> Unfortunatly (!), almost all tags are now supported, except <big> and <small>,
+> and some form elements involving images. 
+> 
+I might try to add big and small, as i use them *grin*
+
+> The big and small is quite easy to do, but not much used in tables, so we never
+> felt the need to implemented them so far. For a test page:
+> http://www.rti-zone.org/dillo/Html.testsuite/font_styles.html
+> 
+> Form elements can be trickier, but the need for them is higher. For test pages:
+> http://www.rti-zone.org/dillo/Html.testsuite/form.html (see submit button
+> with image and button), should not be that hard to implement.
+> http://maps.yahoo.com (search for a city, and you're supposed to see an image
+> server-side map in an submit button), this one is hard.
+> 
+I might try that if i feel more confident later.
+
+> You can also try to torture dillo with all sort of tables and see if they are
+> rendered correctly, and if not submit a patch to Sebastian.
+> 
+> One thing I wanted to have for a long time is a popup menu over an image
+> with the options "view image", "save image", "copy image location", and why not
+> a "copy image" to paste it into gimp.
+> 
+That i can probabbly do, i know a bit of GTK from odd projects here and
+there so it shouldn't be that hard to pull off, atleast copy image
+location.
+
+> But if you really want to try and implement the gziped pages, go ahead!
+> 
+> As you can see, there's plenty to do!
+> 
+> Best,
+> ------------------------------------
+> Eric GAUDET <egaudet@in...>
+> Le 11-Aug-2001 a 20:41:16
+> "In theory, there's no difference between 
+> theory and practice; in practice, there is."
+> ------------------------------------
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> http://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+RE: [Dillo-dev]Entry point of HTML before the renderer
+
+From: Eric GAUDET <egaudet@in...> - 2001-08-12 04:14
+
+-- En reponse de "RE: [Dillo-dev]Entry point of HTML before the renderer" de
+DraX, le 12-Aug-2001 :
+> Hmm, see i thought the gzip thing would be easy, which is why i picked it.
+> 
+> Do you have any suggestions for an "Easier" task?
+> 
+
+I found that adding new html tags and attributes support be the easiest
+(especially if you don't know much about gtk), and the io/cache side to be the
+hardest.
+
+Unfortunatly (!), almost all tags are now supported, except <big> and <small>,
+and some form elements involving images. 
+
+The big and small is quite easy to do, but not much used in tables, so we never
+felt the need to implemented them so far. For a test page:
+http://www.rti-zone.org/dillo/Html.testsuite/font_styles.html
+
+Form elements can be trickier, but the need for them is higher. For test pages:
+http://www.rti-zone.org/dillo/Html.testsuite/form.html (see submit button
+with image and button), should not be that hard to implement.
+http://maps.yahoo.com (search for a city, and you're supposed to see an image
+server-side map in an submit button), this one is hard.
+
+You can also try to torture dillo with all sort of tables and see if they are
+rendered correctly, and if not submit a patch to Sebastian.
+
+One thing I wanted to have for a long time is a popup menu over an image
+with the options "view image", "save image", "copy image location", and why not
+a "copy image" to paste it into gimp.
+
+But if you really want to try and implement the gziped pages, go ahead!
+
+As you can see, there's plenty to do!
+
+Best,
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 11-Aug-2001 a 20:41:16
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+RE: [Dillo-dev]Entry point of HTML before the renderer
+
+From: DraX <drax@wh...> - 2001-08-12 03:33
+
+Hmm, see i thought the gzip thing would be easy, which is why i picked it.
+
+Do you have any suggestions for an "Easier" task? 
+
+
+
+RE: [Dillo-dev]Entry point of HTML before the renderer
+
+From: Eric GAUDET <egaudet@in...> - 2001-08-12 03:20
+
+-- En reponse de "[Dillo-dev]Entry point of HTML before the renderer" de DraX,
+le 12-Aug-2001 :
+> I'm pushing my limited C skills to the max and trying to write a patch to
+> support gzipped html files using zlib. On to my question, in what file
+> does the html file actully get downloaded before it enters the renderer?
+> 
+
+First of all, you have to read _all_ the documentation you can find in dillo
+sources and on the web site.
+Then, a good start for this problem could be to have a look at how the dicache
+is called and how it handles the images, and do something similar with gzipped
+pages.
+
+However, this is not an easy task, and if your C skills are that limited, you
+might want to train first by volunteering for something simpler.
+
+Anyway, good luck with your coding. And if your stuck with a problem, don't
+be shy and ask for help on the list, with or without publishing the half-cooked
+patch you're working on.
+
+> Thanks in advance, Alex
+> 
+
+Best,
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 11-Aug-2001 a 20:13:21
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]Entry point of HTML before the renderer
+
+From: DraX <drax@wh...> - 2001-08-12 02:32
+
+I'm pushing my limited C skills to the max and trying to write a patch to
+support gzipped html files using zlib. On to my question, in what file
+does the html file actully get downloaded before it enters the renderer?
+
+Thanks in advance, Alex 
+
+
+
+[Dillo-dev]what a great browser!
+
+From: John Utz <john@ut...> - 2001-08-11 05:43
+
+i just installed 0.6 and i think it is great! thankyoufor all of your hard
+work!
+
+johnu
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]E-mail flood
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-10 14:42
+
+Hi there!
+
+
+Someday it was to happen, and it did. I have an email pile
+that's near a hundred; this is too much to handle properly, so I
+apologize for all the foreseable delays, and worst, for those
+that may remain unanswered.
+
+I started processing it prioritizing the queue. It will be
+slow, but it works.
+
+Please note that this is good news. Bad news would be to sit in
+waiting for someone to get interested.
+
+In the mean time, please try to be very concise in your emails,
+and try to design them so a short answer keeps you going on
+(whenever that's possible).
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Gtk+ 2.0 Port
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-10 14:40
+
+Xavier,
+
+> Hi,
+>
+> I am interested in porting dillo to gtk+ 2.0.
+> What's the status of this task ?
+
+Inexisting, but willing to! :-)
+
+If GTK+-2.0 is the one that will use unicode (UTF-8), then it
+is definitively an step forward. If this is the case, or if the
+port will be equally required for the later, go ahead!
+
+
+Thanks
+Jorge.- 
+
+
+
+Re: [Dillo-dev]I'm back (kind-of)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-10 14:40
+
+Eric,
+
+> - a friend of mine succesfully tested dillo on his SGI O2 running IRIX (after
+> compiling the gtk and the libpng, because the provided package was too old):
+> Jorge, you might want to add that to the plateforms repported to work :-)
+
+Done!
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Re: [PATCH] Add history buttons to back and forward
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-10 14:40
+
+Hi,
+
+On 8 Aug 2001, Olaf Dietsche wrote:
+
+> [History/navigation]
+>
+> So, I see this as two, maybe three, different items:
+> - keeping (global) history information
+> - keeping (local) navigation information
+> - and the user interface to this: history/navigation buttons
+>
+> The second one is already available. I started the third one with my
+> history button patch; which leaves the first item to be done.
+
+Navigation is already provided, global history should be
+accessible with the rightmost mouse button over BACK or FORWARD.
+
+> > I was expecting the final patch from Eric when this one came
+> > in, but AFAIK Eric's is on a busy agenda these days so I think
+> > he'll gladly hand his work to any volunteer. Please email him
+> > before.
+>
+> Does this means, there is already work done for the global history
+> list?
+
+Please ask Eric.
+
+> > As the opportunity arises, I'll advice again not to do silent
+> > patching, that's what the bug-track is for. Fortunately this time
+> > it was an easy one...
+>
+> When I search for "history", I don't find any entry. So, where is the
+> place, I should look for this kind of information?
+
+Right there!
+
+...but there's no entry. That's the problem! :)
+
+(CVS also holds a tag for every commit, and dillo's ChangeLog
+file, within CVS, is also a good place, but the main
+information resource is the BugTrack).
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]segfault on particular page
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-09 18:22
+
+Hi Henry!
+
+Henry House writes:
+> Dillo 0.6.0 crashes when viewing the following page:
+> 
+> Nav_open_url: Url=>http://www.linuxdevices.com/articles/AT8574944925.html<
+
+> [segfault]
+
+Yeah, this is a cache related problem. It appears that the remote
+server is returning that a the `Content-Length` of an image is 0 (I
+think it's an advertisement GIF). And Cache_parse_header wasn't
+expecting a 0 lengthed object.
+
+This following patch "fixes" this situation (by simply checking for
+0 values). And I also replaced the `atol()` to `strtol()`. Sorry
+Jorge, but `atol()` makes me sick :( I have lost hours and hours of
+debugging my programs, only to find that atol is kind of buggy. I
+prefer strtol() a lot more! And I suggest that the all atoi()'s from
+html.c be changed to strtol()'s too. Jorge, if you want I can make a
+patch changing them! Just ask! (And please do! ;-)
+
+Well, the patch is at:
+
+http://www.linux.ime.usp.br/~livio/dillo/cache_bug.diff
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Color Patch
+
+From: Scott Cooper <scott@ig...> - 2001-08-09 03:17
+
+hey everyone
+
+here's a patch that started out small and got a little bigger but it should be cool in this email.
+
+there is this segfault bug in Colors.c (dillo 0.6.0):
+
+} else if (g_strncasecmp (subtag, "0x", 2) == 0) {
+cp = strchr (subtag, 'x');
+ret_color = strtol(++cp, NULL, 16);
+} else {
+
+a color with a capital X ("0Xff0000", say) bombs it since the strcasecmp lets it through but the strchr returns NULL.
+
+i noticed it only cos i ripped the color table into one of my own projects, but it exposed another issue:
+
+in html, the color "#ff" should be red, but dillo does a strtol on hex colors and hence returns blue. to be correct, any hex color should be padded to the right with zeros to 6 chars. so "#ff7" should be parsed to 0xff7000, not 0xff7.
+
+the patch below is only long 'cos it's more verbose than a strol and lets whitespace on either end of the hex string. you could just use the shift, but i like it loose...a cost of a few more lines of code lets a poorly written web page render ok.
+
+i had a quick scan of the bug list and i couldn't find a reference to this...i don't know if it's that significant since most people use "#ff0000" when writing colours, but it could be responsible for some crazy crashes that don't have any obvious cause.
+
+and anyway, my favourite feature of dillo is its stability so every hole should be plugged.
+
+(this is my first patch, so fingers crossed...)
+
+Scott
+
+scott@indecision:~/src/dillo-0.6.0$ diff ./src/colors.c ./src/colors-new.c
+3a4
+> #include <ctype.h>
+196a198,245
+> * Parse a color in hex
+> * 
+> * Skip leading spaces,
+> * Scan all hex chars, abort on non-hex chars
+> * 
+> * Return Value:
+> * default_color on error, otherwise the right color number.
+> */
+> static gint32 a_Color_parse_hex (char *s, gint32 default_color)
+> {
+> int n;
+> gint32 ret_color;
+> 
+> for (; *s && isspace(*s); s++) {
+> }
+> 
+> for (n = 0, ret_color = 0; n < 6 && *s; n++, s++) {
+> if (*s >= '0' && *s <= '9') {
+> ret_color = (ret_color << 4) + (*s - '0');
+> }
+> else if (*s >= 'a' && *s <= 'f') {
+> ret_color = (ret_color << 4) + (*s - 'a' + 10);
+> }
+> else if (*s >= 'A' && *s <= 'F') {
+> ret_color = (ret_color << 4) + (*s - 'A' + 10);
+> }
+> else if (isspace(*s)) {
+> break;
+> }
+> else {
+> return default_color;
+> }
+> }
+> 
+> if (*s && !isspace(*s)) {
+> /* there are more than 6 chars */
+> return default_color;
+> }
+> 
+> if (n < 6) {
+> /* "0xFF" -> 0xff0000 */
+> ret_color <<= (6 - n) << 2;
+> }
+> 
+> return ret_color;
+> }
+> 
+> /*
+206c255
+< char *cp, *tail;
+---
+> char *cp;
+210c259
+< ret_color = -1;
+---
+> cp = subtag;
+212,232c261,263
+< if ((cp = strchr(subtag, '#')) != NULL) {
+< cp++;
+< ret_color = strtol(cp, NULL, 16);
+< } else if (g_strncasecmp (subtag, "0x", 2) == 0) {
+< cp = strchr (subtag, 'x');
+< ret_color = strtol(++cp, NULL, 16);
+< } else {
+< /* Binary search */
+< low = 0;
+< high = NCOLORS; /* Number of colors */
+< while (low <= high) {
+< mid = (low + high) / 2;
+< if ((ret = g_strcasecmp(subtag, color_keyword[mid].key)) < 0)
+< high = mid - 1;
+< else if (ret > 0)
+< low = mid + 1;
+< else {
+< ret_color = color_keyword[mid].val;
+< break;
+< }
+< }
+---
+> /* skip leading spaces */
+> while (isspace(*cp)) {
+> cp++;
+235,239c266,267
+< if (ret_color == -1 && strlen(subtag) == 6) {
+< DEBUG_HTML_MSG("hexadecimal color codes MUST start with '#'.\n");
+< ret_color = strtol(subtag, &tail, 16);
+< if (ret_color == 0 && tail == subtag)
+< ret_color = -1;
+---
+> if (*cp == '#') {
+> ret_color = a_Color_parse_hex(cp + 1, default_color);
+241,242c269,294
+< if (ret_color < 0 || ret_color > 0xffffff)
+< ret_color = default_color;
+---
+> else if (*cp == '0') {
+> if (cp[1] == 'x' || cp[1] == 'X') {
+> ret_color = a_Color_parse_hex(cp + 2, default_color);
+> }
+> else {
+> ret_color = a_Color_parse_hex(cp, default_color);
+> }
+> }
+> else if (*cp >= '1' && *cp <= '9') {
+> ret_color = a_Color_parse_hex(cp, default_color);
+> }
+> else {
+> /* Binary search */
+> low = 0;
+> high = NCOLORS; /* Number of colors */
+> while (low <= high) {
+> mid = (low + high) / 2;
+> if ((ret = g_strcasecmp(cp, color_keyword[mid].key)) < 0)
+> high = mid - 1;
+> else if (ret > 0)
+> low = mid + 1;
+> else {
+> ret_color = color_keyword[mid].val;
+> break;
+> }
+> }
+243a296,300
+> if (low > high) {
+> ret_color = a_Color_parse_hex(cp, default_color);
+> }
+> }
+> 
+
+
+
+Re: [Dillo-dev]Attribute Parsing
+
+From: Sam Dennis <sam@ma...> - 2001-08-08 21:15
+
+On Tue, Aug 07, 2001 at 06:43:41PM +0200, Sebastian Geerken wrote:
+> Hi.
+> 
+> Most of you will remember the discussion on how to parse the HREF
+> attribute of the <a> tag. This is a similar problem: in
+> 
+> http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/
+> 
+> you'll find something like
+> 
+> <table width="100&#37;">
+> 
+> Dillo reads this as "100" (pixels) and complains about the garbage at
+> the end. I'm not an SGML expert, so I thought to post this to the
+> list. Have attributes to be be parsed generally, or is this page
+> invalid?
+> 
+> Sebastian
+
+The page is right, we're wrong. I think I suggested that attributes be parsed
+inside all tags at the time, but I may be mistaken.
+
+Anyway, this is definitely what the specifications say. 
+
+
+
+[Dillo-dev]I'm back (kind-of)
+
+From: Eric GAUDET <egaudet@in...> - 2001-08-08 18:21
+
+Hi all,
+I've been very quiet lately, but I'm still around and still willing to work on
+dillo. That means the bug-track entries I've been voluntreering for are still
+on my list and I'll hopefully find some time soon to finish them all. But you
+know what it is: new job, new country, ... a baby ... I've been quite busy ;-)
+
+Anyway, here's what I wanted to say:
+
+- Sebastian: awesome job you did with the tables !!! If you want to send me your
+html test pages, I'll add them to the test suite right away.
+I also wanted to remind everyone that you can send me the pages you built, or
+you found, that are relevant for testing dillo, so I can integrate them in the
+testing suite. This is especially true if you do a bug repport that asks to
+"build such a page": build the damn page so everyone can test it!
+
+- a friend of mine succesfully tested dillo on his SGI O2 running IRIX (after
+compiling the gtk and the libpng, because the provided package was too old):
+Jorge, you might want to add that to the plateforms repported to work :-)
+
+Best,
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 08-Aug-2001 Time: 11:03:20
+Constants other than 0 and 1 are
+referred to as "magic numbers". 
+---------------------------------- 
+
+
+
+[Dillo-dev]Re: [PATCH] Add history buttons to back and forward
+
+From: Olaf Dietsche <olaf.dietsche@gm...> - 2001-08-08 15:32
+
+Hi Jorge,
+
+Jorge Arellano Cid <jcid@ne...> writes:
+
+> Some time ago I received a very similar patch from Eric. We
+> started a long thread discussion about the issue, and finally
+> agreed it into a design. I'll comment, cut&paste and join the
+> relevant parts in the hope it becomes clear from there.
+
+Well, maybe. I try to restate, as I understand it. What you're talking
+about, is keeping (global) history information per se; I just added
+history (navigation in your parlance) _buttons_ and used the history
+(navigation) information available.
+
+So, I see this as two, maybe three, different items:
+- keeping (global) history information
+- keeping (local) navigation information
+- and the user interface to this: history/navigation buttons
+
+The second one is already available. I started the third one with my
+history button patch; which leaves the first item to be done.
+
+> I was expecting the final patch from Eric when this one came
+> in, but AFAIK Eric's is on a busy agenda these days so I think
+> he'll gladly hand his work to any volunteer. Please email him
+> before.
+
+Does this means, there is already work done for the global history
+list? If this is the case, the easiest would be, to integrate it into
+CVS and extend the history buttons.
+
+> As the opportunity arises, I'll advice again not to do silent
+> patching, that's what the bug-track is for. Fortunately this time
+> it was an easy one...
+
+When I search for "history", I don't find any entry. So, where is the
+place, I should look for this kind of information?
+
+> PD2: On the other hand, simple questions are easy to answer, so
+> don't be shy!
+
+I suppose, sending patches qualifies as not being shy :-).
+
+Regards, Olaf. 
+
+
+
+[Dillo-dev]segfault on particular page
+
+From: Henry House <hajhouse@ho...> - 2001-08-08 05:15
+
+Attachments: Message as HTML      
+
+Dillo 0.6.0 crashes when viewing the following page:
+
+Nav_open_url: Url=3D>http://www.linuxdevices.com/articles/AT8574944925.html<
+Dns_server: http://www.linuxdevices.com is 800b2da3
+Dns_server: ads.zdnet.com is cdb57072
+Dns_server: gserv.zdnet.com is cdb5704a
+[segfault]
+
+I am using libc5 version 2.2.3.
+
+--=20
+Henry House
+OpenPGP key available from http://romana.hajhouse.org/hajhouse.asc 
+
+
+
+[Dillo-dev]Internationalization & Localization
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-08 01:42
+
+Hi,
+
+
+There's an updated [project notes] with the current position on
+i18n & l10n. There's also a new link to a japanese support patch.
+
+hope this helps.
+Jorge.- 
+
+
+
+Re: [Dillo-dev][PATCH] Add history buttons to back and forward
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-07 23:56
+
+Olaf, Eric, Sebastian, et all!
+
+
+On 6 Aug 2001, Olaf Dietsche wrote:
+
+> Hi,
+>
+> first of all, thanks for starting this great project.
+> Here is a patch on top of cvs, which adds history buttons to the
+> toolbar.
+
+
+Some time ago I received a very similar patch from Eric. We
+started a long thread discussion about the issue, and finally
+agreed it into a design. I'll comment, cut&paste and join the
+relevant parts in the hope it becomes clear from there.
+
+I was expecting the final patch from Eric when this one came
+in, but AFAIK Eric's is on a busy agenda these days so I think
+he'll gladly hand his work to any volunteer. Please email him
+before.
+
+As the opportunity arises, I'll advice again not to do silent
+patching, that's what the bug-track is for. Fortunately this time
+it was an easy one...
+
+----------------------------------------------------------------
+SPECS (add some salt to this collage :):
+
+>>
+The way to trigger the FWD and BCK history is with the
+rightmost mouse button (just as with our context sensitive menus)
+
+>>
+I've been thinking of it, and testing, and found that it'd be
+excellent not to lose the whole history information. I mean,
+since we're using the navigation stack, if I go to a page near
+the beginning and click on a _new_ link of it, the rest of the
+navigation stack will be lost (forward history). So, maybe
+keeping an stack-independent ordered-list (ideally an ordered
+hash) of every single visited-root-URL can do the trick, and
+we'll never have to worry again about loosing stack info. That
+way, we could have access to any previously visited URL without
+worrying about the stack.
+
+A skim through the code shows Nav_open_url as a good place for
+inserting the new URL into the hash...
+
+>>
+
+> I'm not sure I'm following you: you mean the "history" list
+> should not be the navigation stack, but an independant list of
+> all the visited url?
+
+Yes!
+(ideally an ordered hash in where to append new URLs)
+
+> This list
+> should show when the back button is pushed with the 3rd
+> mousebutton, right ?
+> What about the forward button, then ?
+
+If we keep the list ordered, the relative position of current
+URL can be found within it. That position defines what is back
+and what is forward!
+
+Note that the navigation stack remains untouched.
+
+> Don't you want a "about:history" instead ?
+
+I had been thinking of that before your patch!, but after
+playing a while with your scheme, I liked it more!
+
+>>
+
+> Ok. It's not very clear for me how we can manage to keep an
+> "order" in pages
+> being visited, backward and forward and clicking on new links:
+> nothing linear here, obviously.
+
+URLs are appended to the list as they get visited. i.e. every
+new URL is appended. If you go back, let's say to the midddle of
+the "history", and click on a new link, it is equally appended to
+the END of the list, thus defining a list that's ordered by
+order-of-visit. On the other hand, if you follow already visited
+links, they're NOT appended because they're already in the list.
+
+(And as with the navigation stack, only RootUrls count).
+
+
+> [some other ideas were discussed]
+> [a few more]
+> [and finally...]
+
+
+It's interesting indeed, but I'd prefer to first implement the
+simple scheme I described above, play with it, get a feel of it,
+and then decide whether to improve it or not and how.
+
+
+> Ok, last question: what if I open a new window on a link ? Do I
+> keep the "forward history" (1 big history for all windows), or
+> do I keep only the back history (history per window, spawned
+> when opening a link in a new window) ?
+
+1 big history for all windows!
+
+That way, the user can always count on back and forward history
+to help him find where a lost visited-site has gone. And normal
+back and forward will aid him with the latest sites.
+
+I'll be looking forward to see it working!
+
+
+-----------------------------------------------------------------
+
+
+Cheers
+Jorge.-
+
+
+
+PD: As you may notice, there's a lot of work going behind the
+scenes, so please allow some time to our busy developers in
+answering your emails.
+
+PD2: On the other hand, simple questions are easy to answer, so
+don't be shy! 
+
+
+
+[Dillo-dev]Attribute Parsing
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-07 16:45
+
+Hi.
+
+Most of you will remember the discussion on how to parse the HREF
+attribute of the <a> tag. This is a similar problem: in
+
+http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/
+
+you'll find something like
+
+<table width="100&#37;">
+
+Dillo reads this as "100" (pixels) and complains about the garbage at
+the end. I'm not an SGML expert, so I thought to post this to the
+list. Have attributes to be be parsed generally, or is this page
+invalid?
+
+Sebastian 
+
+
+
+Re: [Dillo-dev][PATCH] Add history buttons to back and forward
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-07 13:47
+
+Attachments: history2.diff      
+
+On Mon, Aug 06, 2001 at 09:14:00PM +0200, Olaf Dietsche wrote:
+> Hi,
+> 
+> first of all, thanks for starting this great project.
+> Here is a patch on top of cvs, which adds history buttons to the
+> toolbar.
+> 
+> Does anybody know, how I can set the width of these buttons? They are
+> as wide as every other button and I would like to make them smaller.
+
+One way is to add them as widgets, as in the patch I've appended. To
+be applied after Olaf's patch.
+
+Sebastian 
+
+
+
+[Dillo-dev][PATCH] Add history buttons to back and forward
+
+From: Olaf Dietsche <olaf.dillo@ex...> - 2001-08-06 19:14
+
+Attachments: Message as HTML      dillo-history.patch      
+
+
+
+
+
+Re: [Dillo-dev]Memory Leakage
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-06 02:29
+
+Hello Aaron!
+
+Aaron Lehmann writes:
+> As I browse the web with dillo, the memory usage consistantly goes up.
+> Is it caching every page that it sees, or is there a memory leak? Can
+> the amount of memory cache to use be controlled? I've only run it up
+> to 5.55MB, but I assume it will keep growing.
+
+The problem your seeing is that dillo _does_ cache every page (and
+image) you download. That's probably why your feeling that it leaks. A
+while ago, we've made efforts to get rid of the leaks in dillo. Even
+though I think it leaks very little memory, it still leaks a bit (you
+can experiment and keep doing Back and Forward between two pages
+various times, and keep looking at dillo's memory usage).
+
+But the problem your talking about is sort of registered as bug
+#159 at
+http://dillo.so....net/cgi-bin/bugtrack/Dillo_query.cgi?what=all&Submit=Find+It!
+
+And about hard disk cache, I think it's pretty much covered in
+`CACHE PHILOSOPHY` in dillo/doc/Cache.txt
+
+
+best regards!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Find Text
+
+From: Eric GAUDET <egaudet@in...> - 2001-08-06 01:57
+
+-- En reponse de "Re: [Dillo-dev]Find Text" de Aaron Lehmann, le 06-Aug-2001 :
+> On Tue, Jul 24, 2001 at 10:48:11AM -0400, Jorge Arellano Cid wrote:
+>> I've started implementing "find text".
+> 
+> The Find Text that's in CVS does a perfect job of finding text. The
+> only problem is that it doesn't show it to the user by highlighting
+> it! I assume you know about this. I can't wait until it does highlight
+> the text, because once that happens it will be easier to allow the
+> user to select text for copying.
+> 
+> Are you looking for assistance with this feature?
+> 
+
+I'd be interested in a simple way to highlight text: I've implemented the select
+and copy mecanism (see bug-track), but I don't have time to do the highlighting
+selection. If you can provide a patch that highlight the text found, make sure
+it can be reused and send it to me.
+
+Best,
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 05-Aug-2001 a 18:52:58
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]Memory Leakage
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-08-06 01:43
+
+As I browse the web with dillo, the memory usage consistantly goes up.
+Is it caching every page that it sees, or is there a memory leak? Can
+the amount of memory cache to use be controlled? I've only run it up
+to 5.55MB, but I assume it will keep growing. 
+
+
+
+Re: [Dillo-dev]Find Text
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-08-06 01:36
+
+On Tue, Jul 24, 2001 at 10:48:11AM -0400, Jorge Arellano Cid wrote:
+> I've started implementing "find text".
+
+The Find Text that's in CVS does a perfect job of finding text. The
+only problem is that it doesn't show it to the user by highlighting
+it! I assume you know about this. I can't wait until it does highlight
+the text, because once that happens it will be easier to allow the
+user to select text for copying.
+
+Are you looking for assistance with this feature? 
+
+
+
+[Dillo-dev]Assorted dillo issues
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-08-06 01:32
+
+1) I went to "view bookmarks", then bookmarked something, then looked at my
+bookmark page again through "view bookmarks". I needed to reload to
+get the new bookmark. This shouldn't be hard to fix.
+
+2) Some pages like http://www.shared-source.com have a <?xml version="1.0"?>.
+It appears in the body under dillo. What does the XHTML spec say about
+this? 
+
+
+
+Re: [Dillo-dev]0.6.0 release
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-03 14:55
+
+Hi Raphael!
+
+Mondesir, Raphael writes:
+> Hi All,
+> 
+> Dillo truly is a great product.
+
+I think so too! :-)
+
+> One thing that I noticed when using Dillo 0.6.0 is that the FTP download
+> function does not seem to be working. Is this intentional or are there plans
+> to incorporate this into the program?
+
+Well, it's intentional _and_ there are plans to incorporate this
+into Dillo. This has been a long TODO feature that has been delayed
+specially because of this was intended to be included as a Dillo
+Plugin. Ask Jorge about this if you're interested in helping out.
+First take a look at:
+http://dillo.so....net/Notes.txt [Plugins section]
+
+And most importantly:
+http://dillo.so....net/dpi1.txt
+
+good luck!
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]0.6.0 release
+
+From: Mondesir, Raphael <raphael.mondesir@tf...> - 2001-08-03 14:19
+
+Hi All,
+
+Dillo truly is a great product.
+
+One thing that I noticed when using Dillo 0.6.0 is that the FTP download
+function does not seem to be working. Is this intentional or are there plans
+to incorporate this into the program?
+
+Thanks,
+Raphael
+
+-----Original Message-----
+From: Sam Dennis [mailto:sam@ma...]
+Sent: Thursday, August 02, 2001 9:42 PM
+To: dillo-dev@li...
+Subject: Re: [Dillo-dev]0.6.0 release
+
+
+On Wed, Aug 01, 2001 at 04:14:08AM -0300, Livio Baldini Soares wrote:
+> Hi!
+> 
+> Jorge Arellano Cid writes:
+> 
+> (...)
+> > 
+> > dillo-0.6.0 has just been released!!!!
+> 
+> Wow! Great stuff! This thing just gets better and better. I
+> specially like the new tables... I've rolled around the Internet and
+> found that the tables are working alright. There are still some
+> glitches here and there (see the background in happypenguin.org, and
+> the missing gray border that should surround the main page in
+> http://www.so....net), but there are very usable!
+> 
+> Any chance of getting frames done too? :)
+
+I am working on this, honestly. The code's just not quite ready yet :)
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+http://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]Gtk+ 2.0 Port
+
+From: xavier ordoquy <xordoquy@au...> - 2001-08-03 10:06
+
+Hi,
+
+I am interested in porting dillo to gtk+ 2.0.
+What's the status of this task ?
+
+Regards.
+
+--
+Xavier Ordoquy, Aurora-linux
+If NT is the answer, you didn't understand the question.
+Complexity has nothing to do with intelligence. Simplicity does.
+(Larry Bossidy, CEO, Allied Signal) 
+
+
+
+Re: [Dillo-dev]0.6.0 release
+
+From: Sam Dennis <sam@ma...> - 2001-08-03 01:32
+
+On Wed, Aug 01, 2001 at 04:14:08AM -0300, Livio Baldini Soares wrote:
+> Hi!
+> 
+> Jorge Arellano Cid writes:
+> 
+> (...)
+> > 
+> > dillo-0.6.0 has just been released!!!!
+> 
+> Wow! Great stuff! This thing just gets better and better. I
+> specially like the new tables... I've rolled around the Internet and
+> found that the tables are working alright. There are still some
+> glitches here and there (see the background in happypenguin.org, and
+> the missing gray border that should surround the main page in
+> http://www.so....net), but there are very usable!
+> 
+> Any chance of getting frames done too? :)
+
+I am working on this, honestly. The code's just not quite ready yet :) 
+
+
+
+Re: [Dillo-dev]0.6.0 release
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-01 16:39
+
+On Wed, Aug 01, 2001 at 04:14:08AM -0300, Livio Baldini Soares wrote:
+> Hi!
+> 
+> Jorge Arellano Cid writes:
+> 
+> (...)
+> > 
+> > dillo-0.6.0 has just been released!!!!
+> 
+> Wow! Great stuff! This thing just gets better and better. I
+> specially like the new tables... I've rolled around the Internet and
+> found that the tables are working alright. There are still some
+> glitches here and there (see the background in happypenguin.org, and
+> the missing gray border that should surround the main page in
+> http://www.so....net), but there are very usable!
+
+happypenguin.org contains somewhere "<tr bgcolor=...>", this should be
+simple to implement, and is already registered in the bug-track. (I
+must admit that I had not noticed it in the spec, and thought that it
+is a non-standard extension ;-)
+
+http://www.so....net uses background *images* for this effect, I have
+had some ideas how to implement this, and will sent them later to the
+list.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]word wrapping / page width
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-08-01 16:16
+
+On Wed, Aug 01, 2001 at 05:34:28PM +0200, Ulrich Schwarz wrote:
+> Hi,
+> 
+> since a month or so, the cvs version (including the latest 0.6 release) of
+> dillo doesn't wrap the text on http://futurezone.orf.at but instead
+> extends the page width to the longest text paragraph of that page so
+> that no word wrapping is done and each text paragraph is displayed in
+> a single (extremely long) text line.
+> 
+> Is this due to buggy html code on that page or due to a suboptimal
+> page width calculation of dillo?
+
+I've looked at the page, and found
+
+<TD WIDTH="380" ROWSPAN="2" NOWRAP>
+
+nearly directly before the text. I'm not quite sure about the
+specification (or if it is even clear in this case), but at least,
+this is quite ambiguous. Dillo's current behavior is to use WIDTH
+attributes only as hints; if the cell is wider (in this case due to
+the NOWRAP argument), it is (more or less) ignored,
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Delayed release
+
+From: Ulrich Schwarz <uschwarz@gm...> - 2001-08-01 15:40
+
+Hi,
+
+On Sat, Jul 14, 2001 at 09:15:51AM -0400, Jorge Arellano Cid wrote:
+
+> Has anyone reproduced BUG#166?
+
+It has turned out that this bug on my system was not caused
+by dillo but by KDE installing a broken ~/.gtkrc ("Apply fonts and
+colors to non-KDE apps" in KControl)
+
+So long.
+Ulrich 
+
+
+
+[Dillo-dev]word wrapping / page width
+
+From: Ulrich Schwarz <uschwarz@gm...> - 2001-08-01 15:40
+
+Hi,
+
+since a month or so, the cvs version (including the latest 0.6 release) of
+dillo doesn't wrap the text on http://futurezone.orf.at but instead
+extends the page width to the longest text paragraph of that page so
+that no word wrapping is done and each text paragraph is displayed in
+a single (extremely long) text line.
+
+Is this due to buggy html code on that page or due to a suboptimal
+page width calculation of dillo?
+
+
+So long.
+Ulrich 
+
+
+
+Re: [Dillo-dev]0.6.0 release
+
+From: xavier ordoquy <xordoquy@au...> - 2001-08-01 10:16
+
+On 01 Aug 2001 04:14:08 -0300, Livio Baldini Soares wrote:
+> Wow! Great stuff! This thing just gets better and better. I
+> specially like the new tables... I've rolled around the Internet and
+> found that the tables are working alright. There are still some
+> glitches here and there (see the background in happypenguin.org, and
+> the missing gray border that should surround the main page in
+> http://www.so....net), but there are very usable!
+> 
+> Any chance of getting frames done too? :)
+>
+I had here my greetings to the dillo team.
+This just rocks and shows that it is possible to have a nice
+browser times lighter than what the others provides.
+Good luck and keep on going with the same quality.
+Dillo will just be THE browser to use around :)
+
+--
+Xavier Ordoquy, Aurora-linux
+If NT is the answer, you didn't understand the question.
+Complexity has nothing to do with intelligence. Simplicity does.
+(Larry Bossidy, CEO, Allied Signal) 
+
+
+
+[Dillo-dev][PATCH] Recording current scrolling position
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-01 08:35
+
+Hi guys!
+
+Browsing around with Dillo, something started to irritate me.. the
+fact that the `Back` and `Forward` buttons always place you at the
+_top_ of the page, instead of the location you scrolled to when last
+visiting that URL.
+
+And since Jorge and I had planned the scrolling_position in the
+DilloUrl exactly for this, I thought I give it a try...
+
+The patch is at:
+http://www.linux.ime.usp.br/~livio/dillo/save_scrolling_position.diff
+
+It basically does 3 things:
+
+[1] Add a a_Dw_gtk_scrolled_window_get_scrolling_position() method in
+the dw_scrolled_window.[ch] module. I thought this was better than
+having to access the vadjustment fields for the value explicitly.
+
+[2] Saves the current scrolling position of the current viewed page
+(using the method explained above). I had to triplicate the code in
+Nav_url_open(), a_Nav_back() and a_Nav_forw(), because in the last 2
+cases it is difficult to determine which is the `old_url`, and would
+require some ugly special-case code (I might be wrong, but I couldn't
+come up with a better/cleaner solution).
+
+[3] Loads the current scrolling position of the chosen URL if
+available (this is done in web.c). Why is this checked before the
+anchor? Well because if you go to a anchored URL, but move the
+position of the page, you don't want the page to go to the anchor
+anymore, but prefer the page's last position. In the case that the
+user hasn't changed the page position (therefore matching the anchor),
+we then avoid a seek of the anchor inside the page, and avoid having
+to calculate the adjustment... it has been already calculated, and
+should be the value of url->scrolling_position.
+
+The patch is small and im my opinion improves navigation in Dillo.
+If there are no comments and/or critics, Jorge feel free to apply the
+patch!
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]0.6.0 release
+
+From: Livio Baldini Soares <livio@li...> - 2001-08-01 07:14
+
+Hi!
+
+Jorge Arellano Cid writes:
+
+(...)
+> 
+> dillo-0.6.0 has just been released!!!!
+
+Wow! Great stuff! This thing just gets better and better. I
+specially like the new tables... I've rolled around the Internet and
+found that the tables are working alright. There are still some
+glitches here and there (see the background in happypenguin.org, and
+the missing gray border that should surround the main page in
+http://www.so....net), but there are very usable!
+
+Any chance of getting frames done too? :)
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]0.6.0 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-08-01 01:07
+
+Ladies and gentleman:
+
+...
+
+The wait is over...
+
+
+dillo-0.6.0 has just been released!!!!
+
+
+
+Jorge.- 
+
diff --git a/old/oldmail/200109.txt b/old/oldmail/200109.txt
new file mode 100644
index 0000000..dcc2f9d
--- /dev/null
+++ b/old/oldmail/200109.txt
@@ -0,0 +1,2932 @@
+Re: [Dillo-dev]next encodings patch
+
+From: Grigory Bakunov <black@as...> - 2001-09-28 01:47
+
+Date |28 Sep 2001 04:28:56 +0400
+From |Michael Govorun <mike@sh...>
+
+Hello!
+
+MG> Grigory Bakunov <black@as...> writes:
+
+>> REALY i look through dw_style.c code and doesn't see nothing difficult.
+>> But you need to change ALL gdk_font_load calls to gdk_fontset_load. It's all.
+>> So sed 's/gdk_font_load/gdk_fontset_load/g' and enjoy with dillo and your lovely charsets -)
+MG> Thanks. it works.
+
+MG> But there is another one problem - POST encodings. If server sends to you
+MG> page in (for example) cp1251 it expects POST data also in
+MG> cp1251. Now Dillo sends text as is.
+
+I work on it. It's not more difficult than recoding html -)
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]next encodings patch
+
+From: Michael Govorun <mike@sh...> - 2001-09-28 00:29
+
+Grigory Bakunov <black@as...> writes:
+
+> REALY i look through dw_style.c code and doesn't see nothing difficult.
+> But you need to change ALL gdk_font_load calls to gdk_fontset_load. It's all.
+> So sed 's/gdk_font_load/gdk_fontset_load/g' and enjoy with dillo and your lovely charsets -)
+Thanks. it works.
+
+But there is another one problem - POST encodings. If server sends to you
+page in (for example) cp1251 it expects POST data also in
+cp1251. Now Dillo sends text as is.
+
+-- 
+Michael Govorun 
+
+
+
+Re: [Dillo-dev]next encodings patch
+
+From: Michael Govorun <mike@sh...> - 2001-09-27 17:21
+
+Grigory Bakunov <black@as...> writes:
+
+> MG> Hmm. Not working for me :(
+> MG> It recodes, but not properly.
+
+> What type of problems you have ?
+
+Oh. I think my problem is: 
+
+Jorge Arellano Cid <jcid@ne...> writes:
+
+>Hi there!
+
+> Sometime ago there was a thread on fonts/character enocoding
+> problems. Current CVS has gtk_set_locale and Karsten's patch for
+> font loading.
+
+>> The problem is that search sequence for fonts is arbitrary, and ISO10646
+>> fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646
+>> fonts properly, hence the resolution problems.
+
+> The fix I've applied is to hardcode the font encoding into the font
+> search string in dw_style.c.
+
+-- 
+Michael Govorun 
+
+
+
+Re: [Dillo-dev]next encodings patch
+
+From: Grigory Bakunov <black@as...> - 2001-09-27 15:46
+
+Date |27 Sep 2001 12:47:58 +0400
+From |Michael Govorun <mike@sh...>
+
+Hello!
+
+MG> Hello!
+
+MG> Grigory Bakunov <black@as...> writes:
+
+>> Hello.
+>> I'm new in this list so don't kick me strongly.
+>> I make a patch for force encodings selection.
+>> I drop it here
+
+MG> Hmm. Not working for me :(
+MG> It recodes, but not properly.
+
+MG> another thing:
+MG> What you think about configurable "Accept-Charset" http-header in
+MG> Http_query() function in IO/html.c.
+
+What type of problems you have ?
+I work on accept-charset now -)
+
+MG> -- 
+MG> Michael Govorun
+
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]Re: Dillo Basic auth patch
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-27 15:35
+
+Hi,
+
+> To avoid confusion about who said what, please stick the right name
+> to the quote. :)
+
+Sorry for that. The confusion is my fault.
+I forwarded the small diskussion between Tor-Åke Franssons and me to the list.
+To avoid his email to be shown in the archive I removed the 
+corresponding lines in the subject and the mail-bodies. 
+I only recognized later, that email addresses in the mail-bodies 
+are protected by the archive automatically.
+
+Regards,
+Johannes Hofmann. 
+
+
+
+[Dillo-dev] Re: Dillo Basic auth patch
+
+From: Sam J. <mail@sa...> - 2001-09-27 10:40
+
+On Thursday 27 September 2001 12:31, Tor-=C5ke Fransson wrote:
+> Quoting Sam J. Engstrom:
+> >On Monday 24 September 2001 19:15, Johannes Hofmann wrote:
+> >> Seriously, i intend to use dillo in my ipaq, and using handwriting
+> >> recognition with '****' feedback is kind of hard. Also, i was not su=
+re
+> >> my base64 encoding routine(!) was solid, so i wanted to [...]
+>
+> Johannes Hofmann did not write that. I did.
+>
+> To avoid confusion about who said what, please stick the right name to =
+the
+> quote. :)
+
+That's odd, the automatic quoting seemed correct because the From-header=20
+in the mail says it's from Johannes Hofmann, even though your name is in =
+the=20
+bottom of the message, but I apparently cut it out before noticing. So I=20
+guess the original mail was forwarded to the list but I don't see any men=
+tion=20
+of that.
+
+> ... or just make a workaround, trap "entry_changed" and change the entr=
+y
+> contents, but that requires storing the password in some other place th=
+an
+> in the widget.
+
+Won't the passwords need to be stored somewhere anyway, to remember passw=
+ords=20
+to several sites during a session as other browsers do? It also would be =
+nice=20
+if you could clear them without restarting the browser.
+
+--=20
+Sam J. Engstrom Tel. +358 400 462442 mail@sa...
+Managing Director Nemesol http://nemesol.fi 
+
+
+
+[Dillo-dev]Re: Dillo Basic auth patch
+
+From: <torkel@ly...> - 2001-09-27 09:31
+
+Quoting Sam J. Engstrom:
+
+>On Monday 24 September 2001 19:15, Johannes Hofmann wrote:
+>> Seriously, i intend to use dillo in my ipaq, and using handwriting
+>> recognition with '****' feedback is kind of hard. Also, i was not sure
+>> my base64 encoding routine(!) was solid, so i wanted to [...]
+
+
+Johannes Hofmann did not write that. I did.
+
+To avoid confusion about who said what, please stick the right name to the
+quote. :)
+
+> Maybe the password field could briefly show the newest letter and then
+> change it to an asterisk, like I've seen in some Nokia phones. So the
+> letter is
+> visible long enough to see what you've typed, but the whole password is
+> never shown. I use dillo on the ipaq all the time, and agree that seeing
+> what you're writing helps a lot. [...]
+
+That is a very good idea! But...
+the correct place to implement that feature is in the gtk library, make
+the 'visible' attribute an enum instead of gboolean, and have the function
+gtk_entry_draw_text() in gtkentry.c do the right thing.
+
+I.e we need to convince a lot of people this is a good idea, unless we
+want provide our own libgtk with dillo, or subclass our own gtk_entry and
+stuff that into dillo.
+
+Can't replace just the gtk_entry_draw_text() function externally either,
+it's hardwired into the gtkentry.c code in several places.
+
+... or just make a workaround, trap "entry_changed" and change the entry
+contents, but that requires storing the password in some other place than
+in the widget.
+
+Regards,
+Tor-Åke 
+
+
+
+Re: [Dillo-dev]next encodings patch
+
+From: Michael Govorun <mike@sh...> - 2001-09-27 08:48
+
+Hello!
+
+Grigory Bakunov <black@as...> writes:
+
+> Hello.
+> I'm new in this list so don't kick me strongly.
+> I make a patch for force encodings selection.
+> I drop it here
+
+Hmm. Not working for me :(
+It recodes, but not properly.
+
+another thing:
+What you think about configurable "Accept-Charset" http-header in
+Http_query() function in IO/html.c.
+
+
+-- 
+Michael Govorun 
+
+
+
+Re: [Dillo-dev]Re: Dillo Basic auth patch
+
+From: Sam J. <mail@sa...> - 2001-09-26 23:33
+
+On Monday 24 September 2001 19:15, Johannes Hofmann wrote:
+> Seriously, i intend to use dillo in my ipaq, and using handwriting
+> recognition with '****' feedback is kind of hard. Also, i was not sure my
+> base64 encoding routine(!) was solid, so i wanted to see that i really
+> gave it the right password. I trust that will be changed, should my patch
+> go into CVS.
+
+Maybe the password field could briefly show the newest letter and then change 
+it to an asterisk, like I've seen in some Nokia phones. So the letter is 
+visible long enough to see what you've typed, but the whole password is never 
+shown. I use dillo on the ipaq all the time, and agree that seeing what 
+you're writing helps a lot.
+
+Sorry, no patch for it, just the idea. I haven't even had time to test the 
+actual auth patch yet.
+
+-- 
+Sam J. Engstrom Tel. +358 400 462442 mail@sa...
+Managing Director Nemesol http://nemesol.fi 
+
+
+
+[Dillo-dev]next encodings patch
+
+From: Grigory Bakunov <black@as...> - 2001-09-26 22:27
+
+Hello.
+I'm new in this list so don't kick me strongly.
+I make a patch for force encodings selection.
+I drop it here
+
+http://lambda.asplinux.udm.net/pub/dillo/dillo.encodings.patch
+
+It's based on japanise encodings patch but can help
+all users who use nonlatin1 charsets (especialy this patch
+help for all cyrillic readers with our charsets hell).
+Patch use iconv and work with 'encodings' file that i
+drop into ~/.dillo/ (like bookmarks.html).
+File contain "Charset name" "iconv name" pairs in form
+<enc value="ASCII">AscII</enc>
+<enc value="KOI8-R">Cyrillic KOI8-R</enc>
+<enc value="CP1251">Cyrillic CP1251</enc>
+<enc value="IBM866">Cyrillic IBM866</enc>
+<enc value="UTF-8">Unicode</enc>
+etc...
+As you can see this patch help me to view unicode and other charsets page.
+
+Patch aplayed on current (Thu Sep 27) CVS.
+To check it drop 'encodings' file to your ~/.dillo/
+Name of iconv charsets you can get from
+iconv --list (for glibc iconv)
+
+
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]Fwd: dillo patch for Fugly Fonts
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-26 20:33
+
+Hi there!
+
+Sometime ago there was a thread on fonts/character enocoding
+problems. Current CVS has gtk_set_locale and Karsten's patch for
+font loading.
+
+> The problem is that search sequence for fonts is arbitrary, and ISO10646
+> fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646
+> fonts properly, hence the resolution problems.
+>
+> The fix I've applied is to hardcode the font encoding into the font
+> search string in dw_style.c.
+
+As I've explained before, dillo works in ISO8859-1, so this
+patch is OK by now (further info in [Project Notes]).
+
+To those of you that have had problems before, please test
+current CVS and report back whether it solves the problem or not.
+
+Ah, some of you may require: `LC_ALL=POSIX ./dillo`
+
+
+Good luck!
+Jorge.- 
+
+
+
+[Dillo-dev]Dillo for the blind and visually impaired.
+
+From: Simon Dobrisek <simond@lu...> - 2001-09-26 09:33
+
+Dear colleagues,
+
+I am a teaching assistant and part of my research work at our university
+is to develop a simple but usable web browser for the blind and visually
+impaired people.
+
+For some time we have been involved in a non-profit research project wher=
+e
+we developed a voice-driven text-to-speech system (HOMER II) for blind or
+visually impaired persons for reading Slovenian texts ( my country ;) ).
+
+Later on we got an idea to set a web portal entirely dedicated to such
+disabled persons in Slovenia and to develop a HOMER III system which
+includes an html parser. Additionally, we decided to enable use of mouse
+pointer when browsing through the available text at the portal (some
+useful info, daily newspapers, selected novels ... all preformated into
+simple html pages ... the portal does not exist yet :( ... but an interne=
+t
+source of nonstructed ASCII Slovenian texts does!)
+
+And then I "discovered" the dillo. We have already done some job and our
+extension of the dillo has a screen reading capabilities (with the
+Slovenian text-to-speech and a lot of beep sounds ;) ... it works only
+when pointer is in the "dw_page"). The working name of the system is
+"ihomer".
+
+I have to say that I am a rookie in GTK programming and the dillo project=
+.
+I hope I didn't pollute the code with too much unstable crap but it seems
+stable (as much as dillo is stable). Our extension of the source code wil=
+l
+be publicly available (without the Slovenian TTS but with the instruction=
+s
+how to integrate other language TTS ... actually we have version with the
+"dummy synthesis - delayed print" to the console window).
+
+And now the main point!
+
+Currently, I am stucked with a problem of how to hook on the low level
+signals of the GTK menus and buttons in the dillo. I would need to
+"intercept" the position of the pointer in the menu (better said, I need
+the menu or button label text beneath the pointer to send it to the TTS).
+
+TTS works in a separated thread with a time out function. This means that
+you can't stuff the TTS with some fast browsing. You need to stay in a
+position for some time to hear anything from the TTS. This feature of our
+TTS seem to be stable when browsing through the dw_page. (I hooked TTS on
+the motion_notify_event of the dw_page)
+
+Do you have any hint, instructions?
+
+Thanx!
+
+as.dr. Simon Dobri=B9ek
+
+simond@lu... 
+
+
+
+[Dillo-dev]Updated auth patch available
+
+From: <torkel@ly...> - 2001-09-25 23:16
+
+An updated basic auth patch is available at:
+
+http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_auth0925.diff.gz
+
+I have merged in some changes from Pekka Lampila (handle
+http://user:pass@fo.../) and Johannes Hofmann (don't show password on
+screen).
+
+I also added some bits of my own and made the patch clean against todays
+CVS.
+
+Enjoy.
+
+//Tor-Åke 
+
+
+
+[Dillo-dev]International language support for dillo
+
+From: Hector Garcia Alvarez <hector@de...> - 2001-09-25 22:40
+
+Hi all
+
+I would like to add international language support into dillo.
+Of course those people using it on Palm like machine could compile it
+without this support to keep it smaller.
+Is anybody working on this already?
+How do I send the patch and where?
+
+Regards,
+
+H=E9ctor 
+
+
+
+[Dillo-dev]Re: Bookmark System
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-24 16:18
+
+Alex,
+
+> Hey, i'd like to start working on the bookmark system, i already have
+> added seperators and an "Add Seperator" option to the menubar. Is anyone
+> else working on the bookmark system?
+
+Yes, I read your posts. This issue was discussed on the
+list a long time ago; current bookmarks code far from good, we
+know, and the main reason for not being working it out, is the
+idea of making our bookmarks implementation based on the plugin
+interface.
+
+Since the plugin implementation had been procrastinated to
+favor higher priorities, so had the bookmarks code. As we're
+getting closer to resume our work with the plugin interface,
+you'd better wait until it's done and gauge its potential.
+
+For instance, now that tables are working good, a table based
+display with two main columns, one for bookmark category (left)
+and the other for their listings, seems quite adequate. Let's add
+a top panel for delete, move, create category, export as HTML ...
+functions, plus the necessary #anchor bindings from the left
+panel to the main one, and we have an interesting proposal...
+
+And as plugins are external programs, any not so common
+addition a user may want can be added to a specific custom plugin
+without requiring it to make into dillo's source base.
+
+The whole concept of dillo (simple) plugins is very powerful,
+but yet to be tested. Eric and I had put a lot of work into it,
+so I keep looking forward for the day it begins to work as
+planned. A simpler approach has been tested to work OK (old
+plugin scheme), and it supported FTP quite nicely.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Re: Dillo Basic auth patch
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-24 16:15
+
+On Sat, 22 Sep 2001, Johannes Hofmann wrote:
+
+> Hm, so the right way to go would be protocol+hostname+port+realm...
+
+Ideally, yes. But you have no knowledge of what realm it is until you
+have received the reply header. Using the directory name you can however,
+make smart assumptions on what realm it is in, for example:
+
+if you enter a site at http://foo.bar.com/beer and it is in a certain
+realm, http://foo.bar.com/beer/heineken is probably in the same realm,
+while http://foo.bar.com/wine does not have to be.
+
+However, if you enter the site at http://foo.bar.com/ and authenticate
+there, beer and wine are assumed to be in the same realm with my method.
+
+I.e I use the "surfing pattern", to make guesses on what realm it is.
+I know it is not ideal. Should beer and wine be in the same realm, and you
+enter at beer, and then go to wine, you would have to enter a password
+even though you should not have to.
+
+> So I think best way to go would be your scheme, but in case of
+> authentication failure on a host we already have auth-info for, we
+> could look in the realm-list, if we already have auth-info for that
+> realm. If so, we could send it without bothering the user.
+
+Yes! That is a good idea. I'll think about how to implement that
+
+> There's just one thing I'm thinking about.
+> Once we have a ssl-connection with certificate-based server
+> authentication, we certainly don't want to send auth-info based on
+> protocol+hostname+port only, without checking for dns-spoofing.
+> But I do not know enough about how ssl-connections are handled. Are
+> they kept alive, so that authentication is needed only once?
+
+No, they are not necessarily kept alive. At least one site i know of (my
+bank) asks for authentication certificate over and over again while
+loading a page, which indicates it is not using keep-alive.
+I have not really looked into implementing certificate authentication, but
+i think it should be handled like this:
+
+1. client makes request
+2. server asks for client authentication certificate, sends server
+certificate
+3. client looks at server certificate and compare it with its stored
+certificate for this server
+4a. if 3. results in a match, client sends client certificate
+4b. if the certificates does not match, warn the user about spoofing
+4c. if we have no certificate for this server, notify the user, store
+the server certificate, and send client certificate.
+
+I believe this is how Netscape does it.
+
+I do not know how certificates are passed back and forth, and all of this
+seems too complicated and tideous for me to find time to implement
+it anytime soon, but please go ahead. :)
+
+Regards,
+Tor-Åke Fransson
+
+
+PS If you think we should let the other dillo people in on the discussion,
+feel free to forward this mail and mails preceeding it to
+dillo-dev@li... DS 
+
+
+
+[Dillo-dev]Re: Dillo Basic auth patch
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-24 16:14
+
+On Fri, Sep 21, 2001 at 11:48:14PM +0200, Tor-Åke Fransson wrote:
+> 
+> On Fri, 21 Sep 2001, Johannes Hofmann wrote:
+> 
+> > I just have a small addition to the auth patch, to hide passwords from
+> > too curious people
+> 
+> I was wondering how long it would take for someone to object to that ;)
+> 
+> Seriously, i intend to use dillo in my ipaq, and using handwriting
+> recognition with '****' feedback is kind of hard. Also, i was not sure my
+> base64 encoding routine(!) was solid, so i wanted to see that i really
+> gave it the right password. I trust that will be changed, should my patch
+> go into CVS.
+
+
+Yeah, I already thought you left it in cleartext for debugging...
+
+> 
+> > and a small modification to the auth data lookup.
+> > It looks up auth data based on the hostname, protocol, and port
+> > instead of the url prefix that was used before.
+> 
+> Since different subdirectories on same host can be different realms, you
+> need the path also, ergo:
+> 
+> protocol+hostname+port+path
+> 
+> http://hostname:port/path, see? ;)
+> 
+> > I think one also has to look it up based on the auth-realm, but I did
+> > not see how to implement that at the moment.
+> 
+> You could do it by realm, but the server will only tell you the realm
+> after you have done a request, which in effect doubles the number of
+> requests! I also had that approach at first, but i abandoned it, since
+> dillo does not handle keep-alive connections.
+> 
+> Even though it is not the 'right' thing to do, i think we can safely
+> assume all files in a directory are protected in the same realm. At least
+> it it very common to configure web servers that way.
+> 
+> Using _just_ the realm is not good either, because a realm is
+> not guaranteed to be unique. I just have to name my realm the same as
+> yours, and trick your users to come and surf on my site
+> to steal passwords. You would need protocol+host+port+path+realm. Easy way
+> out is to skip the realm alltogether, hard way is to implement keep-alive,
+> to not double the number of connections.
+> 
+> IMHO, leaking a password to the wrong realm is not that dangerous, unless
+> the server administrator lets users themselves change logging
+> configuration to steal the 'Authorization:' header line. Leaking it to the
+> wrong server is _much_ worse.
+> 
+> In conclusion, it is all a tradoff between user convenience, speed and
+> password security. I aimed for "very convenient", "fast" and "pretty
+> safe".
+>
+
+Hm, so the right way to go would be protocol+hostname+port+realm...
+I thought leaking the password to the right server, but a wrong realm
+would be acceptable. Therefore, I you choose auth-info based on
+protocol+hostname+port and try if it works out. If the realm is wrong,
+I have to enter a new password. I see that this allows only one realm
+per server at a time :-(
+So I think best way to go would be your scheme, but in case of
+authentication failure on a host we already have auth-info for, we
+could look in the realm-list, if we already have auth-info for that
+realm. If so, we could send it without bothering the user.
+
+There's just one thing I'm thinking about.
+Once we have a ssl-connection with certificate-based server
+authentication, we certainly don't want to send auth-info based on
+protocol+hostname+port only, without checking for dns-spoofing.
+But I do not know enough about how ssl-connections are handled. Are
+they kept alive, so that authentication is needed only once?
+
+Regards,
+Johannes Hofmann 
+
+
+
+[Dillo-dev]Re: Dillo Basic auth patch
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-24 16:14
+
+On Fri, 21 Sep 2001, Johannes Hofmann wrote:
+
+> I just have a small addition to the auth patch, to hide passwords from
+> too curious people
+
+I was wondering how long it would take for someone to object to that ;)
+
+Seriously, i intend to use dillo in my ipaq, and using handwriting
+recognition with '****' feedback is kind of hard. Also, i was not sure my
+base64 encoding routine(!) was solid, so i wanted to see that i really
+gave it the right password. I trust that will be changed, should my patch
+go into CVS.
+
+> and a small modification to the auth data lookup.
+> It looks up auth data based on the hostname, protocol, and port
+> instead of the url prefix that was used before.
+
+Since different subdirectories on same host can be different realms, you
+need the path also, ergo:
+
+protocol+hostname+port+path
+
+http://hostname:port/path, see? ;)
+
+> I think one also has to look it up based on the auth-realm, but I did
+> not see how to implement that at the moment.
+
+You could do it by realm, but the server will only tell you the realm
+after you have done a request, which in effect doubles the number of
+requests! I also had that approach at first, but i abandoned it, since
+dillo does not handle keep-alive connections.
+
+Even though it is not the 'right' thing to do, i think we can safely
+assume all files in a directory are protected in the same realm. At least
+it it very common to configure web servers that way.
+
+Using _just_ the realm is not good either, because a realm is
+not guaranteed to be unique. I just have to name my realm the same as
+yours, and trick your users to come and surf on my site
+to steal passwords. You would need protocol+host+port+path+realm. Easy way
+out is to skip the realm alltogether, hard way is to implement keep-alive,
+to not double the number of connections.
+
+IMHO, leaking a password to the wrong realm is not that dangerous, unless
+the server administrator lets users themselves change logging
+configuration to steal the 'Authorization:' header line. Leaking it to the
+wrong server is _much_ worse.
+
+In conclusion, it is all a tradoff between user convenience, speed and
+password security. I aimed for "very convenient", "fast" and "pretty
+safe".
+
+
+Best regards,
+Tor-Åke
+
+
+
+> *** interface.c.orig Fri Sep 21 18:10:18 2001
+> --- interface.c Fri Sep 21 18:08:34 2001
+> ***************
+> *** 1047,1052 ****
+> --- 1047,1053 ----
+> gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_uentry, FALSE,
+> FALSE, 0);
+> gtk_widget_show(*passwd_dialog_uentry);
+> *passwd_dialog_pentry=gtk_entry_new();
+> + gtk_entry_set_visibility((GtkEntry*) *passwd_dialog_pentry, FALSE);
+> gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_pentry, FALSE,
+> FALSE, 0);
+> gtk_widget_show(*passwd_dialog_pentry);
+> /* gtk_widget_show(frame); */
+>
+>
+>
+>
+> *** auth.c.orig Fri Sep 21 18:14:58 2001
+> --- auth.c Fri Sep 21 18:33:34 2001
+> ***************
+> *** 43,73 ****
+>
+> GString *Auth_byurl(DilloUrl *n)
+> {
+> ! gchar *offset;
+> ! int i,longest=-1,len=0,longlen=0;
+> ! gchar *ptr;
+>
+> if (n == NULL)
+> return NULL;
+> !
+> for (i=0;i<num_realms;i++)
+> {
+> ! /* is my compiler broken, why do i need this? */
+> ! ptr=((DilloUrl *) realms[i].base_url)->url_string->str;
+> ! if (NULL == (offset = strrchr(ptr,'/')))
+> ! offset=ptr+strlen(ptr);
+> ! if (strncmp(n->url_string->str,ptr,(char *) offset - (char *) ptr) == 0)
+> {
+> ! len=(gchar *) offset - (gchar *) ptr;
+> ! if (longlen <= len)
+> ! {
+> ! longlen=len;
+> ! longest=i;
+> ! }
+> }
+> }
+> - if (-1 != longest)
+> - return realms[longest].auth;
+>
+> return NULL;
+> }
+> --- 43,62 ----
+>
+> GString *Auth_byurl(DilloUrl *n)
+> {
+> ! int i;
+>
+> if (n == NULL)
+> return NULL;
+> !
+> for (i=0;i<num_realms;i++)
+> {
+> ! if (strcmp(n->hostname, realms[i].base_url->hostname) == 0 &&
+> ! strcmp(n->protocol, realms[i].base_url->protocol) == 0 &&
+> ! n->port == realms[i].base_url->port)
+> {
+> ! return realms[i].auth;
+> }
+> }
+>
+> return NULL;
+> }
+>
+>
+> 
+
+
+
+[Dillo-dev][Johannes.Hofmann@gmx.de: Dillo Basic auth patch]
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-24 16:13
+
+Hi,
+
+first of all I want to thank you for your cool dillo patches (auth and
+https).
+I just have a small addition to the auth patch, to hide passwords from
+too curious people and a small modification to the auth data lookup.
+It looks up auth data based on the hostname, protocol, and port 
+instead of the url prefix that was used before.
+I think one also has to look it up based on the auth-realm, but I did
+not see how to implement that at the moment.
+
+cheers,
+Johannes Hofmann
+
+
+
+*** interface.c.orig Fri Sep 21 18:10:18 2001
+--- interface.c Fri Sep 21 18:08:34 2001
+***************
+*** 1047,1052 ****
+--- 1047,1053 ----
+gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_uentry, FALSE,
+FALSE, 0);
+gtk_widget_show(*passwd_dialog_uentry);
+*passwd_dialog_pentry=gtk_entry_new();
++ gtk_entry_set_visibility((GtkEntry*) *passwd_dialog_pentry, FALSE);
+gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_pentry, FALSE,
+FALSE, 0);
+gtk_widget_show(*passwd_dialog_pentry);
+/* gtk_widget_show(frame); */
+
+
+
+
+*** auth.c.orig Fri Sep 21 18:14:58 2001
+--- auth.c Fri Sep 21 18:33:34 2001
+***************
+*** 43,73 ****
+
+GString *Auth_byurl(DilloUrl *n)
+{
+! gchar *offset;
+! int i,longest=-1,len=0,longlen=0;
+! gchar *ptr;
+
+if (n == NULL)
+return NULL;
+! 
+for (i=0;i<num_realms;i++)
+{
+! /* is my compiler broken, why do i need this? */
+! ptr=((DilloUrl *) realms[i].base_url)->url_string->str;
+! if (NULL == (offset = strrchr(ptr,'/')))
+! offset=ptr+strlen(ptr);
+! if (strncmp(n->url_string->str,ptr,(char *) offset - (char *) ptr) == 0)
+{
+! len=(gchar *) offset - (gchar *) ptr;
+! if (longlen <= len)
+! {
+! longlen=len;
+! longest=i;
+! }
+}
+}
+- if (-1 != longest)
+- return realms[longest].auth;
+
+return NULL;
+}
+--- 43,62 ----
+
+GString *Auth_byurl(DilloUrl *n)
+{
+! int i;
+
+if (n == NULL)
+return NULL;
+! 
+for (i=0;i<num_realms;i++)
+{
+! if (strcmp(n->hostname, realms[i].base_url->hostname) == 0 &&
+! strcmp(n->protocol, realms[i].base_url->protocol) == 0 &&
+! n->port == realms[i].base_url->port)
+{
+! return realms[i].auth;
+}
+}
+
+return NULL;
+} 
+
+
+
+Re: [Dillo-dev]installation
+
+From: Matthieu Camus <matthieu.camus@po...> - 2001-09-24 09:24
+
+Hi,
+
+Have you installed that package ? libjpeg62-devel-6b-19mdk
+
+Regards,
+Matthieu
+
+En r=E9ponse =E0 darren <backdoc@ne...>:
+
+> I found the link to dillo on the xfce website. Since I have been so
+> happy=20
+> with xfce, I figure anything they recommend must be worth a look. But,
+> I'm=20
+> having trouble installing it. =20
+>=20
+> As a side note, I joined this list in an effort to resolve my
+> installation=20
+> problem. But, I didn't realize this was the development list until
+> after I=20
+> had subscribed. The way to subscribe to the user's list and the way to
+>=20
+> unsubscribe to the dev list was not obvious (I didn't see it, anyway).
+>=20
+> So, pardon an installation question. =20
+>=20
+> I've tried compiling with the following options:
+>=20
+> ./configure --with-jpeg-lib=3D/usr/lib --with-jpeg-
+> inc=3D/usr/lib/qt2/include
+>=20
+>=20
+> But, I'm still getting the following errors when I compile:
+>=20
+> checking for jpeg_destroy_decompress in -ljpeg... no
+> configure: WARNING: *** JPEG support will not be included ***
+> no
+> configure: WARNING: *** JPEG support will not be included ***
+>=20
+>=20
+> Thanks for any help you can give,
+> Darren
+>=20
+> BTW, this is on Mandrake 8.0.
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>=20
+Matthieu
+matthieu.camus@un... 
+
+
+
+[Dillo-dev]installation
+
+From: darren <backdoc@ne...> - 2001-09-23 20:29
+
+I found the link to dillo on the xfce website. Since I have been so happy 
+with xfce, I figure anything they recommend must be worth a look. But, I'm 
+having trouble installing it. 
+
+As a side note, I joined this list in an effort to resolve my installation 
+problem. But, I didn't realize this was the development list until after I 
+had subscribed. The way to subscribe to the user's list and the way to 
+unsubscribe to the dev list was not obvious (I didn't see it, anyway).
+
+So, pardon an installation question. 
+
+I've tried compiling with the following options:
+
+./configure --with-jpeg-lib=/usr/lib --with-jpeg- inc=/usr/lib/qt2/include
+
+
+But, I'm still getting the following errors when I compile:
+
+checking for jpeg_destroy_decompress in -ljpeg... no
+configure: WARNING: *** JPEG support will not be included ***
+no
+configure: WARNING: *** JPEG support will not be included ***
+
+
+Thanks for any help you can give,
+Darren
+
+BTW, this is on Mandrake 8.0. 
+
+
+
+Re: [Dillo-dev]Pending tasks
+
+From: Viksell <jorgen.viksell@te...> - 2001-09-23 10:38
+
+Jorge Arellano Cid wrote:
+> -----------------
+> Attribute parsing
+> -----------------
+>=20
+> As I posted before (Subject: "Attribute parsing"), this is a
+> high priority task that's pending. I received emails from Bruno
+> and J=F6rgen stating that they were willing to work on it, but not
+> knowing exactly were to start. My current schedule contemplates
+> working on this, the networking part of plugins, https and auth.
+> So If I start with the latter I'll have little time to help you
+> both, so J=F6rgen: if you feel confident enough to work on
+> attribute parsing, starting from my previous post, please let me
+> know so I can focus on networking; if not, let me know also so I
+> can start here.
+
+Sure, I'll do it.
+As I understand, it is just Html_get_attr that needs to be changed to
+support dynamic lengths and then move parsing of entities in there.
+Or are there any other "deeper" issues?
+
+> ------------------------
+> https, cookies and auth.
+> ------------------------
+>=20
+> There were three issues to this:
+>=20
+> 1) Stability (almost achieved)
+> 2) The specific implementation layer and network support
+> for them.
+> 3) https pages usually require working cookies.
+>=20
+> As Tor-Ake and J=F6rgen have advanced with 2 and 3, I'll need to
+> know what this schemes require from the networking layers (for
+> instance, cookies require sending back stored cookies).
+>=20
+> If you guys work together, and specify what you require from
+> the networking layers, and keep on improving the specific
+> implementation, it will come a time when I'll be free to
+> implement the underlaying support and hopefully then, it'll
+> become a matter of merging.
+
+I'll make a list of the required changes for cookies and send it to=20
+the list some time. Kind of basic stuff except for some oddities with
+different cookie versions...
+
+> Note that cookies should provide dillorc options for:
+>=20
+> - rejecting all cookies
+> - accepting only if the RootUrl and server match.
+> - accepting all
+
+Implemented with a separate file where you can set actions for a
+specific domain or for all domains.
+
+J=F6rgen 
+
+
+
+[Dillo-dev]Pending tasks
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-23 09:38
+
+Hi everyone!
+
+Now that 0.6.1 has achieved a significant stability gain, we
+can focus on several other tasks that were waiting in the
+priorities queue.
+
+Note that the stabilization is not completed, but advanced
+enough to let other tasks to be started.
+
+
+-----------------
+Attribute parsing
+-----------------
+
+As I posted before (Subject: "Attribute parsing"), this is a
+high priority task that's pending. I received emails from Bruno
+and J=F6rgen stating that they were willing to work on it, but not
+knowing exactly were to start. My current schedule contemplates
+working on this, the networking part of plugins, https and auth.
+So If I start with the latter I'll have little time to help you
+both, so J=F6rgen: if you feel confident enough to work on
+attribute parsing, starting from my previous post, please let me
+know so I can focus on networking; if not, let me know also so I
+can start here.
+
+Note that there're other interesting tasks in this post that if
+you feel more comfortable with, can be as helpful to work on.
+
+
+--------------------------------------
+Bug 216 (answers without content/type)
+--------------------------------------
+
+Yes, I also had this problem with ebay (made a little hack, and
+won my bid!). Since that moment the idea of handling this case
+the rigth way is present. Note that the problem arises from a
+http answer lacking the content/type info; the RFC says it SHOULD
+be present, so it's not an error :(
+
+The solution is simple, do you remember magic numbers and the
+'file' command? Well, that's the way to go. I don't mean calling
+'file' and parsing its output, but to examine the magic numbers
+file (and its format) for the small set of MIME types dillo
+supports:
+
+image/{png, jpeg, gif}
+text/{plain, html}
+
+and afterward, to create a custom function that returns the
+MIME type of a file, by examining a few bytes from the start of
+it. Ex:
+
+gchar *a_Mime_get_content_type(const gchar *FewBytesString);
+
+After having this function, it's just a matter of binding it to
+header parsing.
+
+
+--------------------
+Dicache memory usage
+--------------------
+
+The cache system (cache and dicache) uses a lot of memory for
+images, because it stores the original format and the RGB
+decompressed one.
+
+Flushing the dicache is not easy because image widgets use the
+dicache buffers directly. The right solution is to implement
+a memory usage threshold on the dicache, but that would require a
+significative effort...
+
+As a workaround, there's a posibility of binding the
+'about:splash' method (because it doesn't use images) to a
+dicache flushing function. i.e. whenever the splash screen is
+requested, the handling method asserts there's only a single
+browser window open and flushes the dicache (after displaying the
+splash).
+
+This is very far from a clean solution, but may serve those of
+you that feel in a dire need of it.
+
+
+-------
+Plugins
+-------
+
+One of the most procrastinated topics in dillo :(
+After attribute parsing is done, I'll be choosing between
+plugins and the networking part of https, cookies and auth.
+
+
+------------------------
+https, cookies and auth.
+------------------------
+
+There were three issues to this:
+
+1) Stability (almost achieved)
+2) The specific implementation layer and network support
+for them.
+3) https pages usually require working cookies.
+
+As Tor-Ake and J=F6rgen have advanced with 2 and 3, I'll need to
+know what this schemes require from the networking layers (for
+instance, cookies require sending back stored cookies).
+
+If you guys work together, and specify what you require from
+the networking layers, and keep on improving the specific
+implementation, it will come a time when I'll be free to
+implement the underlaying support and hopefully then, it'll
+become a matter of merging.
+
+Note that cookies should provide dillorc options for:
+
+- rejecting all cookies
+- accepting only if the RootUrl and server match.
+- accepting all
+- [confirm] -- this must be very well thought, for not
+annoying the user.
+
+-----------------
+Frames workaround
+-----------------
+
+Before the final implementation of frames, a workaround (as
+dicussed on the list) would be a nice addition. I'll be waiting
+until Livio finishes testing and polishing the current prototype.
+
+
+-------
+History
+-------
+
+We are working with Eric on it. Expect a full creative solution
+to be there sometime :) I'm crossing fingers.
+
+
+-----------------------
+BUG 205 (visited links)
+-----------------------
+
+This is not a bug, but a feature!
+In dillo, visited link sematic is "cached".
+(it has proven useful)
+
+Note: 205 will be removed soon from BugTrack.
+
+
+----------------
+nowrap and width
+----------------
+
+The workaround for this construct was removed in concordance
+with dillo's html parsing policy ([Project Notes]).
+
+Also note that the HTML 4.01 spec says WIDTH is a "recommended"
+cell width (hints in dillo's implementation), and NOWRAP
+"disables automatic text wrapping for this cell", and it adds
+"NOTE: if used carelessly, this attribute may result in
+excessively wide cells".
+
+So current implementation is compliant with both.
+
+
+
+Regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]word wrapping / page width
+
+From: Ulrich Schwarz <uschwarz@gm...> - 2001-09-21 10:32
+
+On Fri, Aug 31, 2001 at 03:39:41PM +0200, Sebastian Geerken wrote:
+
+>>> I thought of a workaround, which ignores the NOWRAP in this
+>>> case, in Html_tag_open_table_cell:
+
+> done
+
+Hm, the recent CVS version of dillo reverts to the old state before
+your patch, where NOWRAP is applied in conjunction with an existing
+WIDTH attribute.
+
+So long.
+Ulrich 
+
+
+
+[Dillo-dev]Patch to make capitalisation consistent in dillo interface
+
+From: Adam Sampson <azz@gn...> - 2001-09-21 02:32
+
+In dillo-0.6.1, some parts of the interface capitalise all words ("Find Text"),
+some capitalise some ("Open Link in New Window"), and some only capitalise the
+first ("Find text in page"). Also, the context menus have extra header items,
+which look odd and don't add significantly to usability (at least, when I'm
+using the menus I care about what I can do, not why I can do it!). This patch
+makes all the phrases I could find only capitalise the first word (because
+that's what Links does, and I happen to like it), and removes the menu headers;
+it also removes the ellipsis from the end of the Save file dialogs, since the
+Open ones don't have them, and it's consistent with what other GTK apps do).
+Feedback appreciated. :)
+
+--- dillo-0.6.1/src/commands.c Sun Aug 12 03:12:49 2001
++++ dillo-0.6.1-azz/src/commands.c Fri Sep 21 03:18:15 2001
+@@ -115,7 +115,7 @@
+GTK_SIGNAL_FUNC(gtk_widget_destroyed),
+&bw->viewsource_window);
+
+- gtk_window_set_title (GTK_WINDOW (window), "View Source");
++ gtk_window_set_title (GTK_WINDOW (window), "View source");
+gtk_container_border_width (GTK_CONTAINER (window), 0);
+
+box1 = gtk_vbox_new (FALSE, 0);
+@@ -139,7 +139,7 @@
+gtk_text_insert (GTK_TEXT (text), NULL, NULL, NULL, buf, size);
+gtk_text_thaw (GTK_TEXT (text));
+
+- button = gtk_button_new_with_label ("close");
++ button = gtk_button_new_with_label ("Close");
+gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
+GTK_SIGNAL_FUNC(gtk_widget_destroy),
+GTK_OBJECT (window));
+--- dillo-0.6.1/src/interface.c Fri Sep 21 02:31:12 2001
++++ dillo-0.6.1-azz/src/interface.c Fri Sep 21 03:20:07 2001
+@@ -884,7 +884,7 @@
+if (!bw->openfile_dialog_window) {
+Interface_make_choose_file_dialog(
+&(bw->openfile_dialog_window),
+- "openfile_dialog", "Dillo", "Dillo: Open File",
++ "openfile_dialog", "Dillo", "Dillo: Open file",
+(GtkSignalFunc) Interface_openfile_ok_callback, (void *)bw);
+}
+
+@@ -1144,7 +1144,7 @@
+fflush(Web->stream);
+fstat(fileno(Web->stream), &st);
+fclose(Web->stream);
+- a_Interface_msg(Web->bw, "File saved (%d Bytes)", st.st_size);
++ a_Interface_msg(Web->bw, "File saved (%d bytes)", st.st_size);
+} else {
+if ( (Bytes = Client->BufSize - Web->SavedBytes) > 0 ) {
+Bytes = fwrite(Client->Buf + Web->SavedBytes, 1, Bytes, Web->stream);
+@@ -1231,7 +1231,7 @@
+if (!bw->save_dialog_window) {
+Interface_make_choose_file_dialog(
+&bw->save_dialog_window,
+- "save_dialog", "Dillo", "Dillo: Save URL as File...",
++ "save_dialog", "Dillo", "Dillo: Save URL as file",
+(GtkSignalFunc) Interface_file_save_url, (void *)bw );
+}
+url = a_Url_new(gtk_entry_get_text(GTK_ENTRY(bw->location)), NULL, 0, 0);
+@@ -1258,7 +1258,7 @@
+Interface_make_choose_file_dialog(
+&bw->save_link_dialog_window,
+"save_link_dialog", "Dillo", 
+- "Dillo: Save link as File...",
++ "Dillo: Save link as file",
+(GtkSignalFunc) Interface_file_save_link,
+(void *)bw);
+}
+--- dillo-0.6.1/src/menu.c Fri Jul 13 18:58:03 2001
++++ dillo-0.6.1-azz/src/menu.c Fri Sep 21 03:11:35 2001
+@@ -124,15 +124,15 @@
+
+/* FILE MENU */
+file_menu = Menu_new(menubar, tiny ? "_F" : "_File", FALSE, bw);
+- Menu_add(file_menu, "_New Browser", "<ctrl>N", bw,
++ Menu_add(file_menu, "_New browser", "<ctrl>N", bw,
+a_Commands_new_callback, bw);
+- Menu_add(file_menu, "_Open File...", "<ctrl>O", bw,
++ Menu_add(file_menu, "_Open file...", "<ctrl>O", bw,
+a_Commands_openfile_callback, bw);
+Menu_add(file_menu, "Open _URL...", "<ctrl>L", bw,
+a_Commands_openurl_callback, bw);
+Menu_add(file_menu, "_Preferences", "<ctrl>E", bw,
+a_Commands_prefs_callback, bw);
+- Menu_add(file_menu, "Close _Window", "<ctrl>W", bw,
++ Menu_add(file_menu, "Close _window", "<ctrl>W", bw,
+a_Commands_close_callback, bw);
+Menu_sep(file_menu);
+Menu_add(file_menu, "E_xit Dillo", "<ctrl>X", bw,
+@@ -141,7 +141,7 @@
+/* BOOKMARKS MENU */
+bookmarks_menu = Menu_new(menubar, tiny ? "_B" : "B_ookmarks", FALSE, bw);
+bw->bookmarks_menu = bookmarks_menu;
+- Menu_add(bookmarks_menu, "_View Bookmarks", NULL, bw,
++ Menu_add(bookmarks_menu, "_View bookmarks", NULL, bw,
+a_Commands_viewbm_callback, bw);
+Menu_sep(bookmarks_menu);
+a_Bookmarks_fill_new_menu(bw);
+@@ -164,21 +164,18 @@
+GtkWidget *menu;
+
+menu = gtk_menu_new();
+- Menu_sep(menu);
+- Menu_add(menu, " PAGE OPTIONS", NULL, bw, NULL, NULL);
+- Menu_sep(menu);
+- Menu_add(menu, "View page Source", NULL, bw,
++ Menu_add(menu, "View page source", NULL, bw,
+a_Commands_viewsource_callback, bw);
+
+Menu_add(menu, "Bookmark this page", NULL, bw,
+a_Commands_addbm_callback, bw);
+Menu_sep(menu);
+- Menu_add(menu, "_Find Text", "<ctrl>F", bw,
++ Menu_add(menu, "_Find text", "<ctrl>F", bw,
+a_Commands_findtext_callback, bw);
+bw->pagemarks_menuitem = Menu_add(menu, "Jump to...", NULL, bw, NULL, bw);
+
+Menu_sep(menu);
+- Menu_add(menu, "Save page As...", NULL, bw,
++ Menu_add(menu, "Save page as...", NULL, bw,
+a_Commands_save_callback, bw);
+
+return menu;
+@@ -193,15 +190,12 @@
+GtkWidget *copy;
+
+menu = gtk_menu_new();
+- Menu_sep(menu);
+- Menu_add(menu, " LINK OPTIONS", NULL, bw, NULL, NULL);
+- Menu_sep(menu);
+- Menu_add(menu, "Open Link in New Window", NULL, bw,
++ Menu_add(menu, "Open link in new window", NULL, bw,
+a_Commands_open_link_nw_callback, bw);
+- Menu_add(menu, "Add Bookmark for Link", NULL, bw,
++ Menu_add(menu, "Add bookmark for link", NULL, bw,
+a_Commands_addbm_callback, bw);
+
+- copy = Menu_add(menu, "Copy Link location", NULL, bw,
++ copy = Menu_add(menu, "Copy link location", NULL, bw,
+a_Commands_set_selection_callback, bw);
+gtk_signal_connect(GTK_OBJECT(copy), "selection_clear_event",
+GTK_SIGNAL_FUNC(a_Commands_clear_selection_callback), NULL);
+@@ -211,7 +205,7 @@
+GTK_SIGNAL_FUNC(a_Commands_give_selection_callback), NULL);
+
+Menu_sep(menu);
+- Menu_add(menu, "Save Link As...", NULL, bw,
++ Menu_add(menu, "Save link as...", NULL, bw,
+a_Commands_save_link_callback, bw);
+return menu;
+}
+
+-- 
+Adam Sampson <azz@gn...> <URL:http://azz.us-lot.org/> 
+
+
+
+[Dillo-dev]Patch for better display of XHTML documents
+
+From: Adam Sampson <azz@gn...> - 2001-09-21 02:09
+
+Hiya.
+
+Since XHTML documents are required to have an XML definition at the top and
+dillo's HTML parser considers <?...?> to just be text, the XML definitions are
+visible in dillo's HTML view. This patch makes dillo treat <?...?> as a tag;
+since it doesn't know what to do with <?xml, it just ignores it, and the
+document displays correctly.
+
+Thanks very much to all the people who've worked on Dillo; it's a really nice
+piece of software, and is now getting used as my default browser.
+
+--- dillo-0.6.1/src/html.c Fri Sep 14 01:00:39 2001
++++ dillo-0.6.1-azz/src/html.c Fri Sep 21 02:59:48 2001
+@@ -3504,7 +3504,7 @@
+token_start = buf_index;
+
+} else if (buf[buf_index] == '<' && (ch = buf[buf_index + 1]) &&
+- (isalpha(ch) || strchr("!/", ch)) ) {
++ (isalpha(ch) || strchr("!/?", ch)) ) {
+/* Tag */
+if (buf_index + 3 < bufsize && !strncmp(buf + buf_index, "<!--", 4)) {
+/* Comment: search for close of comment, skipping over
+
+-- 
+Adam Sampson <azz@gn...> <URL:http://azz.us-lot.org/> 
+
+
+
+[Dillo-dev]usability patch
+
+From: Martin Samuelsson <cosis@ly...> - 2001-09-20 22:33
+
+Attachments: dillo-userfriendly.patch      
+
+i made these changes to make dillo a little more user friendly.
+
+it adds vi like key movement and makes it possible to completly remove the 
+menubar. i am in no way saying that my patch is nice enough to get included,
+i'm not a coder. see it as inspiration on what end users want.
+
+what do you think?
+
+great work btw. the world really needs a browser like dillo. 
+
+
+
+[Dillo-dev]Re: remote url access
+
+From: Sean MacLennan <seanm@st...> - 2001-09-20 03:29
+
+Attachments: dillo-patch      
+
+Hi!
+
+Way back on 10/20/2000 I posted a problem with trying to get Mosaic
+style remote urls working with dillo. Well, I tried it again with
+0.6.1 and it works great! Attached is a patch to try it. For users of
+X?Emacs, the following allows you to try it with browse url:
+
+(setq browse-url-mosaic-program "dillo"
+browse-url-browser-function 'browse-url-mosaic)
+
+Thanks,
+Sean MacLennan 
+
+
+
+Re: [Dillo-dev]Updated https patch available
+
+From: Aaron Lehmann <aaronl@vi...> - 2001-09-19 07:46
+
+On Tue, Sep 18, 2001 at 10:34:17PM +0200, Tor-?ke Fransson wrote:
+> Finally fixed the POST method, and made https use the same query mechanism
+> as http. Which in turn means that my previous auth patch will work with
+> https also :)
+
+This is really cool!!!
+
+> Yesterday i managed reading webmail (IMP) on our corporate
+> intranet using auth and https in Dillo. Hotmail did not work though
+> (missing cookies) ;)
+
+I hope you'll do cookies next! :-) 
+
+
+
+RE: [Dillo-dev]Updated https patch available
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-19 07:21
+
+Hi,
+
+thanks for these cool patches! https and auth work great on my box
+(FreeBSD 4.4)
+
+Cheers,
+Johannes 
+
+
+
+[Dillo-dev]Updated https patch available
+
+From: <torkel@ly...> - 2001-09-18 20:34
+
+Finally fixed the POST method, and made https use the same query mechanism
+as http. Which in turn means that my previous auth patch will work with
+https also :)
+
+Yesterday i managed reading webmail (IMP) on our corporate
+intranet using auth and https in Dillo. Hotmail did not work though
+(missing cookies) ;)
+
+Https patch is at
+http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_https.diff.gz
+
+...applies cleanly with -p1 on my cvs tree from last thursday (i'm on a
+56k modem!) ... oh, and you need OpenSSL.
+
+Regards,
+Tor-Åke 
+
+
+
+[Dillo-dev]Bookmark Seperator patch completed
+
+From: DraX <drax@wh...> - 2001-09-17 02:11
+
+Attachments: dillo_bookmarkseperator.patch      
+
+Attached is my completed patch to add seperators to the bookmark system,
+it now uses <hr>, instead of my deformed href stuff, and it follows the
+bookmark pattern more, which was required when i made it so all browsers
+would have seperators and not just the first.
+
+I hope everyone enjoys, and i hope it makes it into cvs! 
+
+
+
+[Dillo-dev]seperator patch nearly complete
+
+From: DraX <drax@wh...> - 2001-09-16 19:53
+
+ok http://www.stampede.org/~drax/commands.c menu.c bookmark.c
+
+work fine, except seperators aren't parsed by all browser windows, only
+the first, ie if i start a new window, it dosen't have seperators, except
+if i add them from the menu. That and i want to change it from using a
+deformed A HREF to using HR, ubt that will take some modifiying to the way
+it parses the bookmark file.
+
+Try them out, fix the bugs if you want, and as soon as they're all fixed
+i'll submit a real patch. 
+
+
+
+[Dillo-dev]Impl. Basic auth (patch available)
+
+From: <torkel@ly...> - 2001-09-16 19:40
+
+My post this thursday seems to have disappeared somewhere. (not in the
+mail archive) I'll try again:
+
+-------------------------------------------------
+
+Hi all.
+
+I rethinked the authentication scheme a bit. (No changes to DilloUrl) It
+now keeps a list of the base url's for which auth info exists, instead.
+
+Gui code is in place, and all in all it works pretty ok. The 401 page is
+displayed before the reload though. Not so nice. How do i stop dillo from
+displaying it before the user have had a chance to authenticate? I could
+load another (empty) page, but i want to keep the 401 page for displaying,
+should the user/pass be wrong.
+
+Patch is at
+http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_auth.diff.gz
+
+The patch is against todays (thursday) CVS and should apply cleanly w/
+-p1. Even remembered to change the Makefile.in this time ;)
+
+I will post an updated https patch soon. Having trouble with POST.
+
+Regards,
+Tor-Åke 
+
+
+
+[Dillo-dev]Seperator is now working
+
+From: DraX <drax@wh...> - 2001-09-16 18:56
+
+the address in my last email now has a working seperator bookmark file,
+just need to add a "Add Seperator" menu option and then i'll make a patch. 
+
+
+
+[Dillo-dev]Adding seperator to bookmarks
+
+From: DraX <drax@wh...> - 2001-09-16 18:39
+
+out of boredom i started to modify on the bookmark system to allow
+seperators, by using a line like:
+
+<A HREF="SEP-ER-RATOR">SEP-ER-RATOR</A>
+
+Now i got it to the point where it can detect a "Seperator" call and not
+list the seperator in the bookmark list, but my minimal c/gtk skills are
+not giving me a way to put a seperator in. I tried using Menu_sep(), but
+that didn't exactly work, more like it gave me a resolution error on
+compile.
+
+http://www.stampede.org/~drax/bookmark.c includes the bookmark code
+modified to check for SEP-ER-RATOR, if anyone could help me out with
+making this all acutlly work.
+
+I've decided to help out with dillo, i'd fix up the bookmark manager, even
+have a nice little listview interface, and possibly add support for
+netscape style bookmarks, and maybe even XBEL.
+
+Any help getting this first patch completed would be much obliged, it's
+messy i know, i'll clean it up when i get it working :) 
+
+
+
+[Dillo-dev]Patch Manager ala bug manager
+
+From: DraX <drax@wh...> - 2001-09-16 16:28
+
+I was thinking it would be nice if we had a patch manager, that allowed
+people to submit there patches to it, so anyone could download and comment
+on them, this would give a central place to find pending features, and
+would just be sort of nice to have!
+
+I could do one in PHP, if you need someone to do it.
+
+Alex 
+
+
+
+RE: [Dillo-dev]about dillo
+
+From: Eric GAUDET <egaudet@in...> - 2001-09-15 17:36
+
+Hi,
+
+dillo still have a lot of debug messages printed in stdin. You should be able
+to retrieve the lines looking like:
+
+Nav_open_url: Url=>http://dillo.so....net/<
+
+If you really want it in a file (say ~/.dillo/dillo.history), just launch dillo
+with:
+
+dillo > ~/.dillo/dillo.history
+
+And if you *really* want *only* the urls, just lanch dillo with:
+
+dillo | grep Nav_open_url > ~/.dillo/dillo.history
+
+Best,
+Eric
+
+-- En reponse de "[Dillo-dev]about dillo" de Manolo, le 15-Sep-2001 :
+> 
+> 
+> 
+> Hello.
+> 
+> I want to suggest something.
+> 
+> Because Dillo crashes sometimes -few- when i use it, its possible
+> include a "history" option for a more quick finding for the last
+> site that you visited before crashing?
+> 
+> A lot of thanks.
+> 
+> Salutations.
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 15-Sep-2001 a 10:26:04
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]about dillo
+
+From: Manolo <inetd@ma...> - 2001-09-15 14:56
+
+Hello.
+
+I want to suggest something.
+
+Because Dillo crashes sometimes -few- when i use it, its possible
+include a "history" option for a more quick finding for the last
+site that you visited before crashing?
+
+A lot of thanks.
+
+Salutations. 
+
+
+
+[Dillo-dev]0.6.1 release
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-14 04:03
+
+Hi everybody!
+
+Tonight I just released dillo-0.6.1!
+
+Please don't think that the before submitted patches were
+rejected; they're simply waiting for a second revision, or
+probably further improvement.
+
+Ah, FYI there're also a couple of new links on the web site:
+check the [Art] link for some neat images and the 'Free Software'
+in the [Links] section, for an interesting reading.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]meta refresh
+
+From: Viksell <jorgen.viksell@te...> - 2001-09-13 19:36
+
+Attachments: patch-meta      
+
+Hi all!
+
+I noticed bug #208 (meta refresh) and remembered that I did a fix for
+this a while ago. One thing I'm concerned about is if refresh times of
+zero should be allowed since it may be abused. Or it can be used to
+stress-test Dillo! ;-)
+
+As a bonus (or not) I'm throwing in a fix that I think is handy:
+Allowing forms with only one text-type input to be submitted by pressing
+enter, even if they have submit button(s). It seems to be standard
+behaviour in most browsers.
+If the form has more than one text input the next element is focused...
+
+Patch attached since FTP is playing up on me,
+
+Cheers,
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Implementing Basic authentication
+
+From: Viksell <jorgen.viksell@te...> - 2001-09-12 00:43
+
+On Tue, 2001-09-11 at 23:24, Tor-=C5ke Fransson wrote:
+>=20
+> What other useful features are not worked on? Cookies?
+
+I'm working on cookies.=20
+The old Netscape style cookies (version 0) works, except for some
+problems with timezones that has to be fixed.
+Version 1 cookies are about half-way done.
+
+At the moment, Dillo can't parse multiple set-cookie or set-cookie2
+responses in the HTTP header, so that also has to change to make
+everything work.
+
+// J=F6rgen 
+
+
+
+[Dillo-dev]Implementing Basic authentication
+
+From: <torkel@ly...> - 2001-09-11 23:24
+
+Hi all.
+
+To avoid duplicate efforts: is anyone implementing authentication?
+
+In either case i have been working on it for the last three days. Works
+like this:
+
+DilloUrl gets an extra attribute, Auth.
+The 401 return code is trapped in the cache (same place as 30x) and
+user is asked for username/password.
+Auth for the url that caused 401 is set to base64 encoded user/pass and a
+force reload is issued as for redirects.
+In html.c all places where DilloUrl's are created, they are checked for
+relativeness, and if so, they get Auth copied from the base url, so
+user/pass does not have to be entered for every object loaded.
+http.c checks for Auth in the url when creating the query, and if Auth is
+non-null, the query gets an extra line with authentication info.
+
+The performance to browsing unauthenticated is 5 extra lines of
+code executed per link/image on a page, and memory usage is up
+sizeof(GString *) for every DilloUrl created.
+
+This will be quite a big patch when finished (Gui gtk+ code remaining) and
+it will also affect my earlier https patch.
+
+ETA is this weekend. (if noone wants to look at it right now)
+
+What other useful features are not worked on? Cookies?
+
+Regards,
+Tor-Åke 
+
+
+
+Re: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)
+
+From: Eric GAUDET <egaudet@in...> - 2001-09-11 02:21
+
+FYI, the answer I had from gtk's mailining list:
+
+-- FW
+GTK takes strings in the encoding of the current locale. If you give
+it anything else, then your code is broken; it won't work in all
+locales.
+
+Your code works on Red Hat because the locale happens to be en_US or
+the like which uses Latin-1; on Debian in the "C" locale the encoding
+is ASCII, Latin-1 is not allowed.
+
+If you are hardcoding Latin-1 strings into your app, then you require
+a Latin-1 locale to run and work. It's that simple. Even if by some
+bad hack we could make it work in ASCII, it would be totally broken in
+every other non-Latin-1 locale.
+
+The usual way to solve this problem - make strings match the locale -
+is to translate them with gettext.
+
+GTK 2 will require every string to be in UTF-8. Also, Red Hat will
+probably move to all locales using the UTF-8 encoding at some point,
+so Latin-1 will not work even in en_US or fr_FR. Point being, in the
+future hardcoded Latin-1 strings won't work even in the locales that
+are currently Latin-1.
+
+Havoc
+-- end FW
+
+-- En reponse de "Re: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)" de
+Hugo Hallqvist, le 03-Sep-2001 :
+> On Mon, 03 Sep 2001 12:51:23 -0700 (PDT)
+> Eric GAUDET <egaudet@in...> wrote:
+> 
+>> I think I can investigate this problem, because a I can reproduce it both
+>> ways:
+>> - my personal computer is a (heavily customised) mandrake 6.2, and I have no
+>> problem displaying characters in the forms.
+>> - my computer at work is a debian, and I have the same problem Hugo has,
+>> with
+>> all non-ascii entities, for all form elements. For instance:
+> 
+> That is one common thing between us, my computer is running debian
+> unstable/testing, so I guess that should have something to do with it?
+> 
+> 
+>> <html><form> 
+>> <input type="submit" value="abc&eacute;">
+>> </form></html>
+>> will show an empty box, while value="abc&amp;" will of course show "abc&"
+>> 
+>> And that's a problem for me too, even if I don't speak swedish, because my
+>> primary language is french, which uses &eacute; a lot.
+> 
+> Have you tried gtk_set_locale() and if you have; did it work then?
+> 
+> -- 
+> //Hugo Hallqvist - hugha495@st...
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 10-Sep-2001 a 19:19:00
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing Slashdot.org)
+
+From: Eric GAUDET <egaudet@in...> - 2001-09-09 06:46
+
+-- En reponse de "Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing
+Slashdot.org)" de Jorge Arellano Cid, le 08-Sep-2001 :
+> 
+> Hi,
+> 
+>> [...]
+>> I've sent this to
+>> Jorge already, but since more people here enjoy slashdot.org with CVS
+>> Dillo, the patch is at:
+>>
+>> http://www.linux.ime.usp.br/~livio/dillo/url.fix.999873136.diff
+> 
+> I just uploaded a modified patch to CVS.
+> 
+
+Well, I just tested it and I'd say we have a pretty good v0.6.1 !
+
+A nice "cherry on the cake"-feature would be one of the two lynx-style frames
+patches. I tryed both and both seem to do the trick. I kinda like better
+Livio's version, not for what they do (they look the same to me), but Livio's
+code seem much cleaner (way to go, Livio :-)
+
+Best,
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 08-Sep-2001 a 23:35:59
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing Slashdot.org)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-08 23:13
+
+Hi,
+
+> [...]
+> I've sent this to
+> Jorge already, but since more people here enjoy slashdot.org with CVS
+> Dillo, the patch is at:
+>
+> http://www.linux.ime.usp.br/~livio/dillo/url.fix.999873136.diff
+
+I just uploaded a modified patch to CVS.
+
+
+Greetings
+Jorge.- 
+
+
+
+[Dillo-dev][PATCH] Merging frame patches (w3m-style :)
+
+From: Livio Baldini Soares <livio@li...> - 2001-09-08 22:49
+
+Hi guys,
+
+since I'm very interested in this minimal frame support, I've
+decided to try to make my "merged" version of this patch. I loosely
+based this on a patch sent by Robert J Thomson and Hugo Hallqvist last
+patch. Well loosely because my implementation is a bit diferent.
+
+I'm a w3m fan (www.w3m.org), and it's frame support is very similar
+to lynx's, but when in nested frameset's, you can see it visually, as
+it makes nested lists. So this what I have done.
+
+The patch is, I think, pretty much clean, and is easily
+removable/replaceable. I would like to hear comments for improvement
+(specially from Hugo and Robert), before I send this off to Jorge. I
+don't believe there are any bugs, the patch is really simple. I've
+browsed through several framed sites, and haven't got any styles left
+over.
+
+The patch is at:
+http://www.linux.ime.usp.br/~livio/dillo/w3m_frames.999984467.diff
+
+PS: The reason I think this temporary fix is worth pursuing is because
+the real frame support can take a long time before finished. I
+personally think it will because it's a very hard feature to implement
+(I guess harder than tables). And also, this adds no code overhead on
+Dillo. It can be removed and replaced very easily when real frame
+support is done. Does anyone have anything against this patch?
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+RE: [Dillo-dev]bug #207, too long attributes
+
+From: Eric GAUDET <egaudet@in...> - 2001-09-08 02:09
+
+-- En reponse de "[Dillo-dev]bug #207, too long attributes" de J=F6rgen V=
+iksell,
+le 08-Sep-2001 :
+> Hi all!
+>=20
+> Just thought I should mention that bug #207 seems to happen because of =
+a
+> too long attribute (<INPUT VALUE=3D...). This would be related to bug #=
+197
+> that Jorge gave his view on earlier.
+> Is anyone working on this? I am willing to help but I'm not sure where
+> to start.
+>=20
+> J=F6rgen
+>=20
+
+It seems the problem is fixed with the patch for long attributes I submit=
+ted to
+Jorge, which is:
+
+diff -pur dillo/src/html.c dillo.longurl/src/html.c
+--- dillo/src/html.c Mon Aug 27 14:44:12 2001
++++ dillo.longurl/src/html.c Tue Aug 28 23:10:34 2001
+@@ -3290,8 +3288,7 @@ static gint Html_match_attr(const char *
+static gint Html_get_attr_value(const char *tag, gint tagsize,
+char *data, gint datasize, gint strip)
+{
+- gint i =3D 0, j =3D -1, max =3D MAX(tagsize, datasize);
++ gint i =3D 0, j =3D -1, max =3D MIN(tagsize, datasize);
+=20
+if (tag[0] =3D=3D '"' || tag[0] =3D=3D '\'' ) {
+for (i =3D 1; strip && i < max && isspace(tag[i]); i++)
+
+
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 07-Sep-2001 a 19:07:23
+"In theory, there's no difference between=20
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]lynx frames again
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-09-08 00:35
+
+Attachments: lynx-frames.patch      
+
+Hi!
+
+Thanks for the tips of how the style stuff in dillo works, especially Bob. I'm sure I have not fully understand it but yet here's a revised version of my patch. It is more stable now, atleast that's my impression. 
+
+Please feel free to enhance it, as I am sure it could be better written, at least the styles stuff.
+
+If I understood it correctly every page_add_text() adds 1 to the reference counter right? if so, one should be able to do style_unref directly after using the add_text function, however it won't work for me, just segfaulting if I do so. Maybe I did not understand it fully.
+
+
+
+Also, anyone know something about bug #204? It seems very sporadeosly, ehmm, I mean it shows up sometimes, sometimes not on the same page. Is this related to the contents of the page or is it something in dillo?
+
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+[Dillo-dev]Feature: don't load images [PATCH]
+
+From: <torkel@ly...> - 2001-09-07 23:15
+
+Attachments: dillo_noimg.diff      
+
+In my despair over not beeing able to figure out how to load pages
+with large images without running out of memory on my ipaq, i instead
+added an option to not load images at all.
+
+Ideally, i would like a way to not load all images on a page, should
+the page contain many large images, but instead cached uncompressed, and
+then uncompressed as they become exposed.
+
+Or simply a memory consumption high water mark whereover, image loading
+is automatically turned off. Better than running out of memory!
+
+Anyway... the included diff (against cvs of right now) adds this:
+
+Images on/off can be toggled from the menu (File menu, unfortunately, but
+in the abscence of a preferences dialogue it'll have to do).
+
+When images are off, the image url is replaced by a user-selectable
+url (dillorc) and then loaded. This means eventual alt= tags still
+cause a tooltip popup. Imagemaps will behave strange, but the code seemed
+to indicate they are quite broken anyway.
+
+
+Regards,
+Tor-Åke Fransson 
+
+
+
+[Dillo-dev]bug #207, too long attributes
+
+From: Viksell <jorgen.viksell@te...> - 2001-09-07 23:05
+
+Hi all!
+
+Just thought I should mention that bug #207 seems to happen because of a
+too long attribute (<INPUT VALUE=3D...). This would be related to bug #197
+that Jorge gave his view on earlier.
+Is anyone working on this? I am willing to help but I'm not sure where
+to start.
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing Slashdot.org)
+
+From: Livio Baldini Soares <livio@li...> - 2001-09-07 16:02
+
+Hi Sebastian,
+
+Sebastian Geerken writes:
+> Hi,
+> 
+> there are some more bugs in URLs. I've written a small test program,
+> attached to this mail. Just compile
+> 
+> cc -o test-url `glib-config --cflags --libs` test-url.c url.c
+> 
+> and start it.
+
+(-: Wow.... nice little test program. Thanks to that I've made a
+"correct" (heheh, at least I think) fix the the URL problem at
+slashdot.org. It seems that both Bruno's and my patch were a little
+wrong and broke some URLs with `file:/` scheme. I've sent this to
+Jorge already, but since more people here enjoy slashdot.org with CVS
+Dillo, the patch is at:
+
+http://www.linux.ime.usp.br/~livio/dillo/url.fix.999873136.diff
+
+Please test it and send me feedback if you see that it doesn't work
+correctly on a particular page or link.
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]How to add a link to a page?
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-09-07 12:51
+
+Hi Hugo,
+
+On Thu, Sep 06, 2001 at 03:33:53PM +0200, Hugo Hallqvist wrote:
+> On Wed, 05 Sep 2001 19:37:24 -0300
+> Livio Baldini Soares <livio@li...> wrote:
+> [...]
+> > changing the style of the link (change the color to X if link is
+> > visited or Y if not, make it underlined, etc).
+> 
+> This is where I start to get problems. If I want to use a style just briefly and then revert back to the style used before?
+> I copied some of the code from tag_a code and used it, and it displays correctly, but I get warnings on closing dillo that there are styles left.
+> 
+> > I'm really interested in this patch, and I'd be really glad if I
+> > could help you out more (if you want we could make this patch
+> > together -- but feel free to do it alone if you want that too).
+> 
+> What is the style I send to a_Dw_style_new function? I did not quite
+> understand that.
+
+There are some notes in doc/DwStyle.txt, but nothing about the HTML
+parser. You must fill a DwStyle structure (except the ref_count), and
+call a_Dw_style_new, to use it:
+
+DwStyle style_attrs, *style;
+
+style_attrs.foo = bar;
+// etc.
+style = a_Dw_style_new (&style_attrs, random_window);
+// do something with style
+
+After this, the attributes of style should not be changed anymore,
+since styles are often shared between different widgets etc.
+
+Most times, you simply copy the attributes of another style, and
+modify them:
+
+style_attrs = *another_style;
+style_attrs.foo = bar;
+style = a_Dw_style_new (&style_attrs, random_window);
+
+Some words about the stack: the topmost element contains a (reference
+to a) style which will be used to add the text to the current page. If
+you use a style only for a short while (e.g. in this case), you may
+use it this way:
+
+style_attrs = *html->stack[html->stack_top].style;
+style_attrs.foo = bar;
+style = a_Dw_style_new (&style_attrs, random_window);
+
+a_Dw_page_add_text will add a reference to it, so you must unref it at
+the end of Html_tag_open_frame.
+
+Just for completeness: In many cases, you want to set the style for
+the content of an element (e.g. <A>), then you must store it in the
+stack, look at the macro HTML_SET_TOP_ATTR. But this is not necessary
+in this case.
+
+> Also, why does dillo crash if I add a few lines of text, using the a_Dw_page_add_text in a function, even though I haven't touched anything else? 
+> I get a segmentation fault directly when I click a link if I use that function, see the Html_tag_open_frameset function for example.
+
+As far as I see, a style with a reference count of zero (which is so
+freed!) is used.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]table rendering on futurezone.orf.at
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-09-07 12:09
+
+On Fri, Sep 07, 2001 at 12:10:12PM +0200, Ulrich Schwarz wrote:
+> Hi, 
+> 
+> here's another issue about futurezone.orf.at rendering.
+> 
+> After the nowrap/width rendering problem was fixed, I've now found a
+> strange two-column rendering of the first paragraph on
+> Futurezone-subpages in dillo whereas other browsers use only one
+> column-rendering there.
+> 
+> e.g.
+> http://futurezone.orf.at/futurezone.orf?read=detail&id=80073&tmp=71566
+> http://futurezone.orf.at/futurezone.orf?read=detail&id=80131&tmp=5807
+> etc.
+
+I've tested the first one and found a violation: before the table cell
+with the text "Nach jahrelangen juristischen Konflikten ..." (the one
+which is positioned wrong), you'll find a </TR>, but no <TR>, just
+"</TR><TD>", so dillo does not add a new row. BTW, this behavior was
+different some time ago, but was changed for handling pages with
+"<TABLE><TD>", with a missing <TR>.
+
+Sebastian 
+
+
+
+[Dillo-dev]table rendering on futurezone.orf.at
+
+From: Ulrich Schwarz <uschwarz@gm...> - 2001-09-07 10:13
+
+Hi, 
+
+here's another issue about futurezone.orf.at rendering.
+
+After the nowrap/width rendering problem was fixed, I've now found a
+strange two-column rendering of the first paragraph on
+Futurezone-subpages in dillo whereas other browsers use only one
+column-rendering there.
+
+e.g.
+http://futurezone.orf.at/futurezone.orf?read=detail&id=80073&tmp=71566
+http://futurezone.orf.at/futurezone.orf?read=detail&id=80131&tmp=5807
+etc.
+
+So long.
+Ulrich 
+
+
+
+Re: [Dillo-dev]How to add a link to a page?
+
+From: Jason Kibblewhite <jkibble@te...> - 2001-09-06 20:53
+
+On Thu, Sep 06, 2001 at 03:33:53PM +0200, Hugo Hallqvist wrote:
+> On Wed, 05 Sep 2001 19:37:24 -0300
+> Livio Baldini Soares <livio@li...> wrote:
+> 
+> What is the style I send to a_Dw_style_new function? I did not quite understand that.
+> Also, why does dillo crash if I add a few lines of text, using the a_Dw_page_add_text in a function, even though I haven't touched anything else? 
+> I get a segmentation fault directly when I click a link if I use that function, see the Html_tag_open_frameset function for example.
+> 
+> Anyway, here is a first version. Feedback on stability welcome. :-)
+> 
+
+I don't frequent very many frames sites so it was hard to find places to
+test this. Some sites such as google's image browers produced instand
+segfaults without even giving me a change to click on a link, while
+still others such as http://www.tragicallyhip.com segfault when I put the mouse
+over the link, however the latter does work if I run dillo through
+strace. I'm not much of a C coder so I couldn't even begin to explain
+that.
+
+Nice work, even heavy frames pages like securityfocus.com work well.
+
+-- 
+All language designers are arrogant. Goes with the territory...
+-- Larry Wall 
+
+
+
+Re: [Dillo-dev]How to add a link to a page?
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-09-06 13:29
+
+Attachments: frames-lynx.patch      
+
+On Wed, 05 Sep 2001 19:37:24 -0300
+Livio Baldini Soares <livio@li...> wrote:
+
+> Wow! What a nice idea! I should of thought of that :-) It's a great
+> workaround (and should be real easy to implement too!) before real
+> frame support (which isn't easy at all :(, is complete.
+
+Yes, hopefully it will add some functionality, so one doesn't have to cut and paste so much.
+
+> Well, to add a link to a page you should first create and initialize
+> a DilloURL struct (using a_Url_new(url_string, base_url_string) from
+> src/url.c).
+
+Done, this was the easy part. :-)
+
+> This URL will contain the destination that the link will point
+> to. Then with the DilloURL, you should add it to the page, using
+> Html_new_link(html, url). This will add a new link in the DilloHtml's
+> linkblock (which is a list, like, html->linkblock->links[n]), the
+> Html_new_link() will return the index (n) of the link in the
+> linkblock->links array. Eventually you may want that index for
+
+Done too, didn't see that one at first in tag_a code.
+
+> changing the style of the link (change the color to X if link is
+> visited or Y if not, make it underlined, etc).
+
+This is where I start to get problems. If I want to use a style just briefly and then revert back to the style used before?
+I copied some of the code from tag_a code and used it, and it displays correctly, but I get warnings on closing dillo that there are styles left.
+
+> I'm really interested in this patch, and I'd be really glad if I
+> could help you out more (if you want we could make this patch
+> together -- but feel free to do it alone if you want that too).
+
+What is the style I send to a_Dw_style_new function? I did not quite understand that.
+Also, why does dillo crash if I add a few lines of text, using the a_Dw_page_add_text in a function, even though I haven't touched anything else? 
+I get a segmentation fault directly when I click a link if I use that function, see the Html_tag_open_frameset function for example.
+
+Anyway, here is a first version. Feedback on stability welcome. :-)
+
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+[Dillo-dev]0.6.1-pre
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-06 07:44
+
+Hi,
+
+just want to say, that dillo 0.6.1-pre feels a lot more stable than
+0.6.0.
+Just the latest CVS version (updated Sep 5 18:16) crashes on
+http://www.oreillynet.com.
+
+thanks,
+Johannes
+
+
+PS: I am running FreeBSD 4.3.
+Some info from the core file:
+
+bash-2.05$ gdb dillo dillo.core 
+GNU gdb 4.18
+Copyright 1998 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and
+you are
+welcome to change it and/or distribute copies of it under certain
+conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB. Type "show warranty" for
+details.
+This GDB was configured as "i386-unknown-freebsd"...
+Core was generated by dillo'.
+Program terminated with signal 11, Segmentation fault.
+Reading symbols from /usr/local/lib/libpng.so.4...done.
+Reading symbols from /usr/lib/libz.so.2...done.
+Reading symbols from /usr/X11R6/lib/libgtk12.so.2...done.
+Reading symbols from /usr/X11R6/lib/libgdk12.so.2...done.
+Reading symbols from /usr/local/lib/libgmodule12.so.3...done.
+Reading symbols from /usr/local/lib/libglib12.so.3...done.
+Reading symbols from /usr/local/lib/libintl.so.1...done.
+Reading symbols from /usr/lib/libxpg4.so.3...done.
+Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
+Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
+Reading symbols from /usr/lib/libm.so.2...done.
+Reading symbols from /usr/local/lib/libjpeg.so.9...done.
+Reading symbols from /usr/lib/libc_r.so.4...done.
+Reading symbols from /usr/X11R6/lib/libXThrStub.so.6...done.
+Reading symbols from /usr/libexec/ld-elf.so.1...done.
+#0 0x8053811 in Cache_redirect (entry=0x80d5030, Flags=1, bw=0x8093500)
+at cache.c:643
+643 NewUrl =
+a_Url_new(URL_STR(entry->Location),URL_STR(entry->Url),0,0);
+(gdb) p *entry
+$1 = {Url = 0x0, Type = 0x21 <Address 0x21 out of bounds>, Header =
+0xb, 
+Location = 0x3, Data = 0x0, ValidSize = 0, TotalSize = 4, BuffSize =
+5, 
+Flags = 28, io = 0x0, CCCQuery = 0x24, CCCAnswer = 0xb} 
+
+
+
+Re: [Dillo-dev]How to add a link to a page?
+
+From: Livio Baldini Soares <livio@li...> - 2001-09-05 22:37
+
+Howdy Hugo!
+
+Hugo Hallqvist writes:
+> Hi everyone!
+> 
+> I'm wondering how I should go about to add a link to a page in
+> dillo. I try to patch dillo to put up a link when framed pages are
+> viewed, so that I can click on one of them to view the page, just
+> like in lynx.
+
+Wow! What a nice idea! I should of thought of that :-) It's a great
+workaround (and should be real easy to implement too!) before real
+frame support (which isn't easy at all :(, is complete.
+
+> I looked at the tag_open_a but I cannot fully understand how the
+> links are added to the page and most of all displayed.
+
+Well, to add a link to a page you should first create and initialize
+a DilloURL struct (using a_Url_new(url_string, base_url_string) from
+src/url.c).
+
+This URL will contain the destination that the link will point
+to. Then with the DilloURL, you should add it to the page, using
+Html_new_link(html, url). This will add a new link in the DilloHtml's
+linkblock (which is a list, like, html->linkblock->links[n]), the
+Html_new_link() will return the index (n) of the link in the
+linkblock->links array. Eventually you may want that index for
+changing the style of the link (change the color to X if link is
+visited or Y if not, make it underlined, etc).
+
+I think that's about it. Although, probably I'm forgetting
+something.
+
+I'm really interested in this patch, and I'd be really glad if I
+could help you out more (if you want we could make this patch
+together -- but feel free to do it alone if you want that too).
+
+best regards!
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]How to add a link to a page?
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-09-05 22:09
+
+Hi everyone!
+
+I'm wondering how I should go about to add a link to a page in dillo. I try to patch dillo to put up a link when framed pages are viewed, so that I can click on one of them to view the page, just like in lynx.
+
+I looked at the tag_open_a but I cannot fully understand how the links are added to the page and most of all displayed. 
+If someone would make a brief explanation I would be grateful.
+
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+[Dillo-dev]Bugs in URLs
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-09-05 12:55
+
+Attachments: test-url.c      
+
+Hi,
+
+there are some more bugs in URLs. I've written a small test program,
+attached to this mail. Just compile
+
+cc -o test-url `glib-config --cflags --libs` test-url.c url.c
+
+and start it.
+
+Sebastian 
+
+
+
+Fw: Re: [Dillo-dev]0.6.1-pre
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-09-05 06:32
+
+On Tue, 04 Sep 2001 19:13:00 -0700 (PDT)
+Eric GAUDET <egaudet@in...> wrote:
+
+I think so too. Regarding the stability I haven't noticed a single crash, and I've used it almost exclusively.
+Some images don't get loaded properly, however. I also noticed it consumes large amounts of memory after a while, as most I got up to 100 MB in memory consumption before I restarted dillo.
+
+Anyone know what the status of tabs, \n and \r support in <pre> tags is? They to shows up as dotted-boxes here, for example in dillo changelog.
+
+> IMHO we really need the url begining with "//" patch for next release:
+> slashdot's page is looking worse than ever.
+> 
+> > Do you remember my "Yesterday commit" post? It asked for some
+> > feedback on latest CVS stability; only Livio has answered. This
+> > is necessary before 0.6.1 release, because I need to know if it
+> > feels more stable than 0.6.0 or //Hugo Hallqvist - hugha495@st....
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+RE: [Dillo-dev]0.6.1-pre
+
+From: Eric GAUDET <egaudet@in...> - 2001-09-05 02:13
+
+IMHO we really need the url begining with "//" patch for next release:
+slashdot's page is looking worse than ever.
+
+-- En reponse de "[Dillo-dev]0.6.1-pre" de Jorge Arellano Cid, le 04-Sep-2001 :
+> 
+> Hi everyone!
+> 
+> 
+> Do you remember my "Yesterday commit" post? It asked for some
+> feedback on latest CVS stability; only Livio has answered. This
+> is necessary before 0.6.1 release, because I need to know if it
+> feels more stable than 0.6.0 or not.
+> 
+> Thanks
+> Jorge.-
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 04-Sep-2001 a 19:11:46
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]OpenBSD user(s) read this
+
+From: DraX <drax@wh...> - 2001-09-04 22:28
+
+Heh, if i can found out who it is :)
+
+To OpenBSD user(s): if you posted bug 200 please reply to me on the list
+or in private. 
+
+
+
+[Dillo-dev]0.6.1-pre
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-04 20:59
+
+Hi everyone!
+
+
+Do you remember my "Yesterday commit" post? It asked for some
+feedback on latest CVS stability; only Livio has answered. This
+is necessary before 0.6.1 release, because I need to know if it
+feels more stable than 0.6.0 or not.
+
+Thanks
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Tiny memory leak with DilloImages (and HRuler proposal)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-04 19:04
+
+Livio,
+
+> Hello!
+>
+> Jorge, I've been chasing, what seems to be, a tiny (rare) memory
+> leak in the Html_tag_open_img(). It allocates a DilloImage (with
+> a_Image_new()). I believe this gets freed with the a_Dicache_close()
+> or on abort with a_Dicache_callback(). I was trying local browsing and
+> I think this might be causing some leakage, when the image is _not_
+> found. If the image is not found, it doens't get an dicache entry,
+> right?
+
+Right!
+
+> So this DilloImage is never freed... If my reasoning is
+> somewhat correct, than this should free those DilloImages:
+>
+> [patch here]
+>
+> -----------
+>
+> Or some other, more generic, mechanism...
+
+Yes, that structure should be freed within the stopping chain,
+not in the html parsing module. It took me several days to find a
+way of doing it that way!
+
+Currently the dicache bindings are mainly hacks that get the
+job done. BTW, if image loading is stopped, not only the Image
+structure is not freed, but also the image decoding data, ditto
+for abort.
+
+This dicache part needs a design review, but beware, it
+requires deep understanding of the whole CCC process. In general
+terms, from the cache and down (CCC realm), things are handled
+properly. Between the cache and Dw, there's a hacking breach!
+
+...and as you may guess, priorities have it almost forgotten :(
+
+> About the HRulers in Dillo, they have been bugging a bit. It seems
+> that they don't create some space around them, and therefore renders
+> some pages in a "tight" manner.
+> [...]
+
+Sebastian commited that
+(this is a delayed answer).
+
+
+Regards.- 
+
+
+
+[Dillo-dev]entities parsing?
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-09-04 10:06
+
+Hi everyone!
+
+When browsing around a few sites today, I saw one that creates a few dotted boxes in dillo. Everyone seems to be entities.
+http://www.msnbc.com/news/621347.asp?0dm=N14MT&cp1=1
+
+Is this bad html, or is the entities list in dillo incomplete?
+
+Most notably the asterisks, minus and apostroph (sp?) doesn't get correctly parsed.
+
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+[Dillo-dev]Possibility of having dillo <url> open a url in the current instance
+
+From: DraX <drax@wh...> - 2001-09-03 21:25
+
+What are the possibilityes of having dillo called with dillo <url> open a
+url in a currently running version of dillo? 
+
+
+
+Re: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-09-03 20:14
+
+On Mon, 03 Sep 2001 12:51:23 -0700 (PDT)
+Eric GAUDET <egaudet@in...> wrote:
+
+> I think I can investigate this problem, because a I can reproduce it both ways:
+> - my personal computer is a (heavily customised) mandrake 6.2, and I have no
+> problem displaying characters in the forms.
+> - my computer at work is a debian, and I have the same problem Hugo has, with
+> all non-ascii entities, for all form elements. For instance:
+
+That is one common thing between us, my computer is running debian unstable/testing, so I guess that should have something to do with it?
+
+
+> <html><form> 
+> <input type="submit" value="abc&eacute;">
+> </form></html>
+> will show an empty box, while value="abc&amp;" will of course show "abc&"
+> 
+> And that's a problem for me too, even if I don't speak swedish, because my
+> primary language is french, which uses &eacute; a lot.
+
+Have you tried gtk_set_locale() and if you have; did it work then?
+
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+RE: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)
+
+From: Eric GAUDET <egaudet@in...> - 2001-09-03 19:51
+
+-- En reponse de "[Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)" de
+Jorge Arellano Cid, le 03-Sep-2001 :
+> [Hugo wrote]
+> 
+>> I got problems with swedish (international?) characters in
+>> buttons and in lists. The characters for example &auml; shows up
+>> properly in the usual text on a page, but no when they are to be
+>> added in the dropdownlist in a form or as a button in a submit
+>> form.
+> 
+> They work for me!
+> 
+
+I think I can investigate this problem, because a I can reproduce it both ways:
+- my personal computer is a (heavily customised) mandrake 6.2, and I have no
+problem displaying characters in the forms.
+- my computer at work is a debian, and I have the same problem Hugo has, with
+all non-ascii entities, for all form elements. For instance:
+<html><form> 
+<input type="submit" value="abc&eacute;">
+</form></html>
+will show an empty box, while value="abc&amp;" will of course show "abc&"
+
+And that's a problem for me too, even if I don't speak swedish, because my
+primary language is french, which uses &eacute; a lot.
+
+Both computers are set LANG=en and LC_ALL not set.
+
+More info tomorrow, when I'm at my office.
+Meanwhile, I will volunteer for this bug in the bugtrack engine.
+
+> When visiting the page you suggested, I had no problems at all;
+> every character showed up properly. Note that I use dillo without
+> a gtk_set_locale() call (same as 0.6.0 release and CVS), and my
+> environment has:
+> 
+> LC_ALL=POSIX
+> LANG=C
+> 
+> Probably you have a swedish setting there (that's not a problem
+> though!).
+> 
+> Please correct me if I'm wrong: The main reason for not
+> including the gtk_set_locale() call in dillo, is that as dillo
+> works in latin1, and as GTK+ handles strings in the multibyte
+> encoding for the locale, a different locale encoding may result
+> in inconsistencies in character handling.
+> 
+> Note: ISO C says that all programs start by default in the
+> standar 'C' locale, so no explicit setting is required.
+> 
+> 
+> IN BRIEF: check out the above hints, and please confirm me that
+> you've got it working. If not, please ask Karsten, or some other
+> swedish users, and answer back to this list (this time I'll
+> reply quickly, because this subject is now on its turn).
+> 
+> 
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 03-Sep-2001 a 12:42:11
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]antialiased dillo
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-09-03 18:51
+
+Hi,
+
+using gdkxft (http://philrsss.anu.edu.au/~josh/gdkxft/) dillo can render
+antialiased fonts now!
+Well, it gets pretty slow then :-( but it's fun.
+
+Cheers,
+Johannes. 
+
+
+
+[Dillo-dev]Missing feature
+
+From: <Juergen.Daubert@t-...> - 2001-09-03 17:30
+
+Hi all,
+
+first a great thanks to all developer of dillo !
+I'm using dillo since 0.3, version 0.6 works for
+me in most cases.
+
+But i really miss the possibility to browse through
+ftp sides. I dont't need any download features,
+nt does his work very well.
+
+Any ideas ... ?
+
+Greetings
+Jürgen
+
+-- 
+juergen.daubert@t-... 
+
+
+
+[Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-09-03 15:16
+
+Hi,
+
+This is an issue a wanted to answer from a long time, now is
+its turn, so lets get into it:
+
+> Karsten had told me that without this patch he gets boxes instead of
+> propper text.
+> [...]
+>
+> This is bad coding style -- it's a kluge, not a fix.
+>
+> The problem is that search sequence for fonts is arbitrary, and ISO10646
+> fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646
+> fonts properly, hence the resolution problems.
+>
+> The fix I've applied is to hardcode the font encoding into the font
+> search string in dw_style.c.
+
+Note that although Karsten thinks his patch is not a clean fix,
+given current internal character handling in dillo (and to a
+lesser extent GTK+), it's very close to what's required.
+
+Dillo works in ISO-LATIN1; every page is encoded using it (for
+further details, refer to [Project Notes]), so, the idea of
+making an explicit request for the appropriate fonts is OK AFAIK.
+
+The only change I'd make is to raise a warning if latin1 fonts
+are not found, and to try to load the generic ones, so at least
+dillo can be started.
+
+
+[Hugo wrote]
+
+> I got problems with swedish (international?) characters in
+> buttons and in lists. The characters for example &auml; shows up
+> properly in the usual text on a page, but no when they are to be
+> added in the dropdownlist in a form or as a button in a submit
+> form.
+
+They work for me!
+
+When visiting the page you suggested, I had no problems at all;
+every character showed up properly. Note that I use dillo without
+a gtk_set_locale() call (same as 0.6.0 release and CVS), and my
+environment has:
+
+LC_ALL=POSIX
+LANG=C
+
+Probably you have a swedish setting there (that's not a problem
+though!).
+
+Please correct me if I'm wrong: The main reason for not
+including the gtk_set_locale() call in dillo, is that as dillo
+works in latin1, and as GTK+ handles strings in the multibyte
+encoding for the locale, a different locale encoding may result
+in inconsistencies in character handling.
+
+Note: ISO C says that all programs start by default in the
+standar 'C' locale, so no explicit setting is required.
+
+
+IN BRIEF: check out the above hints, and please confirm me that
+you've got it working. If not, please ask Karsten, or some other
+swedish users, and answer back to this list (this time I'll
+reply quickly, because this subject is now on its turn).
+
+
+> I experimented a little and dillo parses the entities
+> correctly, the string puts out nicely in the xterm window, but
+> gtk doesn't seem to like it when it is to add the
+> component(button for example).
+>
+> Maybe this has something to do with the gtk_set_locale thing?
+
+[answered above]
+
+> It is reported as bug #199.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Dillo Square Fonts
+
+From: Jon Bradley <kreator@gc...> - 2001-09-03 08:27
+
+I'm not sure if you can help me, I'm having a problem with dillo, atleast
+I've only seen this happen with the dillo program. Running dillo 0.6.0,
+and also the latest dillo CVS; the font letters, no matter what website,
+look like little square boxes, there is actually no readable character at
+all, just little square boxes in the correct font size.
+
+I noticed this after upgrading from X 4.0.1 binaries, to X 4.0.3 compiled
+and built by me on the local machine. Any recommendations on what to do
+about this?
+
+TIA.
+=-=-=-=-=-=-=-=-=-=-=-=
+Email: kreator@gc...
+bbs: telnet://toga.cx
+=-=-=-=-=-=-=-=-=-=-=-= 
+
+
+
+[Dillo-dev]Email of bug poster in bug reporting engine.
+
+From: DraX <drax@wh...> - 2001-09-01 22:51
+
+The email address of the person submittings a bug should be shown in the
+bugreporting engine.
+
+I'd like to help the person with bug 200, because i know it's not a dillo
+problem, as i use dillo for browsing on openbsd quite a bit :) 
+
diff --git a/old/oldmail/200110.txt b/old/oldmail/200110.txt
new file mode 100644
index 0000000..10ebda0
--- /dev/null
+++ b/old/oldmail/200110.txt
@@ -0,0 +1,3823 @@
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-31 21:42
+
+> The main bad thing with having that extra code in the browser is that it
+> adds cpu cycles and memory usage to normal browsing sessions. How often
+> do you actually view a page source code? Except for when developing web
+> browsers of course. 
+
+or when developing web pages, or just learning how a nifty trick is done. 
+
+Carl Soderstrom
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: DraX <drax@wh...> - 2001-10-31 20:52
+
+On Wed, 31 Oct 2001, Martin Samuelsson wrote:
+
+> 
+> On Wed, Oct 31, 2001 at 12:24:24PM -0800, DraX wrote:
+> > I have no problem with the ABILITY to spawn an external proccess thats a
+> > good idea, but i feel that i shouldn't have to do it myself.
+> 
+> I'm sure you'll understand the unix way in building applications about
+> the same time you learn how to quote other people on mailing lists.
+> Answers should be below the original text and irrelevant text should be
+> removed. There are rfc:s defining this and, most important, it really
+> helps the readers.
+> 
+Flaming me dosen't make you sound more credible you know?
+
+> The main bad thing with having that extra code in the browser is that it
+> adds cpu cycles and memory usage to normal browsing sessions. How often
+> do you actually view a page source code? Except for when developing web
+> browsers of course. Do you view 1% of the pages? Or perhaps on out of
+> 1000? Most users never ever view the source. There's normally no need
+> to.
+> 
+Granted, but i wonder just how many extra cycles or memory usage is added,
+i doubt it's that much at all, probabbly less then is needed to fork off
+an xterm and execute more.
+
+> It's not the web browsers job. It shouldn't be there. It adds bloat to
+> the browser, and other applications problary does a better job.
+> --
+> /Martin
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Martin Samuelsson <cosis@ly...> - 2001-10-31 20:40
+
+On Wed, Oct 31, 2001 at 12:24:24PM -0800, DraX wrote:
+> I have no problem with the ABILITY to spawn an external proccess thats a
+> good idea, but i feel that i shouldn't have to do it myself.
+
+I'm sure you'll understand the unix way in building applications about
+the same time you learn how to quote other people on mailing lists.
+Answers should be below the original text and irrelevant text should be
+removed. There are rfc:s defining this and, most important, it really
+helps the readers.
+
+The main bad thing with having that extra code in the browser is that it
+adds cpu cycles and memory usage to normal browsing sessions. How often
+do you actually view a page source code? Except for when developing web
+browsers of course. Do you view 1% of the pages? Or perhaps on out of
+1000? Most users never ever view the source. There's normally no need
+to.
+
+It's not the web browsers job. It shouldn't be there. It adds bloat to
+the browser, and other applications problary does a better job.
+--
+/Martin 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: DraX <drax@wh...> - 2001-10-31 20:24
+
+I have no problem with the ABILITY to spawn an external proccess thats a
+good idea, but i feel that i shouldn't have to do it myself.
+
+On Wed, 31 Oct 2001, John Utz wrote:
+
+> On Wed, 31 Oct 2001, DraX wrote:
+> 
+> > I just find spawning an external proccess just to look at some html is
+> > stupid.
+> 
+> this is a pretty valid rationale!
+> 
+> but it suffers from a profound lack of flexibility, and can be probably
+> can be discounted by the fact that it contravenes 'The Unix Way'.
+> 
+> 
+> >
+> >
+> > On Wed, 31 Oct 2001, Doug Kearns wrote:
+> >
+> > > On Tue, Oct 30, 2001 at 06:00:57PM -0800, DraX wrote:
+> > > > -1
+> > >
+> > > Well, where is the value in this sort of thing?
+> > >
+> > > What, exactly, does the current source viewer do so well?
+> > >
+> > > I don't understand, bloat, bloat, bloat, bloat ...
+> > >
+> > > Regards,
+> > > Doug
+> > >
+> > > _______________________________________________
+> > > Dillo-dev mailing list
+> > > Dillo-dev@li...
+> > > https://lists.so....net/lists/listinfo/dillo-dev
+> > >
+> >
+> >
+> > _______________________________________________
+> > Dillo-dev mailing list
+> > Dillo-dev@li...
+> > https://lists.so....net/lists/listinfo/dillo-dev
+> >
+> 
+> -- 
+> 
+> John L. Utz III
+> john@ut...
+> 
+> Idiocy is the Impulse Function in the Convolution of Life
+> 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: John Utz <john@ut...> - 2001-10-31 19:31
+
+On Wed, 31 Oct 2001, DraX wrote:
+
+> I just find spawning an external proccess just to look at some html is
+> stupid.
+
+this is a pretty valid rationale!
+
+but it suffers from a profound lack of flexibility, and can be probably
+can be discounted by the fact that it contravenes 'The Unix Way'.
+
+
+>
+>
+> On Wed, 31 Oct 2001, Doug Kearns wrote:
+>
+> > On Tue, Oct 30, 2001 at 06:00:57PM -0800, DraX wrote:
+> > > -1
+> >
+> > Well, where is the value in this sort of thing?
+> >
+> > What, exactly, does the current source viewer do so well?
+> >
+> > I don't understand, bloat, bloat, bloat, bloat ...
+> >
+> > Regards,
+> > Doug
+> >
+> > _______________________________________________
+> > Dillo-dev mailing list
+> > Dillo-dev@li...
+> > https://lists.so....net/lists/listinfo/dillo-dev
+> >
+>
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]feature request: searching HTML source
+
+From: John Utz <john@ut...> - 2001-10-31 19:06
+
+And something that i'd like to see that might do this even better:
+
+how about a configuration item that lets you pick the editor you want to
+use for view src?
+
+i want to use emacs so that i can use psgmlx to manage font lock and tag
+parsing, and search, and so on and so forth.....
+
+hmm, i shall enter a feature bug and try and create this patch
+
+On Tue, 30 Oct 2001, Carl Wilhelm Soderstrom wrote:
+
+> Here's something I'd like to see in a web browser:
+> When you view the source HTML of a page; have a simple dialog box (like
+> right next to the 'close' button), where you can put in a string, and search
+> for it in the source code you're viewing.
+> That way, it's easier to find the particular piece of source that
+> you're looking for.
+>
+> Doing a great job guys! Keep up the good work!
+> Carl Soderstrom
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-31 18:48
+
+On Wed, Oct 31, 2001 at 10:34:21AM -0800, DraX wrote:
+> I just find spawning an external proccess just to look at some html is
+> stupid.
+
+hmmm... looks like the current viewer *doesn't* spawn a new process. (unless
+I'm just not seeing it in 'ps axu'). I kind of expected that it would.
+
+Carl Soderstrom.
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: DraX <drax@wh...> - 2001-10-31 18:34
+
+I just find spawning an external proccess just to look at some html is
+stupid.
+
+
+
+On Wed, 31 Oct 2001, Doug Kearns wrote:
+
+> On Tue, Oct 30, 2001 at 06:00:57PM -0800, DraX wrote:
+> > -1
+> 
+> Well, where is the value in this sort of thing?
+> 
+> What, exactly, does the current source viewer do so well?
+> 
+> I don't understand, bloat, bloat, bloat, bloat ...
+> 
+> Regards,
+> Doug
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: William Kendrick <nbs@so...> - 2001-10-31 18:05
+
+On Wed, Oct 31, 2001 at 06:13:31PM +0100, Martin Samuelsson wrote:
+<snip> 
+> The fact that it looks cute isn't a reason to include it in the main
+> binary imho.
+> 
+> There's nothing preventing a cute looking dillo like html aware text
+> viewer that not is compiled into dillo.
+
+Agreed. It's my hope to one day get Dillo working on my Agenda PDA,
+and I imagine viewing HTML source won't be too important for most users,
+so saving some room in the binary is nice.
+
+Having options for an external viewer (whether it be an 'official Dillo'
+one, or simply "rxvt -e more %s") is the best way to go to keep the
+program small.
+
+Of course, if we just /must/ have a built-in viewer (it's hard to imagine,
+but there might be some environments where a text viewer like 'more'
+or something like a 'notepad' program would NOT be available),
+I think it should be pretty simple. Just a scrollable, fixed-point font
+plaintext display. No colors or anything.
+
+-bill! 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-31 17:27
+
+> The fact that it looks cute isn't a reason to include it in the main
+> binary imho.
+
+I know. :) it's a waste of space in a program that's designed to be tiny. 
+if I actually knew how to write C, I might just take the viewer and make it
+a separate project. 
+oh well... one of these days. :)
+
+Carl Soderstrom. 
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Martin Samuelsson <cosis@ly...> - 2001-10-31 17:13
+
+On Wed, Oct 31, 2001 at 09:45:20AM -0600, Carl Wilhelm Soderstrom wrote:
+> doesn't require any external programs, and looks cute?
+> ;>
+> 
+> those are about the only reasons I can find to like it. 
+
+The fact that it looks cute isn't a reason to include it in the main
+binary imho.
+
+There's nothing preventing a cute looking dillo like html aware text
+viewer that not is compiled into dillo.
+--
+/Martin 
+
+
+
+[Dillo-dev]Yay! Cookies!
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-31 17:06
+
+I now have (rudimentary) cookie support. While I can parse all the RFC2109
+cookies and the old Netscape style cookies, some servers seem to be very
+picky about the format. I got the bulletin boards that I've really been
+missing cookies for to accept them. There is no cookie control yet, nor
+persistent storage, and the cookie jar is shared among all threads.
+
+For those who'd like to try it out, a tarball with a patch and two new
+files is at <URL:http://shasta.cs.uiuc.edu/~lrclause/dillo-cookies.tar.gz>.
+
+I shall now start to consider how to control them:) I'd like to avoid
+blocking the page load while asking about cookies, so that should go into a
+separate thread.=20=20
+
+Persistance would require a lock, because of the threading, otherwise it's
+trivial.=20
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-31 15:45
+
+> Well, where is the value in this sort of thing?
+> 
+> What, exactly, does the current source viewer do so well?
+
+doesn't require any external programs, and looks cute?
+;>
+
+those are about the only reasons I can find to like it. 
+
+Carl Soderstrom. 
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+[Dillo-dev]BUG #241 (was: Big tag-parsing patch)
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-10-31 12:45
+
+On Tue, Oct 30, 2001 at 09:55:02AM -0300, Jorge Arellano Cid wrote:
+> Can anyone reproduce BUG#206 and/or BUG#241?
+> 206: segfault at http://gamefaqs.com
+> 241: unusable last link at http://www.ktl.fi/fineli/
+
+Yes, I can reproduce it, you may have to click the reload
+button. However, I'm currently rewriting (for bug #201) the code in
+dw_page.c for word wrapping, size requisition and some other things,
+the code has become a bit clearer, and indeed, this bug does not occur
+in my code. So I've committed myself to this bug.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Taras <taras.glek@ho...> - 2001-10-31 04:58
+
+On Tue, 2001-10-30 at 20:00, Doug Kearns wrote:
+> On Wed, Oct 31, 2001 at 12:45:11PM -0800, Taras wrote:
+> > On Tue, 2001-10-30 at 19:38, Doug Kearns wrote:
+> > > On Tue, Oct 30, 2001 at 06:00:57PM -0800, DraX wrote:
+> > > > -1
+> > > 
+> > > Well, where is the value in this sort of thing?
+> > > 
+> > > What, exactly, does the current source viewer do so well?
+> > > 
+> > > I don't understand, bloat, bloat, bloat, bloat ...
+> > Not to mention that compared to a full featured external editor this is
+> > crap, crap, crap. Compared to normal browsing, view source is rarely
+> > used, and having it load it every single time you want to quickly see a
+> > page is definetly a drag(IMHO) and unneeded, especially since most times
+> > I do view source is to do something useful with the source, and I would
+> > preffer to use an external editor for that. 
+> > So thats my +1.
+> 
+> <snip>
+> 
+> Did you mean for this to go to the list as well as me ?
+Sorry :), I meant to ditto you to the list
+> Regards,
+> Doug 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Doug Kearns <djkea2@mu...> - 2001-10-31 03:36
+
+On Tue, Oct 30, 2001 at 06:00:57PM -0800, DraX wrote:
+> -1
+
+Well, where is the value in this sort of thing?
+
+What, exactly, does the current source viewer do so well?
+
+I don't understand, bloat, bloat, bloat, bloat ...
+
+Regards,
+Doug 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: DraX <drax@wh...> - 2001-10-31 02:01
+
+-1 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Doug Kearns <djkea2@mu...> - 2001-10-31 00:54
+
+On Tue, Oct 30, 2001 at 05:33:43PM -0600, Carl Wilhelm Soderstrom wrote:
+> > Smaller and lighter than vi, maybe, but not smaller and lighter than
+> > ed. Let the user coose just how small and light he wants.
+> 
+> should we just abandon the source viewer entirely, then? just have a
+> preference for which external viewer you want, and set vi to be the default?
+
++1
+
+Regards,
+Doug 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-31 00:03
+
+> Smaller and lighter than vi, maybe, but not smaller and lighter than
+> ed. Let the user coose just how small and light he wants.
+
+should we just abandon the source viewer entirely, then? just have a
+preference for which external viewer you want, and set vi to be the default?
+
+Carl Soderstrom
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Ted Spradley <tsprad@sp...> - 2001-10-30 23:58
+
+Carl Wilhelm Soderstrom wrote:
+> 
+> > Smaller and lighter than vi, maybe, but not smaller and lighter than
+> > ed. Let the user coose just how small and light he wants.
+> 
+> should we just abandon the source viewer entirely, then? just have a
+> preference for which external viewer you want, and set vi to be the default?
+
+Well, that's what I would do, but that's just me.
+
+Did my message go just to you? I thought I was replying to the list. 
+Need to pay more attention. This discussion belongs on the list.
+
+> 
+> Carl Soderstrom
+> --
+> Network Engineer
+> Real-Time Enterprises
+> (952) 943-8700
+
+-- 
+The Earth is degenerating these days. Bribery and corruption abound.
+Children no longer mind their parents, every man wants to write a book,
+and
+it is evident that the end of the world is fast approaching.
+-Assyrian stone tablet, c.2800bc 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-30 23:06
+
+> Even better in my opinion would be to launch an external viewer/editor for
+> viewing the source. Why redo the wheel?
+
+that's actually a good idea; and should be an option. (like it is in
+Galeon).
+
+The reason I'm interested in re-inventing the wheel in this case, is that
+our new wheel might be smaller and ligher than the old wheel. :)
+
+Carl Soderstrom
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+[Dillo-dev]Re: feature request: searching HTML source
+
+From: Niklas <su99-nho@na...> - 2001-10-30 23:02
+
+Attachments: Message as HTML      
+
+On Tue, 30 Oct 2001 16:51:05 -0600 "Carl Wilhelm Soderstrom"
+<chrome@re...> wrote:
+> When you view the source HTML of a page; have a simple dialog box (like
+> right next to the 'close' button), where you can put in a string, and
+search
+> for it in the source code you're viewing. 
+
+Even better in my opinion would be to launch an external viewer/editor for
+viewing the source. Why redo the wheel?
+
+-- 
+Niklas 
+
+
+
+[Dillo-dev]feature request: searching HTML source
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-10-30 22:51
+
+Here's something I'd like to see in a web browser:
+When you view the source HTML of a page; have a simple dialog box (like
+right next to the 'close' button), where you can put in a string, and search
+for it in the source code you're viewing. 
+That way, it's easier to find the particular piece of source that
+you're looking for. 
+
+Doing a great job guys! Keep up the good work!
+Carl Soderstrom
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+[Dillo-dev]Multiple header fields
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-30 21:57
+
+Hi again!
+
+As I mentioned earlier, I'm working on code for cookies (not nearly as hard
+as I thought). I have the basic cookie matching and aging down, and I'm
+now starting on parsing cookies. I've found one problem in the way the
+HTTP header is parsed, though: AFAICT, the Cache_parse_field function
+assumes that there is only one field with a particular header. However,
+RFC 2109 states that 'An origin server may include multiple Set-Cookie
+headers in a response'. I'm not too happy to hack in such a central
+place, so I hope somebody knowledgeable in this area can come up with a
+good solutions.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Big tag-parsing patch
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2001-10-30 14:17
+
+Attachments: path-dwpage      
+
+tis 2001-10-30 klockan 13.55 skrev Jorge Arellano Cid:
+> [Topic swap]
+>=20
+>=20
+> Can anyone reproduce BUG#206 and/or BUG#241?
+> 206: segfault at http://gamefaqs.com
+> 241: unusable last link at http://www.ktl.fi/fineli/
+
+#241 would be the same old problem with the last line of a page not
+being compared with the other lines.=20
+I think biting the bullet and do a comparison on every word added will
+be the only sane solution. It would be nice to get rid of those problems
+once and for all.
+Attached patch does that. It seems to be faster too! :-)
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Big tag-parsing patch
+
+From: Doug Kearns <djkea2@mu...> - 2001-10-30 14:17
+
+On Tue, Oct 30, 2001 at 09:55:02AM -0300, Jorge Arellano Cid wrote:
+> 
+> Hi everyone!
+
+Hello!
+
+
+<snip>
+
+> ------------
+> [Topic swap]
+> 
+> 
+> Can anyone reproduce BUG#206 and/or BUG#241?
+> 206: segfault at http://gamefaqs.com
+> 241: unusable last link at http://www.ktl.fi/fineli/
+
+I can reproduce 241 _very_ reliably :)
+
+<snip>
+
+Regards,
+Doug 
+
+
+
+Re: [Dillo-dev]Big tag-parsing patch
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-10-30 13:49
+
+On Tue, 30 Oct 2001 09:55:02 -0300 (CLST)
+Jorge Arellano Cid <jcid@ne...> wrote:
+
+> As some of you may know, we were working very hard with J=F6rgen
+> on the new TAG-parsing code (it was priority #1). The good news
+> is that it's already in the CVS!
+> Please consider it beta and test it as much as possible (any
+> page will do!). C'mon, GO GET IT! ;)
+
+Works fine here, haven't had the time to test it to thoroughly though=
+.
+
+> Can anyone reproduce BUG#206 and/or BUG#241?
+> 206: segfault at http://gamefaqs.com
+> 241: unusable last link at http://www.ktl.fi/fineli/
+
+Bug 241 is strange. Tried loading the page a few times in dillo. Mayb=
+e 1/3 of the time the link is not clickable. The html-code is always=
+the same, so the page must have finished loaded.
+
+--=20
+//Hugo Hallqvist - hugha495 at student.liu.se 
+
+
+
+[Dillo-dev]Big tag-parsing patch
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-30 12:56
+
+Hi everyone!
+
+
+As some of you may know, we were working very hard with J=F6rgen
+on the new TAG-parsing code (it was priority #1). The good news
+is that it's already in the CVS!
+Please consider it beta and test it as much as possible (any
+page will do!). C'mon, GO GET IT! ;)
+
+
+What does it do:
+
+* Eliminates fixed-size attribute constraints!
+* A single pass for getting attribute values and entities
+parsing.
+* Avoids g_strdup whenever is possible.
+* Parses CDATA as stated in the W3C's HTML4.01 standar:
+- replaces named entities with LATIN1 char codes
+- replaces numeric character entities with LATIN1 char codes
+- ignores LF
+- replaces CR and TAB with a single space
+Note: Entities outside Latin1 are still pending.
+
+* Fixes: BUG#190, BUG#197, BUG#207, BUG#228 and BUG#239.
+
+
+------------
+[Topic swap]
+
+
+Can anyone reproduce BUG#206 and/or BUG#241?
+206: segfault at http://gamefaqs.com
+241: unusable last link at http://www.ktl.fi/fineli/
+
+(no feedback <-> entry removal)
+
+
+------------
+[Topic swap 2]
+
+
+I'll answer some procrastinated posts when I'm back home.
+
+
+
+Greetings
+Jorge.- 
+
+
+
+Re: [Dillo-dev]interface visibility patch
+
+From: Grigory Bakunov <black@as...> - 2001-10-29 06:13
+
+Date |Fri, 26 Oct 2001 03:39:51 +0300
+From |"Sam J. Engstr=F6m" <mail@sa...>
+
+Hello!
+
+
+SJE> In an effort to get some of my ipaq changes integrated to main dillo=
+I've=20
+SJE> made a patch against 0.6.2 that allows you to configure which interf=
+ace=20
+SJE> widgets (such as toolbar buttons) are visible. This is great on hand=
+helds and=20
+SJE> possibly embedded systems where typing in the url should not be allo=
+wed.
+
+SJE> Next I'll try to make the mouse buttons configurable. I've just now=20
+SJE> discovered that you can pan the viewport with the middle button, and=
+it would=20
+SJE> help a lot when viewing pages on the ipaq.
+
+if nobody don't have objection i place this patch to my dillo patch-o-mat=
+ic
+
+http://haru.wom.ru/pub/dillo/ 
+
+
+
+RE: [Dillo-dev]HTML/XHTML compliance
+
+From: Eric GAUDET <egaudet@in...> - 2001-10-29 04:37
+
+-- En reponse de "[Dillo-dev]HTML/XHTML compliance" de Simon Hill, le
+29-Oct-2001 :
+> 
+> will the rendering engine of dillo be completely w3c html4/xhtml
+> compliant?
+> 
+
+Short answer: no.
+For a longer anwser, have a look at the mailing list archive.
+
+But if you're willing to help, for instance my testing dillo against html
+standards, you're welcome to add entries in the bugtrack.
+
+> red_one
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 28-Oct-2001 a 20:35:10
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]HTML/XHTML compliance
+
+From: Simon Hill <red_one@ot...> - 2001-10-29 03:25
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+
+will the rendering engine of dillo be completely w3c html4/xhtml
+compliant?
+
+red_one
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.0.6 (GNU/Linux)
+Comment: For info see http://www.gnupg.org
+
+iEUEARECAAYFAjvczBAACgkQsnOzDG7Xi8oyswCXdDB+Cc48egrKtk30Lx40V2I0
+EQCeJhRGgZV1ESyrwcJcQ1PyOnoUpW8=
+=ZEs1
+-----END PGP SIGNATURE----- 
+
+
+
+[Dillo-dev]interface visibility patch
+
+From: Sam J. <mail@sa...> - 2001-10-26 00:38
+
+Attachments: dillo-0.6.2-visibility.diff.gz      
+
+In an effort to get some of my ipaq changes integrated to main dillo I've 
+made a patch against 0.6.2 that allows you to configure which interface 
+widgets (such as toolbar buttons) are visible. This is great on handhelds and 
+possibly embedded systems where typing in the url should not be allowed.
+
+Next I'll try to make the mouse buttons configurable. I've just now 
+discovered that you can pan the viewport with the middle button, and it would 
+help a lot when viewing pages on the ipaq.
+
+-- 
+Sam J. Engstrom Tel. +358 400 462442 mail@sa...
+Managing Director Nemesol http://nemesol.fi 
+
+
+
+Re: [Dillo-dev]Dillo pretending to be IE
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-26 00:26
+
+On Thu, 25 Oct 2001, Andreas Schweitzer wrote:
+
+> Hi,
+>=20
+> First of all : Great work guys ! I like dillo a lot !
+>=20
+> Now, after M$ latest stunt :=20
+> http://slashdot.org/articles/01/10/25/1824206.shtml
+> I decided I needed to hack dillo :-) Not that I visit MSN nor that
+> I think MSN is in any way worth visiting .... but still ....
+> this is not the first time something like that happened.
+>=20
+> Here is a patch that makes dillo pretend to be IE. Right now,
+> this is only for MSN. But if you like it I may make it more
+> elegantly.
+
+I would like this feature to be more elegantly implemented. At least to
+where you can set generally what browser to look like, from the
+preferences.
+
+-Lars, working on cookies
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Dillo pretending to be IE
+
+From: Andreas Schweitzer <andy@ph...> - 2001-10-25 22:53
+
+Hi,
+
+First of all : Great work guys ! I like dillo a lot !
+
+Now, after M$ latest stunt : 
+http://slashdot.org/articles/01/10/25/1824206.shtml
+I decided I needed to hack dillo :-) Not that I visit MSN nor that
+I think MSN is in any way worth visiting .... but still ....
+this is not the first time something like that happened.
+
+Here is a patch that makes dillo pretend to be IE. Right now,
+this is only for MSN. But if you like it I may make it more
+elegantly.
+
+Cheers
+Andreas
+
+
+
+--- dillo-0.6.2/src/IO/http.c.orig Tue Oct 16 11:53:53 2001
++++ dillo-0.6.2/src/IO/http.c Thu Oct 25 18:14:49 2001
+@@ -32,6 +32,7 @@
+#include "../web.h"
+#include "../interface.h"
+
++#define IE_STRING "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.0)"
+
+/* Used to send a message to the bw's status bar */
+#define BW_MSG(web, root, fmt...) \
+@@ -105,7 +106,8 @@
+gchar *str, *ptr;
+GString *s_port = g_string_new(""),
+*query = g_string_new(""),
+- *full_path = g_string_new("");
++ *full_path = g_string_new(""),
++ *id_string = g_string_new("");
+
+/* Sending the default port in the query may cause a 302-answer. --Jcid */
+if (URL_PORT(url) && URL_PORT(url) != DILLO_URL_HTTP_PORT)
+@@ -122,17 +124,34 @@
+URL_PATH(url) ? URL_PATH(url) : "/");
+}
+
++/*
++ * There could be a function, that tests if
++ * - the URL is on a blacklist
++ * - the user invoked a command line switch
++ * - the user pressed a button on the browser window
++ * this function could even return the string
++ * 
++ * right now there is only a check if *.msn.com is accessed.
++ * 
++ * if ( pretend_incognito(URL_STR(url)) ){
++ */
++ if ( strstr(URL_STR(url),".msn.com") !=NULL) {
++ g_string_sprintfa(id_string,"%s", IE_STRING);
++ } else {
++ g_string_sprintfa(id_string, "Dillo/%s", VERSION);
++ }
++
+if ( URL_FLAGS(url) & URL_Post ){
+g_string_sprintfa(
+query,
+"POST %s HTTP/1.0\r\n"
+"Host: %s%s\r\n"
+- "User-Agent: Dillo/%s\r\n"
++ "User-Agent: %s\r\n"
+"Content-type: application/x-www-form-urlencoded\r\n"
+"Content-length: %ld\r\n"
+"\r\n"
+"%s",
+- full_path->str, URL_HOST(url), s_port->str, VERSION,
++ full_path->str, URL_HOST(url), s_port->str, id_string->str,
+(glong)strlen(URL_DATA(url)), URL_DATA(url));
+
+} else {
+@@ -141,12 +160,12 @@
+"GET %s HTTP/1.0\r\n"
+"%s"
+"Host: %s%s\r\n"
+- "User-Agent: Dillo/%s\r\n"
++ "User-Agent: %s)\r\n"
+"\r\n",
+full_path->str, 
+(URL_FLAGS(url) & URL_E2EReload) ?
+"Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+- URL_HOST(url), s_port->str, VERSION);
++ URL_HOST(url), s_port->str, id_string->str);
+}
+
+str = query->str;
+
+
+
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Forgot
+
+From: Grigory Bakunov <black@as...> - 2001-10-23 02:09
+
+Also i make small sites with all patches what i found at this moment.
+http://haru.wom.ru/pub/dillo/patches/
+All patches cleaned for current cvs version.
+You can add your own patch by form on site.
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]Charset (and font) problem solving etc.
+
+From: Grigory Bakunov <black@as...> - 2001-10-23 02:08
+
+Okey, i solve some font troubles in dillo.
+As you remember after long debates in dillo code apear
+some 'ugly hacked solution' for font selecting - i mean direct font charset setting like this -
+sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1",...);
+i make a patch for solve it - now all this strings changed to
+sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-%s",
+...,
+prefs.font_charset);
+and to dillorc file added new options - 
+font_charset=xxx
+where xxx is your prefered font charset.
+by default it's equal 'iso8859-1'.
+
+patch place here
+http://haru.wom.ru/pub/dillo/patches/dillo_0.62.charset_selection.patch
+
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]'who' in dillo 'knows' that something is a link? need this for keyboard link navigation
+
+From: John Utz <john@ut...> - 2001-10-19 16:17
+
+thankyou sebastian,
+
+i think your implementation suggestion looks good.
+
+On Fri, 19 Oct 2001, Sebastian Geerken wrote:
+
+> Hi John,
+>
+> On Wed, Oct 10, 2001 at 04:22:55PM -0500, John Utz wrote:
+> > When dillo loads a page, it learns where the links are and colors them
+> > blue.
+> >
+> > Furthermore, when the cursor flies over a link, it is presented in the
+> > data area at the bottom of the page.
+> >
+> > i would like to have keyboard navigation work as simply as possible, so it
+> > needs to make use of existing functionality so that it doesnt break/get
+> > broken by dillo improvements.
+> >
+> > so, what data structure maintains these link facts and what do i use to
+> > access them?
+>
+> They are in several dillo widgets:
+>
+> - DwPage contains them in the word/line structure:
+> page->words[i].style->link; if you iterate over the lines
+> (e.g. for getting the vertical position), page->lines[i] contains
+> indices on the words list (first_word and last_word).
+>
+> - DwImage contains several links for image maps, this is described
+> in doc/DwImage.txt in the tarball.
+>
+> - Of course, a DwContainer (the base class of all widgets
+> containing other widgets) contains, indirectly, also links.
+>
+> Probably the best is to add one or more virtual functions to the base
+> class DwWidget, and implement them for those three widgets.
+>
+> Links are, for Dw, just numbers, the widgets just emit signals which
+> other modules are connected to, look e.g. at Dw_page_button_press. The
+> signals are the same for all widgets, and described in
+> doc/DwImage.txt. For activating links by the keyboard, "link_clicked"
+> is probably the best choice, then the function Html_link_clicked
+> (which is connected to this signal) has to be modified a bit,
+> GdkEventButton does not make much sense for this.
+>
+> Sebastian
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+RE: [Dillo-dev]Suggestions
+
+From: Eric GAUDET <egaudet@in...> - 2001-10-19 15:55
+
+-- En reponse de "[Dillo-dev]Suggestions" de digitalash@vs..., le
+19-Oct-2001 :
+> Hello Friends,
+> 
+> I am Ashwin Desikan from chennai, i just downloaded the latest version of
+> Dillo and it is great.
+> i would like to make a few suggestions though:
+> 
+> 1. support for backspace key in editable textareas.
+
+works for me.
+
+> 2. i think u can put the "page size" box and the "no of pages" box at the top
+> of the tool bar to the right most bottom along with status bar. it would look
+> better.
+> 3. i think u can map the backspace key to back button if the control is not
+> in a textarea.
+> 4. u can provide a small button along with the back and forward buttons
+> (similar to netscape and IE) wherein the list of all the previous links
+> visited is displayed, so that the user can select the one he wants to
+> revisit.
+> 
+
+on the works now. will be finished next week.
+
+> i am willing to contribute to the developement of dillo in whatever way
+> possible. i would like to know if any among u have already started to support
+> frames in dillo (i went through the minimalistic support in 0.6.2 ).
+> 
+
+have a look at the bugtrack: frames are at 50%.
+
+> KEEP UP THE GOOD WORK GUYS
+
+Thanks
+
+> 
+> bye
+> Ashwin Desikan 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 19-Oct-2001 a 08:53:06
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]Suggestions
+
+From: <digitalash@vs...> - 2001-10-19 14:55
+
+Hello Friends,
+
+I am Ashwin Desikan from chennai, i just downloaded the latest version of Dillo and it is great.
+i would like to make a few suggestions though:
+
+1. support for backspace key in editable textareas.
+2. i think u can put the "page size" box and the "no of pages" box at the top of the tool bar to the right most bottom along with status bar. it would look better.
+3. i think u can map the backspace key to back button if the control is not in a textarea.
+4. u can provide a small button along with the back and forward buttons (similar to netscape and IE) wherein the list of all the previous links visited is displayed, so that the user can select the one he wants to revisit.
+
+i am willing to contribute to the developement of dillo in whatever way possible. i would like to know if any among u have already started to support frames in dillo (i went through the minimalistic support in 0.6.2 ).
+
+KEEP UP THE GOOD WORK GUYS
+
+bye
+Ashwin Desikan 
+
+
+
+Re: [Dillo-dev]Several issues
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-10-19 14:09
+
+On Tue, Oct 09, 2001 at 11:34:40AM -0400, Jorge Arellano Cid wrote:
+> > Bookmark URL in status bar.
+> 
+> I'd like to shift bookmarks menu into a popup-menu because the
+> scrolling hack is only working with them (I don't know whether
+> it's possible to make it work with normal menus).
+> 
+> Note: the "scrolling hack" allows scrolling within popups that
+> are to long for the screen.
+
+Just FYI: Gtk+ 2.0 will, AFAIK, support scrolled menus, so this hack
+will become obsolete.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]dillo 0.6.2 scrolling problems
+
+From: James Schofield <jschofield@ot...> - 2001-10-19 14:01
+
+No problem here, Slackware 8.0, GTK 1.2.10.
+
+James
+
+On Thu, 18 Oct 2001, vasant wrote:
+
+>
+> Hi,
+>
+> I downloaded the latest version of Dillo and built it on a
+> Slackware 8.0 system. It builds cleanly but the resulting binary
+> doesn't scroll properly. I think the versions of GTK/GLIB is 1.2.10.
+> Has anyone seen the same problem ?
+>
+> Regards
+> Kanchan
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]'who' in dillo 'knows' that something is a link? need this for keyboard link navigation
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-10-19 13:45
+
+Hi John,
+
+On Wed, Oct 10, 2001 at 04:22:55PM -0500, John Utz wrote:
+> When dillo loads a page, it learns where the links are and colors them
+> blue.
+> 
+> Furthermore, when the cursor flies over a link, it is presented in the
+> data area at the bottom of the page.
+> 
+> i would like to have keyboard navigation work as simply as possible, so it
+> needs to make use of existing functionality so that it doesnt break/get
+> broken by dillo improvements.
+> 
+> so, what data structure maintains these link facts and what do i use to
+> access them?
+
+They are in several dillo widgets:
+
+- DwPage contains them in the word/line structure:
+page->words[i].style->link; if you iterate over the lines
+(e.g. for getting the vertical position), page->lines[i] contains
+indices on the words list (first_word and last_word).
+
+- DwImage contains several links for image maps, this is described
+in doc/DwImage.txt in the tarball.
+
+- Of course, a DwContainer (the base class of all widgets
+containing other widgets) contains, indirectly, also links.
+
+Probably the best is to add one or more virtual functions to the base
+class DwWidget, and implement them for those three widgets.
+
+Links are, for Dw, just numbers, the widgets just emit signals which
+other modules are connected to, look e.g. at Dw_page_button_press. The
+signals are the same for all widgets, and described in
+doc/DwImage.txt. For activating links by the keyboard, "link_clicked"
+is probably the best choice, then the function Html_link_clicked
+(which is connected to this signal) has to be modified a bit,
+GdkEventButton does not make much sense for this.
+
+Sebastian 
+
+
+
+[Dillo-dev]dillo 0.6.2 scrolling problems
+
+From: vasant <vkanchan@un...> - 2001-10-19 00:10
+
+Hi,
+
+I downloaded the latest version of Dillo and built it on a
+Slackware 8.0 system. It builds cleanly but the resulting binary
+doesn't scroll properly. I think the versions of GTK/GLIB is 1.2.10.
+Has anyone seen the same problem ?
+
+Regards
+Kanchan 
+
+
+
+[Dillo-dev]Surprise!
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-18 12:27
+
+Hi everyone!
+
+Surprise!
+
+dillo-0.6.2 was released.
+
+(Note that there's new documentation; namely the parser).
+
+
+Enjoy
+Jorge.- 
+
+
+
+[Dillo-dev]Surprise! (fwd)
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-18 11:00
+
+[This is a fwd. because the former email is still bouncing...]
+
+---------- Forwarded message ----------
+Date: Wed, 17 Oct 2001 21:33:59 -0300 (CLST)
+From: Jorge Arellano Cid <jcid@ne...>
+To: Dillo mailing list <dillo-dev@li...>
+Subject: Surprise!
+
+
+Hi everyone!
+
+Surprise!
+
+dillo-0.6.2 was released.
+
+(Note that there's new documentation; namely the parser).
+
+
+Enjoy
+Jorge.- 
+
+
+
+[Dillo-dev]Re: Fix for segfault with long attributes
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-10-17 10:35
+
+Hi,
+
+I just realized that attributes actually don't need to be that large to
+cause a buffer overflow.
+Just try to view the following HTML page.
+
+<html>
+<head></head>
+<body text="mmmmmmmmmmmmmmmmmmmmm">
+</body>
+</html>
+
+A better crafted "text" attribute would execute arbitrary code.
+
+regards,
+Johannes Hofmann 
+
+
+
+Re: [Dillo-dev]dillo strange behaviour
+
+From: John Utz <john@ut...> - 2001-10-16 19:24
+
+really?
+
+excuse me, my mistake. sorry.
+
+On Tue, 16 Oct 2001, Grigory Bakunov wrote:
+
+> Date |Tue, 16 Oct 2001 12:53:16 -0500 (CDT)
+> >From |John Utz <john@ut...>
+>
+> Hello!
+>
+> JU> Hi grigory!
+>
+> JU> i really appreciate your detailed discussion of the problem!
+>
+> JU> it brings a question to my mind, what is the 'dillo way' to handle broken
+> JU> html?
+>
+> JU> i havent been working on this project too long, so if there is an
+> JU> established policy about broken html, then i'd like to see it spelled out
+> JU> on the dillo project page.
+>
+> JU> can i suggest that there be a 'broken html' plugin(s)? i know that we have
+> JU> discussed the broken html on ebay....but i havent heard any direction on
+> JU> this issue.....
+>
+>
+> Read carrefully please. It's not broken HTML.
+> It's wrong Dillo behaviour.
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]dillo strange behaviour
+
+From: Grigory Bakunov <black@as...> - 2001-10-16 18:35
+
+Date |Tue, 16 Oct 2001 12:53:16 -0500 (CDT)
+From |John Utz <john@ut...>
+
+Hello!
+
+JU> Hi grigory!
+
+JU> i really appreciate your detailed discussion of the problem!
+
+JU> it brings a question to my mind, what is the 'dillo way' to handle broken
+JU> html?
+
+JU> i havent been working on this project too long, so if there is an
+JU> established policy about broken html, then i'd like to see it spelled out
+JU> on the dillo project page.
+
+JU> can i suggest that there be a 'broken html' plugin(s)? i know that we have
+JU> discussed the broken html on ebay....but i havent heard any direction on
+JU> this issue.....
+
+
+Read carrefully please. It's not broken HTML.
+It's wrong Dillo behaviour. 
+
+
+
+Re: [Dillo-dev]dillo strange behaviour
+
+From: Martin Samuelsson <cosis@ly...> - 2001-10-16 18:15
+
+On Tue, Oct 16, 2001 at 12:53:16PM -0500, John Utz wrote:
+> can i suggest that there be a 'broken html' plugin(s)? i know that we have
+> discussed the broken html on ebay....but i havent heard any direction on
+> this issue.....
+
+Wouldn't the prefered way to run such a protocol fixer be as a proxy server?
+
+It seems like a really bad idea to perform that task inside the browser. 
+For a number of obvious reasons.
+
+Do anyone know if there exist any proxy software that tries to parse and 
+correct buggy html?
+--
+/Martin 
+
+
+
+Re: [Dillo-dev]dillo strange behaviour
+
+From: John Utz <john@ut...> - 2001-10-16 17:40
+
+Hi grigory!
+
+i really appreciate your detailed discussion of the problem!
+
+it brings a question to my mind, what is the 'dillo way' to handle broken
+html?
+
+i havent been working on this project too long, so if there is an
+established policy about broken html, then i'd like to see it spelled out
+on the dillo project page.
+
+can i suggest that there be a 'broken html' plugin(s)? i know that we have
+discussed the broken html on ebay....but i havent heard any direction on
+this issue.....
+
+tnx!
+
+johnu
+
+On Tue, 16 Oct 2001, Grigory Bakunov wrote:
+
+> I found realy strange dillo behaviour on rpmfind.net site.
+>
+> look - at first search we have this html:
+> ----- HTML-phase-1 ------------------------------------
+> <form method="get" action="/linux/rpm2html/search.php" enctype="application/x-www-form-urlencoded">
+> <input type="text" size="35" name="query" value="">
+> <input type="submit" value="Search ..." name="submit">
+> </form>
+> ------------------------------------------------END-------
+>
+> so, realy good work form. after input into 'query' field text '12345'
+> and press submit we pass to rpmfind.net site next url query:
+> http://rpmfind.net/linux/rpm2html/search.php?query=1234&submit=Search+...
+> and now form in html look like this
+>
+> ------- HTML-phase-2---------------------------------
+> <form action="/linux/rpm2html/search.php?query=1234" enctype="application/x-www-form-urlencoded" method="GET">
+> <input name="query" type="TEXT" size="60" value="1234">
+> <input name=submit type=submit value="Search ...">
+> </form>
+> ------------------------------------------------END-----
+> As all see - authors of rpmfind site place our 'query' string into form action tag.
+> so, after input into query field '4321' and press submit - we have VERY strange URL string:
+> http://rpmfind.net/linux/rpm2html/search.php?query=1234?query=4321&submit=Search+...
+> look! we have to 'query' variable in url. but RFC says it's not correct.
+> and at least - we have absolutely wrong html form text -
+>
+> ------- HTML-phase-3---------------------------------
+> <form action="/linux/rpm2html/search.php?query=1234%3Fquery%3D4321"
+> enctype="application/x-www-form-urlencoded" method="GET">
+> <input name="query" type="TEXT" size="60" value="1234?query=4321">
+> <input name=submit type=submit value="Search ...">
+> </form>
+> ------------------------------------------------END----
+>
+> so, we need to remove dublicate variables when insert new variables by GET method.
+> Thanks for all who be so patient and read this message to the end.
+>
+>
+> ___________________________________________________________________
+> Truly yours, Grigory Bakunov
+> ASPLinux Support Team
+> http://www.asplinux.ru
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]dillo strange behaviour
+
+From: Grigory Bakunov <black@as...> - 2001-10-16 17:28
+
+I found realy strange dillo behaviour on rpmfind.net site.
+
+look - at first search we have this html:
+----- HTML-phase-1 ------------------------------------
+<form method="get" action="/linux/rpm2html/search.php" enctype="application/x-www-form-urlencoded">
+<input type="text" size="35" name="query" value=""> 
+<input type="submit" value="Search ..." name="submit">
+</form>
+------------------------------------------------END-------
+
+so, realy good work form. after input into 'query' field text '12345'
+and press submit we pass to rpmfind.net site next url query:
+http://rpmfind.net/linux/rpm2html/search.php?query=1234&submit=Search+...
+and now form in html look like this
+
+------- HTML-phase-2---------------------------------
+<form action="/linux/rpm2html/search.php?query=1234" enctype="application/x-www-form-urlencoded" method="GET">
+<input name="query" type="TEXT" size="60" value="1234">
+<input name=submit type=submit value="Search ...">
+</form>
+------------------------------------------------END-----
+As all see - authors of rpmfind site place our 'query' string into form action tag.
+so, after input into query field '4321' and press submit - we have VERY strange URL string:
+http://rpmfind.net/linux/rpm2html/search.php?query=1234?query=4321&submit=Search+...
+look! we have to 'query' variable in url. but RFC says it's not correct.
+and at least - we have absolutely wrong html form text -
+
+------- HTML-phase-3---------------------------------
+<form action="/linux/rpm2html/search.php?query=1234%3Fquery%3D4321"
+enctype="application/x-www-form-urlencoded" method="GET">
+<input name="query" type="TEXT" size="60" value="1234?query=4321">
+<input name=submit type=submit value="Search ...">
+</form>
+------------------------------------------------END----
+
+so, we need to remove dublicate variables when insert new variables by GET method.
+Thanks for all who be so patient and read this message to the end.
+
+
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]backround colour
+
+From: Liam <jedi@ro...> - 2001-10-16 08:19
+
+Hey everyone,
+
+I'm new on the dillo scene and was wondering why all backrounds that are 
+supposed to be white are some sort of off-white? Is this intended?
+
+Also, I'd like to say that it is really nice to see a browser that loads 
+so fast, both for use and loading webpages.
+
+Cheers,
+Liam 
+
+
+
+[Dillo-dev]CCC principle
+
+From: <SirVer@gm...> - 2001-10-15 14:59
+
+Hey there,
+
+i implemented a kind of dpi1 plugin scheme a while ago, then, I run out
+of time. Now, I'd like to try it again with the new CCC style.
+But I don't fully grap the principle. Could someone explain me how it
+works exactly?
+
+Thanks
+Holger 
+
+
+
+[Dillo-dev]Fix for segfault with long attributes
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-10-12 11:58
+
+Hi,
+
+in Html_get_attr_value() I found a small typo that causes an buffer
+overflow in dillo when reading attribute values larger than 1024 bytes.
+The attached patch fixes the problem.
+
+regards,
+Johannes Hofmann
+
+*** html.c.orig Fri Oct 12 13:54:58 2001
+--- html.c Fri Oct 12 13:55:17 2001
+***************
+*** 3424,3430 ****
+static gint Html_get_attr_value(const char *tag, gint tagsize,
+char *data, gint datasize, gint strip)
+{
+! gint i = 0, j = -1, max = MAX(tagsize, datasize);
+
+
+if (tag[0] == '"' || tag[0] == '\'' ) {
+--- 3424,3430 ----
+static gint Html_get_attr_value(const char *tag, gint tagsize,
+char *data, gint datasize, gint strip)
+{
+! gint i = 0, j = -1, max = MIN(tagsize, datasize);
+
+
+if (tag[0] == '"' || tag[0] == '\'' ) { 
+
+
+
+Re: [Dillo-dev]'who' in dillo 'knows' that something is a link? need this for keyboard link navigation
+
+From: Hayden <finally_extinct@ru...> - 2001-10-11 04:00
+
+On Wed, 10 Oct 2001 16:22:55 -0500 (CDT)
+John Utz <john@ut...> wrote:
+
+> hi;
+> 
+> When dillo loads a page, it learns where the links are and colors them
+> blue.
+> 
+> Furthermore, when the cursor flies over a link, it is presented in the
+> data area at the bottom of the page.
+> 
+> i would like to have keyboard navigation work as simply as possible, so it
+> needs to make use of existing functionality so that it doesnt break/get
+> broken by dillo improvements.
+> 
+> so, what data structure maintains these link facts and what do i use to
+> access them?
+> 
+> tnx!
+> 
+> johnu
+
+I actually started looking into this and text selection the other day, they are the features I miss most in dillo.
+There are no structures holding the location of the links as far as I know, currently when the mouse is moved over a link the function Dw_page_find_link is called. This function returns the contents of word->style->link (which could contain a link or not) for the word that the cursor is over.
+The function itself searches the lines one by one till it matches the y position of the cursor, and then searches the words on that line one by one till the x position of the cursor is matched.
+
+I think seerching word by word from start to end is currently the only way to find a link on a page without a reference such as the cursor position. 
+
+
+
+[Dillo-dev]'who' in dillo 'knows' that something is a link? need this for keyboard link navigation
+
+From: John Utz <john@ut...> - 2001-10-10 21:15
+
+hi;
+
+When dillo loads a page, it learns where the links are and colors them
+blue.
+
+Furthermore, when the cursor flies over a link, it is presented in the
+data area at the bottom of the page.
+
+i would like to have keyboard navigation work as simply as possible, so it
+needs to make use of existing functionality so that it doesnt break/get
+broken by dillo improvements.
+
+so, what data structure maintains these link facts and what do i use to
+access them?
+
+tnx!
+
+johnu
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]BUG 232 patch to add 'Back' to PAGE OPTIONS menu
+
+From: John Utz <john@ut...> - 2001-10-10 20:32
+
+hi;
+
+note the simplicity of the patch. code reuse fills me with joy.
+furthermore, it only took me 15 minutes to do.
+
+hope this is deemed worthy of includion. i know it sure improves *my* user
+experience.
+
+
+bash-2.05$ diff -c menuold.c menu.c
+*** menuold.c Fri Jul 13 10:58:03 2001
+--- menu.c Wed Oct 10 13:30:30 2001
+***************
+*** 175,180 ****
+--- 175,184 ----
+Menu_sep(menu);
+Menu_add(menu, "_Find Text", "<ctrl>F", bw,
+a_Commands_findtext_callback, bw);
++ Menu_sep(menu);
++ Menu_add(menu, "Back", NULL, bw,
++ a_Commands_back_callback, bw);
++ Menu_sep(menu);
+bw->pagemarks_menuitem = Menu_add(menu, "Jump to...", NULL, bw, NULL,
+bw);
+
+Menu_sep(menu);
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]Updated auth patch available
+
+From: <torkel@ly...> - 2001-10-10 10:58
+
+An updated basic auth patch is available at:
+
+http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_auth1010.diff.gz
+
+
+Changes in this patch are, according to Pekka Lampila (medar@ka...)
+
+- Bugfix to auth information in url (ignore user:passwd(a)... in path part
+of url string)
+- Indentation changed from emacs out-of-the-box-C-mode to something else
+- Merge with current cvs
+
+
+Thank you Pekka. :)
+I have not yet had time to test it myself, but i'm sure it works.
+
+
+Enjoy.
+
+//Tor-Åke 
+
+
+
+Re: [Dillo-dev]Several issues
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-09 18:43
+
+On Tue, 9 Oct 2001, Jorge Arellano Cid wrote:
+
+>=20
+> Hi list!
+>=20
+>=20
+> Here's a grouping of several issues mainly raised by Lars:
+>=20
+>> History menus on back/forward buttons.
+>=20
+> Done.
+
+Sweet!
+
+>> Bookmark URL in status bar.
+>=20
+> I'd like to shift bookmarks menu into a popup-menu because the
+> scrolling hack is only working with them (I don't know whether
+> it's possible to make it work with normal menus).
+>=20
+> Note: the "scrolling hack" allows scrolling within popups that
+> are to long for the screen.
+
+Well, the menu items are shortened at the moment, so you'd never need to
+scroll. Or?
+
+>=20
+>> Profiling
+>>
+>> % cumulative self self total
+>> time seconds seconds calls us/call us/call name
+>> 15.16 2.01 2.01 5885091 0.34 0.34 a_Url_dup
+>> [...]
+>=20
+> After careful consideration, I decided to try out a function
+> (Html_set_new_link) that avoids the main source of the second
+> a_Url_dup.
+> It seems to reduce render time by 25% on the most favorable
+> case (a page FULL of links) and to be near a 7% on the average ;)
+
+Very nice! Glad it was useful.
+
+>> Page down/up step (from half a page to a configurable factor)
+>=20
+> I'll send the patch to Sebastian for further revision.
+
+Yes, it needs revision. It doesn't take effect for a new page until after
+the first scroll, I have no idea why. And I would like to have it not be
+configurable, really, but set to slightly less than a page (if we can do
+one or two lines of text less, that'd be nice for reading, but it's more
+tricky).=20
+
+>> Image aspect ratio when there's only one dimension specified.
+>>
+>> I had a page where an image was scaled by just setting the
+>> width. Most browsers preserve the aspect ratio when scaling it,
+>> but not Dillo. The HTML specs don't mention aspect ratio at
+>> all. Should we categorize this under 'broken HTML', or should
+>> we keep the aspect ratio when only one of width and height is
+>> specified?
+>=20
+> Interesting question!
+>=20
+> If the HTML specs don't specify that situation, then it is
+> broken HTML (as far as dillo is concerned). OTOH I see the point
+> in preserving the aspect ratio, but considering that those
+> attributes are deprecated, that the spec say they "overrride" the
+> original value, and that they seem to be expected as a couple,
+> maybe the best solution is to keep the "statu quo" and to raise a
+> warning message!
+
+Well, I haven't actually seen the problem in many (any, I think) other
+places, so a quiet (non-dialog) warning is probably appropriate.
+
+>> Save dialog doesn't remember the directory
+>=20
+> Please make separate buffers for open and save.
+
+I was considering that for a while. I not quite sure in what situations
+you'd use both. I have no problem with splitting them up.
+
+>> Key bindings: Space to scroll down, Backspace up...
+>=20
+> Some time ago I wrote this to Bruno Widmann:
+>=20
+>>> I receive miscelaneous key binding requests, some for vi like
+>>>bindings, others like less pager, like lynx, etc. I find dillo OK
+>>>as it is now, but who knows, maybe we can allow key binding
+>>>customization in dillorc...
+>>>
+>>> Keys: Direction arrows, PgUp and PgDn.
+>>>
+>>> As I said before, I don't think of it as a great improvement,
+>>>but it will certainly make some guys happier :)
+>>>
+>>> Ah, and definitively, I don't want to make dillo configurable
+>>>"ad absurdum". So if you want, let's try those keys and that
+>>>should be enough.
+
+I agree that heavy configuration should at least be very well thought
+out. It's easy to get to where it's worse than useless. I'm going to keep
+a set of my own patches around for having Dillo work the way I do, I won't
+spend much time pressuring you into accepting them.
+
+>>>--------------------------------------
+>>>Bug 216 (answers without content/type)
+>>>--------------------------------------
+>>>
+>>> Yes, I also had this problem with ebay (made a little hack, and
+>>>won my bid!). Since that moment the idea of handling this case
+>>>the rigth way is present. Note that the problem arises from a
+>>>http answer lacking the content/type info; the RFC says it SHOULD
+>>>be present, so it's not an error :(
+>>>
+>>> The solution is simple, do you remember magic numbers and the
+>>>'file' command? Well, that's the way to go. I don't mean calling
+>>>'file' and parsing its output, but to examine the magic numbers
+>>>file (and its format) for the small set of MIME types dillo
+>>>supports:
+>>>
+>>> image/{png, jpeg, gif}
+>>> text/{plain, html}
+>>>
+>>> and afterward, to create a custom function that returns the
+>>>MIME type of a file, by examining a few bytes from the start of
+>>>it. Ex:
+>>>
+>>> gchar *a_Mime_get_content_type(const gchar *FewBytesString);
+>>>
+>>> After having this function, it's just a matter of binding it to
+>>>header parsing.
+
+That would be fairly easy, indeed.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Several issues
+
+From: John Utz <john@ut...> - 2001-10-09 17:13
+
+On Tue, 9 Oct 2001, Jorge Arellano Cid wrote:
+
+>
+> Hi list!
+>
+>
+> Here's a grouping of several issues mainly raised by Lars:
+>
+> Note that there's different, but very interesting topic that
+> consists in designing a keyboard navigation model for dillo. I
+> know John Utz is willing to develop it, so those of you that feel
+> interested, please contact him and try to devise a simple,
+> interesting and useful model! :-)
+
+oh good. i am glad this got a mention.... i'll try and post a bug and a
+work item today.
+
+>
+> --- o ---
+>
+> Ah, I can't resist to repost a topic that has remained
+> unanswered, it has the advantage of not requiring a lot of dillo
+> expertise and that will let us bid on ebay!
+
+how ironic! i had dillo open on ebay for the very first time
+last nite. i had wondered why i had not tried that before, now i know :-)
+i did notice that the mime type was *very* stupid - what where those folks
+at ebay thinking? - or am *i* being stupid and misunderstanding something?
+
+i was just thinking that i should step thru the code in ups and see what
+is going on...
+
+the patch is an intriguing solution. it concerns me a trifle to start
+hacking in octet-stream parsing into the mailine dillo code (welcome to
+mozilla) - and i understand that the submitter understands that too,
+that's why he referred to it as a hack.
+
+perhaps an octet-stream parser plugin might be the best idea - that would
+allow for isolation of broken pseudo-html into one clean location. That
+cpould execute the magic number code and then ask the user if it was from
+ebay and then offer to memorize that fact and do it automatically in the
+future. Or it could be linked to a bookmark at that site to avoid question
+asking - but that seems kinda hackish too.
+
+2 related points:
+
+1. octet-stream parsing is a general issue that needs a plugin - if the
+mimetype is octet-stream but it's actually an MS-Word doc, then that would
+be detectable (and handleable by invoking Abiword!) with this idea.
+
+2. the 'ebay problem' maybe related to some commercial web-site creation
+program that i am unaware of. if this where the case, then that would
+imply that we would be likely to hit it again on some other site. Has
+anybody ran into a similar example?
+
+> Regards
+> Jorge.-
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]Several issues
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-09 15:47
+
+Hi list!
+
+
+Here's a grouping of several issues mainly raised by Lars:
+
+> History menus on back/forward buttons.
+
+Done.
+
+
+> Bookmark URL in status bar.
+
+I'd like to shift bookmarks menu into a popup-menu because the
+scrolling hack is only working with them (I don't know whether
+it's possible to make it work with normal menus).
+
+Note: the "scrolling hack" allows scrolling within popups that
+are to long for the screen.
+
+
+> Profiling
+>
+> % cumulative self self total
+> time seconds seconds calls us/call us/call name
+> 15.16 2.01 2.01 5885091 0.34 0.34 a_Url_dup
+> [...]
+
+After careful consideration, I decided to try out a function
+(Html_set_new_link) that avoids the main source of the second
+a_Url_dup.
+It seems to reduce render time by 25% on the most favorable
+case (a page FULL of links) and to be near a 7% on the average ;)
+
+
+> Page down/up step (from half a page to a configurable factor)
+
+I'll send the patch to Sebastian for further revision.
+
+
+> Image aspect ratio when there's only one dimension specified.
+>
+> I had a page where an image was scaled by just setting the
+> width. Most browsers preserve the aspect ratio when scaling it,
+> but not Dillo. The HTML specs don't mention aspect ratio at
+> all. Should we categorize this under 'broken HTML', or should
+> we keep the aspect ratio when only one of width and height is
+> specified?
+
+Interesting question!
+
+If the HTML specs don't specify that situation, then it is
+broken HTML (as far as dillo is concerned). OTOH I see the point
+in preserving the aspect ratio, but considering that those
+attributes are deprecated, that the spec say they "overrride" the
+original value, and that they seem to be expected as a couple,
+maybe the best solution is to keep the "statu quo" and to raise a
+warning message!
+
+
+> Save dialog doesn't remember the directory
+
+Please make separate buffers for open and save.
+
+
+> Key bindings: Space to scroll down, Backspace up...
+
+Some time ago I wrote this to Bruno Widmann:
+
+>> I receive miscelaneous key binding requests, some for vi like
+>>bindings, others like less pager, like lynx, etc. I find dillo OK
+>>as it is now, but who knows, maybe we can allow key binding
+>>customization in dillorc...
+>>
+>> Keys: Direction arrows, PgUp and PgDn.
+>>
+>> As I said before, I don't think of it as a great improvement,
+>>but it will certainly make some guys happier :)
+>>
+>> Ah, and definitively, I don't want to make dillo configurable
+>>"ad absurdum". So if you want, let's try those keys and that
+>>should be enough.
+>>
+>> Cheers
+>> Jorge.-
+>>
+>>PD: If you don't want to try the key customization, please let me
+>> know so I can forward the idea to the list.
+
+
+Note that there's different, but very interesting topic that
+consists in designing a keyboard navigation model for dillo. I
+know John Utz is willing to develop it, so those of you that feel
+interested, please contact him and try to devise a simple,
+interesting and useful model! :-)
+
+
+--- o ---
+
+Ah, I can't resist to repost a topic that has remained
+unanswered, it has the advantage of not requiring a lot of dillo
+expertise and that will let us bid on ebay!
+
+
+
+>>--------------------------------------
+>>Bug 216 (answers without content/type)
+>>--------------------------------------
+>>
+>> Yes, I also had this problem with ebay (made a little hack, and
+>>won my bid!). Since that moment the idea of handling this case
+>>the rigth way is present. Note that the problem arises from a
+>>http answer lacking the content/type info; the RFC says it SHOULD
+>>be present, so it's not an error :(
+>>
+>> The solution is simple, do you remember magic numbers and the
+>>'file' command? Well, that's the way to go. I don't mean calling
+>>'file' and parsing its output, but to examine the magic numbers
+>>file (and its format) for the small set of MIME types dillo
+>>supports:
+>>
+>> image/{png, jpeg, gif}
+>> text/{plain, html}
+>>
+>> and afterward, to create a custom function that returns the
+>>MIME type of a file, by examining a few bytes from the start of
+>>it. Ex:
+>>
+>> gchar *a_Mime_get_content_type(const gchar *FewBytesString);
+>>
+>> After having this function, it's just a matter of binding it to
+>>header parsing.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Re: w3m-frames patch needs update for current cvs-dillo
+
+From: Livio Baldini Soares <livio@li...> - 2001-10-08 19:04
+
+Howdy Ulrich!
+
+Ulrich Schwarz writes:
+> Hi Livio,
+> 
+> your great w3m-frames patch for dillo needs an update for the current
+> dillo cvs version:
+
+> /home/fruli/dillo/dillo-patched/src/html.c:1388: undefined reference to `Html_new_link'
+
+Thanks for the tip! I've updated the patch for today's CVS and
+improved it just a little. I've added a `bullet` to mark each link
+(frameset) inside the frame. I think it looks a tiny bit better now.
+
+Jorge, if you ever get around applying this patch, I guess you
+should apply this version and not the one I've sent you:
+
+http://www.linux.ime.usp.br/~livio/dillo/w3m_frames.1002566719.diff
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Good Job Guys
+
+From: Tony P <digital712@ho...> - 2001-10-08 17:14
+
+I just joined to say what a spiffy little browser you guys have
+created. Good work, looks really nice with AA font's too. Looking
+forward to using it more often once the table rendering gets a little
+better.
+
+Oh ya, I was thinking the other day, Gnome Transfer Manager is a pretty
+spiffy download program, since you guys are are going to make it a
+plugin type browser anyway, this might be a fairly simple solution for
+handling downloads. Just a thought.
+
+Keep up the great work!
+
+Thanks,
+
+Tony 
+
+
+
+[Dillo-dev]dillo patches for iPaq
+
+From: Shooby Ban <shooby@gn...> - 2001-10-07 15:44
+
+I uploaded my dirty hacks for 0.6.1 to http://projects.gnome.hu/dillo
+
+There is a semi-solution for meta refresh stuffs...
+
+I made some hacks in interfaces.c to make small panel real small.
+
+Other thinx:
+
+I've seen a cool feature in Pocket Explorer. The images are resizing after
+loading to the size of the window. (I think this is a good feature in a
+content sensitive right click menu... :)))
+
+I'm in hurry, sorry for the breaf.
+
+--
+Sho 
+
+
+
+[Dillo-dev]Latest commit II
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-06 22:40
+
+Hi!
+
+
+Sorry about the previous commit, testing code slipped in so the
+popup functions were broken. Now it's OK (AFAIK ;).
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Latest commit
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-06 14:22
+
+Hi everyone!
+
+
+Uhhh, I had been very short of time lately, mainly due to
+splitting my attention between W3C's RAND concerns and dillo...
+
+Anyway, I just commited a patch for navigation stack history,
+it works as follows:
+
+- Right click over Back or Forward button to activate
+- Left-click to jump to selected URL
+- Middle-click to open it in a new window
+- Look at the status bar to check the URL you're selecting
+- If there're too many items, the popup will scroll!
+
+
+Actually there's still another 50% of the patch pending, but I
+rushed it in because it has become a recurrent issue, and a need.
+
+Fine print: I'm not sure of GTK+'s behaviour when closing or
+activating popup items. It seems plausible for it to be
+destroying them when not attached to any particular widget, but
+as I said before, I'm not sure yet. Any light on this subject is
+very welcome!
+
+Please someone send me a diff to the help file that integrates
+the above information.
+
+Ah, I also set Ctrl-Q to close window and Alt-Q to quit, plus
+some minor tweaks.
+
+
+Enjoy
+Jorge.-
+
+
+PS: Lars, I owe you an answer. 
+
+
+
+Re: [Dillo-dev]Dillo on Agenda VR3
+
+From: William Kendrick <nbs@so...> - 2001-10-05 17:42
+
+On Fri, Oct 05, 2001 at 08:22:44PM +0300, Sam J. Engström wrote:
+<snip>
+> > 1. Small form factor. Hide a lot of the less-used options inside
+> > a menu. Make other widgets (forward, back, stop, scrollbars) as small
+> > as possible.
+> 
+> This should be configurable so you could choose which toolbar buttons you 
+> want. The small icons are small enough for the ipaq, but there could be a set
+> of micro icons, 5x5 pixels or something, to choose from.
+
+I noticed "dillorc" last night and went nuts. :) I added a "tiny" icon
+set, as well as a "miniscule" panel size. (Removes progress bar at the
+top (they were cut off anyway) and status bar at the bottom (to save
+verticle space))
+
+
+<snip> 
+> There's the Squashed GTK project for making gtk widgets smaller
+> http://mvista.so....net/projects/gtksquashed/ you might find useful.
+
+Ah, I was unfamiliar with this. Thanks, I'll look into it.
+
+
+> I think GTK is good enough for handhelds too.
+<snip>
+
+True, but the problem is, the Agenda's already got FLTK in it, so
+GTK+ would just eat up the userspace on the flash disk. :^/
+
+It would also end up being a new requirement for people who want to
+try it... unless I can get GTK to statically link for the Agenda.
+
+
+Thanks!
+
+
+BTW, a screenshot of Dillo running at 160x240, with my dillorc and
+interface/prefs tweaks, as well as diffs for 0.6.1, are here:
+
+http://www.sonic.net/~nbs/agenda-browser/
+
+
+Take it easy!
+
+-bill!
+bill@ne...
+http://www.newbreedsoftware.com/bill/ 
+
+
+
+Re: [Dillo-dev]Dillo on Agenda VR3
+
+From: Sam J. <mail@sa...> - 2001-10-05 17:22
+
+On Friday 05 October 2001 07:39, you wrote:
+> I was wondering if people have had luck running it [dillo] on small devices,
+> ...
+
+I've been using dillo as my main browser on the ipaq, and providing a tweaked 
+version for it similar to yours. We should get our tweaks integrated to the 
+main dillo, so people with yet another pda wouldn't need to start doing their 
+own changes, just worry about porting. My version is at 
+http://www.hut.fi/~sengstro/ipaq.html
+
+> The important aspects include:
+>
+> 1. Small form factor. Hide a lot of the less-used options inside
+> a menu. Make other widgets (forward, back, stop, scrollbars) as small
+> as possible.
+
+This should be configurable so you could choose which toolbar buttons you 
+want. The small icons are small enough for the ipaq, but there could be a set 
+of micro icons, 5x5 pixels or something, to choose from.
+
+> 2. Zoom-out. Agenda has 160 width. Many websites require (sigh) at
+> least 800x600 display to be viewable. (sigh) Zooming out 5 times would let
+> you see the whole page without scrolling horizontally.
+
+At least panning would help.
+
+> 3. Zoom-in. ... Of course, at 1/5th the size, pages would be unreadable.
+> So I had the idea of a 'magnifying glass' mode. While zoomed out,
+> you can switch to what I call "PenZoom" mode, and pan around the page
+> and read it legibly.
+
+Zooming would be great, but what I'd really like, and I think would be easier 
+to implement too, is the ability to choose from a menu while running 
+different rendering options such as hide images (remove space used by them 
+too, maybe show links to them) and disable table rendering. You could then 
+easily read the text which is usually the most important content of a page.
+
+> Since GTK+ doesn't come with the default Agenda 'romdisk' releases, I think
+> the first step for someone porting it (oh no, am I volunteering? crap!)
+> would be to alter the code so that it can target to _either_ GTK+ (for
+> desktop users) or FLTK (for PDA users).
+
+There's the Squashed GTK project for making gtk widgets smaller
+http://mvista.so....net/projects/gtksquashed/ you might find useful. I 
+think GTK is good enough for handhelds too.
+
+> * I did see one post from someone saying they use Dillo on an iPAQ.
+> It's in a completely different league than the Agenda. Color, faster,
+> higher resolution, more RAM and 'disk'space. But the fact that it
+> works is encouraging to me ;)
+
+Yes, as a pda it's better, but compared to desktop computers the resolution, 
+ram and flash sizes are laughably small. The same aspects as you've described 
+generally apply.
+
+Regards,
+Sam
+
+-- 
+Sam J. Engstrom Tel. +358 400 462442 mail@sa...
+Managing Director Nemesol http://nemesol.fi 
+
+
+
+[Dillo-dev]Selection (was: Pending projects: History, scroll size, middle-cl)
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-10-05 16:53
+
+On Mon, Oct 01, 2001 at 10:12:33PM -0700, Eric GAUDET wrote:
+> -- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll size,
+> [...]
+> > A feature I'm dying to see though is selection support, it sucks to have
+> > a fast browser and not be able to copy examples from it into my
+> > code..etc.
+> > 
+> > I know this is a big task, but it hurts not to have it.
+> 
+> I know, I want it too. I even volunteered and begun to implement it. The hard
+> part is to highlight the selection, because there's nothing in dillo to do that.
+> Especially now, with tablesall over the place.
+
+Yes, nested widgets make some things more complicated, but otherwise
+tables much simpler. If the problem is to handle several nested
+widgets, this is a idea: a simplification may be to serialize them
+"virtually": to add some mechanisms to handle all text as it were in
+one structure, by defining a data type to access text at one level,
+e.g. as a pair of DwPage and line (or word) index. BTW, in a change
+I'm currently working on (bug #201), I'm adding a possibility to find
+the position of a widget within the parent widget fast, in a way
+specific to the parent widget; for a page widget, it is the line
+number (other widgets don't use this).
+
+As I said, just a vague idea, without any implementation ideas.
+
+> I believe the guys that implemented the find-text ran into the same problem ;-)
+
+It was Jorge, but finding text is probably simpler than text
+selection.
+
+> Quick poll about that: would you guys of the list be happy with a drag-box
+> selection (just like selecting in an image in gimp)? I mean just selecting a
+> rectangle in the text, not rest of the line.
+
+Yes, happier than now. :-)
+
+Sebastian 
+
+
+
+[Dillo-dev]Dillo on Agenda VR3
+
+From: William Kendrick <nbs@so...> - 2001-10-05 04:39
+
+Hi! My name's Bill Kendrick. I'm poking around the web lately, trying to
+see what kind of existing web browser software might be good to port to
+the Agenda VR3 PDA. (It's a Linux-based handheld.)
+
+Of the many I found listed on SourceForge, I found three which looked
+promising. One of which didn't crash the minute I asked it to load a
+web page. :) It was Dillo! :)
+
+I was wondering if people have had luck running it on small devices,
+and whether the existing codebase would lend itself well to converting
+to other widget sets, other than GTK+. (The Agenda VR3 comes with FLTK
+built-in. There's an FLTK-based browser around, called ViewML, but it
+hasn't been updated since early this year.)
+
+For those interested, the VR3 is a 66MHz MIPS-based system running
+a Linux 2.4.x kernel. It has a 160x240 resolution LCD screen, which can
+display 16 shades of grey (4bpp). It, of course, has a stylus. It also
+has a soft keyboard/handwriting area which can be popped when needed.
+The current versions have 8MB of RAM and 16MB of flash (about 3 or so are
+currently available for user data and user-installed programs).
+
+
+Late last night, half asleep, I whipped up a picture of what I think
+a suitable web browser would look like on the Agenda, and it includes a
+few options which wouldn't make too much sense on a desktop browser,
+but hey... that's what "#ifdef"s are for. :)
+
+You can see a mockup screenshot I made, as well as some details, here:
+
+http://www.sonic.net/~nbs/agenda-browser/
+
+
+The important aspects include:
+
+1. Small form factor. Hide a lot of the less-used options inside
+a menu. Make other widgets (forward, back, stop, scrollbars) as small
+as possible.
+
+2. Zoom-out. Agenda has 160 width. Many websites require (sigh) at least
+800x600 display to be viewable. (sigh) Zooming out 5 times would
+let you see the whole page without scrolling horizontally.
+
+3. Zoom-in. ... Of course, at 1/5th the size, pages would be unreadable.
+So I had the idea of a 'magnifying glass' mode. While zoomed out,
+you can switch to what I call "PenZoom" mode, and pan around the page
+and read it legibly.
+
+
+Since GTK+ doesn't come with the default Agenda 'romdisk' releases, I think
+the first step for someone porting it (oh no, am I volunteering? crap!)
+would be to alter the code so that it can target to _either_ GTK+ (for
+desktop users) or FLTK (for PDA users).
+
+After that, adding the zoom features would be the next step.
+
+
+What do people think? Am I crazy? Should I just try and start writing
+an FLTK browser from scratch instead? Are any of you even interested in
+PDAs yet? :) *
+
+
+-bill!
+bill@ne...
+http://www.newbreedsoftware.com/bill/
+
+* I did see one post from someone saying they use Dillo on an iPAQ.
+It's in a completely different league than the Agenda. Color, faster,
+higher resolution, more RAM and 'disk'space. But the fact that it
+works is encouraging to me ;) 
+
+
+
+Re: [Dillo-dev]Re: usability patch
+
+From: Martin Samuelsson <cosis@ly...> - 2001-10-04 21:25
+
+On Thu, Oct 04, 2001 at 10:42:05PM +0200, Tor-Åke Fransson wrote:
+> How about having that option control if dillo should start with toolbars
+> ripped off or not?
+
+I agree that ripping off the menubars unclutters the browsing window, but it 
+generates a new problem. For every menubar that gets ripped off there is a 
+new window created. Which of course does clutter the window list.
+
+Clearly, making the dirt go away and sweeping it under the carpet isn't the 
+same thing. I want a nice and neat user interface.
+
+The window managers job is to make it easy to switch focus between different 
+active applications. It's not its job to hide things that shouldn't been 
+there in the first place.
+
+I've thought about rip off items before and came to the conclusion that best 
+thing to do is to make it an option in gtk to hide the item instead of making
+it a separate window.
+
+Since I don't think I could implement such a change in the lib I made the 
+change in the application instead.
+
+Making the change in gtk would be the correct way to solve this for all 
+applications. But I'm not man enough to make it. Anyone else feeling up to it?
+--
+/Martin 
+
+
+
+[Dillo-dev]Re: usability patch
+
+From: <torkel@ly...> - 2001-10-04 20:42
+
+Well, since the toolbars can be ripped off (as on all proper gtk
+applications), and i can have the window manager hide them somewhere until
+i need them, i would never use this feature.
+
+Especially since i use dillo on my ipaq, where shortcut keys isn't an
+option...
+
+How about having that option control if dillo should start with toolbars
+ripped off or not?
+
+Regards,
+Tor-Åke
+
+Quoting Martin Samuelsson:
+> [...]
+> For example the panel at the top of the screen. I noticed that it's size
+> could get changed. So I wrote these few lines to make it disappear all
+> together.
+
+>Is there any chance that my patch could get applied in the official
+>distribution? Should I change it in some way? Apply through the bts?
+>
+>I believe there are more people than me who finds that the bar does
+>nothing but wasting valuable screen space.
+>
+>What do you think? Is it worthless? Am I worthless? Do you get this mail 
+
+
+
+[Dillo-dev]keyboard navigation doesnt seem to work. i'll make it work if u want
+
+From: John Utz <john@ut...> - 2001-10-04 16:37
+
+hi;
+
+if somebody isnt working on this already. i'd be happy to.
+
+i am using dillo to browse docs on my laptop on the bus to and from work,
+and using the mouse is really not good in that situation :-).
+
+tell me the procedure for owning this work. i feel that it should work the
+same way lynx does modulo expected GTK widget behavior.
+
+does anybody disagree with this?
+
+should i create a feature bug in the bug tracker?
+
+can somebody tell me anything beyond the naming conventions doc about
+where this should go in the src code tree? it seems like control.c would
+not be a *bad* place, but that seems not really right.
+
+should this be a new module/file?
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]Re: usability patch
+
+From: Martin Samuelsson <cosis@ly...> - 2001-10-03 20:35
+
+Attachments: dillo-nouglybar.patch      
+
+Since I got no feedback what so ever on my last mail I'm retrying.
+
+Tried dillo for the first time a couple of weeks ago and totally fell in love. 
+It's a wonderful browser for the pages it does render. And I hope it will do
+frames and cookies without getting bloated sometime in the future.
+
+However there are a few things that irritates me in the user interface.
+
+For example the panel at the top of the screen. I noticed that it's size could 
+get changed. So I wrote these few lines to make it disappear all together.
+
+Is there any chance that my patch could get applied in the official 
+distribution? Should I change it in some way? Apply through the bts?
+
+I believe there are more people than me who finds that the bar does nothing but 
+wasting valuable screen space.
+
+What do you think? Is it worthless? Am I worthless? Do you get this mail?
+--
+/Martin 
+
+
+
+[Dillo-dev]Some profiling
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-03 16:33
+
+I have my Dillo run with -pg, and when I restarted this morning to get the
+newest patch in, I took out the gprof results. Here's the top ten of what
+I got, this is from fairly standard browsing of slashdot, theregister, gtk
+api docs, java docs, webboards, cnn and a few other things. There doesn't
+seem to be anything critically slow, though a_Url_dup is called quite a
+lot. The cache search is somewhat slow, maybe a g_hashtable will be useful
+someday. All in all, I don't see anything that warrants change right
+away. Good job!
+
+-Lars
+
+% cumulative self self total=20=20=20=20=20=20=20=20=
+=20=20=20
+time seconds seconds calls us/call us/call name=20=20=20=20
+15.16 2.01 2.01 5885091 0.34 0.34 a_Url_dup
+7.99 3.07 1.06 113824 9.31 9.40 Dw_page_forall
+6.41 3.92 0.85 505303 1.68 2.07 Dw_page_new_word
+4.75 4.55 0.63 16500 38.18 117.16 Cache_entry_search
+4.00 5.08 0.53 191117 2.77 2.77 Html_get_attr_value
+3.09 5.49 0.41 21717 18.88 50.55 a_Dicache_get_entry
+2.41 5.81 0.32 35397 9.04 9.13 Dw_image_scale_row
+1.96 6.07 0.26 2870616 0.09 0.09 a_Dw_widget_get_type
+1.89 6.32 0.25 274063 0.91 1.23 Gif_sequence
+1.81 6.56 0.24 66995 3.58 5.03 Dw_page_draw_line
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Oh, oh... bugtrack gone :_(
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-03 02:34
+
+Hi all!
+
+> > It seems that all bugtrack entries have disappeared. Jorge, was it
+> > you?
+>
+> No AFAIK :)
+>
+> > In case it wasn't and all the entries are gone (why is that?)
+
+I answered this early in the morning, and was about to quote
+that anyone can make a backup of the main DB file with:
+
+http://dillo.so....net/cgi-bin/bugtrack/Dillo_text.py
+
+but it didn't work, so I decided to check it later.
+
+Several hours after, I tested again (with a view to start
+fixing), and it worked, just as before!
+
+So, it _IS_ sourceforge having problems with CGI apps. In our
+case, if the updating CGI was stopped shortly after it started,
+that could explain the 1-sized files...
+
+> I checked the sited and all the data files had length 1.
+> That's pretty fishy.
+> Fortunately I had a backup there!
+>
+> > really wierd... hope this helps!
+
+
+Weird, but it starts to get clearer.
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Oh, oh... bugtrack gone :_(
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-02 20:19
+
+Livio,
+
+> Hi all!
+>
+> It seems that all bugtrack entries have disappeared. Jorge, was it
+> you?
+
+No AFAIK :)
+
+> In case it wasn't and all the entries are gone (why is that?)
+
+I checked the sited and all the data files had length 1.
+That's pretty fishy.
+Fortunately I had a backup there!
+
+> really wierd... hope this helps!
+
+Thanks Livio.
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]Oh, oh... bugtrack gone :_(
+
+From: Livio Baldini Soares <livio@li...> - 2001-10-02 17:56
+
+Hi all!
+
+It seems that all bugtrack entries have disappeared. Jorge, was it
+you? In case it wasn't and all the entries are gone (why is that?), I
+have a copy of today's entries at:
+
+http://www.linux.ime.usp.br/~livio/dillo/bugtrack.1002045154.old
+
+really wierd... hope this helps!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-cl
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-02 14:50
+
+On Mon, 01 Oct 2001, Eric GAUDET wrote:
+
+> -- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll size,
+> middle-cl" de Taras, le 02-Oct-2001 :
+>> Mon, 2001-10-01 at 19:20, Eric GAUDET wrote:
+>>> -- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll
+>>> size, middle-cl" de DraX, le 01-Oct-2001 :
+>>> > Middle mouse click on the page should open whatever is in the
+>>> > clipboard. Anybody got a problem with that?
+>>> >=20
+>>> > -Lars
+>>> >=20
+>>>=20
+>>> I don't like that in netscape already, please don't do the same mistake
+>>> with dillo.
+>> I hate that too. Its easy enough to paste in the url bar.
+
+Too bad. I really like that feature. I dislike having to find the little
+X button and then the url bar, when I'm used to just clicking anywhere on
+the page. I guess I'll just make that a private patch.
+
+>> A feature I'm dying to see though is selection support, it sucks to have
+>> a fast browser and not be able to copy examples from it into my
+>> code..etc.
+>>=20
+>> I know this is a big task, but it hurts not to have it.
+>=20
+> I know, I want it too. I even volunteered and begun to implement it. The
+> hard part is to highlight the selection, because there's nothing in dillo
+> to do that. Especially now, with tablesall over the place. I believe
+> the guys that implemented the find-text ran into the same problem ;-)
+>=20
+> Quick poll about that: would you guys of the list be happy with a
+> drag-box selection (just like selecting in an image in gimp)? I mean just
+> selecting a rectangle in the text, not rest of the line.
+
+It would be better than nothing, that's certain.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Dillo for the blind and visually impaired.
+
+From: Simon Dobrisek <simond@lu...> - 2001-10-02 07:32
+
+Dear Jorge,
+
+first of all, thanx for the reply!
+
+> That means that the learning curve to modify the specialized
+> parts is quite steep and lofty. On the other hand, I see that the
+> simplicity of the parser and small codebase is a plus for your
+> project.
+
+This I have noticed. For our project the crucial part is the dw_page
+(lines, words, ...) and it can be handled fairly easily. We have avoided
+journeys to any other part of the dillo ... only a few minor interventions
+in scrolled_frame/window (scrolling had generated motion notify event and
+we wanted to distinct this event and the true pointer motion event).
+
+> In brief, if you're planning for the mid to long term, I'd
+> suggest you to try to keep with one of the official releases and
+> to make a specialized version of dillo for the visually impaired
+> (instead of trying to catch-up with a patch scheme).
+
+I agree. We are doing this. The first working version is based on dillo
+0.5.1, just now we are introducing specialized parts into the dillo 0.6.1
+code. We would call this specialized version with a combination of names
+"dillo" and "homer".
+
+> Beware of the GPL: Your code MUST be GPLed!
+
+Our project requires from us to do that.
+
+> Menus are different, because they're pure GTK widgets, you may
+> need to derive a custom class to do that, I'm not sure. Maybe the
+> tooltips code can hint you, and the authoritative source is the
+> GTK+ mailing list.
+
+Hmmm... I have already played with the tooltips. I will check the GTK+
+mailing list.
+
+Thanx again!
+
+Simon.
+
+simond@lu... 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-cl
+
+From: Eric GAUDET <egaudet@in...> - 2001-10-02 05:12
+
+-- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll size,
+middle-cl" de Taras, le 02-Oct-2001 :
+> Mon, 2001-10-01 at 19:20, Eric GAUDET wrote:
+>> -- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll size,
+>> middle-cl" de DraX, le 01-Oct-2001 :
+>> > Middle mouse click on the page should open whatever is in the clipboard.
+>> > Anybody got a problem with that?
+>> > 
+>> > -Lars
+>> > 
+>> 
+>> I don't like that in netscape already, please don't do the same mistake with
+>> dillo.
+> I hate that too. Its easy enough to paste in the url bar.
+> 
+> A feature I'm dying to see though is selection support, it sucks to have
+> a fast browser and not be able to copy examples from it into my
+> code..etc.
+> 
+> I know this is a big task, but it hurts not to have it.
+
+I know, I want it too. I even volunteered and begun to implement it. The hard
+part is to highlight the selection, because there's nothing in dillo to do that.
+Especially now, with tablesall over the place.
+I believe the guys that implemented the find-text ran into the same problem ;-)
+
+Quick poll about that: would you guys of the list be happy with a drag-box
+selection (just like selecting in an image in gimp)? I mean just selecting a
+rectangle in the text, not rest of the line.
+
+>> 
+>> ------------------------------------
+>> Eric GAUDET <egaudet@in...>
+>> Le 01-Oct-2001 a 19:19:51
+>> "In theory, there's no difference between 
+>> theory and practice; in practice, there is."
+>> ------------------------------------
+>> 
+>> 
+>> _______________________________________________
+>> Dillo-dev mailing list
+>> Dillo-dev@li...
+>> hhttps://lists.so....net/lists/listinfo/dillo-de
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 01-Oct-2001 a 22:04:10
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-cl
+
+From: Taras <taras.glek@ho...> - 2001-10-02 04:59
+
+Mon, 2001-10-01 at 19:20, Eric GAUDET wrote:
+> -- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll size,
+> middle-cl" de DraX, le 01-Oct-2001 :
+> > Middle mouse click on the page should open whatever is in the clipboard.
+> > Anybody got a problem with that?
+> > 
+> > -Lars
+> > 
+> 
+> I don't like that in netscape already, please don't do the same mistake with
+> dillo.
+I hate that too. Its easy enough to paste in the url bar.
+
+A feature I'm dying to see though is selection support, it sucks to have
+a fast browser and not be able to copy examples from it into my
+code..etc.
+
+I know this is a big task, but it hurts not to have it.
+> 
+> ------------------------------------
+> Eric GAUDET <egaudet@in...>
+> Le 01-Oct-2001 a 19:19:51
+> "In theory, there's no difference between 
+> theory and practice; in practice, there is."
+> ------------------------------------
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> hhttps://lists.so....net/lists/listinfo/dillo-de 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-cl
+
+From: Eric GAUDET <egaudet@in...> - 2001-10-02 02:21
+
+-- En reponse de "Re: [Dillo-dev]Pending projects: History, scroll size,
+middle-cl" de DraX, le 01-Oct-2001 :
+> Middle mouse click on the page should open whatever is in the clipboard.
+> Anybody got a problem with that?
+> 
+> -Lars
+> 
+
+I don't like that in netscape already, please don't do the same mistake with
+dillo.
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 01-Oct-2001 a 19:19:51
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+Re: [Dillo-dev]Dillo for the blind and visually impaired.
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-01 22:36
+
+Simon,
+
+>
+> Dear colleagues,
+>
+> I am a teaching assistant and part of my research work at our university
+> is to develop a simple but usable web browser for the blind and visually
+> impaired people.
+>
+> For some time we have been involved in a non-profit research project where
+> we developed a voice-driven text-to-speech system (HOMER II) for blind or
+> visually impaired persons for reading Slovenian texts ( my country ;) ).
+>
+> Later on we got an idea to set a web portal entirely dedicated to such
+> disabled persons in Slovenia and to develop a HOMER III system which
+> includes an html parser. Additionally, we decided to enable use of mouse
+> pointer when browsing through the available text at the portal (some
+> useful info, daily newspapers, selected novels ... all preformated into
+> simple html pages ... the portal does not exist yet :( ... but an internet
+> source of nonstructed ASCII Slovenian texts does!)
+>
+> And then I "discovered" the dillo. We have already done some job and our
+> extension of the dillo has a screen reading capabilities (with the
+> Slovenian text-to-speech and a lot of beep sounds ;) ... it works only
+> when pointer is in the "dw_page"). The working name of the system is
+> "ihomer".
+>
+> I have to say that I am a rookie in GTK programming and the dillo project.
+> I hope I didn't pollute the code with too much unstable crap but it seems
+> stable (as much as dillo is stable). Our extension of the source code will
+> be publicly available (without the Slovenian TTS but with the instructions
+> how to integrate other language TTS ... actually we have version with the
+> "dummy synthesis - delayed print" to the console window).
+
+Interesting project!
+
+Beware, though, that dillo is a visual user agent that's highly
+optimized to be fast: with very innovative coding on the network
+layers and cache for speed, fast and streamed table rendering for
+early feedback, etc.
+
+That means that the learning curve to modify the specialized
+parts is quite steep and lofty. On the other hand, I see that the
+simplicity of the parser and small codebase is a plus for your
+project.
+
+In brief, if you're planning for the mid to long term, I'd
+suggest you to try to keep with one of the official releases and
+to make a specialized version of dillo for the visually impaired
+(instead of trying to catch-up with a patch scheme).
+
+Beware of the GPL: Your code MUST be GPLed!
+
+> And now the main point!
+>
+> Currently, I am stucked with a problem of how to hook on the low level
+> signals of the GTK menus and buttons in the dillo. I would need to
+> "intercept" the position of the pointer in the menu (better said, I need
+> the menu or button label text beneath the pointer to send it to the TTS).
+
+Dillo toolbars, and dw widgets are easy to hook: just as the
+tooltips and as the hand-mouse-cursor.
+
+Menus are different, because they're pure GTK widgets, you may
+need to derive a custom class to do that, I'm not sure. Maybe the
+tooltips code can hint you, and the authoritative source is the
+GTK+ mailing list.
+
+> TTS works in a separated thread with a time out function. This means that
+> you can't stuff the TTS with some fast browsing. You need to stay in a
+> position for some time to hear anything from the TTS. This feature of our
+> TTS seem to be stable when browsing through the dw_page. (I hooked TTS on
+> the motion_notify_event of the dw_page)
+>
+> Do you have any hint, instructions?
+
+[As stated above]
+
+
+Good luck
+Jorge.- 
+
+
+
+[Dillo-dev]Last Patch of the Day: Bookmark URL in statuc bar
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 22:06
+
+Have to go home now, but before I leave, here's a patch that shows the
+bookmark URL in the statusbar when the mouse is over the menu item. I'm
+not quite sure if status_is_link is what I think it is, though.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile /tmp/dillo-patch4=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+Index: bookmark.c
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+RCS file: /cvsroot/dillo/dillo/src/bookmark.c,v
+retrieving revision 1.17
+diff -u -B -b -r1.17 bookmark.c
+--- bookmark.c 2001/08/29 17:45:18 1.17
++++ bookmark.c 2001/10/01 22:05:25
+@@ -104,6 +104,29 @@
+}
+=20
+/*
++ * Put the url in the status bar when moving cursor over menuitem.
++ */
++void a_Bookmarks_menu_select_callback(GtkWidget *wid, gpointer *user_data)
++{
++ CallbackInfo *CbInfo =3D (CallbackInfo *)user_data;
++=20=20=20
++ gtk_label_set(GTK_LABEL(CbInfo->bw->status),
++ bookmarks[CbInfo->index].url->url_string->str);
++ CbInfo->bw->status_is_link =3D 1;
++}
++
++/*
++ * Remove the url in the status bar when removing cursor from menuitem.
++ */
++void a_Bookmarks_menu_deselect_callback(GtkWidget *wid, gpointer *user_dat=
+a)
++{
++ CallbackInfo *CbInfo =3D (CallbackInfo *)user_data;
++=20=20=20
++ gtk_label_set(GTK_LABEL(CbInfo->bw->status), "");
++ CbInfo->bw->status_is_link =3D 0;
++}
++
++/*
+* Add a bookmark to the bookmarks menu of a particular browser window
+*/
+void Bookmarks_add_to_menu(BrowserWindow *bw, GtkWidget *menuitem, guint i=
+ndex)
+@@ -119,6 +142,12 @@
+/* accelerator goes here */
+gtk_signal_connect(GTK_OBJECT (menuitem), "activate",
+(GtkSignalFunc)Bookmarks_goto_bookmark, CbInfo);
++ gtk_signal_connect(GTK_OBJECT (menuitem), "select",=20
++ (GtkSignalFunc)a_Bookmarks_menu_select_callback,
++ CbInfo);
++ gtk_signal_connect(GTK_OBJECT (menuitem), "deselect",=20
++ (GtkSignalFunc)a_Bookmarks_menu_deselect_callback,
++ CbInfo);
+}
+=20
+/*
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+[Dillo-dev]Patch: Bug #211
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 20:51
+
+Attached is a patch for bug #211: Save-as dialog does not remember dir.
+
+It remembers the same dir for save page, save link and open file. It will
+also remember the file name of the last saved or opened file and use that
+for suggestions if the URL doesn't give a useable suggestion.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile /tmp/dillo-patch3=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+Index: interface.c
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+RCS file: /cvsroot/dillo/dillo/src/interface.c,v
+retrieving revision 1.39
+diff -u -b -B -r1.39 interface.c
+--- interface.c 2001/09/27 14:25:21 1.39
++++ interface.c 2001/10/01 20:50:52
+@@ -832,6 +832,10 @@
+g_string_free(UrlStr, TRUE);
+a_Url_free(url);
+=20
++ printf("Full name %s\n", fn);
++ if (bw->file_dialog_last_name !=3D NULL) g_free(bw->file_dialog_last_na=
+me);
++ bw->file_dialog_last_name =3D g_strdup(fn);
++
+gtk_widget_destroy(bw->openfile_dialog_window);
+}
+=20
+@@ -883,6 +887,10 @@
+(GtkSignalFunc) Interface_openfile_ok_callback, (void *)bw);
+}
+=20
++ if (bw->file_dialog_last_name !=3D NULL)
++ gtk_file_selection_set_filename(
++ GTK_FILE_SELECTION(bw->openfile_dialog_window), bw->file_dialog_l=
+ast_name);
++
+if (!GTK_WIDGET_VISIBLE(bw->openfile_dialog_window))
+gtk_widget_show(bw->openfile_dialog_window);
+else
+@@ -1089,6 +1098,9 @@
+Web->flags |=3D WEB_Download;
+/* todo: keep track of this client */
+a_Cache_open_url(Web, Interface_save_callback, Web);
++
++ if (bw->file_dialog_last_name !=3D NULL) g_free(bw->file_dialog_last=
+_name);
++ bw->file_dialog_last_name =3D g_strdup(name);
+}
+a_Url_free(url);
+=20
+@@ -1115,21 +1127,43 @@
+Web->flags |=3D WEB_Download;
+/* todo: keep track of this client */
+a_Cache_open_url(Web, Interface_save_callback, Web);
++
++ if (bw->file_dialog_last_name !=3D NULL) g_free(bw->file_dialog_last=
+_name);
++ bw->file_dialog_last_name =3D g_strdup(name);
+}
+=20
+gtk_widget_destroy(bw->save_link_dialog_window);
+}
+=20
+/*
+- * Scan Url and return a local-filename suggestion for saving
++ * Scan Url and return a local-filename suggestion for saving.
++ * The filename includes the directory last saved in, if any.
+*/
+-char *Interface_make_save_name(const DilloUrl *url)
++char *Interface_make_save_name(const DilloUrl *url, BrowserWindow *bw)
+{
+gchar *FileName;
+=20
+if (URL_PATH(url) && (FileName =3D strrchr(URL_PATH(url), '/')))
+- return g_strndup(++FileName, MIN(strlen(FileName), 64));
+- return g_strdup("");
++ FileName =3D g_strndup(++FileName, MIN(strlen(FileName), 64));
++ else
++ FileName =3D g_strdup("");
++ if (bw->file_dialog_last_name !=3D NULL) {
++ gchar *FilenameWithDir =3D NULL;=20
++ if (*FileName) {
++ gchar *dirpart =3D g_dirname(bw->file_dialog_last_name);
++ FilenameWithDir =3D
++ g_strconcat(dirpart,
++ G_DIR_SEPARATOR_S,
++ FileName,
++ NULL);
++ g_free(dirpart);
++ } else {
++ FilenameWithDir =3D g_strdup(bw->file_dialog_last_name);
++ }
++ g_free(FileName);
++ return FilenameWithDir;
++ } else=20
++ return FileName;
+}
+=20
+/*
+@@ -1147,7 +1181,7 @@
+(GtkSignalFunc) Interface_file_save_url, (void *)bw );
+}
+url =3D a_Url_new(gtk_entry_get_text(GTK_ENTRY(bw->location)), NULL, 0,=
+0);
+- SuggestedName =3D Interface_make_save_name(url);
++ SuggestedName =3D Interface_make_save_name(url, bw);
+gtk_file_selection_set_filename(
+GTK_FILE_SELECTION(bw->save_dialog_window), SuggestedName);
+g_free(SuggestedName);
+@@ -1174,7 +1208,7 @@
+(GtkSignalFunc) Interface_file_save_link,
+(void *)bw);
+}
+- SuggestedName =3D Interface_make_save_name(bw->menu_popup.info.url);
++ SuggestedName =3D Interface_make_save_name(bw->menu_popup.info.url, bw);
+gtk_file_selection_set_filename(
+GTK_FILE_SELECTION(bw->save_link_dialog_window), SuggestedName);
+g_free(SuggestedName);
+Index: browser.h
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+RCS file: /cvsroot/dillo/dillo/src/browser.h,v
+retrieving revision 1.22
+diff -u -b -B -r1.22 browser.h
+--- browser.h 2001/09/27 14:25:21 1.22
++++ browser.h 2001/10/01 20:50:52
+@@ -101,6 +101,8 @@
+gpointer question_dialog_data;
+GtkWidget *viewsource_window;
+=20
++ gchar *file_dialog_last_name;
++
+/* Dillo navigation stack (implemented with list.h) */
+DilloNav *nav_stack;
+gint nav_stack_size; /* [1 based] */
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+Re: [Dillo-dev]next encodings patch
+
+From: Jorge Arellano Cid <jcid@ne...> - 2001-10-01 20:43
+
+Grigory,
+[and everyone]
+
+> Hello.
+
+Hi!
+
+> I'm new in this list so don't kick me strongly.
+
+Hmmmm, what a shame we have come to expect that...
+
+Fortunately this mailing list has a long tradition of polite,
+technically skilled and cooperative email interchange, and we
+love it that way!
+
+Back in the old days when I was at the university, a memorable
+teacher told us that the toughest problem of gathering a working
+team of highly skilled to brilliant considered individuals was
+that those guy's egos were bigger than a whole cathedral, and
+that they would avoid cooperating with each other in the pursue
+of demonstrating that they were the best overall, and that they
+could undertake the whole task without the aid of anyone!
+
+He was right...
+
+I had come to observe that really brilliant or knowledgeable
+people (up to geniuses), don't behave that way. They know what
+they're worth, an thus doesn't have to demonstrate anything.
+
+Even more, the later ones are the most cooperative, encouraging
+and open to share their valuable knowledge, when it comes to help
+their colleagues to improve their skills.
+
+The excellent news is that being a genius is not a requirement
+for adopting that working spirit; and so we did!
+
+
+> I make a patch for force encodings selection.
+> I drop it here
+>
+> http://lambda.asplinux.udm.net/pub/dillo/dillo.encodings.patch
+
+OK.
+
+> It's based on japanise encodings patch but can help
+> all users who use nonlatin1 charsets (especialy this patch
+> help for all cyrillic readers with our charsets hell).
+> Patch use iconv and work with 'encodings' file that i
+> drop into ~/.dillo/ (like bookmarks.html).
+> File contain "Charset name" "iconv name" pairs in form
+> <enc value="ASCII">AscII</enc>
+> <enc value="KOI8-R">Cyrillic KOI8-R</enc>
+> <enc value="CP1251">Cyrillic CP1251</enc>
+> <enc value="IBM866">Cyrillic IBM866</enc>
+> <enc value="UTF-8">Unicode</enc>
+> etc...
+> As you can see this patch help me to view unicode and other charsets page.
+
+As described in the project notes (an as stated within all the
+suggested reading-material), this problem is far from easy to
+solve. BTW, the required framework will be available with
+GTK+2.0. In the mean time, I'll provide links to custom patches
+for specific languages, as long as they provide a home page that
+explains how to apply and enable the patch, as well as what they
+provide and what they break :).
+
+So take your time, and when you have a stable version of your
+code, just let me know, and I'll gladly add a link to it from the
+i18n section of the [Links] page.
+
+
+Regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-click, space/back
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 19:54
+
+On 01 Oct 2001, J=F6rgen Viksell wrote:
+
+> 2001-10-01 klockan 17.09 skrev Lars Clausen:
+>> Middle mouse click on the page should open whatever is in the clipboard.
+>> Anybody got a problem with that?
+>=20
+> The middle button (button 2) is already mapped to a scrolling function.
+
+Grumble. I can see some use for that, but it's limited to how far you can
+move the mouse before hitting the edge of the screen. I really like having
+middle mouse 'paste' the url in, that way url's found in text (inside our
+outside the browser) can be opened really quickly. We could consider a
+click with no movement to do paste, but that's rather fragile (what if your
+middle button is flaky? what if you scroll a little trying to paste?).
+Seems early to start making the mouse buttons configurable:)
+
+>> Space should scroll down, and probably Backspace scroll up.
+>=20
+> Yes please, I'm always pressing that damn spacebar... ;-)
+
+See previous patch:)
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-click, space/back
+
+From: Viksell <jorgen.viksell@te...> - 2001-10-01 19:48
+
+2001-10-01 klockan 17.09 skrev Lars Clausen:
+> Middle mouse click on the page should open whatever is in the clipboard.
+> Anybody got a problem with that?
+
+The middle button (button 2) is already mapped to a scrolling function.
+
+> Space should scroll down, and probably Backspace scroll up.
+
+Yes please, I'm always pressing that damn spacebar... ;-)
+
+J=F6rgen 
+
+
+
+[Dillo-dev]Image scaling aspect ratio?
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 17:51
+
+I had a page where an image was scaled by just setting the width. Most
+browsers preserve the aspect ratio when scaling it, but not Dillo. The
+HTML specs don't mention aspect ratio at all. Should we categorize this
+under 'broken HTML', or should we keep the aspect ratio when only one of
+width and height is specified?
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]patch hell
+
+From: Grigory Bakunov <black@as...> - 2001-10-01 17:44
+
+Hello.
+I look at this list and one thing born in my head.
+What bout ONE place to hold ALL patches for dillo ?
+I can make it if nobody other want to do it.
+Or we just can use sourceforge patches tracker -
+gods or mantainers ! please activate pathes tracker on sourceforge for dillo!
+And thanks for great browser. realy.
+
+___________________________________________________________________
+Truly yours, Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]Patch: Space and backspace scrolls page
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 17:33
+
+This patch adds space and backspace scrolling the page.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile /tmp/dillo-patch2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+diff -rubB dillo-orig/src/dw_gtk_scrolled_frame.c dillo/src/dw_gtk_scrolled=
+_frame.c
+--- dillo-orig/src/dw_gtk_scrolled_frame.c Thu Jul 19 20:35:52 2001
++++ dillo/src/dw_gtk_scrolled_frame.c Mon Oct 1 12:27:53 2001
+@@ -475,6 +475,7 @@
+else
+return gtk_container_focus (container, GTK_DIR_TAB_FORWARD);
+=20
++ case GDK_BackSpace:
+case GDK_Page_Up:
+if (event->state & GDK_CONTROL_MASK)
+Dw_gtk_scrolled_frame_move_by(frame,
+@@ -484,6 +485,7 @@
+- frame->vadjustment->page_increment=
+);
+return TRUE;
+=20
++ case GDK_space:
+case GDK_Page_Down:
+if (event->state & GDK_CONTROL_MASK)
+Dw_gtk_scrolled_frame_move_by(frame,
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-click, space/back
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 17:23
+
+On Mon, 1 Oct 2001, drax@wh... wrote:
+
+> Sounds great! One thing i'd like is to ahve the progress thing down on
+> the status bar, stretched out long instead of in a block, and to take the
+> address bar off of the menubar! Then dillos interface would fit my taste
+> much better.
+>=20
+> Maybe i'll looki into doing one of those myself...
+>=20
+> DraX
+>=20
+>=20
+> On 1 Oct 2001, Lars Clausen wrote:
+>=20
+>>=20
+>> The bugtrack system seems to be broken ATM. I'm starting to look at a
+>> bunch of minor useability features that I miss in Dillo from other
+>> browsers:
+>>=20
+>> History menus on back/forward buttons (a la Galeon): Need to brush up on
+>> events and menu creation.
+>>=20
+>> Page scroll size is 1/2 page, I prefer a full page. This setting goes
+>> into preferences. I tried setting adjustments in
+>> Dw_gtk_scrolled_frame_set_scroll_adjustments, but it doesn't seem to be
+>> called. Where should I go to reliably set
+>> [hv]adjustment->page_increment?
+
+Ok, here be the patch for scroll_increment. Please let me know if it is
+not up to coding standards.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile /tmp/dillo-patch1=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+diff -rubB dillo-orig/src/dw_gtk_viewport.c dillo/src/dw_gtk_viewport.c
+--- dillo-orig/src/dw_gtk_viewport.c Thu Jul 19 20:35:52 2001
++++ dillo/src/dw_gtk_viewport.c Mon Oct 1 12:20:57 2001
+@@ -12,6 +12,7 @@
+#include <gtk/gtk.h>
+#include "dw_gtk_viewport.h"
+#include "dw_container.h"
++#include "prefs.h"
+=20
+#include "debug.h"
+=20
+@@ -424,6 +425,9 @@
+static void Dw_gtk_viewport_adj_changed (GtkAdjustment *adj,
+GtkDwViewport *viewport)
+{
++ if (prefs.scroll_increment !=3D 0.0)
++ adj->page_increment =3D adj->page_size*prefs.scroll_increment;
++
+Dw_gtk_viewport_mouse_event (GTK_WIDGET (viewport),
+viewport->mouse_x, viewport->mouse_y, NULL=
+);
+}
+diff -rubB dillo-orig/src/prefs.c dillo/src/prefs.c
+--- dillo-orig/src/prefs.c Thu Sep 20 16:14:47 2001
++++ dillo/src/prefs.c Mon Oct 1 11:05:18 2001
+@@ -49,7 +49,8 @@
+{ "panel_size", DRC_TOKEN_PANEL_SIZE },
+{ "small_icons", DRC_TOKEN_SMALL_ICONS },
+{ "limit_text_width", DRC_TOKEN_LIMIT_TEXT_WIDTH },
+- { "font_factor", DRC_TOKEN_FONT_FACTOR }
++ { "font_factor", DRC_TOKEN_FONT_FACTOR },
++ { "scroll_increment", DRC_TOKEN_SCROLL_INCREMENT }
+};
+=20
+static const guint n_symbols =3D sizeof (symbols) / sizeof (symbols[0]);
+@@ -144,6 +145,9 @@
+case DRC_TOKEN_LIMIT_TEXT_WIDTH:
+prefs.limit_text_width =3D (strcmp(scanner->value.v_string, "YES") =
+=3D=3D 0);
+break;
++ case DRC_TOKEN_SCROLL_INCREMENT:
++ prefs.scroll_increment =3D strtod(scanner->value.v_string, NULL);
++ break;
+default:
+break; /* Not reached */
+}
+diff -rubB dillo-orig/src/prefs.h dillo/src/prefs.h
+--- dillo-orig/src/prefs.h Wed Jun 27 08:27:02 2001
++++ dillo/src/prefs.h Mon Oct 1 11:04:32 2001
+@@ -41,6 +41,7 @@
+DRC_TOKEN_FONT_FACTOR,
+DRC_TOKEN_SHOW_ALT,
+DRC_TOKEN_LIMIT_TEXT_WIDTH,
++ DRC_TOKEN_SCROLL_INCREMENT,
+DRC_TOKEN_LAST
+} Dillo_Rc_TokenType;
+=20
+@@ -64,6 +65,7 @@
+gboolean small_icons;
+gboolean limit_text_width;
+gdouble font_factor;
++ gdouble scroll_increment;
+};
+=20
+/* Global Data */
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+Re: [Dillo-dev]Pending projects: History, scroll size, middle-click, space/back
+
+From: DraX <drax@wh...> - 2001-10-01 17:17
+
+Sounds great! One thing i'd like is to ahve the progress thing down on the
+status bar, stretched out long instead of in a block, and to take the
+address bar off of the menubar! Then dillos interface would fit my taste
+much better.
+
+Maybe i'll looki into doing one of those myself...
+
+DraX
+
+
+On 1 Oct 2001, Lars Clausen wrote:
+
+>=20
+> The bugtrack system seems to be broken ATM. I'm starting to look at a
+> bunch of minor useability features that I miss in Dillo from other
+> browsers:
+>=20
+> History menus on back/forward buttons (a la Galeon): Need to brush up on
+> events and menu creation.
+>=20
+> Page scroll size is 1/2 page, I prefer a full page. This setting goes in=
+to
+> preferences. I tried setting adjustments in
+> Dw_gtk_scrolled_frame_set_scroll_adjustments, but it doesn't seem to be
+> called. Where should I go to reliably set [hv]adjustment->page_increment=
+?=20
+>=20
+> Middle mouse click on the page should open whatever is in the clipboard.
+> Anybody got a problem with that?
+>=20
+> Space should scroll down, and probably Backspace scroll up. Some browser=
+s
+> have Backspace go to previous page, but I don't like that. Any comments?
+>=20
+> -Lars
+>=20
+> --=20
+> Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+> "I do not agree with a word that you say, but I |----------------------=
+------
+> will defend to the death your right to say it." | Where are we going, a=
+nd
+> --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket?
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>=20 
+
+
+
+[Dillo-dev]Pending projects: History, scroll size, middle-click, space/back
+
+From: Lars Clausen <lrclause@cs...> - 2001-10-01 17:09
+
+The bugtrack system seems to be broken ATM. I'm starting to look at a
+bunch of minor useability features that I miss in Dillo from other
+browsers:
+
+History menus on back/forward buttons (a la Galeon): Need to brush up on
+events and menu creation.
+
+Page scroll size is 1/2 page, I prefer a full page. This setting goes into
+preferences. I tried setting adjustments in
+Dw_gtk_scrolled_frame_set_scroll_adjustments, but it doesn't seem to be
+called. Where should I go to reliably set [hv]adjustment->page_increment?=
+=20
+
+Middle mouse click on the page should open whatever is in the clipboard.
+Anybody got a problem with that?
+
+Space should scroll down, and probably Backspace scroll up. Some browsers
+have Backspace go to previous page, but I don't like that. Any comments?
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
diff --git a/old/oldmail/200111.txt b/old/oldmail/200111.txt
new file mode 100644
index 0000000..99b9277
--- /dev/null
+++ b/old/oldmail/200111.txt
@@ -0,0 +1,3639 @@
+Re: [Dillo-dev]checking cache data with HEAD
+
+From: Miklos Magyari <miklos.magyari@et...> - 2001-11-29 15:15
+
+hi,
+
+> I would love to see this fixed, but worry slightly if this will slow
+> down Dillo overall because we'd need to contact the server every time,
+> which seems to take the most time.
+
+this delay is the reason why I suggested having a config directive to
+turn this on/off. 
+Of course, it would be theoretically possible to maintain a list of
+sites that should always check for updates and the rest shouldn't, but
+this seems to be over-complicated for me and doesn't fit in dillo's
+design goals.
+
+Miki 
+
+
+
+Re: [Dillo-dev]checking cache data with HEAD
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-29 15:03
+
+On Thu, 29 Nov 2001, Miklos Magyari wrote:
+
+> hi guys,
+>=20
+> I took a quick look in the docs and the source, and it _seems_ that
+> dillo doesn't check for updates for a cached object automatically. Is
+> there any reason for it, or just simply not implemented yet?
+> I suggest at least having a new directive in dillorc for cache
+> behaviour. If the user wants to always check if the cache is up-to-date,
+> we should use http's HEAD method to compare the cached and actual
+> timestamp of an object. I would be happy to make some effort
+> implementing this feature if you like the idea.
+
+I agree a lot! Any kind of news page (slashdot, The Register, Bulletin
+Boards) suffer from lack of updates, I have to manually reload them all the
+time. I would love to see this fixed, but worry slightly if this will slow
+down Dillo overall because we'd need to contact the server every time,
+which seems to take the most time.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]checking cache data with HEAD
+
+From: Miklos Magyari <miklos.magyari@et...> - 2001-11-29 14:35
+
+> we should use http's HEAD method to compare the cached and actual
+> timestamp of an object.
+or, alternatively (what I forgot to mention) we could use conditional
+GET with If-Modified-Since directive in the request header.
+
+cheers,
+Miki 
+
+
+
+[Dillo-dev]checking cache data with HEAD
+
+From: Miklos Magyari <miklos.magyari@et...> - 2001-11-29 09:16
+
+hi guys,
+
+I took a quick look in the docs and the source, and it _seems_ that
+dillo doesn't check for updates for a cached object automatically. Is
+there any reason for it, or just simply not implemented yet?
+I suggest at least having a new directive in dillorc for cache
+behaviour. If the user wants to always check if the cache is up-to-date,
+we should use http's HEAD method to compare the cached and actual
+timestamp of an object. I would be happy to make some effort
+implementing this feature if you like the idea.
+
+cheers,
+Miki 
+
+
+
+[Dillo-dev]Link to Japanese support patch seems to be down.
+
+From: <jserv.bbs@go...> - 2001-11-28 09:09
+
+Hi, all:
+
+While I attempted to consult the [Japanese support patch] in the section
+of [i18n & l10n] in Dillo Links page (http://dillo.so....net/Links.html)
+, I found that the link http://www.ee.ed.ac.uk/~rjt/dillo/japanese.html could
+not be reachable.
+
+I am a user form Taiwan and about to make efforts to Chinese support for
+Dillo. So I hope to refer the Japanese support patch in advance.
+
+Does anyone knows the link or give me that patch? Thanks.
+
+Regards,
+Jim Huang
+--
+¡° Origin: ¦¨¥\¤j¾Ç¸ê°T¤uµ{¾Ç¨t[¾K¸ê¤ßBBS] <goodguy.csie.ncku.edu.tw> 
+¡» From: ccns.ncku.edu.tw 
+
+
+
+[Dillo-dev][patch] Let Dillo display Traditional Chinese pages.
+
+From: <jserv.bbs@go...> - 2001-11-28 08:32
+
+Hi, all:
+
+I am a new user to Dillo Web Browser from Taiwan. I found it really
+nice for searching or browser. However, I also noticed that Dillo couldn't
+display Chinese Web page well, resulting from the fact that Dillo is not
+built in the manner of i18n programming paradigm.
+
+So, I did a patch to Dillo to let Dillo support Traditional Chinese
+(the language used widely in Taiwan) display and its encoding, Big-5.
+As follows:
+
+in src/dw_style.c:
+
+static void Dw_style_font_realize (DwStyleFont *font, gboolean try_all)
+{
+char fontname[256], *ItalicChar;
+
+ItalicChar = prefs.use_oblique ? "o" : "i";
+sprintf (fontname,
+"-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1",
+font->name,
+font->bold ? "bold" : "medium",
+font->italic ? ItalicChar : "r",
+font->size);
+++ strcat (fontname,
+++ ",-arphic technology co.-ar pl mingti2l big5"
+++ "-medium-r-normal-*-*-160-*-*-c-*-big5-0");
+-- font->font = gdk_font_load(fontname);
+++ font->font = gdk_fontset_load(fontname);
+
+Here, I suppose that Taiwan Linux users all have "ar pl mingti2l big5"
+font provided by Arphic Technology. It seems to be stupid but it works
+like this:
+
+http://ccns.ncku.edu.tw/~jimchyun/misc/dillo-big5.jpg
+
+Regards,
+Jim Huang
+--
+¡° Origin: ¦¨¥\¤j¾Ç¸ê°T¤uµ{¾Ç¨t[¾K¸ê¤ßBBS] <goodguy.csie.ncku.edu.tw> 
+¡» From: ccns.ncku.edu.tw 
+
+
+
+[Dillo-dev]Here's a URL parsing hack...
+
+From: Paul Chamberlain <tif@ti...> - 2001-11-28 03:44
+
+Attachments: url.diff      
+
+I grew tired of the javascript links that didn't work
+even though it was obvious to me that there was a URL
+embedded in that javascript. I hacked the url parser
+so that it looks for an embedded " if all else
+fails. At the very least this fixes a bunch of the
+links when I view news.yahoo.com.
+
+It's okay to post hacks here, right?
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]Javascript ?
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-28 01:18
+
+> Currently I'm concerned with rfc2396 (details at bug-track), and 
+> there're still some patches waiting to be merged before releasing
+> dillo-0.6.3.
+> 
+
+Please say one is the cookies patch? (Dillo with cookies is pretty much feature complete for me, just add the ability to upload files and I will be the happiest man alive).
+
+> The plan is to restart working the simple-plugins after 0.6.3
+> release.
+> 
+> Note that this scheme is far from what's commonly known as a
+> plugin. It's more close to a fast-cgi interface than a dlopen
+> handled module.
+
+Why not use libguile? It is the official extension language of the 
+GNU Project, and would allow fast plugin development. Best part is 
+that you can load C code from it with (load-extension "libfoo" 
+init_function) (the .so and version stuff is added automatically). 
+This is only in unstable guile from CVS though (which is _much_ 
+improved over 1.4). So, people could write their plugins in C if they 
+wanted and simply load it into scheme and attach it to dillo, or they 
+could write the plugin entirely in scheme (or some combination of the 
+two). There is the problem of added memory used by guile though (last 
+time I checked guile used something like 8MB of vm, with about 2MB 
+resident at any time). 
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]Javascript ?
+
+From: mallum <breakfast@10...> - 2001-11-27 16:24
+
+on Tue, Nov 27, 2001 at 08:52:18AM -0300, Jorge Arellano Cid wrote:
+> 
+> Note that this scheme is far from what's commonly known as a
+> plugin. It's more close to a fast-cgi interface than a dlopen
+> handled module.
+> 
+cool. Im guessing this would make it possible to write / prototype
+plugins in languages like Python or Perl ?
+
+-- mallum 
+
+
+
+Re: [Dillo-dev]Javascript ?
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-27 11:55
+
+Hi,
+
+> > Song Yun Zhao <song.zhao@tu...> schrieb am 27.11.01:
+> > Just wondering if Dillo has Javascript support?
+> > If not, how feasible would it be to add it?
+> I does not have JS support and as far as I am concerned
+> I'd be more than glad to keep it out of dillo - or at
+> least to keep it in a way that I can block out the code
+> with a '--disable-javascript' while configuring.
+
+My feelings exactly!
+Javascript is out of the plans.
+
+> Eventually there is an effort to include such features
+> with the planned plugin architecture.
+
+Not Javascript, just other features.
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Javascript ?
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-27 11:55
+
+Hi,
+
+> on Tue, Nov 27, 2001 at 09:35:29AM +0100, Bjoern Weber wrote:
+>
+> > Eventually there is an effort to include such features
+> > with the planned plugin architecture.
+> >
+>
+> May I enquire on what the current state of the plugin architecture is
+> ? Hows it fare on the list of priority's ?
+
+Sure.
+
+Currently I'm concerned with rfc2396 (details at bug-track),
+and there're still some patches waiting to be merged before
+releasing dillo-0.6.3.
+
+Also there's the whole subject of source forge and whether or
+not moving away...
+
+The plan is to restart working the simple-plugins after 0.6.3
+release.
+
+Note that this scheme is far from what's commonly known as a
+plugin. It's more close to a fast-cgi interface than a dlopen
+handled module.
+
+
+Greetings
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Javascript ?
+
+From: mallum <breakfast@10...> - 2001-11-27 11:16
+
+on Tue, Nov 27, 2001 at 09:35:29AM +0100, Bjoern Weber wrote:
+
+> Eventually there is an effort to include such features
+> with the planned plugin architecture.
+> 
+
+May I enquire on what the current state of the plugin architecture is
+? Hows it fare on the list of priority's ?
+
+-- mallum 
+
+
+
+[Dillo-dev]dillo on QNX
+
+From: Bjoern Weber <foxbow@we...> - 2001-11-27 08:37
+
+Good morning,
+
+as I wrote before, I'm testing out dillo on the QNX RTP 6.1
+and so far as I'm concerned it runs smooth, yet not as stable
+as on other platforms. I'm just wondering if anyone else out
+there is interested in running dillo on that platform or has
+been testing it so we can corporate our efforts to mark out
+the last flaws.
+
+Greetings,
+Bjoern
+--=20
+Sometimes, even at infinity, the largest distance
+can be much too close...
+=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
+=5F=5F=5F=5F
+Geben Sie Ihren Lottotipp gerne auf den letzten Dr=FCcker ab=3FBeim WEB.DE
+Lottoservice gibt's keine Warteschlangen. http://tippen2.web.de/=3Fx=3D9 
+
+
+
+Re: [Dillo-dev]Javascript ?
+
+From: Bjoern Weber <foxbow@we...> - 2001-11-27 08:35
+
+> Song Yun Zhao <song.zhao@tu...> schrieb am 27.11.01:
+> Just wondering if Dillo has Javascript support=3F
+> If not, how feasible would it be to add it=3F
+I does not have JS support and as far as I am concerned
+I'd be more than glad to keep it out of dillo - or at=20
+least to keep it in a way that I can block out the code
+with a '--disable-javascript' while configuring.
+Eventually there is an effort to include such features
+with the planned plugin architecture.
+
+Greetings,
+Bjoern
+
+--=20
+Sometimes, even at infinity, the largest distance
+can be much too close...
+=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
+Berufsunf=E4higskeitversicherung von Mamax bei WEB.DE.=20
+Jetzt informieren! http://bu.web.de 
+
+
+
+[Dillo-dev]Javascript ?
+
+From: Song Yun Zhao <song.zhao@tu...> - 2001-11-26 23:49
+
+Hi, 
+
+Just wondering if Dillo has Javascript support?
+If not, how feasible would it be to add it?
+
+thanks 
+
+
+
+Re: [Dillo-dev]list items (was: Dillo Freezing)
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-26 15:44
+
+On Wed, Nov 21, 2001 at 11:18:48PM +0100, Hugo Hallqvist wrote:
+> On Wed, 21 Nov 2001 19:41:00 +0100
+> Sebastian Geerken <sgeerken@st...> wrote:
+> 
+> > Hi,
+> > 
+> > the freeze bugfix also solved the problems I had with list items, now
+> > list items are special DwPage's. There will be some enhances, probably
+> > within a new widget DwListItem.
+> 
+> After a little more browsing. I noticed pages with numbered lists are not incremented correctly.
+> Look for example: http://www.blocket.se
+
+Fixed.
+
+Sebastian 
+
+
+
+Re: Re: [Dillo-dev]Cookies for dessert.. : )
+
+From: Paul Chamberlain <tif@ti...> - 2001-11-26 15:41
+
+Lars Clausen wrote:
+> > What kind of mechanism will the end user have to accept/deny cookies ? 
+> I've been thinking about how to do a good dialog to ask the user. I'm
+> leaning towards a standalone program that works on the cookie control
+> file. That way, Dillo isn't bloated with that interface, and those who
+> just want to use the file for control can do that.
+
+*delurking*
+
+I have also thought about using standalone programs to keep dillo
+from getting bloated while adding features. I thought that it could
+be done by implementing a "local CGI" feature, then writing CGI-like
+programs that output HTML forms and modify a user's local config files.
+It seems entirely reasonable to me to implement the entire "Preferences"
+UI in HTML this way.
+
+There are some drawbacks. You'd want to implement some security
+around this so mischevious remote web-pages couldn't try to launch
+local commands. Doing this means multiple executables, perhaps
+even multiple languages.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]tag parsing.
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-26 00:19
+
+> On Sun, 25 Nov 2001, Hugo Hallqvist wrote:
+> 
+> > Is this valid html? I saw a link on linuxtoday.com today that had
+> > one of these in it. and it showed up unparsed. < a
+> > href=">mirrors.kernel.org</a>
+> 
+> While the HTML specs don't give a formal parsing rule for tags, I
+> doubt very much that it's correct. Unfortunately, the specs are in
+> the SGML specs, which seems to cost money to look at.
+
+I don't think that SGML cares about whitespace in tags...that 
+probably should be valid html. I think that the XML standard says 
+something about this (white space not mattering, making that valid), 
+and since every valid xml document is a valid sgml document, that 
+would mean that dillo isn't parsing correctly. I'll go and look it up 
+in the standard now...(I wish I still had my annonated standard)...I 
+can't find anything that explicitly says that is wrong, but I 
+attempted to validated a document that uses that and I got this 
+error:
+
+< a href=">mirrors.kernel.org</a>.
+
+Error: end tag for element "A" which is not open; try removing the 
+end tag or check for improper nesting of elements 
+
+So, that is improper html. Linuxtoday is at fault.
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]tag parsing.
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-25 22:58
+
+On Sun, 25 Nov 2001, Hugo Hallqvist wrote:
+
+> Is this valid html? I saw a link on linuxtoday.com today that had one of
+> these in it. and it showed up unparsed. < a
+> href=3D">mirrors.kernel.org</a>
+
+While the HTML specs don't give a formal parsing rule for tags, I doubt
+very much that it's correct. Unfortunately, the specs are in the SGML
+specs, which seems to cost money to look at.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]tag parsing.
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-11-25 21:29
+
+Is this valid html? 
+I saw a link on linuxtoday.com today that had one of these in it. and it showed up unparsed.
+< a href=">mirrors.kernel.org</a>
+
+
+-- 
+//Hugo Hallqvist - hugha495 at student dot liu dot se 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-23 17:48
+
+> What do we need to move (or distribute) dillo?
+> 
+> * Download bandwidth and accurate counters
+> * mailing list (searchable and browseable)
+> * CVS
+> * Web site with a CGI enable-policy that lasts!
+> * ssh shell account for Web site administration.
+> 
+> 
+> Savannah's future looks promising, but it doesn't seem to
+> provide now what we need. Anyway, if they have (at least):
+> 
+> * Web site with a CGI enable-policy that lasts!
+> * ssh shell account for Web site administration.
+> 
+> I'd go there, and also set:
+> 
+> * mailing list (if searchable and browseable)
+> 
+> Probably downloads can be located elsewhere cause they only
+> provide http downloads from a directory, but no stats AFAIK.
+> 
+> CVS can be set within the same machine as downloads or in
+> Savannah. I'm not sure which is better. Savannah has viewCVS and
+> that's a plus, but having downloads and CVS at the same domain
+> seems like a good distribution policy...
+> 
+> Comments, suggestions, offerings etc, are very welcomed.
+> 
+> Ah, if we finally decide to move, it'd be great to release
+> 0.6.3 from the new site, probably with Livio's new design.
+> 
+> I'd go as stated, with CVS and downloads maintained by the
+> Debian-br crew!
+
+In a few months, I am planning to start a small online company (music 
+store that only carries non-copy protected cds). If all goes well, I 
+should have a server colocated somewhere before February or 
+March...it will have plenty of spare bandwidth and disk space, so 
+when I get it set up (filing incorporation papers, getting the other 
+people in in to purchase their shares, then setting up the server and 
+installing my code on it, and finally getting the first set of CDs), 
+dillo can go there if you want. I plan for the server to be a mid-
+range 1U p3 box with about 256MB of ram and a nice 40GB hard drive, 
+all running Debian.
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-23 16:44
+
+Gentlemen,
+
+
+On Mon, 12 Nov 2001, Livio Baldini Soares wrote:
+
+> Unfortunately I feel compelled to bring out a question that might cause
+> polemic. Some of you may know that VA (Linux) is changing their "ways" and
+> becoming more and more comercial. (BTW, VA Linux is the owner of sourceforge).
+> And I've recently learnt that sourforge is now using non-free software :-(
+> Before reading on, maybe you should read this article (highly recommended):
+>
+> http://www.fsfeurope.org/news/article2001-10-20-01.en.html
+
+and also:
+
+http://www.advogato.org/article/376.html
+http://slashdot.org/developers/01/11/12/1456219.shtml
+
+
+
+After careful consideration of these references, previous posts
+on this thread and from my personal experiences, I've come to
+think that unfortunately there're underhanded politics coming
+from VA.
+
+This is hard to write, specially when I'm both aware and
+grateful for all that VA has given to the Open Source & Free SW
+community. OTOH, I can't overlook the following points:
+
+* After months of license discussion, Loic was asked to give up
+his rights on contributions to the SF codebase (that were given
+under the GPL, and expected to remain as such), but later,
+without any previous warning, it was made propietary to VA.
+
+* The SF codebase that's still free is about a year old and
+in an unmaintainable state. Considering that, in conjunction with
+the time it took for Loic to sign the final document (while
+discussing it), the hypothesis of it all being planned seems a
+very plausible one.
+
+* Once on their server, you don't own the project. It can't be
+deleted, and the only way around is to tag it "unmaintained".
+This is kind of insidious! It makes people think the project is
+stalled without developers, that the last release is in SF and
+that there's no need to look for it elsewhere...
+
+* Facilities for exporting projects were "temporarily" removed.
+
+* SF is using propietary SW. There's no problem if there's a
+need, but being artificial, it gives the impression that Free-SW
+is not good enough for the task.
+
+* You're still free to use the SF server, but you won't have
+the freedom to copy, modify, study and distribute the SW it runs.
+
+* Technical issue: Download counters, although being essential
+information (both for a project and SF), are not working properly
+since months (maybe more than five). It's bug 440446 in SF's bug
+track. It was posted after a previous fix of the counters, that
+were reported to even go backwards sometimes.
+
+
+
+About dillo
+-----------
+
+I have no problems with moving dillo, even more, if that serves
+to solve the download counter and the mailing list problems, it's
+very welcome!
+
+Note: mailing lists at SF are unmaintained by now, as they're
+working on a new solution... With regard to dillo, dillo-dev was
+created by James McCollough, he's the maintainer, but all my
+attempts to reach him by email had failed :(. Thus, since mailman
+SW started asking for an admin password, I haven't access to the
+susbscribers list. SF doesn't provide a way to change this, and
+my support requests remain unanswered...
+
+
+What do we need to move (or distribute) dillo?
+
+* Download bandwidth and accurate counters
+* mailing list (searchable and browseable)
+* CVS
+* Web site with a CGI enable-policy that lasts!
+* ssh shell account for Web site administration.
+
+
+Savannah's future looks promising, but it doesn't seem to
+provide now what we need. Anyway, if they have (at least):
+
+* Web site with a CGI enable-policy that lasts!
+* ssh shell account for Web site administration.
+
+I'd go there, and also set:
+
+* mailing list (if searchable and browseable)
+
+Probably downloads can be located elsewhere cause they only
+provide http downloads from a directory, but no stats AFAIK.
+
+CVS can be set within the same machine as downloads or in
+Savannah. I'm not sure which is better. Savannah has viewCVS and
+that's a plus, but having downloads and CVS at the same domain
+seems like a good distribution policy...
+
+Comments, suggestions, offerings etc, are very welcomed.
+
+Ah, if we finally decide to move, it'd be great to release
+0.6.3 from the new site, probably with Livio's new design.
+
+I'd go as stated, with CVS and downloads maintained by the
+Debian-br crew!
+
+
+Regards
+Jorge. 
+
+
+
+Re: [Dillo-dev]"&nbsp" problem
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-23 15:51
+
+> Hello,
+> 
+> first of all I have to say thanks for your work. The Dillo is
+> absolutely super. Maybe I found small problem, which I believe is not
+> difficult to fix. The problem is with &nbsp. When I used "&nbsp" in my
+> page I expected to see empty space but I saw string "&nbsp" instead. I
+> tried it in Netscape and Mozilla and there is behavior proper (one
+> empty space). Bellow is simple code demonstrating this. Can somebody
+> fix it, or give me clue which part of source I can fix it myself.
+> 
+
+Entities must start with & and end with ;, I believe the proper 
+behavior is to take the entire page after that as an entity and not 
+display anything. So, just add a ; after nbsp (&nbsp;) and it will 
+work.
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]"&nbsp" problem
+
+From: Grigory Bakunov <black@as...> - 2001-11-23 08:41
+
+Date |Fri, 23 Nov 2001 09:25:58 +0100
+From |Vaclav Tvrdik <Vaclav.Tvrdik@ip...>
+
+Hello!
+
+
+VT> Hello,
+
+VT> first of all I have to say thanks for your work. The Dillo is absolutely
+VT> super. Maybe I found small problem, which I believe is not difficult to fix.
+VT> The problem is with &nbsp. When I used "&nbsp" in my page I expected to see
+VT> empty space but I saw string "&nbsp" instead. I tried it in Netscape and
+VT> Mozilla and there is behavior proper (one empty space). Bellow is simple
+VT> code demonstrating this. Can somebody fix it, or give me clue which part of
+VT> source I can fix it myself.
+
+VT> Thank you and best regards
+
+VT> Vaclav TVRDIK
+VT> PGP Key : 0xA983E45F
+
+VT> file : test.html
+
+VT> <HTML>
+VT> <HEAD><TITLE>test</TITLE></HEAD>
+VT> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"
+ALINK="#000080">>
+VT> <TABLE BORDER=1>
+VT> <TR><TD BGCOLOR=red>test of nbsp</TD><TD BGCOLOR=blue>&nbsp</TD></TR>
+VT> </TABLE>
+VT> </BODY>
+VT> </HTML>
+
+
+HUH.
+AFAIK for use entities you need to correct this &nbsp to
+&nbsp; - how it sow in http://www.w3.org
+
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]"&nbsp" problem
+
+From: Bo Lorentsen <bl@ne...> - 2001-11-23 08:37
+
+Vaclav Tvrdik wrote:
+
+> first of all I have to say thanks for your work. The Dillo is absolutely
+> super. Maybe I found small problem, which I believe is not difficult to fix.
+> The problem is with &nbsp. When I used "&nbsp" in my page I expected to see
+> empty space but I saw string "&nbsp" instead. I tried it in Netscape and
+> Mozilla and there is behavior proper (one empty space). Bellow is simple
+> code demonstrating this. Can somebody fix it, or give me clue which part of
+> source I can fix it myself.
+
+I think it would be a good idea to terminate the "&nbsp" with a simicolon, like
+this "&nbsp;".
+
+Hope this help !
+
+/BL 
+
+
+
+[Dillo-dev]"&nbsp" problem
+
+From: Vaclav Tvrdik <Vaclav.Tvrdik@ip...> - 2001-11-23 08:23
+
+Hello,
+
+first of all I have to say thanks for your work. The Dillo is absolutely
+super. Maybe I found small problem, which I believe is not difficult to fix.
+The problem is with &nbsp. When I used "&nbsp" in my page I expected to see
+empty space but I saw string "&nbsp" instead. I tried it in Netscape and
+Mozilla and there is behavior proper (one empty space). Bellow is simple
+code demonstrating this. Can somebody fix it, or give me clue which part of
+source I can fix it myself.
+
+Thank you and best regards
+
+Vaclav TVRDIK
+PGP Key : 0xA983E45F
+
+file : test.html
+
+<HTML>
+<HEAD><TITLE>test</TITLE></HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"
+ALINK="#000080">
+<TABLE BORDER=1>
+<TR><TD BGCOLOR=red>test of nbsp</TD><TD BGCOLOR=blue>&nbsp</TD></TR>
+</TABLE>
+</BODY>
+</HTML> 
+
+
+
+Re: [Dillo-dev]Cookies for dessert.. : )
+
+From: William Kendrick <nbs@so...> - 2001-11-22 23:23
+
+On Thu, Nov 22, 2001 at 04:26:57PM -0600, Lars Clausen wrote:
+<snip> 
+> I've been thinking about how to do a good dialog to ask the user. I'm
+> leaning towards a standalone program that works on the cookie control
+> file.
+
+Excellent. :)
+
+-bill! 
+
+
+
+Re: [Dillo-dev]Cookies for dessert.. : )
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-22 22:27
+
+On Wed, 21 Nov 2001, hebertrich@ya... wrote:
+
+> Gentlemen ...=20
+>=20
+> What kind of mechanism will the end user have to accept/deny cookies ?=20
+
+Currently, there is a text file that controls cookies. It will allow or
+deny or allow non-persistently cookies from a given domain, plus allow a
+default setting.
+
+> What kind of built i protection will Dillo have to help the surfer
+> do it's thing while at the same time reject what is obviously cookies
+> containing personally identifiable numbers or info ?=20
+> In fact is such protection feasible ?
+
+In my opinion, not really. Very few cookies will contain the information
+themselves, all they need is an identifying number that will let them look
+into the database. There's no standard for the contents of cookies
+whatsoever. Many are also 'encrypted'. All we can say is where they are
+from, how long they will last, and who will be able to get them.
+
+> Will there be for example cookies off=20
+> cookies on ( accept all) ask user
+> accept/deny for domains... ( lil window with
+> a list ? ) third party cookies on ( accept
+> all ) ask user display cookies ( scroll list
+> ,click and view the cookie ) <keep> <delete>
+> cookie warning ( ex this cookie is
+> illegal...shows user name / password ..
+
+I've been thinking about how to do a good dialog to ask the user. I'm
+leaning towards a standalone program that works on the cookie control
+file. That way, Dillo isn't bloated with that interface, and those who
+just want to use the file for control can do that.
+
+One of the few places where I need cookies is the Dagorhir bulletin board
+(www.dagorhir.com/dagorhir/infoboard). Its cookies contain the username
+and password in cleartext, but it's not an important password, so it's ok.
+Most places that have important passwords will either use https or just
+have an identifying cookie. Trying to figure out the 'legality' of the
+cookie (beyond standards conformance) is IMHO futile.
+
+> I guess what i want to say is try to do your best, like usual : )=
+=20
+>=20
+> Can automatic protection be made to look into the cookie for obvious=20
+> UIN or other privacy issues ?=20
+
+As explained above, not really. The big privacy issues aren't in the
+contents of the cookie, but in how it's used.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Font size problem with locales, and null char in text files
+
+From: Niklas Hoglund <niklas.hoglund@te...> - 2001-11-21 21:27
+
+I'm experiencing two bugs in Dillo 0.6.2. Firstly, if I have my
+default locale setting, LC_ALL=sv_SE, Dillo ignores the font_factor
+setting and displays tiny fonts. With LC_ALL=C it works OK.
+
+Secondly, and this is more an irritating thing than a bug, when
+displaying for example the changelog on Dillo's homepage every line
+begins with a null character (the one used when the font lacks some
+character). This only happens on text displayed with the fixed-width
+font.
+
+If it matters any, I use the Debian package of Dillo.
+
+Except for that, you have my kudos for making a nice little program.
+
+-- 
+Niklas 
+
+
+
+[Dillo-dev]Cookies for dessert.. : )
+
+From: Richard <hebertrich@ya...> - 2001-11-21 20:35
+
+Gentlemen ... 
+
+What kind of mechanism will the end user have to accept/deny cookies ? 
+
+What kind of built i protection will Dillo have to help the surfer
+do it's thing while at the same time reject what is obviously cookies
+containing personally identifiable numbers or info ? 
+In fact is such protection feasible ?
+Will there be for example cookies off 
+cookies on ( accept all) ask user 
+accept/deny for domains... ( lil window with a list ? ) 
+third party cookies on ( accept all ) ask user 
+display cookies ( scroll list ,click and view the cookie ) 
+<keep> <delete>
+cookie warning ( ex this cookie is illegal...shows user name / password .. 
+
+I guess what i want to say is try to do your best, like usual : ) 
+
+Can automatic protection be made to look into the cookie for obvious 
+UIN or other privacy issues ? 
+
+Richard Hebert 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+On 20 Nov 2001 19:33:35 -0600
+Lars Clausen <lrclause@cs.uiuc.edu> wrote:
+
+> On Tue, 20 Nov 2001, Clinton Ebadi wrote:
+> 
+> > I noticed the patches for cookies and https (among other things) on 
+> > http://haru.wom.ru/pub/dillo/patches/. Are there any plans to merge 
+> > these into the main dillo source tree? Cookies would be useful to me 
+> > (i.e. for viewing sites like kuro5hin where you have to be logged in 
+> > to do important things like post).
+> [...]
+> 
+> The cookie patch out there is only half of the story. Jorgen Viksell had
+> created a different cookie patch that to some degree complemented mine. We
+> have combined the two, and now have error checking, file-based cookie
+> control and persistence. We shall send out the full patch soon.
+> 
+> -Lars
+> 
+> -- 
+> Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
+> "I do not agree with a word that you say, but I |----------------------------
+> will defend to the death your right to say it." | Where are we going, and
+> --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+_________________________________________________________
+Do You Yahoo!?
+Get your free @yahoo.com address at http://mail.yahoo.com 
+
+
+
+Re: [Dillo-dev]list items (was: Dillo Freezing)
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-11-21 18:53
+
+On Wed, 21 Nov 2001 19:41:00 +0100
+Sebastian Geerken <sgeerken@st...> wrote:
+
+> the freeze bugfix also solved the problems I had with list items, now
+> list items are special DwPage's. There will be some enhances, probably
+> within a new widget DwListItem.
+
+I've tested the patch for a moment now, and it seems to handle every "problem-page", I've tested, fine. For example:
+http://www.tomshardware.com
+http://www.phatboydesigns.net/alloywm/index.html
+
+Very nice! Keep up the good work!
+
+-- 
+//Hugo Hallqvist - hugha495 at student dot liu dot se 
+
+
+
+[Dillo-dev]list items (was: Dillo Freezing)
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-21 18:41
+
+Hi,
+
+the freeze bugfix also solved the problems I had with list items, now
+list items are special DwPage's. There will be some enhances, probably
+within a new widget DwListItem.
+
+Sebastian 
+
+
+
+Re: Dillo Freezing (was: Re: [Dillo-dev]DwPage Update)
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-21 18:16
+
+On Sat, Nov 17, 2001 at 11:54:04AM -0200, Livio Baldini Soares wrote:
+> Livio Baldini Soares writes:
+> > 
+> > If there is any other info you'll like from me, just say so. I'll try to come
+> > up with a reproducible test, but my feeling is that this is like a race, or
+> > something very rare...
+> > 
+> 
+> Ok, it seems that this page causes the mentioned error about half the time:
+> http://so....net/softwaremap/trove_list.php?form_cat=87
+> 
+> If it doesn't well then try resizing the dillo window _while_ the page is
+> loading (or reloading). Here's what I got this time:
+> 
+> Dw_table_sub_calc_col_widths (sub=0x82c63e8, width=1260419230, total_width=1260419229)
+> 
+> Which is bogus, so Dw_table_size_request must be doing something wrong with
+> it's calculations.
+> 
+> hope this helps,
+
+Yes, thanks, it helped a lot to track this bug down. It should finally
+be fixed, please post your experiences.
+
+Sebastian 
+
+
+
+[Dillo-dev]it works!
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-21 16:11
+
+Cookies work. Yes indeed, they work well. The fact that I am sending this message from dillo proves it (i am away from my home box, and am using OpenWebMail on my mail host). This needs cookies to work, and it is working. So, any plans to merge this in to cvs? Woo, now I never have to leave dillo (I don't go anywhere that uses frames anyway). My one last reason for using anything other than dillo is gone :-) !
+
+--
++ hackedtobits.com -- the home of irresponsible journalism
+http://lamer.hackedtobits.com -- the home of the lamer 
+
+
+
+Re: [Dillo-dev]DwPage Update
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-21 15:40
+
+On Fri, Nov 16, 2001 at 04:35:28PM -0200, Livio Baldini Soares wrote:
+> Yeeeaaaah! :-) This bug was kind of irritating me... Well, I don't know if
+> you're aware of it or not, but this also fixed bug #252!
+
+Yes, handling of breaks was changed a bit. Bug tracking engine is
+updated.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Cookies and https
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-21 15:32
+
+On Wed, 21 Nov 2001, Grigory Bakunov wrote:
+
+> Date |Tue, 20 Nov 2001 17:11:09 -0500
+>>From |"Clinton Ebadi" <unknown_lamer@ha...>
+>=20
+> Hello!
+>=20
+> I want to say - all who use old cookies patch
+> MUST update it from patch'o'matic http://haru.wom.ru/pub/dillo/patches/
+> Now this patch is realy greate! it's not only save cookies
+> do ~/.dillo, it's can control ACCEPT/REJECT cookies.
+>=20
+> Nice work guys!
+
+Thank you! It still has one problem: The order of the control file is
+important, so if you have DEFAULT: DENY at the top, no (new) cookies are
+allowed, regardless of what's below.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Cookies and https
+
+From: Grigory Bakunov <black@as...> - 2001-11-21 07:33
+
+Date |Tue, 20 Nov 2001 17:11:09 -0500
+From |"Clinton Ebadi" <unknown_lamer@ha...>
+
+Hello!
+
+I want to say - all who use old cookies patch
+MUST update it from patch'o'matic http://haru.wom.ru/pub/dillo/patches/
+Now this patch is realy greate! it's not only save cookies
+do ~/.dillo, it's can control ACCEPT/REJECT cookies.
+
+Nice work guys!
+
+Now i only need to join http_auth and cookies patches
+to enjoy ;-)
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]Cookies and https
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-21 01:33
+
+On Tue, 20 Nov 2001, Clinton Ebadi wrote:
+
+> I noticed the patches for cookies and https (among other things) on=20
+> http://haru.wom.ru/pub/dillo/patches/. Are there any plans to merge=20
+> these into the main dillo source tree? Cookies would be useful to me=20
+> (i.e. for viewing sites like kuro5hin where you have to be logged in=20
+> to do important things like post).
+[...]
+
+The cookie patch out there is only half of the story. Jorgen Viksell had
+created a different cookie patch that to some degree complemented mine. We
+have combined the two, and now have error checking, file-based cookie
+control and persistence. We shall send out the full patch soon.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Cookies and https
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-11-20 22:50
+
+> Note the "do other stuff" part...yes, I can use galeon or skipstone, 
+> but then I can't do much else. Usually I am running xchat, xmms, 
+> gaim, a bunch of wterms, and dillo. I can do that fine. If you 
+> replace dillo with galeon, I have to lose gaim, xmms, and a few 
+> wterms to make the box usable.
+
+point taken. I can't gainsay that dillo is a *lot* better than just about
+every other browser out there, in terms of memory use. Just saying that
+it's not hopeless without it. :)
+
+Carl Soderstrom. 
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]Cookies and https
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-20 22:38
+
+> > I am in a bit of a tough situation 
+> > with dillo--it is the only browser I can use on my box, since I have
+> > a mere 32MB of ram (and cannot install Netscape Navigator as it is
+> > non-free software). 
+> 
+> I used to run Galeon in 32MB of ram, with acceptable performance. it's
+> no speed demon, but it's not bad. was a lot better on a Cyrix 166/32MB
+> than Netscape was on a 486/100/32MB. on this same machine, Mozilla was
+> nearly unusable.
+> 
+
+Note the "do other stuff" part...yes, I can use galeon or skipstone, 
+but then I can't do much else. Usually I am running xchat, xmms, 
+gaim, a bunch of wterms, and dillo. I can do that fine. If you 
+replace dillo with galeon, I have to lose gaim, xmms, and a few 
+wterms to make the box usable.
+
+> it makes a world of difference to use a lightweight window
+> manager/desktop environment. KDE and/or GNOME+Sawfish will crush
+> anything with less than 64MB; jettison those if you haven't already. I
+> use FVWM; but Blackbox or WindowMaker will work about as well. Galeon
+> takes up a bit more memory than Konqueror, but (IMHO) has a much
+> nicer user interface. give it a try. :) 
+
+I run WindowMaker 0.70. I have no need for desktop evironments. I 
+even have my WindowMaker settings tuned way down, so it uses a mere 
+700K of ram (including all of my dock apps). I have a solid color for 
+a background, and make sure to minimize my background stuff to keep 
+ram for myself (about the only daemons I run are boa and cron).
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]Cookies and https
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-11-20 22:19
+
+> I am in a bit of a tough situation 
+> with dillo--it is the only browser I can use on my box, since I have 
+> a mere 32MB of ram (and cannot install Netscape Navigator as it is 
+> non-free software). 
+
+I used to run Galeon in 32MB of ram, with acceptable performance. it's no
+speed demon, but it's not bad. was a lot better on a Cyrix 166/32MB than Netscape
+was on a 486/100/32MB. on this same machine, Mozilla was nearly unusable.
+
+it makes a world of difference to use a lightweight window manager/desktop
+environment. KDE and/or GNOME+Sawfish will crush anything with less than
+64MB; jettison those if you haven't already. I use FVWM; but Blackbox or
+WindowMaker will work about as well. 
+Galeon takes up a bit more memory than Konqueror, but (IMHO) has a much
+nicer user interface. give it a try. :) 
+
+Carl Soderstrom. 
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+[Dillo-dev]Cookies and https
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-20 22:03
+
+I noticed the patches for cookies and https (among other things) on 
+http://haru.wom.ru/pub/dillo/patches/. Are there any plans to merge 
+these into the main dillo source tree? Cookies would be useful to me 
+(i.e. for viewing sites like kuro5hin where you have to be logged in 
+to do important things like post). I am in a bit of a tough situation 
+with dillo--it is the only browser I can use on my box, since I have 
+a mere 32MB of ram (and cannot install Netscape Navigator as it is 
+non-free software). Having to load konqueror to do something as 
+simple as post a message to k5 is painful (especially since I can't 
+do much else when running konqueror or mozilla).
+
+If no one else wants to do it, I will manually apply the patches to 
+the stuff in cvs (since cookies was done for 0.62) and submit a cvs 
+diff (just ask). 
+
+Even without cookies, dillo still rocks. Uses less than 1MB of ram 
+(woo, no dicache is great!) and renders most sites (one exception: 
+any of the forums in forums.newdoom.com...) extremely well. My only 
+complaints would be a lack of cookies, https, frames, and disk cache 
+(you see, I am on a dial-up so...). I can live without all of those 
+(except maybe cookies). I had an idea for implementing frames: since 
+dillo has the html widget, why not just use a GtkLayout and embed 
+multiple dillo widgets inside? Anyway, I can apply those patches and 
+send a big diff if you'd like (just say what patches and I'll start 
+working on it when I get the message).
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]dillo strange behaviour (fwd)
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-20 17:17
+
+Hi everyone!
+
+
+On Tue, 16 Oct 2001, Grigory Bakunov wrote:
+
+> I found realy strange dillo behaviour on rpmfind.net site.
+>
+> look - at first search we have this html:
+> ----- HTML-phase-1 ------------------------------------
+> <form method="get" action="/linux/rpm2html/search.php" enctype="application/x-www-form-urlencoded">
+> <input type="text" size="35" name="query" value="">
+> <input type="submit" value="Search ..." name="submit">
+> </form>
+> ------------------------------------------------END-------
+>
+> so, realy good work form. after input into 'query' field text '12345'
+> and press submit we pass to rpmfind.net site next url query:
+> http://rpmfind.net/linux/rpm2html/search.php?query=1234&submit=Search+...
+> and now form in html look like this
+>
+> ------- HTML-phase-2---------------------------------
+> <form action="/linux/rpm2html/search.php?query=1234" enctype="application/x-www-form-urlencoded" method="GET">
+> <input name="query" type="TEXT" size="60" value="1234">
+> <input name=submit type=submit value="Search ...">
+> </form>
+> ------------------------------------------------END-----
+> As all see - authors of rpmfind site place our 'query' string into form action tag.
+> so, after input into query field '4321' and press submit - we have VERY strange URL string:
+> http://rpmfind.net/linux/rpm2html/search.php?query=1234?query=4321&submit=Search+...
+> look! we have to 'query' variable in url. but RFC says it's not correct.
+> and at least - we have absolutely wrong html form text -
+>
+> ------- HTML-phase-3---------------------------------
+> <form action="/linux/rpm2html/search.php?query=1234%3Fquery%3D4321"
+> enctype="application/x-www-form-urlencoded" method="GET">
+> <input name="query" type="TEXT" size="60" value="1234?query=4321">
+> <input name=submit type=submit value="Search ...">
+> </form>
+> ------------------------------------------------END----
+>
+> so, we need to remove dublicate variables when insert new variables by GET method.
+> Thanks for all who be so patient and read this message to the end.
+
+By the time this report was posted, rpmfind.net was down or
+unaccessible from here. But now it seems to be back again and the
+patch for BUG#255 I just commited, should also fix this bug!
+
+Note: to remove duplicate variables is NOT the rigth solution.
+It's a matter of resolving as RFC2396 suggests!
+
+BTW: the current URL resolver fails a lot when contrasted with
+RFC2396's examples, but it doesn't seem to cause much trouble
+because it happens in not-so-common cases. Anyway, now I'm
+playing with a parsing prototype that uses regular expresions. If
+there's a knowledgeable volunteer (versed in url.c, RFCs, RE,
+...) willing to finish it please drop me note. If not, I'll keep
+working on it, because it is a very sensible part of the browser.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Forgot (fwd)
+
+From: Grigory Bakunov <black@as...> - 2001-11-19 15:08
+
+Date |Mon, 19 Nov 2001 11:22:00 -0300 (CLST)
+From |Jorge Arellano Cid <jcid@em...>
+
+Hello!
+
+
+JAC> (this is a fwd, because I got no answer to the original)
+
+huh. i always forget to answer. ;-)
+realy sorry.
+
+JAC> ---------- Forwarded message ----------
+JAC> Date: Tue, 6 Nov 2001 21:03:42 -0300 (CLST)
+JAC> From: Jorge Arellano Cid <jcid@em...>
+JAC> To: Grigory Bakunov <black@as...>
+JAC> Subject: Re: [Dillo-dev]Forgot
+
+
+JAC> Grigory,
+
+>> Also i make small sites with all patches what i found at this moment.
+>> http://haru.wom.ru/pub/dillo/patches/
+>> All patches cleaned for current cvs version.
+>> You can add your own patch by form on site.
+
+JAC> I gave the path-o-matic a try! Nice work.
+
+JAC> One of the reasons I had for not enabling sourceforge's one, is
+JAC> that currently I have more than enough things to worry about, and
+JAC> adding more is a NO-NO for me.
+
+JAC> Well, if you add an explanation that those patches are there
+JAC> for improvement, that they haven't been accepted yet, and that
+JAC> using them may break otherwise good behaviour, that they're
+JAC> posted there to let interested developers work them out without
+JAC> trashing the mailing list, and also ask the poster to explain
+JAC> briefly what they're known to break and warn that the submission
+JAC> MUST be done using a browser other than dillo (no file upload
+JAC> facility yet), I'll gladly add a link to it from somewhere
+JAC> convenient in the site.
+
+Realy all my problems in too short english practice - if somebody
+write this explanation for site - i place it on first page and make
+more frienly interface. also i want to add optional <textarea/> instead of 
+<input type='file'/> - so dillo users can cut'n'paste their patches
+to textarea.
+
+Currently all patches brint to conformity with dillo cvs code and applyed
+without any HUNKs.
+
+Two patches - http_auth and cookies - conflicts.
+Two patches - my encodings and Japanise by Robert Thomson - do similar things -
+help to work with different encodings in html.
+
+JAC> Wow!, I can't believe I wrote it all in a single paragraph! :)
+Wow! I don't try to repeat your deed. ;-)
+
+Thanks for not so small piece of realy great code - i
+enjoy to read your nice coding style.
+
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]Font Handling
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-19 14:05
+
+Hi,
+
+On Sun, Nov 18, 2001 at 04:05:48PM -0500, Clinton Ebadi wrote:
+> Hello, I've been looking through the source, trying to find a way to 
+> change the default font from helvetica to arial (helvetica scales 
+> really badly). I was able to change it (the font table), but that 
+> still makes it an ugly hack. I am going to add an option to the 
+> configuration file to allow for configuration of the default fonts. 
+
+I was already working on this, some time ago I nearly finished some
+modifications on font handling:
+
+1. introduction of generic fonts (see
+http://www.w3.org/TR/CSS2/fonts.html#generic-font-families), and
+dillorc options to define them. Furthermore some changes in the
+HTML parser, e.g. to use "monospace" for <PRE>,
+
+2. an option for setting the default font, and
+
+3. some more modifications for handling as much fonts as possible,
+e.g. search for "black" fonts if a bold variant is not available
+in a specific family.
+
+(This is BTW registered as bug #176.)
+
+Unfortunately, the work is currently on an inaccessible hard disk, I
+hope to get it within the next time, until then you'll have to work
+with a private modification :-)
+
+> What would be the best way of doing this? My idea was to have a field 
+> like this:
+> 
+> default_fonts=foo&bar&baz
+> 
+> (font names separated by &), and then to write a function to parse 
+> this line and set the font table to use those (from what I read in 
+> html.c, that means I would have to rewrite some of the html init code 
+> to handle more than four font options), with the last font in the 
+> table being NULL, so the new code would know when to stop looking for 
+> default fonts.
+
+Handling lists of fonts (also for <font> and CSS) is what
+a_Dw_style_font_new_from_list (dw_style.c) was intended for.
+
+> Of course, if you know the first font will exist 
+> (which is usually the case when you are overriding the defaults), why 
+> have more than one option? My idea for the long run (once I have more 
+> time to do this) is to have these options:
+> 
+> default_fixed_font=foo&bar
+> default_sans-serif_font=foo&bar
+> default_serif_font=foo&bar
+
+Already part of my patch.
+
+> default_font_size=10 (eventually add pt, in, cm, mm, px extensions)
+> default_font_style=sans-serif (or serif / fixed)
+> 
+> Where you can still use more than one font (to get rid of the hard-
+> coded font table). So, is my idea good, or does it need any changes? 
+> (or is someone already doing this).
+
+It does not even have to be implemented. ;-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]replace GtkOptionMenu with GtkCombo?
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-19 13:38
+
+On Sun, Nov 18, 2001 at 02:57:49PM +1100, Hayden wrote:
+> Hello,
+> 
+> Just wondering why you are using the GtkOptionMenu for the select tags. Other browsers seem to use their widget set equivalent of the GtkCombo.
+> Is there any reason why GtkCombo is not/can not be used?
+
+From http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#edef-SELECT:
+
+The SELECT element creates a menu. Each choice offered by the menu
+is represented by an OPTION element. A SELECT element must contain
+at least one OPTION element.
+
+And, on the same page before:
+
+menus
+Menus offer users options from which to choose. The SELECT
+element creates a menu, in combination with the OPTGROUP and
+OPTION elements.
+
+GtkOptionMenu is indeed intended for this, while GtkCombo is a
+combination of a menu and an entry. (Mozilla seems to imitate the
+Windows look, rendering an option menu in a way similar to combos, but
+you cannot edit the text.)
+
+Sebastian 
+
+
+
+[Dillo-dev]Font Handling
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-11-18 20:57
+
+Hello, I've been looking through the source, trying to find a way to 
+change the default font from helvetica to arial (helvetica scales 
+really badly). I was able to change it (the font table), but that 
+still makes it an ugly hack. I am going to add an option to the 
+configuration file to allow for configuration of the default fonts. 
+What would be the best way of doing this? My idea was to have a field 
+like this:
+
+default_fonts=foo&bar&baz
+
+(font names separated by &), and then to write a function to parse 
+this line and set the font table to use those (from what I read in 
+html.c, that means I would have to rewrite some of the html init code 
+to handle more than four font options), with the last font in the 
+table being NULL, so the new code would know when to stop looking for 
+default fonts. Of course, if you know the first font will exist 
+(which is usually the case when you are overriding the defaults), why 
+have more than one option? My idea for the long run (once I have more 
+time to do this) is to have these options:
+
+default_fixed_font=foo&bar
+default_sans-serif_font=foo&bar
+default_serif_font=foo&bar
+default_font_size=10 (eventually add pt, in, cm, mm, px extensions)
+default_font_style=sans-serif (or serif / fixed)
+
+Where you can still use more than one font (to get rid of the hard-
+coded font table). So, is my idea good, or does it need any changes? 
+(or is someone already doing this).
+
+-------------------------------
+#umbclinux @ irc.openprojects.net
+lamer.hackedtobits.com
+linux@ck...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+[Dillo-dev]replace GtkOptionMenu with GtkCombo?
+
+From: Hayden <super_super_hero_hayden@ya...> - 2001-11-18 06:02
+
+Hello,
+
+Just wondering why you are using the GtkOptionMenu for the select tags. Other browsers seem to use their widget set equivalent of the GtkCombo.
+Is there any reason why GtkCombo is not/can not be used?
+
+
+Hayden 
+
+
+
+Re: [Dillo-dev]minor error in https patch
+
+From: Grigory Bakunov <black@as...> - 2001-11-18 03:09
+
+Date |Sun, 18 Nov 2001 13:10:06 +1100
+From |Hayden <super_super_hero_hayden@ya...>
+
+Hello!
+
+H> When using Dillo with the https patch applied you lose the about protocol (well whatever it is), this is because in io/Url.c on line 102 the 3 should be a 4.
+
+
+fixed in patchomatic.
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]minor error in https patch
+
+From: Hayden <super_super_hero_hayden@ya...> - 2001-11-18 03:02
+
+When using Dillo with the https patch applied you lose the about protocol (well whatever it is), this is because in io/Url.c on line 102 the 3 should be a 4.
+
+
+Hayden 
+
+
+
+RE: [Dillo-dev]dillo plugins patch
+
+From: Eric GAUDET <egaudet@in...> - 2001-11-17 21:08
+
+-- En reponse de "[Dillo-dev]dillo plugins patch" de Grigory Bakunov, le
+17-Nov-2001 :
+> I search for updates to my dillo patchomatic site and found
+> this:
+> http://www.rti-zone.org/dillo/
+> I want to know - what's with this code ? somebody maintain
+> this ? it's still work ?
+> 
+
+I don't maintain this code, because the dillo plugins interface has changed
+since. This was the implementation I proposed before, but Jorge wants more. I'm
+still waiting for the new one, though :-(
+
+> 
+> Also i want to say - i update https,encodings,http_auth
+> patches on patchomatic for current dillo cvs code.
+> 
+> 
+> look for: http://haru.wom.ru/pub/dillo/
+> 
+> -------------------------------------------------------
+> Grigory Bakunov
+> ASPLinux Support Team
+> http://www.asplinux.ru
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 17-Nov-2001 a 13:06:16
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
+
+
+[Dillo-dev]dillo plugins patch
+
+From: Grigory Bakunov <black@as...> - 2001-11-17 16:41
+
+I search for updates to my dillo patchomatic site and found
+this:
+http://www.rti-zone.org/dillo/
+I want to know - what's with this code ? somebody maintain
+this ? it's still work ?
+
+
+Also i want to say - i update https,encodings,http_auth
+patches on patchomatic for current dillo cvs code.
+
+
+look for: http://haru.wom.ru/pub/dillo/
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: Dillo Freezing (was: Re: [Dillo-dev]DwPage Update)
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-17 13:54
+
+Livio Baldini Soares writes:
+> 
+> If there is any other info you'll like from me, just say so. I'll try to come
+> up with a reproducible test, but my feeling is that this is like a race, or
+> something very rare...
+> 
+
+Ok, it seems that this page causes the mentioned error about half the time:
+http://so....net/softwaremap/trove_list.php?form_cat=87
+
+If it doesn't well then try resizing the dillo window _while_ the page is
+loading (or reloading). Here's what I got this time:
+
+Dw_table_sub_calc_col_widths (sub=0x82c63e8, width=1260419230, total_width=1260419229)
+
+Which is bogus, so Dw_table_size_request must be doing something wrong with
+it's calculations.
+
+hope this helps,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Dillo Freezing (was: Re: [Dillo-dev]DwPage Update)
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-17 13:40
+
+Well, here goes some bad news :(
+
+Sebastian Geerken writes:
+> Hi!
+> 
+> The "invisible list/blockquote" bug has been fixed, changes are in the
+> CVS. I've furthermore worked on the <p><li> bug (by putting it into an
+> own widget), but have not succeeded to get it to run bug free. This is
+> what the new code in DwPage is for.
+
+Ever since the first change (on 0.6.2) in DwTable and DwWidget, Dillo has
+sometimes been "freezing". It happens not so often (something like 2 times a
+day). I have no way to reproduce this, but I've attached gdb to the frozen dillo
+and it seems to be spinning at Dw_table_sub_calc_col_widths() (always!).
+
+More precisely here's the loop in gdb:
+Entry point: Dw_table_sub_calc_col_widths (sub=0x82e3f98, width=721, total_width=720).
+
+BTW: I don't know if it's ok for `width` to be bigger than `total_width`...
+
+loop: 
+1346 do {
+1351 width_norm_cols = avail_width;
+1352 num_norm_cols = num_cols;
+1353 for (i = 0; i < sub->num_subs; i++) {
+1354 if (sub_status[i] != AT_NORM) {
+1353 for (i = 0; i < sub->num_subs; i++) {
+1354 if (sub_status[i] != AT_NORM) {
+1353 for (i = 0; i < sub->num_subs; i++) {
+1376 success = TRUE;
+1377 for (i = 0; success && i < sub->num_subs; i++) {
+1378 cols_per_sub = (sub->subs[i].end_col - sub->subs[i].start_col);
+1380 switch (sub_status[i]) {
+1383 if (width_norm_cols * cols_per_sub
+1393 sub_status[i] = AT_MAX;
+1396 break;
+1418 success = FALSE;
+1377 for (i = 0; success && i < sub->num_subs; i++) {
+1346 do {
+
+Last but not least, this is the backtrace:
+
+#0 Dw_table_sub_calc_col_widths (sub=0x82e3f98, width=721, total_width=720)
+at dw_table.c:1351
+#1 0x805cd1c in Dw_table_size_request (widget=0x832a810, requisition=0x837bba4) 
+at dw_table.c:290
+#2 0x401184d5 in gtk_marshal_NONE__POINTER (object=0x832a810, 
+func=0x805cb34 <Dw_table_size_request>, func_data=0x0, args=0xbfffdd20)
+at gtkmarshal.c:193
+#3 0x40147bf3 in gtk_signal_real_emit (object=0x832a810, signal_id=105, 
+params=0xbfffdd20) at gtksignal.c:1432
+#4 0x40145cff in gtk_signal_emit (object=0x832a810, signal_id=105)
+at gtksignal.c:552
+#5 0x805f068 in a_Dw_widget_size_request (widget=0x832a810, 
+requisition=0x837bba4) at dw_widget.c:494
+#6 0x805a441 in Dw_page_calc_widget_size (page=0x82caa10, widget=0x832a810, 
+size=0x837bba4) at dw_page.c:800
+#7 0x805a779 in Dw_page_rewrap (page=0x82caa10) at dw_page.c:863
+#8 0x805985d in Dw_page_size_request (widget=0x82caa10, 
+requisition=0xbfffe47c) at dw_page.c:334
+#9 0x401184d5 in gtk_marshal_NONE__POINTER (object=0x82caa10, 
+func=0x8059834 <Dw_page_size_request>, func_data=0x0, args=0xbfffe158)
+at gtkmarshal.c:193
+#10 0x40147bf3 in gtk_signal_real_emit (object=0x82caa10, signal_id=105, 
+params=0xbfffe158) at gtksignal.c:1432
+#11 0x40145cff in gtk_signal_emit (object=0x82caa10, signal_id=105)
+at gtksignal.c:552
+#12 0x805f068 in a_Dw_widget_size_request (widget=0x82caa10, 
+requisition=0xbfffe47c) at dw_widget.c:494
+#13 0x805ce3d in Dw_table_size_request (widget=0x8399d40, 
+requisition=0x83ee998) at dw_table.c:323
+#14 0x401184d5 in gtk_marshal_NONE__POINTER (object=0x8399d40, 
+func=0x805cb34 <Dw_table_size_request>, func_data=0x0, args=0xbfffe520)
+at gtkmarshal.c:193
+#15 0x40147bf3 in gtk_signal_real_emit (object=0x8399d40, signal_id=105, 
+params=0xbfffe520) at gtksignal.c:1432
+#16 0x40145cff in gtk_signal_emit (object=0x8399d40, signal_id=105)
+at gtksignal.c:552
+#17 0x805f068 in a_Dw_widget_size_request (widget=0x8399d40, 
+requisition=0x83ee998) at dw_widget.c:494
+#18 0x805a441 in Dw_page_calc_widget_size (page=0x827c450, widget=0x8399d40, 
+size=0x83ee998) at dw_page.c:800
+#19 0x805a779 in Dw_page_rewrap (page=0x827c450) at dw_page.c:863
+#20 0x805985d in Dw_page_size_request (widget=0x827c450, 
+requisition=0xbfffec7c) at dw_page.c:334
+#21 0x401184d5 in gtk_marshal_NONE__POINTER (object=0x827c450, 
+func=0x8059834 <Dw_page_size_request>, func_data=0x0, args=0xbfffe958)
+at gtkmarshal.c:193
+#22 0x40147bf3 in gtk_signal_real_emit (object=0x827c450, signal_id=105, 
+params=0xbfffe958) at gtksignal.c:1432
+#23 0x40145cff in gtk_signal_emit (object=0x827c450, signal_id=105)
+at gtksignal.c:552
+#24 0x805f068 in a_Dw_widget_size_request (widget=0x827c450, 
+requisition=0xbfffec7c) at dw_widget.c:494
+#25 0x805ce3d in Dw_table_size_request (widget=0x831e678, 
+requisition=0x82a4a18) at dw_table.c:323
+#26 0x401184d5 in gtk_marshal_NONE__POINTER (object=0x831e678, 
+func=0x805cb34 <Dw_table_size_request>, func_data=0x0, args=0xbfffed20)
+at gtkmarshal.c:193
+#27 0x40147bf3 in gtk_signal_real_emit (object=0x831e678, signal_id=105, 
+params=0xbfffed20) at gtksignal.c:1432
+#28 0x40145cff in gtk_signal_emit (object=0x831e678, signal_id=105)
+at gtksignal.c:552
+#29 0x805f068 in a_Dw_widget_size_request (widget=0x831e678, 
+requisition=0x82a4a18) at dw_widget.c:494
+#30 0x805a441 in Dw_page_calc_widget_size (page=0x836d2d0, widget=0x831e678, 
+size=0x82a4a18) at dw_page.c:800
+#31 0x805a779 in Dw_page_rewrap (page=0x836d2d0) at dw_page.c:863
+#32 0x805985d in Dw_page_size_request (widget=0x836d2d0, 
+requisition=0xbffff4ac) at dw_page.c:334
+#33 0x401184d5 in gtk_marshal_NONE__POINTER (object=0x836d2d0, 
+func=0x8059834 <Dw_page_size_request>, func_data=0x0, args=0xbffff158)
+at gtkmarshal.c:193
+#34 0x40147bf3 in gtk_signal_real_emit (object=0x836d2d0, signal_id=105, 
+params=0xbffff158) at gtksignal.c:1432
+#35 0x40145cff in gtk_signal_emit (object=0x836d2d0, signal_id=105)
+at gtksignal.c:552
+#36 0x805f068 in a_Dw_widget_size_request (widget=0x836d2d0, 
+requisition=0xbffff4ac) at dw_widget.c:494
+#37 0x8057bef in Dw_gtk_viewport_calc_child_size (viewport=0x8179420, 
+child_width=938, child_height=607, child_requisition=0xbffff4ac)
+at dw_gtk_viewport.c:497
+#38 0x8057d70 in Dw_gtk_viewport_calc_size (viewport=0x8179420)
+at dw_gtk_viewport.c:586
+#39 0x805fee8 in Dw_widget_queue_resize_idle (data=0x8179420)
+at dw_widget.c:1076
+
+
+If there is any other info you'll like from me, just say so. I'll try to come
+up with a reproducible test, but my feeling is that this is like a race, or
+something very rare...
+
+best regards! 
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]Handhelds
+
+From: Sam J. <sam@ne...> - 2001-11-17 12:52
+
+Jorge Arellano Cid wrote:
+
+> Sam also sent a patch to increase the customization granularity
+> of the control panel, allowing the user to chose which widgets to
+> hide. Unfortunately it broke some key bindings and raised
+> gdk-CRITICAL warnings. :(
+
+
+Hmm it ran without errors patched against 0.6.2 for me, and since nobody 
+on the list complained I assumed it was ok.
+
+
+> The idea was good indeed so there's a new rewritten patch for
+> that on CVS. What does it mean? Now you can tailor dillo's panel
+> even further by hiding some widgets.
+
+
+Looks good.
+
+
+> As for the pen-pointing device, I think a good solution is to
+> have two small buttons (rightmost part of the status bar), that
+> fake a middle or right click. i.e. the user presses rigth-lock
+> button, then the next pen-click event (a physical left) is
+> trapped, stopped, and a new event (right-click) is emmited. This
+> is not on CVS, but I'll be expecting the patch! :-)
+
+I thought about this too, but then decided that this functionality would 
+be more useful as a standalone program so it can be used with other apps 
+as well. Maybe Shooby's XRmouse will do the trick.
+
+Regards,
+Sam
+
+-- 
+Sam J. Engstrom Tel. +358 400 462442 mail@sa...
+Managing Director Nemesol http://nemesol.fi 
+
+
+
+Re: [Dillo-dev]Handhelds
+
+From: Shooby Ban <shooby@gn...> - 2001-11-17 10:47
+
+] The second part is the user interface. Sam pointed out that the
+]iPAQ only has a left click (is uses a pen like device), so it was
+]missing a lot of the UI.
+
+I have made a mouse button changing applet for iPaq once, so I can use
+right-click menus well. But I've got problems with big images and forms,
+with the original gtk fileopen dialog (that's huge)...
+
+]icons even smaller, now there's the posibility of hiding the
+]whole control panel! (AKA full-screen mode). This will benefit
+
+Cool man! This is a good idea!
+
+]have two small buttons (rightmost part of the status bar), that
+]fake a middle or right click. i.e. the user presses rigth-lock
+
+Look at projects.gnome.hu/xrmouse for nice looking stuff :))) maybe in a
+widget indneed a popup window.
+
+Regards,
+Shooby
+
+-- 
+Sho 
+
+
+
+RE: [Dillo-dev]Handhelds
+
+From: Mondesir, Raphael <raphael.mondesir@tf...> - 2001-11-16 21:34
+
+Does anyone know where I can find a bootable floppy distribution of Dillo?
+
+Thanks,
+Raphael
+
+-----Original Message-----
+From: William Kendrick [mailto:nbs@so...]
+Sent: Friday, November 16, 2001 4:26 PM
+To: dillo-dev@li...
+Subject: Re: [Dillo-dev]Handhelds
+
+
+On Fri, Nov 16, 2001 at 05:34:34PM -0300, Jorge Arellano Cid wrote:
+<snip>
+> Well, there're still some things pending, but I thought iPAQ
+> users would be happy to read this.
+
+Cool! :) My interest in Dillo (in fact, my knowledge of its existence)
+came from my ownership of an Agenda VR3 PDA. I'll soon be in possession
+of a Sharp SL-5000 PDA, too. Unfortunately, neither come with GTK+.
+(Agenda runs X11 and has FLTK. Sharp runs QtEmbeded.) My greatest dream
+would be to have Dillo's interface code abstracted from GTK+, so that
+it could be built against Qt and FLTK bindings, too. :)
+
+Anyway... at least these first steps are sounding good. Thanks Jorge &
+all!
+
+-bill!
+(who has an Atari 800XL set up next to his Linux box at home ;) )
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]Handhelds
+
+From: William Kendrick <nbs@so...> - 2001-11-16 21:26
+
+On Fri, Nov 16, 2001 at 05:34:34PM -0300, Jorge Arellano Cid wrote:
+<snip>
+> Well, there're still some things pending, but I thought iPAQ
+> users would be happy to read this.
+
+Cool! :) My interest in Dillo (in fact, my knowledge of its existence)
+came from my ownership of an Agenda VR3 PDA. I'll soon be in possession
+of a Sharp SL-5000 PDA, too. Unfortunately, neither come with GTK+.
+(Agenda runs X11 and has FLTK. Sharp runs QtEmbeded.) My greatest dream
+would be to have Dillo's interface code abstracted from GTK+, so that
+it could be built against Qt and FLTK bindings, too. :)
+
+Anyway... at least these first steps are sounding good. Thanks Jorge & all!
+
+-bill!
+(who has an Atari 800XL set up next to his Linux box at home ;) ) 
+
+
+
+[Dillo-dev]Handhelds
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-16 20:37
+
+Hi everyone!
+
+
+Sometime ago (more than I'd like) there was a thread about
+running dillo on handhelds; I wish I could have had the time to
+answer it then, but my priority list was pointing to different
+places...
+
+While thinking about some issues raised there, I began to
+develop an interface model and to code some bits. The good news
+is that this procrastinated answer not only has ideas but also
+some code news.
+
+First, running on handhelds has never been a goal in dillo, so
+developing specific modules to enable or allow some PDAs to run
+dillo is more likely to be discarded. Specially if the required
+code is complex, or big, or too specific.
+
+OTOH, making dillo able to run on legacy HW is a desired
+feature. And there's where handhelds may benefit.
+
+Ironically, the main problem (IMNSHO;) of running dillo on PDAs
+wasn't mentioned then: memory usage.
+
+Dillo's dicache was taking huge amounts of memory (roughly
+3xoriginal image size) for RGB buffers. And that's the main
+memory consumption source. Fortunately, Livio and I were
+discussing from some time ago, about a new implementation of the
+dicache to allow a memory boundary. In short: The first part of
+that work is done (thanks Livio!), and the CVS version uses a lot
+less memory!
+
+The second part is the user interface. Sam pointed out that the
+iPAQ only has a left click (is uses a pen like device), so it was
+missing a lot of the UI.
+
+Sometimes I receive patches for very specific things that only
+solve problems in a rather narrow scope. Certainly, a better
+practice is to try to identify the root, and to try to develop a
+model that solves the problem in a more generic way. (I don't
+remember exactly, but I'd bet 90% I read that in the ANTIC
+magazine, almost 20 years ago, in a best-practices section.
+Caveat emptor! --FWIW my favorite at the time was ANALOG).
+
+So I finally came out with a new UI model. Instead of making
+icons even smaller, now there's the posibility of hiding the
+whole control panel! (AKA full-screen mode). This will benefit
+every single user, and for small resolution devices it will
+increase the viewport size. And yes, it's already on CVS!
+
+Sam also sent a patch to increase the customization granularity
+of the control panel, allowing the user to chose which widgets to
+hide. Unfortunately it broke some key bindings and raised
+gdk-CRITICAL warnings. :(
+
+The idea was good indeed so there's a new rewritten patch for
+that on CVS. What does it mean? Now you can tailor dillo's panel
+even further by hiding some widgets.
+
+As for the pen-pointing device, I think a good solution is to
+have two small buttons (rightmost part of the status bar), that
+fake a middle or right click. i.e. the user presses rigth-lock
+button, then the next pen-click event (a physical left) is
+trapped, stopped, and a new event (right-click) is emmited. This
+is not on CVS, but I'll be expecting the patch! :-)
+
+Well, there're still some things pending, but I thought iPAQ
+users would be happy to read this.
+
+
+Regards
+Jorge.-
+
+
+PS: I'm very interested in the sourceforge issue. Just post all
+your comments and links, to help find out what to do. 
+
+
+
+Re: [Dillo-dev]DwPage Update
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-16 18:35
+
+Hi Sebastian!
+
+Sebastian Geerken writes:
+> Hi!
+> 
+> The "invisible list/blockquote" bug has been fixed, changes are in the
+> CVS. I've furthermore worked on the <p><li> bug (by putting it into an
+> own widget), but have not succeeded to get it to run bug free. This is
+> what the new code in DwPage is for.
+
+Yeeeaaaah! :-) This bug was kind of irritating me... Well, I don't know if
+you're aware of it or not, but this also fixed bug #252!
+
+BTW: The new "full-screen" mode activated by double left click is awesome! I
+_really_ liked it! Congrats for you and Jorge!
+
+
+best regars to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]DwPage Update
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-16 18:19
+
+Hi!
+
+The "invisible list/blockquote" bug has been fixed, changes are in the
+CVS. I've furthermore worked on the <p><li> bug (by putting it into an
+own widget), but have not succeeded to get it to run bug free. This is
+what the new code in DwPage is for.
+
+More on this later.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Ron Farrer <rbf@fa...> - 2001-11-13 18:16
+
+Livio Baldini Soares (livio@li...) wrote:
+
+> Hello again,
+> 
+> sorry for bringing this up again.
+
+No need to apologize IMHO. It is an important issue that needs to be
+discussed.
+
+> It won't be that bad to stay at sourceforge, but I'm very "political" about
+> Free Software. So my suggestion was to move in to Savannah, for example, which
+> is pure Free Software. But if noone else sees a point, than we might as well
+> just stick with sourceforge.
+
+My feelings exactly. My opinion, which doesn't count for anything, would
+be to move to Savannah.
+
+> > > PS: On other news, I have tried to start a new Dillo web page. I am _not_ a web
+> > > developer, and haven't made more than a few ugly pages in my life. So I
+> > > really need suggestions and opinions. Currently I haven't made any changes
+> > > in the contents of Dillo home page, just the organization (layout)... what
+> > > would you guys like to see at our home page? Info, links, etc? What about
+> > > the layout? New art? New logo? The preview version I've made is available
+> > > here:
+> > > 
+> > > http://www.linux.ime.usp.br/~livio/dillo/new-home/
+> 
+> Hummm.. noone had time to look at the site :( Is it _that_ bad? :-P
+
+It looks fine, although you might want to remove the sourceforge logo as
+it isn't on sourceforge...
+
+Anyway I haven't contributed code to dillo (yet) so my opinion likely
+doesn't count on this, but should it then that is how I feel about the
+whole issue.
+
+Ron
+-- 
+Email: <rbf@fa...> or <rbf@de...>
+
+P.S. I maintain the dillo Debian package and was wondering if anyone has
+any improvements they'd like to see? 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Eduardo Marcel Maçan <macan@co...> - 2001-11-13 17:02
+
+Heh, really... but I guess we should make a button saying
+"best viewed with dillo" hehehehe :)
+
+Em Tue, 13 Nov 2001 09:10:21 -0600 Carl Wilhelm Soderstrom <chrome@re...> escreveu:
+> > > > http://www.linux.ime.usp.br/~livio/dillo/new-home/
+> > 
+> > Hummm.. noone had time to look at the site :( Is it _that_ bad? :-P
+> 
+> I looked at it, and it's not bad at all. You just need to remove the
+> Sourceforge logo from it (since that particular page isn't hosted there). :)
+> 
+> Carl Soderstrom
+> -- 
+> Network Engineer
+> Real-Time Enterprises
+> (952) 943-8700
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+-- 
+"If you have an apple and I have an apple and we exchange apples then you 
+and I will still each have one apple. But if you have an idea and I have 
+an idea and we exchange these ideas, then each of us will have two ideas."
+George Bernard Shaw 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-11-13 15:10
+
+> > > http://www.linux.ime.usp.br/~livio/dillo/new-home/
+> 
+> Hummm.. noone had time to look at the site :( Is it _that_ bad? :-P
+
+I looked at it, and it's not bad at all. You just need to remove the
+Sourceforge logo from it (since that particular page isn't hosted there). :)
+
+Carl Soderstrom
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-13 13:01
+
+Hello again,
+
+sorry for bringing this up again.
+
+Richard writes:
+> On Mon, 12 Nov 2001 15:01:47 -0200
+> Livio Baldini Soares <livio@li...> wrote:
+> 
+> 
+> Well i read ... : ( 
+> 
+> This is extremely important.
+> By giving someone copyright on their work they just give it away.
+> By god i hope you havent signed this.
+
+No, we haven't and we probably won't be asked to. The author (Loïc Dachary)
+had contributed to the Sourceforge web site code so they needed to get his
+permission to use his contributions.
+
+> Definitely move out of there.
+
+Well, it's not as desperate as it might seem. There was a pretty insightful
+discussion at slashdot yesterday about this same issue:
+(http://slashdot.org/developers/01/11/12/1456219.shtml). And another discussion
+at Adgovato: (http://www.advogato.org/article/376.html).
+
+It seems the director of sourceforge himself wrote to say what was going
+on. The title of his post is `From the Site Director of Sourceforge.net` and is
+near the end of the page, and the longest you'll. They have no intention of
+asking any of the projects to close their source. It seems VA (Linux) Systems is
+in financial difficulties and they are trying to get around it.
+
+It won't be that bad to stay at sourceforge, but I'm very "political" about
+Free Software. So my suggestion was to move in to Savannah, for example, which
+is pure Free Software. But if noone else sees a point, than we might as well
+just stick with sourceforge.
+
+> > PS: On other news, I have tried to start a new Dillo web page. I am _not_ a web
+> > developer, and haven't made more than a few ugly pages in my life. So I
+> > really need suggestions and opinions. Currently I haven't made any changes
+> > in the contents of Dillo home page, just the organization (layout)... what
+> > would you guys like to see at our home page? Info, links, etc? What about
+> > the layout? New art? New logo? The preview version I've made is available
+> > here:
+> > 
+> > http://www.linux.ime.usp.br/~livio/dillo/new-home/
+
+Hummm.. noone had time to look at the site :( Is it _that_ bad? :-P
+
+best regards to all!
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Richard <hebertrich@ya...> - 2001-11-13 01:54
+
+On Mon, 12 Nov 2001 15:01:47 -0200
+Livio Baldini Soares <livio@li...> wrote:
+
+I hope you will keep us informed as to where the project will move.
+
+I reread again and again ...cause it's a complex article..though i see a few differences 
+from my first reading i see that the need to move is real and extremely important.
+
+This is too much for me .
+Ill totally boycott Sourceforge from now on.
+Not being able to pull out a project and move it to another site is highway robbery.
+No less no more.Time to fly out the nest, i agree.
+
+
+Sorry i had a bad time reading and verifying all this...
+im stunned and dont find this funny at all.
+
+
+this being said need beta testers ? 
+i love to torture applications . Muah ha ha ha 
+
+: ) 
+
+
+
+
+
+
+
+
+
+_________________________________________________________
+Do You Yahoo!?
+Get your free @yahoo.com address at http://mail.yahoo.com 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Richard <hebertrich@ya...> - 2001-11-13 01:26
+
+On Mon, 12 Nov 2001 15:01:47 -0200
+Livio Baldini Soares <livio@li...> wrote:
+
+
+Well i read ... : ( 
+
+This is extremely important.
+By giving someone copyright on their work they just give it away.
+By god i hope you havent signed this.
+
+Get the heck out of there.Fast
+This stinks and i hope every project will be able to get out along
+with their software.If not, that you can setup somewhere else ,change all the links
+without having them sue you cause they have a copyright on your work.
+Definitely move out.
+
+This is incredible news .Dangerous to the max.
+This should be highly published and this article
+spread throughout to every developper.
+
+Definitely move out of there.
+
+
+
+
+
+> Hi everyone!
+> 
+> Unfortunately I feel compelled to bring out a question that might cause
+> polemic. Some of you may know that VA (Linux) is changing their "ways" and
+> becoming more and more comercial. (BTW, VA Linux is the owner of sourceforge).
+> And I've recently learnt that sourforge is now using non-free software :-(
+> Before reading on, maybe you should read this article (highly recommended):
+> 
+> http://www.fsfeurope.org/news/article2001-10-20-01.en.html
+> 
+> And there is a very interesting issue about _extracting_ the Dillo project
+> from sourceforge... it seems there is not way! There used to be a way, but now
+> the support for project data exportation has been removed.
+> 
+> After reading the section `Escape Entrapment` from the above article, I felt I
+> needed to right to you guys and ask your opinions. I have been very satisfied
+> with sourceforge's services, but this is terrible news... My suggestions is to
+> take everything from Dillo away from sourceforge and move into Savannah
+> (savannah.gnu.org). GNU and the FSF have long time been faithful to Free
+> Software and I believe we should move ASAP.
+> 
+> What do you guys think?
+> 
+> PS: On other news, I have tried to start a new Dillo web page. I am _not_ a web
+> developer, and haven't made more than a few ugly pages in my life. So I
+> really need suggestions and opinions. Currently I haven't made any changes
+> in the contents of Dillo home page, just the organization (layout)... what
+> would you guys like to see at our home page? Info, links, etc? What about
+> the layout? New art? New logo? The preview version I've made is available
+> here:
+> 
+> http://www.linux.ime.usp.br/~livio/dillo/new-home/
+> 
+> best regards and sorry for being the one with the bad news,
+> 
+> -- 
+> Livio <livio@li...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+_________________________________________________________
+Do You Yahoo!?
+Get your free @yahoo.com address at http://mail.yahoo.com 
+
+
+
+Re: [Dillo-dev]Are these legal links ?
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-13 01:01
+
+Michael,
+
+> I wonder if the links on this page are legal HTML links. They contain a
+> slash and dillo doesn't seem to interpret it correctly.
+>
+> http://www.linuxgazette.com/issue71/lg_tips71.html
+
+They're legal (as specified in rfc1808):
+
+fragment = *( uchar | reserved )
+[...]
+reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
+
+
+I made a fix, and a bug-track entry.
+
+
+See ya'
+Jorge.- 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Eduardo Marcel Maçan <macan@co...> - 2001-11-12 17:42
+
+Attachments: Message as HTML      
+
+New home for dillo...
+
+Lívio, since you, like me, are a Brazilian guy, you certainly know cipsga...
+http://www.cipsga.org.br , which plays the role of the Free Software Foundation
+in Brazil (sort of) and has strived to give the community what it needs
+to grow around here..
+
+If a new home is needed to host dillo from now on, I can arrange for
+it to be hosted on CIPSGA servers, which already host the
+debian.org.br primary web mirror, and the pages of the debian-br group.
+The Debian-br crew is responsible for the maintainance of the servers,
+I am sure we can quickly arrange space and software to support
+the development of the dillo web browser.
+
+I must say, dillo has somewhat of a cult following among us in the
+debian-br team :)
+
+Regards!
+
+Eduardo Maçan
+
+On Mon, 12 Nov 2001 15:01:47 -0200
+Livio Baldini Soares <livio@li...> wrote:
+
+> Hi everyone!
+> 
+> Unfortunately I feel compelled to bring out a question that might cause
+> polemic. Some of you may know that VA (Linux) is changing their "ways" and
+> becoming more and more comercial. (BTW, VA Linux is the owner of sourceforge).
+> And I've recently learnt that sourforge is now using non-free software :-(
+> Before reading on, maybe you should read this article (highly recommended):
+> 
+> http://www.fsfeurope.org/news/article2001-10-20-01.en.html
+> 
+> And there is a very interesting issue about _extracting_ the Dillo project
+> from sourceforge... it seems there is not way! There used to be a way, but now
+> the support for project data exportation has been removed.
+> 
+> After reading the section `Escape Entrapment` from the above article, I felt I
+> needed to right to you guys and ask your opinions. I have been very satisfied
+> with sourceforge's services, but this is terrible news... My suggestions is to
+> take everything from Dillo away from sourceforge and move into Savannah
+> (savannah.gnu.org). GNU and the FSF have long time been faithful to Free
+> Software and I believe we should move ASAP.
+> 
+> What do you guys think?
+> 
+> PS: On other news, I have tried to start a new Dillo web page. I am _not_ a web
+> developer, and haven't made more than a few ugly pages in my life. So I
+> really need suggestions and opinions. Currently I haven't made any changes
+> in the contents of Dillo home page, just the organization (layout)... what
+> would you guys like to see at our home page? Info, links, etc? What about
+> the layout? New art? New logo? The preview version I've made is available
+> here:
+> 
+> http://www.linux.ime.usp.br/~livio/dillo/new-home/
+> 
+> best regards and sorry for being the one with the bad news,
+> 
+> -- 
+> Livio <livio@li...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+-- 
+"If you have an apple and I have an apple and we exchange apples then you 
+and I will still each have one apple. But if you have an idea and I have 
+an idea and we exchange these ideas, then each of us will have two ideas."
+George Bernard Shaw 
+
+
+
+[Dillo-dev]About (leaving) SourceForge :-(
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-12 17:01
+
+Hi everyone!
+
+Unfortunately I feel compelled to bring out a question that might cause
+polemic. Some of you may know that VA (Linux) is changing their "ways" and
+becoming more and more comercial. (BTW, VA Linux is the owner of sourceforge).
+And I've recently learnt that sourforge is now using non-free software :-(
+Before reading on, maybe you should read this article (highly recommended):
+
+http://www.fsfeurope.org/news/article2001-10-20-01.en.html
+
+And there is a very interesting issue about _extracting_ the Dillo project
+from sourceforge... it seems there is not way! There used to be a way, but now
+the support for project data exportation has been removed.
+
+After reading the section `Escape Entrapment` from the above article, I felt I
+needed to right to you guys and ask your opinions. I have been very satisfied
+with sourceforge's services, but this is terrible news... My suggestions is to
+take everything from Dillo away from sourceforge and move into Savannah
+(savannah.gnu.org). GNU and the FSF have long time been faithful to Free
+Software and I believe we should move ASAP.
+
+What do you guys think?
+
+PS: On other news, I have tried to start a new Dillo web page. I am _not_ a web
+developer, and haven't made more than a few ugly pages in my life. So I
+really need suggestions and opinions. Currently I haven't made any changes
+in the contents of Dillo home page, just the organization (layout)... what
+would you guys like to see at our home page? Info, links, etc? What about
+the layout? New art? New logo? The preview version I've made is available
+here:
+
+http://www.linux.ime.usp.br/~livio/dillo/new-home/
+
+best regards and sorry for being the one with the bad news,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]Are these legal links ?
+
+From: Michael Duelli <m.duelli@we...> - 2001-11-12 11:00
+
+Hi,
+
+I wonder if the links on this page are legal HTML links. They contain a 
+slash and dillo doesn't seem to interpret it correctly.
+
+http://www.linuxgazette.com/issue71/lg_tips71.html
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net
+http://linuxmaths.s...net 
+
+
+
+Re: [Dillo-dev]configure
+
+From: Bjoern Weber <foxbow@we...> - 2001-11-09 07:40
+
+Jorge Arellano Cid <jcid@em...> schrieb am 08.11.01:
+[.. pthread.h + configure ..]
+> AFAIU detecting and configuring is automake&autoconf work (they
+> generate configure). So, I'd suggest to get a few pthreaded SW
+> packages, that use autoconf stuff, and see how do they solve the
+> problem in *BSD.
+I will look out for that and give my best to test.
+
+[...]
+> [the same applies for jpeg]
+In fact I can tell that the imlib package suffers the same problem.
+I have not been able to compile the imlib on a Sparc-NetBSD 1.3-1.5
+without manually dabbling either the configure script to lie or the
+sourcecode so it's able to find all the gfxlibs located in 
+usr/local.
+
+[.. compiling jpeg/png ..]
+> Yes, jpeg's code is not nested inside a #ifdef; in any case, I
+> don't yet find very useful to add the option of excluding jpeg or
+> png or gif...
+I'll sign that, yet it does not make much sense either to look for 
+the headers first, forget the evidence that they're not found
+and continue like nothing happened. If the libs are and headers
+are required and not found, I think configure should bail out
+with an error and not with a warning and produce incorrect 
+makefiles/code.
+
+[...]
+> Please send me the details of your QNX config, so I can list it
+> in the platform compatibility list.
+I am reluctant to do that since dillo bombs out from time to time
+and unless I found out if that is due to the X emulation, the gtk
+port or dillo I won't tell that it's really running. Unfortunately
+I was not able to reproduce the behaviour in any way so I'll keep
+on watching and share my wisdom with you when it's there =)
+
+A nice friday to you all!
+Bjoern
+-- 
+Sometimes, even at infinity, the largest distance
+can be much too close...
+________________________________________________________________
+Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! 
+Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 
+
+
+
+[Dillo-dev]great work on Dillo, keep it up. (fwd)
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-08 18:40
+
+---------- Forwarded message ----------
+Date: Wed, 31 Oct 2001 23:02:31 -0000
+From: Steve Nicholson <steve.nicholson@yo...>
+To: jcid@us...
+Subject: great work on Dillo, keep it up.
+
+Hi
+Have been trying different web browsers on my Debian workstation to find
+something that is light and fast to work on a P133 laptop I have been
+given. I normally keep well away from alpha stuff but thought I would
+try it since I was so disappointed with everything else I have tried.
+I'm very very impressed, Dillo is fantastic and just what I have been
+looking for it's really fast compared to anything else I've found. It's
+light with the basic functionality I want ,open multiple windows, open
+new window clicking on window, renders tables and graphics with most
+operations able to be done from the keyboard. This is just to say
+thanks your work is really appreciated and I will definitely be keeping
+an eye on developments. There are far too many bloatware web browsers
+round now this fills a gap for sure.
+
+I noticed there is a bug report regarding viewing items on eBay, is
+there anything I can do to help with this? I don't know anything about
+C, but I do development for HTML and Zope if there is anything I can do
+regarding testing etc. let me know.
+
+Thanks again and have a fantastic day.
+
+Steve
+-------------------------------------------------------
+Your Solutions Ltd, +44 (0)207 473 1004, London, UK
+http://www.yoursolutions.com/ IT Technical services
+------------------------------------------------------- 
+
+
+
+[Dillo-dev]<br><br>...<br>
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-08 13:27
+
+Hi,
+
+Michael Duelli wrote:
+
+> Hi,
+> I don't know if this is a bug but it seems like dillo does render several
+> <br> as one <br>.
+
+I even received a patch for this, but when reviewing the HTML
+specs, it was undefined!
+
+Netscape and Mozilla add a blank line for each <br>, but lynx
+doesn't! Is hard to tell wich is right because when it's not
+clearly stated in the standar, it's up to the user agent.
+
+Personally, I tend to think that the philosophy behind HTML/XML
+rendering, is to let the user agent (AKA browser) decide how to
+render contents, and to allow extra fine-tunning, on appearance,
+to CSS.
+
+If anyone can provide a SPEC quote, or related work, that shows
+some more light on it, it'd be appreciated.
+
+
+Cheers
+Jorge.- 
+
+
+
+RE: [Dillo-dev]configure
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-08 13:27
+
+Hi!
+
+Bjoern Weber wrote:
+
+> Something concerning the configure script.
+> Upon compiling dillo-0.6.2 on a sparc with NetBSD 1.5
+> I encountered a couple of problems with the results of
+> the configure script. The script found out that there was
+> no pthread.h (which is correct) but still insisted using it.
+
+AFAIU detecting and configuring is automake&autoconf work (they
+generate configure). So, I'd suggest to get a few pthreaded SW
+packages, that use autoconf stuff, and see how do they solve the
+problem in *BSD.
+
+If one of them manages to detect and configure the right
+includes and libs, it'd be a matter of examining its configure.in
+and pasting to dillo!
+
+OTOH, if none of the sample packages does it right, most
+probably is a bug, or problem, of the autoconf stuff...
+
+[the same applies for jpeg]
+
+> Although it did not find any headers for libjpeg or libpng
+> which are clearly installed. Interesting fact, if the
+> configure finds out that there is no *jpeg*.h, the matching
+> source will be compiled though, only the -ljpeg in the
+> linker options is omitted. This behaviour I could reproduce
+> on the sparc as well as on a qnx-X86 machine.
+
+Yes, jpeg's code is not nested inside a #ifdef; in any case, I
+don't yet find very useful to add the option of excluding jpeg or
+png or gif...
+
+The point is that Jpeg libs must be found unless installed in a
+weird location (as /opt/custom/vodooo/...). So usr/local/...
+should be detected!
+
+[The same strategy as for pthread is advised]
+
+> But the good thing is, after adapting the Makefile both
+> dillo's are running smoothly!
+
+That's why dillo is listed to run in *BSD!
+
+Please send me the details of your QNX config, so I can list it
+in the platform compatibility list.
+
+
+
+Sammy wrote:
+
+> hi,
+>
+> i've found two problems with the configure script. one thing
+> is that the --with-jpeglib & --with-jpeginc options aren't
+> working. these should be fixed in the next release (i sent
+> in a patch). this should solve the jpeg includes not being
+> found in net/open/freebsd (i use freebsd).
+
+I already commited a slightly modified patch to CVS, please
+test it and tell me how it does.
+
+Note: this patch doesn't solve the problem of detecting the
+installation place, it just provides a way to explicitly specify
+where they are.
+
+Note2: It's basically Sammy's patch, but I don't have a *BSD to
+test it.
+
+
+> i also sent in a patch that corrects the -pthread problem
+> but it probably won't come into the main tree as it was a
+> rather large fix (because of the inclusion of two scripts
+> from autoconf to detect the hosttype).
+> the problem for pthread could be solved easily though
+> (also with passing a --with-libpthread option or something
+> alike where you can add linker options to use instead of
+> the default -lpthread)
+
+Let's try the above described procedure. If everything fails, a
+configure option (as --without-libpthread) can be developed as a
+workaround...
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]email problems
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-07 22:41
+
+Hi there!
+
+
+I've been under a pretty busy schedule: big patches, lots of
+email, a lot of code to review, and my nettaxi account stopped
+receiving email and started bouncing it :(.
+
+Mmmm, that's a tough problem. I dislike a lot to lose email,
+so, please, those of you that sent me anything between Nov 2 and
+Nov 7, please resend it to jcid@so... (I just updated
+the forwarding address), or to my ematic account. Thanks.
+
+And as we're talking about email, the [mailing list] link of
+the home page was updated; please click it, an read what it says,
+specially the newest subscribers.
+
+
+Finally, beware that current CVS is not as stable as usual.
+We're dealing with massive patches and it'll take extra work to
+tune it up!
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Just uploaded
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-07 17:51
+
+Hi!
+
+Thanks for the hints so far. Some notes:
+
+Two bugs have already been fixed: (i) in <PRE>, words should not be
+wrapped, and (ii) crashes at long pages. Changes are in the CVS.
+
+About Lists: I can reproduce this every time with
+http://www.rti-zone.org/dillo/Html.testsuite/lists_unord.html, but not
+locally, this is the reason why I did not notice the bug before. BTW,
+if you look at the source, you'll find that indentation is now done by
+nested widgets (for simplicity), so the problem is that somehow whole
+widgets are not seen. For testing, resize the window, then the missing
+lists will suddenly appear.
+
+Sebastian 
+
+
+
+[Dillo-dev]Segmentation fault in Dw_page_word_wrap
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-07 17:49
+
+Hi! I've been getting segfaults with dillo recently, normally after
+using it for a while. I ran it in gdb to try to isolate the problems,
+unfortunately that made X get stuck when it actually segfaulted. I had to
+kill gdb, but its dying words were:
+
+Nav_open_url: Url=3D>http://www6.tomshardware.com/cpu/index.html<
+
+Program received signal SIGSEGV, Segmentation fault.
+Dw_page_word_wrap (page=3D0x86b67e0, word_ind=3D5765) at dw_page.c:687
+687 last_line->top =3D
+(gdb) Terminated
+
+Hopefully its sacrifice is not in vain:)
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]dillo
+
+From: Intrepids Wrath <bigbrat64@ho...> - 2001-11-07 16:30
+
+Just downloaded the dillo web browser really love the speed.
+I am fairly new to the linux envirement. as you can see though manged to 
+get dillo up and running really quick. Only ten seconds after up and 
+running it froze.
+Probably something from my side not sure am really fast learner took me 
+about an hour to learn how to compile files without documentation. and 
+would like to participate in this project
+even if it's just posting little minor erros recieved. But also 
+learning really fast on source codes. running mandrake 8.0 had to add a 
+few files in compiling cause recieved errors the first 2 attempts but 
+once I loaded the file opened with ease. I took the browser into a 
+message board and it opens ok but will not open threads sends you back 
+to logins. Also a little familiar with wing commander for editing if 
+there is a source that can be edited into the dillo would appreciate all 
+that I can play with. Thank-you for your time
+One dedicated illeterate computer abuser.lol 
+
+
+
+Re: [Dillo-dev]Just uploaded
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-07 11:14
+
+Hello again... here's some more feedback...
+
+Livio Baldini Soares writes:
+> Sebastian Geerken writes:
+> > Hi!
+> > 
+> > I've just uploaded some major changes, especially in DwPage. I've
+> > tested it, but it would be better to get some feedback.
+
+(...)
+
+> http://www.ime.usp.br/~kon/MAC5755/noticias.html
+> http://www.ime.usp.br/dcc/posgrad/bolsas/cand-bolsa.html
+> http://www.ime.usp.br/dcc/posgrad/faq/faq2/node2.html
+> http://www.ime.usp.br/dcc/ (this is a different problem.. the links on the
+> right column can't be clicked)
+
+The problem seems to show up when the pages are already in the cache. They may
+load up fine for the first time but go back and then forward again... generally
+the lists will be gone.
+
+> http://www.rti-zone.org/dillo/Html.testsuite/lists_ord.html and
+> http://www.rti-zone.org/dillo/Html.testsuite/lists_lists_unord.html render just fine...
+
+Not exactly.. these too very seldomly get renderd incorrectly. Usually the
+last list on both of these pages (30 element, and 4-nested). Try viewing these
+from cache, or reloading the pages, then maybe you'll see what I mean.
+
+
+And there is another issue that showed up after the changes... Some borders on
+tables are rendering wider on the top then on the rest of the table. For
+example:
+
+http://www.happypenguin.org (check out the tables on the _right_ column of the
+page - where they have links to other sites)
+http://www.ime.usp.br/dcc/pograd/ (there is only one big table with a blue border)
+
+Sorry I can't help out on finding these problems... but I have no time on my
+hands :(
+
+best regards to all,
+
+-- 
+Livio <livio@li...> 
+
+
+
+[Dillo-dev]email problems
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-11-07 00:06
+
+Hi there!
+
+
+I've been under a pretty busy schedule: big patches, lots of
+email, a lot of code to review, and my nettaxi account stopped
+receiving email and started bouncing it :(.
+
+Mmmm, that's a tough problem. I dislike a lot to lose email,
+so, please, those of you that sent me anything between Nov 2 and
+Nov 6, please resend it to jcid@so... (I just updated
+the forwarding address), or to my ematic account. Thanks.
+
+And as we're talking about email, the [mailing list] link of
+the home page was updated; please click it, an read what it says,
+specially the newest subscribers.
+
+
+Finally, beware that current CVS is not as stable as usual.
+We're dealing with massive patches and it'll take extra work to
+tune it up!
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]<br><br>...<br>
+
+From: Michael Duelli <m.duelli@we...> - 2001-11-06 20:21
+
+Hi,
+
+I don't know if this is a bug but it seems like dillo does render several 
+<br>s as on <br>.
+
+Regards,
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net
+http://linuxmaths.s...net 
+
+
+
+Re: [Dillo-dev]Just uploaded
+
+From: Livio Baldini Soares <livio@li...> - 2001-11-06 19:11
+
+Hello Sebastian!
+
+Sebastian Geerken writes:
+> Hi!
+> 
+> I've just uploaded some major changes, especially in DwPage. I've
+> tested it, but it would be better to get some feedback.
+
+Humm.. I seem to be getting some problems rendering lists (ordered or
+unordered). But I can't come up with a single test case which fails for me 100%
+of the time... here are some links to simple pages which (sometimes) shows this
+problem:
+
+http://www.ime.usp.br/~kon/MAC5755/noticias.html
+http://www.ime.usp.br/dcc/posgrad/bolsas/cand-bolsa.html
+http://www.ime.usp.br/dcc/posgrad/faq/faq2/node2.html
+http://www.ime.usp.br/dcc/ (this is a different problem.. the links on the
+right column can't be clicked)
+
+The lists disappears altogether... (check the sources to see what I mean). But
+this is not true to all lists, for example the tests at
+http://www.rti-zone.org/dillo/Html.testsuite/lists_ord.html and
+http://www.rti-zone.org/dillo/Html.testsuite/lists_lists_unord.html render just fine...
+
+Besides these problems, the rest seem to be just fine. ;)
+
+best regards,
+
+-- 
+Livio <livio@li...> 
+
+
+
+Re: [Dillo-dev]configure
+
+From: Bjoern Weber <foxbow@we...> - 2001-11-06 08:22
+
+DraX <drax@wh...> schrieb am 05.11.01:
+> the jpeg .h's are installed by default in /usr/local/include 
+> and ./configure (atleast on openbsd) dosen't pick them up. 
+> so try ln -s'ing cp'ing or playing wtih configure options.
+Well, as I told, I managed to get things running and I 
+consider /usr/local/ a reasonable place for additional
+libraries/includes, so configure should be able to find
+things there as well. But as I read before, the 
+(malfunctioning) --with-jpeglib= options will be working
+in the next release, so the problem shall dissolve then.
+
+Bjoern
+-- 
+Sometimes, even at infinity, the largest distance
+can be much too close...
+______________________________________________________________________________
+Lotto online tippen! Egal zu welcher Zeit, egal von welchem Ort. 
+Mit dem WEB.DE Lottoservice. http://tippen2.web.de/?x=5 
+
+
+
+[Dillo-dev]Minding my own business..optional reading : )
+
+From: Richard <hebertrich@ya...> - 2001-11-05 19:54
+
+Normally i mind my own business..
+Sip my coffee and look in from the sidelines..
+
+There are lots of people out there making things timeless..
+Some other make huge efforts at duplicating what's been done.
+A good example is IRC clients for Linux.
+There are more than we can can count.
+Web browsers are basically the same.
+Skipstone,Galeon,Opera,Mozilla,Netscape,Explorer ( i 
+stop here the page would be half-full ) All of them have 
+the same basic goal.Display everything,do everything and if it does the job
+half assed,well too bad.They all have plug-ins , cookies, java 
+and i leave aside the graphical interface that is basically the same.
+
+As far as i can make it they try with more or less success
+to stick to the standards and render pages more or less like they
+were intended to be viewed by the designer.A page seen in Explorer dosent
+look the same in Netscape..
+
+What im asking myself is this.
+What has Dillo to offer that will make it unique,have a "market share"
+that's his own and be able to grow and be popular ?
+Certainly you can see that in the browser war, unless your browser
+has something unique, has a unique approach to doing things
+or something that can make the balance tip so ever lightly in it's favor 
+that the best efforts of the programmers will be in the long term vain 
+and Dillo would stay a project that never lifted off the runway.
+
+Back i started with a Altair 6800 , i was programming with switches and
+reading the output in bin on a row of led's.I seen lot's software since.
+All the projects that have been successful software wise had something
+unique and innovative.Written in C is an advantage, i grant you.
+But to the user ? What are you getting him ready for as an experience 
+that is unique so that Dillo gets spoken of and is turned into a
+success story ?
+
+Im interrested to the max in Dillo.
+I beleive you're at a crossroads and that this browser can do real
+well in the open source community.
+I just havent seen any thoughts about where you guys are going.
+I see feature requests that more or less are what's in other browsers.
+If you can resist the traps of being just like any other browser
+this project stands a fair chance.
+Then again what can this project offer the end user that will make it unique ?
+Im curious about your thoughts on the matter.
+
+
+Yeah i know what business is it of mine ? : ) 
+
+Richard Hebert
+Computing enthusiast.
+
+
+
+
+
+
+
+
+
+
+
+
+
+_________________________________________________________
+Do You Yahoo!?
+Get your free @yahoo.com address at http://mail.yahoo.com 
+
+
+
+Re: [Dillo-dev]configure
+
+From: DraX <drax@wh...> - 2001-11-05 18:36
+
+the jpeg .h's are installed by default in /usr/local/include and
+./configure (atleast on openbsd) dosen't pick them up. so try ln -s'ing
+cp'ing or playing wtih configure options.
+
+
+On Mon, 5 Nov 2001, Bjoern Weber wrote:
+
+> 
+> Something concerning the configure script.
+> Upon compiling dillo-0.6.2 on a sparc with NetBSD 1.5
+> I encountered a couple of problems with the results of
+> the configure script. The script found out that there was
+> no pthread.h (which is correct) but still insisted using it.
+> Although it did not find any headers for libjpeg or libpng
+> which are clearly installed. Interesting fact, if the
+> configure finds out that there is no *jpeg*.h, the matching
+> source will be compiled though, only the -ljpeg in the
+> linker options is omitted. This behaviour I could reproduce
+> on the sparc as well as on a qnx-X86 machine.
+> 
+> Should that be consider as a bug or a glitch that will be
+> fixed in the cleanup - I did not find a matching entry yet.
+> 
+> But the good thing is, after adapting the Makefile both
+> dillo's are running smoothly!
+> 
+> Bjoern Weber
+> -- 
+> Sometimes, even at infinity, the largest distance
+> can be much too close...
+> ________________________________________________________________
+> Lotto online tippen! Egal zu welcher Zeit, egal von welchem Ort.
+> Mit dem WEB.DE Lottoservice. http://tippen2.web.de/?x=13
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]New dillo-cvs crashes on big htmlpages
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-11-05 18:31
+
+Hi, all.
+
+The new code in cvs seems to bail out on big html-pages.
+It crashes in
+Dw_page_word_wrap, dw_page.c:687
+repeatedly.
+
+Testcases: http://i184.ryd.student.liu.se/
+
+-- 
+//Hugo Hallqvist - hugha495 at student dot liu dot se 
+
+
+
+[Dillo-dev]Just uploaded
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-05 17:45
+
+Hi!
+
+I've just uploaded some major changes, especially in DwPage. I've
+tested it, but it would be better to get some feedback.
+
+The documentation in the distribution has partly become out of date,
+but will be updated within a few days.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]configure
+
+From: Sammy Mannaert <nstalkie@tv...> - 2001-11-05 16:56
+
+Bjoern Weber wrote:
+> 
+> Something concerning the configure script.
+> Upon compiling dillo-0.6.2 on a sparc with NetBSD 1.5
+> I encountered a couple of problems with the results of
+> the configure script. The script found out that there was
+> no pthread.h (which is correct) but still insisted using it.
+> Although it did not find any headers for libjpeg or libpng
+> which are clearly installed. Interesting fact, if the
+> configure finds out that there is no *jpeg*.h, the matching
+> source will be compiled though, only the -ljpeg in the
+> linker options is omitted. This behaviour I could reproduce
+> on the sparc as well as on a qnx-X86 machine.
+> 
+> Should that be consider as a bug or a glitch that will be
+> fixed in the cleanup - I did not find a matching entry yet.
+> 
+> But the good thing is, after adapting the Makefile both
+> dillo's are running smoothly!
+> 
+
+hi,
+
+i've found two problems with the configure script. one thing
+is that the --with-jpeglib & --with-jpeginc options aren't 
+working. these should be fixed in the next release (i sent
+in a patch). this should solve the jpeg includes not being
+found in net/open/freebsd (i use freebsd).
+i also sent in a patch that corrects the -pthread problem
+but it probably won't come into the main tree as it was a 
+rather large fix (because of the inclusion of two scripts
+from autoconf to detect the hosttype). 
+the problem for pthread could be solved easily though 
+(also with passing a --with-libpthread option or something
+alike where you can add linker options to use instead of
+the default -lpthread) 
+
+
+
+Re: [Dillo-dev]Plugins sustem ?
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-11-05 15:40
+
+On Fri, Nov 02, 2001 at 05:11:54PM +0100, Rolly Arnaud wrote:
+> Hi!
+> I'm new to the mailing-list and i've few questions :
+> 
+> 1) Dillo have a strange behaviour when rendering backgrounds on many websites 
+> (slashdot for example) : Is it due to the politic 'render only correct HTML' ?
+
+Do you mean the following:
+
+1. Go to "
+2. Go then to another section, e.g.
+- " or
+- " or
+- ...
+The round corners of the titles are then drawn incorrectly:
+green on grey/brown background.
+
+This is because these images are read from an additional cache, the
+DICache (Decompressed Image data), which handles only RGB data, and so
+has problems with transparency.
+
+So, this is indeed a bug.
+
+> 2) I'm interested in a plug-in system that would allow integration of new 
+> embedding functionnalities (aka Netscape plug-ins). Is it possible with the 
+> current software design ? Is there someone working on it ?
+
+Look at " section
+"Plugins". Graphical plugins are planned, but not for the next time,
+one problem is that the current rendering is not very mature, there
+will be still relevant changes in it.
+
+Sebastian 
+
+
+
+[Dillo-dev]configure
+
+From: Bjoern Weber <foxbow@we...> - 2001-11-05 15:25
+
+Something concerning the configure script.
+Upon compiling dillo-0.6.2 on a sparc with NetBSD 1.5
+I encountered a couple of problems with the results of
+the configure script. The script found out that there was
+no pthread.h (which is correct) but still insisted using it.
+Although it did not find any headers for libjpeg or libpng
+which are clearly installed. Interesting fact, if the
+configure finds out that there is no *jpeg*.h, the matching
+source will be compiled though, only the -ljpeg in the
+linker options is omitted. This behaviour I could reproduce
+on the sparc as well as on a qnx-X86 machine.
+
+Should that be consider as a bug or a glitch that will be
+fixed in the cleanup - I did not find a matching entry yet.
+
+But the good thing is, after adapting the Makefile both
+dillo's are running smoothly!
+
+Bjoern Weber
+-- 
+Sometimes, even at infinity, the largest distance
+can be much too close...
+________________________________________________________________
+Lotto online tippen! Egal zu welcher Zeit, egal von welchem Ort.
+Mit dem WEB.DE Lottoservice. http://tippen2.web.de/?x=13 
+
+
+
+Re: [Dillo-dev]features .yes but which ? 
+
+From: Carl Wilhelm Soderstrom <chrome@re...> - 2001-11-04 04:11
+
+> If i wanted frills id get Mozilla which i trashed and dont use.
+> If i need a reasonably fast browser with pulg in support for fun pages and downloads
+> i use Opera.
+
+take a look at Galeon (galeon.so....net). it's mozilla wrapped in GTK;
+so it's got Mozilla's rendering engine; but runs a lot faster and has more
+user-desired features (since the user interface isn't being designed by
+AOL). it still takes the same amount of memory as mozilla, due to the
+rendering engine; but at least it's a lot more responsive and
+user-customizable. 
+
+I like Dillo because it has its own rendering engine; and hopefully will
+be able to avoid the bloat that characterizes mozilla, when the rendering
+engine is done. 
+
+Carl Soderstrom
+-- 
+Network Engineer
+Real-Time Enterprises
+(952) 943-8700 
+
+
+
+Re: [Dillo-dev]features .yes but which ? ( the story of the malicious cucumber.. )
+
+From: Lars Clausen <lrclause@cs...> - 2001-11-03 20:54
+
+On Sat, 03 Nov 2001, hebertrich@ya... wrote:
+
+> Good Morning=20=20
+>=20
+>=20
+> Downloads,frames and cut and paste of text, that would be it for me .If
+> you put in cookies a way to disable them totally would be cool. Once
+> Dillo is at that point ill put it on archive and keep it .
+>=20
+> Nice work .
+> It's a great lil browser as it is, cant wait to see what's up next.
+
+Cookies are being worked on, a way to totally disable them is probably a
+good idea. I like the smallness as well, but many sites don't work without
+e.g. frames. And if we keep as many features as possible out in plugins,
+we can keep it small.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]features .yes but which ? ( the story of the malicious cucumber.. )
+
+From: Richard <hebertrich@ya...> - 2001-11-03 17:55
+
+Good Morning 
+
+
+Benn using Dillo for two weeks now.
+Trying Dillo is a fun experience.
+I was reading the bug trak ..many are more feature requests than bugs and it's by reading them
+more than noticing anything peculiar that i have a lil beef..
+
+Many of the feature enhancements requests mentioned would make dillo just like any browser.
+What's fun right now about dillo is this.It dosent support JAVA ,it has NO plugins
+it dosent animate ,dosent support cookies and there aint a thing wrong with this.
+
+What is missing is downloads,frames and text cut and paste from/to the browser.
+
+Why did i download Dillo ? Fast, no frills.
+If i wanted frills id get Mozilla which i trashed and dont use.
+If i need a reasonably fast browser with pulg in support for fun pages and downloads
+i use Opera.
+
+Traditional browsers are a pain.
+Mostly they do many things and do them bad.
+I see Dillo as the alternative to bloated,slow large and inefficient traditional browsers.
+
+See if i need a page real quick,i use Dillo 
+If i could have a fast no frils browser that supports downloads..id keep it .
+I dont need cookies , animations, flash, when i want to get information quick.
+
+I beleive Dillo has acheived this.
+Fast to the point and no frills.
+
+Downloads,frames and cut and paste of text, that would be it for me .If you put in cookies
+a way to disable them totally would be cool.
+Once Dillo is at that point ill put it on archive and keep it .
+
+Nice work .
+It's a great lil browser as it is, cant wait to see what's up next.
+
+best regards 
+richard
+
+_________________________________________________________
+Do You Yahoo!?
+Get your free @yahoo.com address at http://mail.yahoo.com 
+
+
+
+[Dillo-dev]Bug in bitvec.c line 48 ?
+
+From: Michael Duelli <m.duelli@we...> - 2001-11-03 14:47
+
+Hi,
+
+have a look at
+
+http://www.suse.de/de/support/index.html with dillo
+
+I am getting this message in the terminal several times:
+
+** CRITICAL **: file bitvec.c: line 48 (a_Bitvec_get_bit): assertion `pos 
+< bvec->len' failed.
+
+Regards,
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net
+http://linuxmaths.s...net 
+
+
+
+[Dillo-dev]Plugins sustem ?
+
+From: Rolly Arnaud <arolly@an...> - 2001-11-02 16:02
+
+Hi!
+I'm new to the mailing-list and i've few questions :
+
+1) Dillo have a strange behaviour when rendering backgrounds on many websites 
+(slashdot for example) : Is it due to the politic 'render only correct HTML' ?
+
+2) I'm interested in a plug-in system that would allow integration of new 
+embedding functionnalities (aka Netscape plug-ins). Is it possible with the 
+current software design ? Is there someone working on it ?
+
+Thanks. 
+
+
+
+Re: [Dillo-dev]Re: feature request: searching HTML source
+
+From: Steve Nicholson <steve.nicholson@yo...> - 2001-11-01 22:34
+
+> > It's not the web browsers job. It shouldn't be there. It
+> adds bloat to the browser, and other applications problary does a
+better job.
+
+I have to agree, it doesn't matter if it only uses a small amount of
+memory or cpu adding this. If you added every feature everyone wanted
+as part of the main program it would be bloated and slow like the rest.
+I want something that does the core things fast. I do web development
+and don't consider quickly viewing source to be core, there are lots of
+ways available for me to do that. I find some of the source viewers
+frustrating in other apps and want to be able to choose what I use.
+Since it is mainly more technical people that would want this it would
+be better to have it more configurable than an internal viewer. If it's
+a quick peak I want calling a basic xterm with Less will do, then a
+different keybinding to have an in-depth look with something that
+colours the different tags is what I want.
+
+I came in half way through this thread since I only came across Dillo
+yesterday and joined the list but wanted to express my view on it. I
+think all the extra bits that other programs do well should be left to
+those programs, e.g. downloading files use wget, etc. If the user has
+to configure a download tool this could be considered a feature by some
+IT departments as it would prevent most uses from downloading crap to
+their work PC.
+
+Steve. 
+
+
+
+[Dillo-dev]problems browsing gtk-manual
+
+From: Hugo Hallqvist <hugha495@st...> - 2001-11-01 19:56
+
+Hi everyone!
+
+I noticed a few problems when browsing gtks and glibs reference documentation today.
+There are alot of these things inside the html-files: &#8212; 
+and they didn't show up before when using the old code version 0.62.
+
+Is this a problem with the new tag-parsing code ?
+
+btw: they should show up as - (minus), atleast they do so in netscape.
+
+-- 
+//Hugo Hallqvist - hugha495@st... 
+
+
+
+Re: ENOUGH! (was: [Dillo-dev]Re: feature request: searching HTML source)
+
+From: William Kendrick <nbs@so...> - 2001-11-01 08:18
+
+On Wed, Oct 31, 2001 at 07:30:20PM -0800, Eric GAUDET wrote:
+> Enough with this childish behaviour and name calling !!!!
+> If you can't discuss in a civil manner and respect the other readers,
+> LEAVE THE LIST.
+> I don't care if you fork the project, I'm just used to the soft tone of this
+> list and I love it like that.
+
+"./configure --enable internal-source-viewer"
+
+or not!
+
+:^P
+
+
+:)
+
+-bill! 
+
+
+
+ENOUGH! (was: [Dillo-dev]Re: feature request: searching HTML source)
+
+From: Eric GAUDET <egaudet@in...> - 2001-11-01 03:30
+
+Enough with this childish behaviour and name calling !!!!
+If you can't discuss in a civil manner and respect the other readers,
+LEAVE THE LIST.
+I don't care if you fork the project, I'm just used to the soft tone of this
+list and I love it like that.
+
+-- En reponse de "Re: [Dillo-dev]Re: feature request: searching HTML source" de
+DraX, le 31-Oct-2001 :
+> On Wed, 31 Oct 2001, Martin Samuelsson wrote:
+>> On Wed, Oct 31, 2001 at 12:24:24PM -0800, DraX wrote:
+...
+...> I don't understand, bloat, bloat, bloat, bloat ...
+...
+...> I just find spawning an external proccess just to look at some html is
+...> stupid.
+...
+>> 
+>> I'm sure you'll understand the unix way in building applications about
+>> the same time you learn how to quote other people on mailing lists.
+>> Answers should be below the original text and irrelevant text should be
+>> removed. There are rfc:s defining this and, most important, it really
+>> helps the readers.
+>> 
+> Flaming me dosen't make you sound more credible you know?
+> 
+
+------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 31-Oct-2001 a 19:24:37
+"In theory, there's no difference between 
+theory and practice; in practice, there is."
+------------------------------------ 
+
diff --git a/old/oldmail/200112.txt b/old/oldmail/200112.txt
new file mode 100644
index 0000000..f64fa09
--- /dev/null
+++ b/old/oldmail/200112.txt
@@ -0,0 +1,3635 @@
+[Dillo-dev]Skript for keeping a history
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2001-12-30 20:19
+
+Hi,
+
+here's a little ruby script that starts dillo and saves a 
+browsing history (tested with 0.6.3).
+
+Regards,
+Johannes Hofmann
+
+
+
+#!/usr/local/bin/ruby
+excludes = /history.html|about:|slashdot/
+
+input = IO.popen("dillo")
+output = open(".dillo/history.html", "a+")
+
+if output.stat.size == 0 then
+output.write("""
+<html>
+<head>
+<title>History</title>
+</head>
+<body>
+""")
+end
+
+re = /Nav_open_url: Url=>([^<]+)</
+while line = input.gets 
+url = re.match (line)
+if url and not excludes.match(url[1]) then
+d = Time.new
+output.write(d.to_s+"<a href=\"" + url[1] + "\">" + url[1] + "</a><br>\n")
+output.flush
+end
+end 
+
+
+
+[Dillo-dev]Compiling 0.6.3 png trouble ?
+
+From: Richard <hebertrich@ya...> - 2001-12-28 14:51
+
+I feel like having a beer.. ( who dosen't ? : ) 
+
+Ok, here it is .. 
+This morning i took my courage in one hand and my trackball in the other.
+Got the latest Dillo pack and tried to compile it.
+At first i realised i needed some libs..so here i went and installed libjpeg-devel pack 
+libpng and it's devel pack .. but o surprise.. ( gotta love em suckers in the holidays ) 
+
+This is what i get when i run make..I need to know what is causing this.
+If anyone has an idea im interrested in knowing how to correct it .
+
+Richard 
+
+
+
+" hacking in the morning , hacking in the evening .. hacking my life away " 
+( sang to an old western beat ) 
+
+here's the listing 
+
+gcc -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -Wall -Waggregate-return -o dillo chain.o commands.o cache.o dw.o dw_bullet.o dw_container.o dw_embed_gtk.o dw_gtk_scrolled_frame.o dw_gtk_scrolled_window.o dw_gtk_statuslabel.o dw_gtk_viewport.o dw_hruler.o dw_image.o dw_marshal.o dw_page.o dw_style.o dw_table.o dw_tooltip.o dw_widget.o findtext.o web.o progressbar.o dillo.o bookmark.o dicache.o dns.o gif.o jpeg.o png.o html.o image.o misc.o interface.o nav.o plain.o menu.o prefs.o colors.o bitvec.o klist.o url.o IO/libDio.a -ljpeg -lpthread -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
+png.o: In function `Png_error_handling':
+/home/ric/dillo-0.6.3/src/png.c:108: undefined reference to `png_get_error_ptr'
+png.o: In function `Png_datainfo_callback':
+/home/ric/dillo-0.6.3/src/png.c:130: undefined reference to `png_get_progressive_ptr'
+/home/ric/dillo-0.6.3/src/png.c:133: undefined reference to `png_get_IHDR'
+/home/ric/dillo-0.6.3/src/png.c:147: undefined reference to `png_get_valid'
+/home/ric/dillo-0.6.3/src/png.c:151: undefined reference to `png_set_expand'
+/home/ric/dillo-0.6.3/src/png.c:155: undefined reference to `png_set_strip_16'
+/home/ric/dillo-0.6.3/src/png.c:161: undefined reference to `png_get_gAMA'
+/home/ric/dillo-0.6.3/src/png.c:162: undefined reference to `png_set_gamma'
+/home/ric/dillo-0.6.3/src/png.c:167: undefined reference to `png_set_gray_to_rgb'
+/home/ric/dillo-0.6.3/src/png.c:172: undefined reference to `png_set_interlace_handling'
+/home/ric/dillo-0.6.3/src/png.c:176: undefined reference to `png_read_update_info'
+/home/ric/dillo-0.6.3/src/png.c:178: undefined reference to `png_get_IHDR'
+/home/ric/dillo-0.6.3/src/png.c:181: undefined reference to `png_get_rowbytes'
+/home/ric/dillo-0.6.3/src/png.c:182: undefined reference to `png_get_channels'
+png.o: In function `Png_datarow_callback':
+/home/ric/dillo-0.6.3/src/png.c:218: undefined reference to `png_get_progressive_ptr'
+/home/ric/dillo-0.6.3/src/png.c:220: undefined reference to `png_progressive_combine_row'
+png.o: In function `Png_dataend_callback':
+/home/ric/dillo-0.6.3/src/png.c:280: undefined reference to `png_get_progressive_ptr'
+png.o: In function `Png_callback':
+/home/ric/dillo-0.6.3/src/png.c:321: undefined reference to `png_destroy_read_struct'
+/home/ric/dillo-0.6.3/src/png.c:349: undefined reference to `png_check_sig'
+/home/ric/dillo-0.6.3/src/png.c:355: undefined reference to `png_create_read_struct'
+/home/ric/dillo-0.6.3/src/png.c:361: undefined reference to `png_create_info_struct'
+/home/ric/dillo-0.6.3/src/png.c:366: undefined reference to `png_set_progressive_read_fn'
+/home/ric/dillo-0.6.3/src/png.c:380: undefined reference to `png_process_data'
+collect2: ld returned 1 exit status
+make[3]: *** [dillo] Error 1
+make[3]: Leaving directory `/home/ric/dillo-0.6.3/src'
+make[2]: *** [all-recursive] Error 1
+make[2]: Leaving directory `/home/ric/dillo-0.6.3/src'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory `/home/ric/dillo-0.6.3'
+make: *** [all-recursive-am] Error 2
+[root@ric dillo-0.6.3]# rpm -q libpng
+libpng-1.0.12-2
+[root@ric dillo-0.6.3]# rpm -q libpng-devel
+libpng-devel-1.0.12-2
+
+... - - - ...
+
+_________________________________________________________
+Do You Yahoo!?
+Get your free @yahoo.com address at http://mail.yahoo.com 
+
+
+
+[Dillo-dev]dillo freezing up in some sites, proxy involved
+
+From: Jyri Jokinen <autumn.rider@su...> - 2001-12-27 16:42
+
+This is an odd one. It seems that the way Dillo is started affects
+it's way to use a proxy. When a certain site comes straight from the
+Squid cache running on the same machine as Dillo, and Dillo is started
+in a particular way, it freezes up.
+
+Please see http://surffi.net/~arider/dillo/ for a better
+explanation and screensots.
+
+-- 
+jyri jokinen 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-24 21:38
+
+> Did you read the email?
+> 
+> We were talking about the bugtrack engine (a collection of CGI
+> programs written in python, that never use GTK+).
+
+D'oh. I thought you meant the main browser. Oops...(stupid me, 
+getting the context all wrong)
+
+---
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+[Dillo-dev]0.6.3 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-23 13:00
+
+Hi!
+
+Finally, the so awaited 0.6.3 release is out. It was a long
+road, but we can be confident that our efforts ended up in an
+outstanding quality version of dillo.
+
+So those of you that still don't have it: go get it!
+
+
+Regards, and receive my best wishes for these holidays.
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-23 12:59
+
+On Sun, 23 Dec 2001, Clinton Ebadi wrote:
+
+> > Does anyone here knows python and feels like adding that?
+> > It's very simple, all the data is in a plain text file, with
+> > concurrency handling done using the voluntary file lock protocol.
+>
+> But why not Guile (the official GNU extension language) as a
+> plugin/extension language. It is the official GNU extension language.
+> It can even do threading using QuickThreads, and OO with GOOPS. I've
+> been reading the source and have tried to figure out where it would
+> work, but all the Gtk+...(since I don't know Gtk+ this is a problem).
+
+!?
+
+Did you read the email?
+
+We were talking about the bugtrack engine (a collection of CGI
+programs written in python, that never use GTK+).
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]A word of thanks
+
+From: Dan P. <danp27@ce...> - 2001-12-23 06:14
+
+Hello, Just a note to let you know how much I enjoy using Dillo. I guess
+I've tried, and cursed, just about every browser out there for years but I
+well remember my first reaction upon loading Dillo. It went something like
+"HOLY SH*T,it's loaded already!". I knew then and there that I had hit
+gold. The only thing faster is maybe lynx.
+
+I use Dillo everyday, It is my primary browser of choice. I still keep
+Netscape 4.7 and mozilla around for emergency viewing of troublesome pages
+(image maps,java,persistent cookies and the like) but it is a last resort
+that will make me fire up anything else. I look forward to a new version of 
+Dillo like a 6 year old looks forward to Christmas.
+
+Thank you very much for all your hard work, it is deeply appreciated. 
+Gotta go, Ive got a proggy to compile (0.6.3 is out). 
+
+Sincerely,
+Dan P. 
+
+
+
+[Dillo-dev]0.6.3 release
+
+From: Jorge Arellano Cid <jcid@in...> - 2001-12-23 20:18
+
+Hi!
+
+Finally, the so awaited 0.6.3 release is out. It was a long
+road, but we can be confident that our efforts ended up in an
+outstanding quality version of dillo.
+
+So those of you that still don't have it: go get it!
+
+
+Regards, and receive my best wishes for these holidays.
+Jorge.-
+
+
+-- 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-22 20:29
+
+> > Bug 238 is not a bug, if the poster is on the list, please install
+> > GNU Make, as the make provided with OpenBSD(pmake as it is often
+> > called) does not support some things that the GNU automake/autoconf
+> > tools do in the makefiles.
+> I don't think that forcing users to install gmake is a good idea. I
+> hardly beleive that it's possible to create the makefiles so both gnu
+> and bsd (and other) make utilities can do the job. I'm going to do
+> some work on this, because I'm also affected as a hardcore BSD'er :)
+
+This has been fixed in Automake 1.5 (which doesn't work with most 
+automake 1.4 setups). Of course, this bug only applies to the 
+maintainer specific portions of the makefiles, so if you don't 
+./configure --enable-maintainer-mode, it would work (I think). It has 
+to do with the automatic dependecy tracking, which was completely 
+replaced in 1.5. So, unless you are using GNU make you can't do stuff 
+like 'make dist'.
+
+---
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-22 20:29
+
+> Does anyone here knows python and feels like adding that?
+> It's very simple, all the data is in a plain text file, with
+> concurrency handling done using the voluntary file lock protocol.
+
+But why not Guile (the official GNU extension language) as a 
+plugin/extension language. It is the official GNU extension language. 
+It can even do threading using QuickThreads, and OO with GOOPS. I've 
+been reading the source and have tried to figure out where it would 
+work, but all the Gtk+...(since I don't know Gtk+ this is a problem).
+
+> By now I'm too busy too work on it, and very concerned about
+> 0.6.3 release. BTW, how has the CVS version being doing? (I have only
+> a couple of comments. Should I assume it was OK? :)
+
+the unknown_lamer thinks that 0.6.3 should have cookies. Of course, 
+it isn't a big issue since I now have 384MB of ram...(but, why waste 
+that with Mozilla when I can fill it with a thousand instances of 
+dillo instead!)
+
+---
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+[Dillo-dev]Re: Font size problem with locales, and null char in text files
+
+From: Niklas Hoglund <niklas.hoglund@te...> - 2001-12-21 19:39
+
+On Wed, Dec 12, 2001 at 07:57:46PM -0300, Jorge Arellano Cid wrote in
+a private mail:
+
+> Niklas,
+>=20
+> > I'm experiencing two bugs in Dillo 0.6.2. Firstly, if I have my
+> > default locale setting, LC_ALL=3Dsv_SE, Dillo ignores the font_factor
+> > setting and displays tiny fonts. With LC_ALL=3DC it works OK.
+> >
+> > Secondly, and this is more an irritating thing than a bug, when
+> > displaying for example the changelog on Dillo's homepage every line
+> > begins with a null character (the one used when the font lacks some
+> > character). This only happens on text displayed with the fixed-width
+> > font.
+> >
+> > If it matters any, I use the Debian package of Dillo.
+>=20
+> I hope by this time you have been able to solve the problem.
+> Anyway, I've heard of font loading problems before, specially
+> from swedish guys!, and I don't know what it is, but it seems
+> that their distributions lack some fonts that others have
+> included by default, and that dillo requires.
+
+I'm using the Debian distribution. Dillo uses small font sizes if
+LC_ALL=3Dsv_SE (which is my default). It works well if I start it with
+"LC_ALL=3DPOSIX dillo", so it's really not a problem, but a bug.
+
+I still get the squares at the start of every line in a <pre>. I guess
+that's the newline being rendered or something. I found something
+about that in the mailing list archives, so maybe that's fixed. I'm
+using the debian package of dillo, which may be a bit old. (The title
+bar says 0.6.1 while it's loading, and the splash page says 0.6.2,
+which it is. :)
+
+> It works perfectly here, believe me!
+>=20
+> If you still have trouble with it, please check the mailing
+> list archives, there're plenty of swedish guys to ask, but don't
+> ask J=F6rgen (he has had trouble with it :).
+>=20
+> Finally, if you found a solution, please let me know what it
+> was, with a view to include it in the README file.
+
+I guess you already knew LC_ALL=3DPOSIX as that's in the archives. There
+seemed to be a fix for the squares in <pre> available too.
+
+By the way, it'd be nice if the mailing list archives were available
+in mbox format. I find it much more convenient to use my mailer than
+web pages with just a few unthreaded messages per page. Maybe that's
+something that can be added if Dillo is moved somewhere else.
+
+> PS: sorry for this delayed answer, but now that I have a little
+> span of time, I'm backtracking my email queue and found your
+> letter...
+
+No problem. Dillo is still usable, and for heavier browsing can always
+use Galeon. (And sometimes I even use Netscape, as Debian's Galeon
+doesn't yet support java or flash.) Galeon is a bit sluggish, though,
+so I'll be happy when Dillo gets mature enough to use for most
+surfing. (I'm mostly lacking frames and ftp downloads.)
+
+--=20
+Happy holidays,
+Niklas 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: DraX <drax@wh...> - 2001-12-21 16:18
+
+As a "hardcore" BSD user my self I can understand, but atleast half of the
+apps people compile and install need gmake anyway, one project isn't going
+to change anything, and it would be a large ammount of work because the
+make files would need to be patched everytime they were generated by
+./configure, etc. Installing gmake is easy, it's a package and it's in
+ports/pkgsrc. 
+
+
+
+On Fri, 21 Dec 2001, Miklos Magyari wrote:
+
+> DraX wrote:
+> > 
+> > Bug 238 is not a bug, if the poster is on the list, please install GNU
+> > Make, as the make provided with OpenBSD(pmake as it is often called) does
+> > not support some things that the GNU automake/autoconf tools do in the
+> > makefiles.
+> 
+> hi,
+> 
+> I don't think that forcing users to install gmake is a good idea. I
+> hardly beleive that it's possible to create the makefiles so both gnu
+> and bsd (and other) make utilities can do the job. 
+> I'm going to do some work on this, because I'm also affected as a
+> hardcore BSD'er :)
+> 
+> cheers,
+> Miki
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]Re: Dillo's bug-track engine - submitter's email
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-21 14:19
+
+Pekka,
+
+> Hi,
+>
+> On the mailinglist you asked if anyone knowing python, would like to add
+> submitters email to bug-track engine. I have coded little with python,
+> so if no one else has volunteered I could do it.
+
+Thanks for the interest, but Mallum is handling that now!
+
+
+> Another feature I would like to see in bug-track is converting urls to
+> links. It's PITA to write them manually.
+
+That's not the Bugtrack's fault, but dillo not being able (nor
+allowing) to cut&paste text from the rendered area :(
+
+Workaround tip:
+
+View source, scroll to the BUG# and copy&paste from there!!!
+At least that's what I do.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-21 14:19
+
+Mallum,
+
+On Thu, 20 Dec 2001, mallum wrote:
+
+> I know Python pretty good. Can I get at the Bug reporting code via cvs?
+
+NO, but here's how!
+
+Get:
+
+http://dillo.s...net/Bugtrack-html.tar.gz
+http://dillo.s...net/Bugtrack-dec.tar.gz
+
+Bugtrack-html.tar.gz has the HTML interface.
+Bugtrack-dec.tar.gz has the CGIs.
+
+Note that within the CGI tarball:
+
+drwsrwsr-x jcid/dillo 0 2001-11-16 08:11 bugtrack/
+-rwxrwxrwx jcid/dillo 19810 2001-12-18 06:56 bugtrack/BugTrack.DB
+-rwxrwxr-x jcid/dillo 3040 2001-01-08 20:52 bugtrack/Dillo_volunteer.cgi
+-rwxrwxrwx jcid/dillo 19498 2001-12-17 21:22 bugtrack/BugTrack.DB.tmp
+-rwxrwxr-x jcid/dillo 3036 2001-01-08 20:49 bugtrack/Dillo_insert.cgi
+-rwxrwxr-x jcid/dillo 5482 2001-01-08 21:37 bugtrack/Dillo_insert.py
+-rwxrwxr-x jcid/dillo 4060 2001-01-08 21:37 bugtrack/Dillo_query.cgi
+-rwxrwxr-x jcid/dillo 3937 2001-06-28 09:36 bugtrack/Dillo_volunteer.py
+-rwxrw-rw- jcid/dillo 3 2001-12-18 06:56 bugtrack/IDNum.DB
+-rw-rw-r-- jcid/dillo 123 2001-01-08 20:33 bugtrack/wrapper.c
+-rwxrwxr-x jcid/dillo 662 2001-01-10 19:42 bugtrack/Dillo_text.py
+-rw-r--r-- jcid/dillo 1039 2001-09-27 20:57 bugtrack/BTrm.py
+-rwxr-xr-x jcid/dillo 17323 2001-11-16 08:10 bugtrack/BugTrack.DB.BAK
+
+
+- Permissions are very important.
+- .cgi named programs are simple C wrappers to python sources
+This is not necessary! --Dillo_query.cgi is a python source,
+so it can be cleaned up.
+- BugTrack.DB is the plain text Database.
+- IDNum.DB holds the next BUG number.
+- BTrm.py serves to remove records. It isn't finished yet, and
+hopefully it should append the "deleted" records into another
+plain text Database file, so they can be queried later. For
+instance, from the query page, selecting "already fixed jobs"
+within the "Job activity search" section.
+
+- The new submitter-email camp should be optional, and not
+displayed in the query results page, when not present.
+
+- Maybe allowing a few more chars to the status camp is a good
+idea.
+
+
+Why this little bugtrack system instead of ....?
+
+Because it's specially tailored to dillo project needs,
+and it has provided a superb, clear and _fast_ interface to the
+main developers (to know the whereabouts of developing).
+
+
+Regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo, GTK --> WINGs??
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-12-21 13:29
+
+On Mon, Dec 17, 2001 at 12:24:23PM +0530, Mayuresh Kathe wrote:
+> [...]
+> Dillo fits the bill perfectly, it is small, fast and renders HTML 
+> pretty well, but it depends heavily on glib, gdk and gtk+.
+> To make it much better integrated with WindowMaker, and at the same 
+> time even more faster and lighter it would be better to implement the 
+> UI using WINGs, the default UI set for WindowMaker.
+> 
+> Is there anyone with good programming skills who could help me out 
+> with this?
+
+This is a short (and incomplete) list, which should show that porting
+is actually a quite bad idea:
+
+1. Glib usage is spread over the whole code, and given how useful
+Glib is, it does not make any sense not to use it. Notice that
+Glib can be used independently of Gtk, it has only one tenth of
+the size Gtk has.
+
+2. In Dw, the Gtk object system is used (GtkObject). In Gtk 2.0, it
+is moved to Glib, so the same applies as in 1.
+
+3. Usage of Gtk itself: The simplest part is the interface, but
+there are also some new widgets, e.g. for the connection between
+Gtk and Dw (which contains special widgets for displaying the
+documents). Porting them is probably as difficult as rewriting
+them, also since they were designed for Gtk with all its
+interfaces and features. Dw itself uses Gdk quite much.
+
+5. There are also other references, just type: 
+
+grep -l g[dt]k_ `find -name "*.c"`
+
+Additional to the port, the affected parts are of course developed
+further, and I believe synchronisation of both trees is nearly
+impossible.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]about current state of patches
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2001-12-21 12:16
+
+fre 2001-12-21 klockan 03.52 skrev Grigory Bakunov:
+[snip]
+> 2) "Cookies patch" by Lars Clausen - all we need it. This
+> patch clean and i think it's must be inject into cvs
+> after little correction for support current url handling
+> scheme.
+
+Here is a new patch, adapted for the altered url scheme. There's also
+some changes to actually make the control rules work...
+http://w1.211.telia.com/~u21114235/patch-cookies-21dec
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Miklos Magyari <miklos.magyari@et...> - 2001-12-21 07:49
+
+DraX wrote:
+> 
+> Bug 238 is not a bug, if the poster is on the list, please install GNU
+> Make, as the make provided with OpenBSD(pmake as it is often called) does
+> not support some things that the GNU automake/autoconf tools do in the
+> makefiles.
+
+hi,
+
+I don't think that forcing users to install gmake is a good idea. I
+hardly beleive that it's possible to create the makefiles so both gnu
+and bsd (and other) make utilities can do the job. 
+I'm going to do some work on this, because I'm also affected as a
+hardcore BSD'er :)
+
+cheers,
+Miki 
+
+
+
+Re: [Dillo-dev]installation
+
+From: C. Dummy <cdummy@ro...> - 2001-12-21 05:15
+
+Thanks to all of you for help. After installing gtk dev and libraries below
+I could compile no problem. It's nice little browser but I still need netscape
+for some pages.
+Andrey
+
+"G. Rob Burgess" wrote:
+
+> Wow, you are using just about the same setup as I am, right down to
+> blackbox, blackbox is awesome. I had the same probs compiling, you need to
+> get a bunch of libraries, apt-get these:
+>
+> libjpeg62-dev
+> libpng2-dev
+> libgtk1.2-dev
+>
+> and I think
+>
+> zlib1g-dev
+>
+> and possibly some others, after you get these just look where the make
+> bombs out and try to guess the library. Just to let you know it *is*
+> possible on a Debian 2.2, if you get hung up again let me know where, good
+> luck dillo & blackbox r the best. --rob
+>
+> ps I hope you have blackbox 0.6x, much better than earlier ones
+>
+> Rob Burgess
+> Network Specialist II
+> University of Miami
+>
+> On Thu, Dec 20, 2001 at 11:48:24AM -0500, C. Dummy wrote:
+> > I'm linux newbie. I run Debian 2.2 with all dev libraries. I use
+> > Blackbox window manager. Small and fast. I'm interested in dillo 0.6.2
+> > because is small and fast. Unfortunatelly I can't install because I'm
+> > getting this errors when I do
+> > ./configure
+> > ng for GTK - version >= 1.2.0... no
+> > *** The gtk-config script installed by GTK could not be found
+> > *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
+> > *** your path, or set the GTK_CONFIG environment variable to the
+> > *** full path to gtk-config.
+> > configure: WARNING: Unable to find Gtk+ with a version >= 1.2.0
+> > checking for jpeg_destroy_decompress in -ljpeg... no
+> > configure: WARNING: *** JPEG support will not be included ***
+> > no
+> > configure: WARNING: *** JPEG support will not be included ***
+> > and following after
+> > make
+> > make all-recursive
+> > make[1]: Entering directory `/temp/dillo-0.6.2'
+> > Making all in doc
+> > make[2]: Entering directory `/temp/dillo-0.6.2/doc'
+> > make[2]: Nothing to be done for `all'.
+> > make[2]: Leaving directory `/temp/dillo-0.6.2/doc'
+> > Making all in src
+> > make[2]: Entering directory `/temp/dillo-0.6.2/src'
+> > Making all in IO
+> > make[3]: Entering directory `/temp/dillo-0.6.2/src/IO'
+> > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -D_REENTRANT -Wall
+> > -Waggregate-return -c mime.c
+> > In file included from mime.c:12:
+> > mime.h:9: gtk/gtk.h: No such file or directory
+> > In file included from mime.h:10,
+> > from mime.c:12:
+> > ../dw_widget.h:4: gtk/gtkobject.h: No such file or directory
+> > ../dw_widget.h:5: gtk/gtkwidget.h: No such file or directory
+> > ../dw_widget.h:6: gdk/gdktypes.h: No such file or directory
+> > In file included from ../dw_widget.h:8,
+> > from mime.h:10,
+> > from mime.c:12:
+> > ../dw_style.h:4: gdk/gdktypes.h: No such file or directory
+> > In file included from mime.h:11,
+> > from mime.c:12:
+> > ../cache.h:4: glib.h: No such file or directory
+> > In file included from ../cache.h:5,
+> > from mime.h:11,
+> > from mime.c:12:
+> > ../chain.h:9: glib.h: No such file or directory
+> > In file included from ../cache.h:6,
+> > from mime.h:11,
+> > from mime.c:12:
+> > ../url.h:14: glib.h: No such file or directory
+> > In file included from mime.h:12,
+> > from mime.c:12:
+> > ../IO/Url.h:7: glib.h: No such file or directory
+> > make[3]: *** [mime.o] Error 1
+> > make[3]: Leaving directory `/temp/dillo-0.6.2/src/IO'
+> > make[2]: *** [all-recursive] Error 1
+> > make[2]: Leaving directory `/temp/dillo-0.6.2/src'
+> > make[1]: *** [all-recursive] Error 1
+> > make[1]: Leaving directory `/temp/dillo-0.6.2'
+> > make: *** [all-recursive-am] Error 2
+> >
+> > Ithink errors in make are coused by errot in ./configure
+> > I have gtk installed libraries and dev. I think because I have gnome
+> > apps installed, and when I was installing
+> > Debian I marked all development libraries.
+> > Any hints and help would be very appreciate.
+> > Andrey
+> >
+> >
+> > _______________________________________________
+> > Dillo-dev mailing list
+> > Dillo-dev@li...
+> > https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]about current state of patches
+
+From: Grigory Bakunov <black@as...> - 2001-12-21 02:57
+
+Dear Dillo hackers.
+
+I need to comment some patches on my dillo patch'o'matic site.
+It's posting mainly for core developers and patch maintainers.
+
+At first for patches maintainers.
+DEAR PATCH MAKERS!
+Please don't leave patches to the mercy of fate.
+Some patches - for example realy simple but realy usefull
+"http authentefication patch" by Tor-eke Fransson now absolutely
+outdated - current cvs version use new url parser.
+Another realy good patch - cookies support by Lars Clausen.
+It's have similar problem with new url handling API.
+Many nice patches doesn't work well with current cvs version.
+Please update your works - it's realy need for all Dillo
+users.
+
+Hmm...
+DEAR DILLO PROGRAMMERS!
+
+Please look to patches on patch'o'matic.
+I comment some patches for you.
+
+1) "ANSI C patch" by ksr - this patch does nothing but it's especialy
+good - it's just normalize dillo code to ANSI C standart -
+for example change C++-like comments (" // something")
+to correct C comments ("/* something */"). I think it's
+a good idea to inject this to current cvs.
+2) "Cookies patch" by Lars Clausen - all we need it. This
+patch clean and i think it's must be inject into cvs
+after little correction for support current url handling
+scheme.
+3) IPv6 support by Tobin Fricke. - no comments. I don't use
+it but code look clean.
+4) HTTPS and Auth patches by Tor-eke Fransson. I use this
+patches for every day work. But http auth part of patch
+must be slightly correted.
+5) Charset selection patch by your humble servant. It's
+absolutely simple patch to avoid conflict of interests
+between english and non-english users. I think it's may
+be injected in cvs too ;)
+
+On patch'o'matic we have more patches than i show here -
+please look to it.
+And thanks for all dillo coders and patchers - you make
+good deed and best web browser.
+
+PS: Sorry for my terrible and unreadable english.
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: DraX <drax@wh...> - 2001-12-20 21:24
+
+:( Just PHP and sh, so I can't help.
+
+
+On Thu, 20 Dec 2001, Jorge Arellano Cid wrote:
+
+> 
+> On Wed, 19 Dec 2001, DraX wrote:
+> 
+> > Bug 238 is not a bug, if the poster is on the list, please install GNU
+> > Make, as the make provided with OpenBSD(pmake as it is often called) does
+> > not support some things that the GNU automake/autoconf tools do in the
+> > makefiles.
+> >
+> > Bug reporting system needs to supply the posters email :(
+> 
+> Yes, it wouldn't hurt.
+> 
+> Does anyone here knows python and feels like adding that?
+> It's very simple, all the data is in a plain text file, with
+> concurrency handling done using the voluntary file lock protocol.
+> 
+> By now I'm too busy too work on it, and very concerned about
+> 0.6.3 release. BTW, how has the CVS version being doing? (I have
+> only a couple of comments. Should I assume it was OK? :)
+> 
+> 
+> Cheers
+> Jorge.-
+> 
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Bug 238
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-20 21:00
+
+On Wed, 19 Dec 2001, DraX wrote:
+
+> Bug 238 is not a bug, if the poster is on the list, please install GNU
+> Make, as the make provided with OpenBSD(pmake as it is often called) does
+> not support some things that the GNU automake/autoconf tools do in the
+> makefiles.
+>
+> Bug reporting system needs to supply the posters email :(
+
+Yes, it wouldn't hurt.
+
+Does anyone here knows python and feels like adding that?
+It's very simple, all the data is in a plain text file, with
+concurrency handling done using the voluntary file lock protocol.
+
+By now I'm too busy too work on it, and very concerned about
+0.6.3 release. BTW, how has the CVS version being doing? (I have
+only a couple of comments. Should I assume it was OK? :)
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]installation
+
+From: Christophe Baillon <cbaillon@if...> - 2001-12-20 20:12
+
+Hi,
+
+Have you installed libgtk-dev ?
+If not, try apt-get install libgtk-dev
+install too libjpeg : apt-get install libjpeg62-dev
+
+
+If you prefer binary, Dillo binary package is not available in potato
+(debian 2.2).
+
+But you can find it in woody and sid (testing ans unstable).
+
+The most simple is to wait woody to become the stable distribution
+(soon).
+
+
+Regards
+
+
+On Thu, 2001-12-20 at 16:48, C. Dummy wrote:
+> I'm linux newbie. I run Debian 2.2 with all dev libraries. I use
+> Blackbox window manager. Small and fast. I'm interested in dillo 0.6.2
+> because is small and fast. Unfortunatelly I can't install because I'm
+> getting this errors when I do
+> ./configure
+> ng for GTK - version >= 1.2.0... no
+> *** The gtk-config script installed by GTK could not be found
+> *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
+> *** your path, or set the GTK_CONFIG environment variable to the
+> *** full path to gtk-config.
+> configure: WARNING: Unable to find Gtk+ with a version >= 1.2.0
+> checking for jpeg_destroy_decompress in -ljpeg... no
+> configure: WARNING: *** JPEG support will not be included ***
+> no
+> configure: WARNING: *** JPEG support will not be included ***
+> and following after
+> make
+> make all-recursive
+> make[1]: Entering directory `/temp/dillo-0.6.2'
+> Making all in doc
+> make[2]: Entering directory `/temp/dillo-0.6.2/doc'
+> make[2]: Nothing to be done for `all'.
+> make[2]: Leaving directory `/temp/dillo-0.6.2/doc'
+> Making all in src
+> make[2]: Entering directory `/temp/dillo-0.6.2/src'
+> Making all in IO
+> make[3]: Entering directory `/temp/dillo-0.6.2/src/IO'
+> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -D_REENTRANT -Wall
+> -Waggregate-return -c mime.c
+> In file included from mime.c:12:
+> mime.h:9: gtk/gtk.h: No such file or directory
+> In file included from mime.h:10,
+> from mime.c:12:
+> ../dw_widget.h:4: gtk/gtkobject.h: No such file or directory
+> ../dw_widget.h:5: gtk/gtkwidget.h: No such file or directory
+> ../dw_widget.h:6: gdk/gdktypes.h: No such file or directory
+> In file included from ../dw_widget.h:8,
+> from mime.h:10,
+> from mime.c:12:
+> ../dw_style.h:4: gdk/gdktypes.h: No such file or directory
+> In file included from mime.h:11,
+> from mime.c:12:
+> ../cache.h:4: glib.h: No such file or directory
+> In file included from ../cache.h:5,
+> from mime.h:11,
+> from mime.c:12:
+> ../chain.h:9: glib.h: No such file or directory
+> In file included from ../cache.h:6,
+> from mime.h:11,
+> from mime.c:12:
+> ../url.h:14: glib.h: No such file or directory
+> In file included from mime.h:12,
+> from mime.c:12:
+> ../IO/Url.h:7: glib.h: No such file or directory
+> make[3]: *** [mime.o] Error 1
+> make[3]: Leaving directory `/temp/dillo-0.6.2/src/IO'
+> make[2]: *** [all-recursive] Error 1
+> make[2]: Leaving directory `/temp/dillo-0.6.2/src'
+> make[1]: *** [all-recursive] Error 1
+> make[1]: Leaving directory `/temp/dillo-0.6.2'
+> make: *** [all-recursive-am] Error 2
+> 
+> Ithink errors in make are coused by errot in ./configure
+> I have gtk installed libraries and dev. I think because I have gnome
+> apps installed, and when I was installing
+> Debian I marked all development libraries.
+> Any hints and help would be very appreciate.
+> Andrey
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+
+
+______________________________________________________________________________
+ifrance.com, l'email gratuit le plus complet de l'Internet !
+vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
+http://www.ifrance.com/_reloc/email.emailif 
+
+
+
+Re: [Dillo-dev]New URL parsing commit + more!
+
+From: Grigory Bakunov <black@as...> - 2001-12-20 17:28
+
+Date |Mon, 17 Dec 2001 21:18:05 -0300 (CLST)
+From |Jorge Arellano Cid <jcid@em...>
+
+Hello!
+
+
+JAC> Hi there!
+
+JAC> Finally the new URL parsing prototype is on the CVS. Please get
+JAC> it and test it through; that's almost 0.6.3 release!
+
+JAC> I was willing to make the new release from a new site, but as I
+JAC> haven't received an answer yet, and as it should be done before
+JAC> Christmas, most probably it will be from SF...
+
+JAC> Well, now is a matter of knowing how the new dillo behaves,
+JAC> updating the splash, the help page and start rolling the new
+JAC> release. (Ahem, that is, if testing doesn't tell otherwise).
+
+JAC> Note that while testing I found a BUG that left dillo out of
+JAC> file descriptors, so I decided to retain the patch until finding
+JAC> what was going wrong with it; some time later the test revealed
+JAC> that "the" bug was also present on 0.6.2! -- what a relief! It
+JAC> was BUG#268 (fixed now).
+
+
+JAC> Greetings
+JAC> Jorge.-
+
+
+JAC> PS: a lot of effort was put in optimizing the speed. I bet you'll
+JAC> notice (i.e. against former CVS).
+
+
+
+Little feature request - how about to add http authorization
+to main dillo branch ? it's realy easy and donesn't bloat
+code.
+
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]installation
+
+From: Ron Farrer <rbf@fa...> - 2001-12-20 17:18
+
+Attachments: Message as HTML      
+
+C. Dummy (cdummy@ro...) wrote:
+
+> I'm linux newbie. I run Debian 2.2 with all dev libraries. I use
+> Blackbox window manager. Small and fast. I'm interested in dillo 0.6.2
+> because is small and fast.=20
+<snip>
+
+Would you like a deb of 0.6.2 built for stable/potato? I have one, you
+can grab it from http://people.debian.org/~rbf/files/potato/i386/
+
+HTH,
+Ron
+--=20
+Email: <rbf@fa...> or <rbf@de...> 
+
+
+
+Re: [Dillo-dev]Dillo preferences tool
+
+From: Grigory Bakunov <black@as...> - 2001-12-20 17:13
+
+Date |Thu, 20 Dec 2001 00:37:15 +0000 (GMT)
+From |Robert J Thomson <Robert.Thomson@ee.ed.ac.uk>
+
+Hello!
+
+
+RJT> Hi,
+
+RJT> I have just written a little Tcl/Tk script that lets you create/edit the
+RJT> Dillo preferences file using a GUI.
+
+RJT> It is just a quick hack, so don't expect wonders. 
+
+RJT> I have posted it at:
+
+RJT> http://www.ee.ed.ac.uk/~rjt/dillo/config.html
+
+RJT> Regards,
+
+RJT> Bob.
+Yes!!!
+At least!
+It's work realy fine.
+Thanks alot!
+
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]installation
+
+From: <SirVer@gm...> - 2001-12-20 17:05
+
+do yourself a favour: 
+su -
+apt-get build-dep dillo
+
+try again
+
+greets
+Holger
+
+On Thu, Dec 20, 2001 at 11:48:24AM -0500, C. Dummy wrote:
+> I'm linux newbie. I run Debian 2.2 with all dev libraries. I use
+> Blackbox window manager. Small and fast. I'm interested in dillo 0.6.2
+> because is small and fast. Unfortunatelly I can't install because I'm
+> getting this errors when I do
+> ./configure
+> ng for GTK - version >= 1.2.0... no
+> *** The gtk-config script installed by GTK could not be found
+> *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
+> *** your path, or set the GTK_CONFIG environment variable to the
+> *** full path to gtk-config.
+> configure: WARNING: Unable to find Gtk+ with a version >= 1.2.0
+> checking for jpeg_destroy_decompress in -ljpeg... no
+> configure: WARNING: *** JPEG support will not be included ***
+> no
+> configure: WARNING: *** JPEG support will not be included ***
+> and following after
+> make
+> make all-recursive
+> make[1]: Entering directory `/temp/dillo-0.6.2'
+> Making all in doc
+> make[2]: Entering directory `/temp/dillo-0.6.2/doc'
+> make[2]: Nothing to be done for `all'.
+> make[2]: Leaving directory `/temp/dillo-0.6.2/doc'
+> Making all in src
+> make[2]: Entering directory `/temp/dillo-0.6.2/src'
+> Making all in IO
+> make[3]: Entering directory `/temp/dillo-0.6.2/src/IO'
+> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -D_REENTRANT -Wall
+> -Waggregate-return -c mime.c
+> In file included from mime.c:12:
+> mime.h:9: gtk/gtk.h: No such file or directory
+> In file included from mime.h:10,
+> from mime.c:12:
+> ../dw_widget.h:4: gtk/gtkobject.h: No such file or directory
+> ../dw_widget.h:5: gtk/gtkwidget.h: No such file or directory
+> ../dw_widget.h:6: gdk/gdktypes.h: No such file or directory
+> In file included from ../dw_widget.h:8,
+> from mime.h:10,
+> from mime.c:12:
+> ../dw_style.h:4: gdk/gdktypes.h: No such file or directory
+> In file included from mime.h:11,
+> from mime.c:12:
+> ../cache.h:4: glib.h: No such file or directory
+> In file included from ../cache.h:5,
+> from mime.h:11,
+> from mime.c:12:
+> ../chain.h:9: glib.h: No such file or directory
+> In file included from ../cache.h:6,
+> from mime.h:11,
+> from mime.c:12:
+> ../url.h:14: glib.h: No such file or directory
+> In file included from mime.h:12,
+> from mime.c:12:
+> ../IO/Url.h:7: glib.h: No such file or directory
+> make[3]: *** [mime.o] Error 1
+> make[3]: Leaving directory `/temp/dillo-0.6.2/src/IO'
+> make[2]: *** [all-recursive] Error 1
+> make[2]: Leaving directory `/temp/dillo-0.6.2/src'
+> make[1]: *** [all-recursive] Error 1
+> make[1]: Leaving directory `/temp/dillo-0.6.2'
+> make: *** [all-recursive-am] Error 2
+> 
+> Ithink errors in make are coused by errot in ./configure
+> I have gtk installed libraries and dev. I think because I have gnome
+> apps installed, and when I was installing
+> Debian I marked all development libraries.
+> Any hints and help would be very appreciate.
+> Andrey
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+> 
+
+
+
+[Dillo-dev]installation
+
+From: C. Dummy <cdummy@ro...> - 2001-12-20 16:48
+
+I'm linux newbie. I run Debian 2.2 with all dev libraries. I use
+Blackbox window manager. Small and fast. I'm interested in dillo 0.6.2
+because is small and fast. Unfortunatelly I can't install because I'm
+getting this errors when I do
+./configure
+ng for GTK - version >= 1.2.0... no
+*** The gtk-config script installed by GTK could not be found
+*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
+*** your path, or set the GTK_CONFIG environment variable to the
+*** full path to gtk-config.
+configure: WARNING: Unable to find Gtk+ with a version >= 1.2.0
+checking for jpeg_destroy_decompress in -ljpeg... no
+configure: WARNING: *** JPEG support will not be included ***
+no
+configure: WARNING: *** JPEG support will not be included ***
+and following after
+make
+make all-recursive
+make[1]: Entering directory `/temp/dillo-0.6.2'
+Making all in doc
+make[2]: Entering directory `/temp/dillo-0.6.2/doc'
+make[2]: Nothing to be done for `all'.
+make[2]: Leaving directory `/temp/dillo-0.6.2/doc'
+Making all in src
+make[2]: Entering directory `/temp/dillo-0.6.2/src'
+Making all in IO
+make[3]: Entering directory `/temp/dillo-0.6.2/src/IO'
+gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -D_REENTRANT -Wall
+-Waggregate-return -c mime.c
+In file included from mime.c:12:
+mime.h:9: gtk/gtk.h: No such file or directory
+In file included from mime.h:10,
+from mime.c:12:
+../dw_widget.h:4: gtk/gtkobject.h: No such file or directory
+../dw_widget.h:5: gtk/gtkwidget.h: No such file or directory
+../dw_widget.h:6: gdk/gdktypes.h: No such file or directory
+In file included from ../dw_widget.h:8,
+from mime.h:10,
+from mime.c:12:
+../dw_style.h:4: gdk/gdktypes.h: No such file or directory
+In file included from mime.h:11,
+from mime.c:12:
+../cache.h:4: glib.h: No such file or directory
+In file included from ../cache.h:5,
+from mime.h:11,
+from mime.c:12:
+../chain.h:9: glib.h: No such file or directory
+In file included from ../cache.h:6,
+from mime.h:11,
+from mime.c:12:
+../url.h:14: glib.h: No such file or directory
+In file included from mime.h:12,
+from mime.c:12:
+../IO/Url.h:7: glib.h: No such file or directory
+make[3]: *** [mime.o] Error 1
+make[3]: Leaving directory `/temp/dillo-0.6.2/src/IO'
+make[2]: *** [all-recursive] Error 1
+make[2]: Leaving directory `/temp/dillo-0.6.2/src'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory `/temp/dillo-0.6.2'
+make: *** [all-recursive-am] Error 2
+
+Ithink errors in make are coused by errot in ./configure
+I have gtk installed libraries and dev. I think because I have gnome
+apps installed, and when I was installing
+Debian I marked all development libraries.
+Any hints and help would be very appreciate.
+Andrey 
+
+
+
+[Dillo-dev]Bug 238
+
+From: DraX <drax@wh...> - 2001-12-20 00:46
+
+Bug 238 is not a bug, if the poster is on the list, please install GNU
+Make, as the make provided with OpenBSD(pmake as it is often called) does
+not support some things that the GNU automake/autoconf tools do in the
+makefiles. 
+
+Bug reporting system needs to supply the posters email :( 
+
+Thanks, Alex 
+
+
+
+[Dillo-dev]Dillo preferences tool
+
+From: Robert J Thomson <Robert.Thomson@ee...> - 2001-12-20 00:37
+
+Hi,
+
+I have just written a little Tcl/Tk script that lets you create/edit the
+Dillo preferences file using a GUI.
+
+It is just a quick hack, so don't expect wonders. 
+
+I have posted it at:
+
+http://www.ee.ed.ac.uk/~rjt/dillo/config.html
+
+Regards,
+
+Bob.
+
+========
+Robert J Thomson
+Department of Electronics and Electrical Engineering
+The University of Edinburgh, King's Buildings, Mayfield Rd, Edinburgh EH9 3JL
+(Int +44) 131 650 5658, (Int +44) 131 650 6554 (FAX)
+======== 
+
+
+
+Re: [Dillo-dev]Dillo, GTK --> WINGs??
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-18 01:43
+
+> Hi,
+> 
+> I am creating a distro targetted towards the educational community,
+> for the same I have selected WindowMaker as the default and only
+> window manager.
+
+Good choice for a windowmanager (wmaker rocks!)
+
+> 
+> I figured one of the most important components of the distro would be
+> a great help system, which would be easy to use (compared to man or
+> Xman)
+
+Have you tried tkman? Tkman is a _really_ nice man page browser. It 
+can show pages as outlines, search (which you can do with normal man, 
+but you only have to press a button in tkman), and jump between 
+manuals by clicking the manual name (this is helpful when viewing 
+stuff like the curses manual).
+
+Also, you should try using GNU InfoTeX as the documentation system. A 
+nice graphical info browser is tkinfo. Pinfo is the best (IMHO) 
+console info browser. InfoTeX is also nice because you can easily 
+produce info pages, man pages, html, pdfs, and books from the same 
+file. Writing the documentation in InfoTeX opens up a lot of 
+possibilties for you.
+
+> Dillo fits the bill perfectly, it is small, fast and renders HTML
+> pretty well, but it depends heavily on glib, gdk and gtk+. To make it
+> much better integrated with WindowMaker, and at the same time even
+> more faster and lighter it would be better to implement the UI using
+> WINGs, the default UI set for WindowMaker.
+
+Why port to WINGs? Just use the GtkSTEP engine. It looks just like 
+the WINGs widgets (and both are meant to look like the old NeXT 
+widgets). 
+
+> Is there anyone with good programming skills who could help me out
+> with this?
+
+Doing so would take a long time because dillo has a lot of dependency 
+on Gtk and glib. Forking dillo is a _very_ bad idea. It is still very 
+immature (when compared to other browsers). Just use Dillo with the 
+GtkSTEP Gtk theme engine, and you may as well be using WINGs from an 
+appearance perspective. Gtk+, Gdk, and Glib only take a few megabytes 
+of disk space, and you gain access to a large number of applications 
+by including them. 
+
+As for being lighter, I don't think that using WINGs would make it 
+much lighter. Gtk+ is already a light enough toolkit for most uses. 
+Gtk+ applications run very nicely on my 233Mhz k6 with 32MB of RAM. 
+And they run fast. Gtk+ doesn't add a large amount of overhead to the 
+programs. It is also much more powerful than WINGs. The few kilobytes 
+of memory you would reclaim with WINGs isn't worth the gigantic 
+effort it would take to port Dillo to it.
+
+
+---
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+[Dillo-dev]New URL parsing commit + more!
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-18 00:23
+
+Hi there!
+
+Finally the new URL parsing prototype is on the CVS. Please get
+it and test it through; that's almost 0.6.3 release!
+
+I was willing to make the new release from a new site, but as I
+haven't received an answer yet, and as it should be done before
+Christmas, most probably it will be from SF...
+
+Well, now is a matter of knowing how the new dillo behaves,
+updating the splash, the help page and start rolling the new
+release. (Ahem, that is, if testing doesn't tell otherwise).
+
+Note that while testing I found a BUG that left dillo out of
+file descriptors, so I decided to retain the patch until finding
+what was going wrong with it; some time later the test revealed
+that "the" bug was also present on 0.6.2! -- what a relief! It
+was BUG#268 (fixed now).
+
+
+Greetings
+Jorge.-
+
+
+PS: a lot of effort was put in optimizing the speed. I bet you'll
+notice (i.e. against former CVS). 
+
+
+
+[Dillo-dev]Howto: Eliminate the progressbars?
+
+From: Mayuresh Kathe <mayuresh@vs...> - 2001-12-17 07:08
+
+Hi,
+
+How do I eliminate the progress bars showed along with the toolbar?
+
+~Mayuresh 
+
+
+
+[Dillo-dev]Howto: Change Image in Toolbar?
+
+From: Mayuresh Kathe <mayuresh@vs...> - 2001-12-17 07:07
+
+Hi,
+
+How do I change the Back, Forward, Home, etc.. images in the toolbar?
+(substitute them with something else)
+
+~Mayuresh 
+
+
+
+[Dillo-dev]Dillo, GTK --> WINGs??
+
+From: Mayuresh Kathe <mayuresh@vs...> - 2001-12-17 06:54
+
+Hi,
+
+I am creating a distro targetted towards the educational community, 
+for the same I have selected WindowMaker as the default and only 
+window manager.
+
+I figured one of the most important components of the distro would be 
+a great help system, which would be easy to use (compared to man or 
+Xman)
+
+For that I selected HTML as the content display language and hence was 
+searching for a small, fast HTML viewer.
+
+Dillo fits the bill perfectly, it is small, fast and renders HTML 
+pretty well, but it depends heavily on glib, gdk and gtk+.
+To make it much better integrated with WindowMaker, and at the same 
+time even more faster and lighter it would be better to implement the 
+UI using WINGs, the default UI set for WindowMaker.
+
+Is there anyone with good programming skills who could help me out 
+with this?
+
+Awaiting your reply.
+
+~Mayuresh 
+
+
+
+Re: [Dillo-dev]font problems with new dillo versions
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-16 16:13
+
+Martynas,
+
+> Hi,
+>
+> I have a problem with Dillo since v0.6.2 and cvs versions. I'm still using
+> dillo-0.6.1-pre, because it shows me html better. It's difficult to describe
+> the problem, so I made two screenshots:
+> http://mjoc.infoseka.lt/archive/dillo/dillo_bad.png -- this is new versions
+> http://mjoc.infoseka.lt/archive/dillo/dillo_good.png -- this is 0.6.1-pre
+>
+> I use lt_LT locale (Lithuania), gtk_set_locale() is used, so everything must
+> be fine, imho. So I'm looking for this problem at my side.
+> Dillo output for mjoc.infoseka.lt (where lithuanian chars are used):
+> Setting locale to lt_LT
+> dillo_dns_init: Here we go!
+> [...]
+> Dillo: normal exit!
+>
+> It looks fine. Do anybody know what's wrong?
+
+As you may know, i18n is an epic problem, and the right way to
+address it is to modify GTK! (fortunately that's exactly what
+the GTK+ team is doing).
+
+OTOH, I fully understand the will to see "local" pages.
+
+As dillo only handles properly ISO-8859-1 encoded HTML, letting
+it work with other charsets breaks a lot of things; you have been
+warned. --but you can read those pages.
+
+Fast unsupported hack:
+
+Try adapting 061's Dw_style_font_realize to the newest CVS.
+
+
+Cheers
+Jorge.-
+
+
+PS: don't tell anyone I told you! ;) 
+
+
+
+Re: [Dillo-dev]font problems with new dillo versions
+
+From: Grigory Bakunov <black@as...> - 2001-12-16 08:57
+
+Date |Sun, 16 Dec 2001 10:57:08 +0000
+From |Martynas Jocius <mjoc@de...>
+
+Hello!
+
+MJ> Hi,
+
+MJ> I have a problem with Dillo since v0.6.2 and cvs versions. I'm still using
+MJ> dillo-0.6.1-pre, because it shows me html better. It's difficult to describe
+MJ> the problem, so I made two screenshots:
+MJ> http://mjoc.infoseka.lt/archive/dillo/dillo_bad.png -- this is new versions
+MJ> http://mjoc.infoseka.lt/archive/dillo/dillo_good.png -- this is 0.6.1-pre
+
+MJ> I use lt_LT locale (Lithuania), gtk_set_locale() is used, so everything must
+MJ> be fine, imho. So I'm looking for this problem at my side.
+MJ> Dillo output for mjoc.infoseka.lt (where lithuanian chars are used):
+MJ> Setting locale to lt_LT
+MJ> dillo_dns_init: Here we go!
+MJ> [...]
+MJ> Dillo: normal exit!
+
+MJ> It looks fine. Do anybody know what's wrong?
+MJ> Thanks.
+
+May be i so stupid ? what a problem with font you have ?
+
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]font problems with new dillo versions
+
+From: Martynas Jocius <mjoc@de...> - 2001-12-16 08:48
+
+Hi,
+
+I have a problem with Dillo since v0.6.2 and cvs versions. I'm still using
+dillo-0.6.1-pre, because it shows me html better. It's difficult to describe
+the problem, so I made two screenshots:
+http://mjoc.infoseka.lt/archive/dillo/dillo_bad.png -- this is new versions
+http://mjoc.infoseka.lt/archive/dillo/dillo_good.png -- this is 0.6.1-pre
+
+I use lt_LT locale (Lithuania), gtk_set_locale() is used, so everything must
+be fine, imho. So I'm looking for this problem at my side.
+Dillo output for mjoc.infoseka.lt (where lithuanian chars are used):
+Setting locale to lt_LT
+dillo_dns_init: Here we go!
+[...]
+Dillo: normal exit!
+
+It looks fine. Do anybody know what's wrong?
+Thanks.
+
+--
+Martynas Jocius 
+
+
+
+Re: [Dillo-dev]New version of external viewer patch
+
+From: Hayden <super_super_hero_hayden@ya...> - 2001-12-15 00:27
+
+On 08 Dec 2001 15:37:56 -0600
+Lars Clausen <lrclause@cs.uiuc.edu> wrote:
+
+> 
+> I did some more work on the external viewer patch, in particular I
+> generalized it to be a framework for calling external programs of any
+> kind, improved the cleanup, and cleaned up several parts of the code. I
+> also as an example of a difference external program made the
+> File/Preferences menu item open a shell with $EDITOR ~/.dillo/dillorc and
+> reload prefs afterwards. I think next I shall make a standalone prefs
+> editor to call instead. A quick grep of the source seems to indicate that
+> some of the preferences settings aren't always read out of the prefs
+> structure, but stored elsewhere. We should figure out how to update these
+> (don't store them, or provide callbacks, or hack in each piece).
+> 
+> I'm not including the configure.in changes in the below, only Makefile.am.
+> So if you want to compile from this, you will need to do automake &&
+> autoconf before running ./configure.
+> 
+
+Hello,
+
+It would be a good idea to implement a dialog window,which has a download or open option, that pops up when dillo comes across something it can't handle. With the download option the url would be passed to the download agent the user has previously configured (I guess a "download_agent=" option in dillorc or alike). When the open option is chosen it would open the external viewer with the file. If the mime doesn't have an external viewer then you could just display an error msg in dillo's status bar somewhere along the lines of "mime has no associated external viewer: mime/type".
+Ofcourse then you could add an option to dillorc that allows dillo to execute immediately anything with an external viewer assigned in mailcap.
+
+
+Hayden 
+
+
+
+Re: [Dillo-dev]Re: Cookies
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-13 02:35
+
+> > great for me, with one problem--the cookies don't work until I 
+exit
+> > and restart the browser.
+> 
+> That's real odd, it shouldn't work that way. Can you point to a
+> specific (simple) place where it does that?
+
+slashdot, k5 (its down now), tpu.org, newsforge, freshmeat, pretty 
+much everywhere that doesn't use a session only cookie.
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+[Dillo-dev]Re: Url resolving --Dont panic!
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-12 22:07
+
+Hi,
+
+Sometime ago, I wrote:
+
+> A few days ago I finished coding the regular-expressions-based
+> URL parsing and resolving routines. It's a couple of lines from
+> being 100% RFC 2396 compliant, but unfortunately too slow.
+>
+> I'm absolutely aware of the importance of the speed here. After
+> all, there's no point in optimizing the Dw engine and networking
+> to our best, while letting the URL resolver take 60% (or more)
+> of the rendering time.
+>
+> I tried to make it faster, developing a new ADT for strings
+> (faster than GStrings), but the performance impact was too small
+> to make it worth.
+>
+> A few tests more, and it was clear that the time was being
+> dominated by RE parsing.
+>
+> It was a big effort, but I'm afraid that the way to go now is
+> to try to develop a new parser/resolver, without REs, that's as
+> RFC compliant as possible.
+
+
+The good news is that I developed another prototype, without
+RE, that's as RFC compliant as the former, but 4 times faster!
+
+In brief, if it passes further stress testing, dillo will
+retain its traditional performance, but with a full blown parser.
+
+Note: while working on this solution, I can't help to mention
+that's kind of funny to know I rejected my own patch, twice!!
+First, the fully tested RE-based one, and later the optimized
+version. OTOH I'm happy the maintainer is not accepting crappy
+stuff, neither making concesions to any guy!
+
+
+Let's keep up the good work
+Jorge.- 
+
+
+
+Re: [Dillo-dev]image scaling?
+
+From: Sebastian Geerken <sgeerken@st...> - 2001-12-12 17:48
+
+Hi,
+
+On Tue, Dec 11, 2001 at 10:22:53AM -0300, Jorge Arellano Cid wrote:
+> 
+> 
+> On Fri, 7 Dec 2001, Lee, Kwan wrote:
+> 
+> > Hi Jorge,
+> >
+> > is there a simple hack you suggest?
+> 
+> I have thought of scaling 'width' and 'height' by an image size
+> factor could do the trick. This is non trivial as all the details
+> have to be carefully considered before.
+
+There are for the simplest solution only two changes necessary:
+1) Dw_image_size_request must return a scaled size, and 2) "width" and
+"height" attributes of <img> must be scaled. However, this will use
+quite much memory, since currently each DwImage has its own buffer for
+the scaled image data (unscaled DwImage's share buffers). This is
+currently reasonable, since scaled images are rare, and mostly scaled
+different, so sharing would not be possible.
+
+Simple example: If you have 10 100x100 images with the same URL, you
+need 3*100*100 = 30000 bytes for the one buffer. If you scale all at,
+say, 50%, you need 3*100*100 + 10*3*50*50 = 105000 bytes, most for the
+scaled buffers. If they can be shared, you only need 37500 bytes.
+
+Since there are some other problems with images, I've thought of
+encapsulating the representation of images into a new type, which
+provides functions for:
+
+* Copying data into the buffer. This also affects the related
+scaled buffer (see next point).
+
+* Scaling: the root buffer will keep track of the scaled buffers,
+so that sharing could be implemented in a transparent way.
+
+* Drawing: this is used by the DwImage widget.
+
+The interface should be designed that way, that the implementation can
+be changed quite simply, and perhaps even several implementations can
+be used parallel. This would e.g. make the following possible:
+
+1. Transparent images are currently often not rendered
+correctly. This new image buffer will support transparency per
+se, the implementation will be secondary. A first implementation
+e.g. will probably use clipping bitmaps, but otherwise, it might
+be interesting to take a look at the development of complete
+alpha support in X.
+
+2. The current implementation, based on GdkRGB, is rather slow,
+since quite much data has to be transferred from the client to
+the server. A faster (but more memory consuming) way may be to
+use pixmaps.
+
+Another topic are BTW background images, this is not related to this,
+but probably the simplest solution to reuse the current code is to put
+an abstract interface between the DICache and the DwImage widget,
+which is then also implemented by some code for handling
+backgrounds. Interfaces should in C be implemented simply by a list of
+function pointers.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Re: Cookies
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-12 01:33
+
+> Currently, the decision to move from SF to cipsga (Brazil) is
+> almost made. Probably we'll move, and quicly release 0.6.3 from
+> there. After that there'll be time to review the cookies patch.
+> 
+> Hopefully the move and 0.6.3 release, will happen before
+> Christmas.
+
+Are there any plans for cookies in 0.6.3? The cookies patch works 
+great for me, with one problem--the cookies don't work until I exit 
+and restart the browser.
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+[Dillo-dev]RE: image scaling?
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-11 14:25
+
+On Fri, 7 Dec 2001, Lee, Kwan wrote:
+
+> Hi Jorge,
+>
+> is there a simple hack you suggest?
+
+I have thought of scaling 'width' and 'height' by an image size
+factor could do the trick. This is non trivial as all the details
+have to be carefully considered before.
+
+> Is there a way to modify dillorc to do
+> this image scaling option?
+
+No.
+
+> do I have to hack the source code, recompile for
+> the arm and then install it on the ipaq?
+
+All of it, and of course, after having developed the solution!
+
+> is there an easier way, such as an
+> ipkg distribution available? :)
+
+No.
+
+Cheers
+Jorge.-
+
+
+> thank you.
+>
+> -kwan
+>
+> -----Original Message-----
+> From: Jorge Arellano Cid [mailto:jcid@em...]
+> Sent: Friday, December 07, 2001 6:09 AM
+> To: Lee, Kwan
+> Subject: Re: image scaling?
+>
+>
+>
+>
+> On Thu, 6 Dec 2001, Lee, Kwan wrote:
+>
+> > Hi,
+>
+> Hi!
+>
+> > I was wondering if dillo is going to support or has the capabilities to
+> > scale images so that larger image can be scaled down to kind of fit on the
+> > screen of the ipaq.
+> >
+> > Thank you.
+>
+> Currently dillo is able to scale images. Maybe a simple hack
+> can do the trick for you while waiting for a more definitive
+> solution.
+>
+>
+> Greetings
+> Jorge.-
+>
+> 
+
+
+
+[Dillo-dev]Re: Cookies
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-11 14:25
+
+J=F6rgen,
+
+> Hi Jorge!
+>
+> As You may know, me and Lars combined our efforts to make cookies fully
+> supported.
+
+Sure I know!
+
+> We have received some good reviews
+
+Nice.
+
+> (and patches for that not so good)
+
+Yes J=F6rgen, it seems that's almost unevitable. And it doesn't
+feel good to reject a patch too, especially when you know it was
+contributed in the hope of helping... But including it in the
+distribution anyway is certainly the wrong decision, so I guess
+that's one of the bitter tasks for the in-charge developer.
+
+
+> ... from people using it and we feel that it would be nice to
+> include it in the main branch.
+> Do You have a spot open for inclusion in the near future? :-)
+
+Sure.
+
+Currently, the decision to move from SF to cipsga (Brazil) is
+almost made. Probably we'll move, and quicly release 0.6.3 from
+there. After that there'll be time to review the cookies patch.
+
+Hopefully the move and 0.6.3 release, will happen before
+Christmas.
+
+
+Best
+Jorge.- 
+
+
+
+Re: [Dillo-dev]odd segfault
+
+From: TANAKA Keishiro <ksr@lp...> - 2001-12-10 11:39
+
+>I'm making some pretty big changes to Dillo for a medical informatics
+>project here (we absolutely need ssl, meta refresh, basic auth, and cookies;
+>trying to integrate Lars' cookies and auth patches with our locally-developed
+>ssl patches.)
+>
+>I'm getting a segfault in Cache_process_queue on forms submission (from weblogin.washington.edu):
+Hi, see http://todo.org/download/dillo/dillo-0.6.2-uo-branch-2.tar.gz
+
+Maybe it fixes the problem. But it changes a lot, so it could not help
+you. The following paragraph is described what is problem.
+
+cache.c should not use array of CacheData. CacheData should keep the
+fixed position for its life range. But at this implementation, the
+cache list might be allocated unexpectedly in
+a_List_resize(a_List_add). It is undecided when
+Cache_delayed_process_queue_callback is called. A pointer to CacheData
+is used as argument as callback function. But there is delayed time,
+in the period (between when argument is passed to callback and when
+callback is called), reallocation of cache list might occur. If
+reallocation occurs, the callback function would access the freed
+memory(CacheData) after reallocation. So cache.c had better using array
+of pointer to CacheData...... 
+
+
+
+[Dillo-dev]New version of external viewer patch
+
+From: Lars Clausen <lrclause@cs...> - 2001-12-08 21:38
+
+I did some more work on the external viewer patch, in particular I
+generalized it to be a framework for calling external programs of any
+kind, improved the cleanup, and cleaned up several parts of the code. I
+also as an example of a difference external program made the
+File/Preferences menu item open a shell with $EDITOR ~/.dillo/dillorc and
+reload prefs afterwards. I think next I shall make a standalone prefs
+editor to call instead. A quick grep of the source seems to indicate that
+some of the preferences settings aren't always read out of the prefs
+structure, but stored elsewhere. We should figure out how to update these
+(don't store them, or provide callbacks, or hack in each piece).
+
+I'm not including the configure.in changes in the below, only Makefile.am.
+So if you want to compile from this, you will need to do automake &&
+autoconf before running ./configure.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile ~/src/external.patch=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+diff -rbBu dillo-orig/src/IO/mime.h dillo-mime/src/IO/mime.h
+--- dillo-orig/src/IO/mime.h Sun Mar 4 10:03:44 2001
++++ dillo-mime/src/IO/mime.h Thu Dec 6 18:21:39 2001
+@@ -26,6 +26,9 @@
+void **Data);
+DwWidget* a_Gif_image (const char *Type,void *web, CA_Callback_t *Call,
+void **Data);
++DwWidget* a_Extern_viewer (const char *Type, void *web, CA_Callback_t *Cal=
+l,
++ void **Data);
++void a_External_set_viewers();
+=20
+/*
+* Functions defined inside Mime module
+@@ -33,5 +36,8 @@
+void a_Mime_init(void);
+DwWidget* a_Mime_set_viewer(const char *content_type, void *Ptr,
+CA_Callback_t *Call, void **Data);
++gint Mime_add_minor_type(const char *Key, Viewer_t Method);
++gint Mime_add_major_type(const char *Key, Viewer_t Method);
++
+=20
+#endif
+diff -rbBu dillo-orig/src/Makefile.am dillo-mime/src/Makefile.am
+--- dillo-orig/src/Makefile.am Mon Aug 27 16:44:12 2001
++++ dillo-mime/src/Makefile.am Sat Dec 8 15:17:55 2001
+@@ -87,6 +87,8 @@
+url.c \
+url.h \
+list.h \
+- pixmaps.h
++ pixmaps.h \
++ external.c \
++ external.h
+=20
+EXTRA_DIST =3D pixmaps_old.h chg srch
+diff -rbBu dillo-orig/src/commands.c dillo-mime/src/commands.c
+--- dillo-orig/src/commands.c Fri Nov 16 05:01:33 2001
++++ dillo-mime/src/commands.c Sat Dec 8 15:05:21 2001
+@@ -26,6 +26,7 @@
+#include "commands.h"
+#include "prefs.h"
+#include "menu.h"
++#include "external.h"
+=20
+/*
+* Local data
+@@ -66,10 +67,21 @@
+}
+=20
+/*
+- * ?
++ * Callback invoked when the prefs are done being edited.
++ * Note: If prefs contents are stored outside the prefs structure
++ * anywhere, they need to be updated.
++ */
++static void Commands_prefs_done_callback(int status, void *data) {
++ a_Prefs_init();
++}
++
++/*
++ * You will need to export (or setenv) EDITOR for this to work.
+*/
+void a_Commands_prefs_callback(GtkWidget *widget, gpointer client_data)
+{
++ a_External_make_process("xterm -e $EDITOR ~/.dillo/dillorc",=20
++ Commands_prefs_done_callback, NULL);
+}
+=20
+/*
+diff -rbBu dillo-orig/src/external.c dillo-mime/src/external.c
+--- dillo-orig/src/external.c Fri Dec 7 13:22:27 2001
++++ dillo-mime/src/external.c Sat Dec 8 15:29:05 2001
+@@ -0,0 +1,364 @@
++/*
++ * File: external.c
++ *
++ * Copyright (C) 2001 Lars Clausen (lrclause@cs.uiuc.edu)
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ */
++
++/* Functions for handling calling external programs (in particular,
++ * external mime handlers and stand-alone programs).
++ */
++
++#include <string.h>
++#include <gtk/gtk.h>
++#include <stdio.h>
++#include <stdarg.h>
++#include <sys/types.h>
++#include <sys/time.h>
++#include <sys/resource.h>
++#include <sys/wait.h>
++#include <errno.h>
++#include <stdlib.h>
++#include <signal.h>
++
++#include "dillo.h"
++#include "dw.h"
++#include "IO/mime.h"
++#include "debug.h"
++#include "list.h"
++#include "interface.h"
++#include "progressbar.h"
++
++/* I'm loath to hack mime.c to add callback data for this, since I don't
++ understand where the CBData comes from. Instead I (for now) hold a list
++ here of the commands. Not fast, but hey, neither is spawning an
++ external viewer.
++*/
++
++typedef struct {
++ char *mime_type;
++ char *command;
++} Dillo_External_Mime_Handler_t;
++
++typedef struct {
++ int offset;
++ int temp_fd;
++ char *temp_file_name;
++ BrowserWindow *bw;
++ char *command;
++} Dillo_External_Writer_t;
++
++typedef void (External_Callback_t)(int retval,=20
++ void *callback_data);
++
++typedef struct {
++ int pid;
++ External_Callback_t *callback;
++ void *callback_data;
++} Dillo_External_Process_t;
++
++
++gint ExternalViewersSize =3D 0, ExternalViewersMax =3D 8;
++Dillo_External_Mime_Handler_t *ExternalViewers =3D NULL;
++gint ExternalProgramsSize =3D 0, ExternalProgramsMax =3D 8;
++Dillo_External_Process_t *ExternalPrograms =3D NULL;
++
++gboolean a_External_make_process(char *Command,
++ External_Callback_t *CB,
++ void *CBData);
++static void External_reap_process(int signum);
++static void External_viewer_callback(int Op, CacheClient_t *Client);
++static Dillo_External_Writer_t *External_viewer_new(BrowserWindow *bw,
++ char *command);
++static void External_viewer_reap_callback(int status,=20
++ void *data);
++static char *External_viewer_find_command(const char *Type);
++static DwWidget *External_viewer(const char *Type, void *Ptr,
++ CA_Callback_t *Call, void **Data);
++static void External_set_viewers_from_file(char *filename);
++void a_External_set_viewers();
++
++/*
++ * Start an external process using system(), calling the callback function
++ * when the process dies. Returns TRUE if the fork was successfull.
++ */
++gboolean=20
++a_External_make_process(char *Command, External_Callback_t *CB, void *CBDa=
+ta) {
++ /* va_list args;*/
++ int pid;
++
++ pid =3D fork();
++
++ if (pid < 0) {
++ DEBUG_MSG(10, "Error starting external program %s\n", Command);
++ return FALSE;
++ }
++ if (pid =3D=3D 0) {
++ /* va_start(args, command);*/
++ int retval;
++
++ signal(SIGCHLD, _exit);
++
++ retval =3D system(Command);
++ if (retval =3D=3D -1)=20
++ DEBUG_MSG(10, "Error executing external program %s: %s\n",=20
++ Command, strerror(errno));
++ DEBUG_MSG(3, "Returned from %s, return value=3D%d\n", Command, retva=
+l);
++ exit(retval);
++ } else {
++ signal(SIGCHLD, External_reap_process);
++ DEBUG_MSG(1, "New external PID is %d\n", pid);
++ a_List_add(ExternalPrograms, ExternalProgramsSize,=20
++ sizeof(*ExternalPrograms), ExternalProgramsMax);
++ ExternalPrograms[ExternalProgramsSize].callback =3D CB;
++ ExternalPrograms[ExternalProgramsSize].callback_data =3D CBData;
++ ExternalPrograms[ExternalProgramsSize].pid =3D pid;
++ ExternalProgramsSize++;
++
++ return FALSE;
++ }
++}
++
++/*=20
++ * Signal handler: Reaps dead children of external processes.
++ * Since internal processes never die (they are just reused), we only
++ * need to do this for external processes, which should all be created
++ * through a_External_make_process().
++ */
++static void=20
++External_reap_process(int signum) {
++ int status;
++ int dead_pid;
++ int i;
++
++ for (i =3D 0; i < ExternalProgramsSize; i++) {
++ if ((dead_pid =3D waitpid(ExternalPrograms[i].pid, &status, WNOHANG)) =
+> 0) {
++ DEBUG_MSG(1, "Reaping child %d\n", dead_pid);
++ if (ExternalPrograms[i].callback !=3D NULL) {
++ (*ExternalPrograms[i].callback)(status,
++ ExternalPrograms[i].callback_data);
++ }
++ a_List_remove(ExternalPrograms, i, ExternalProgramsSize);
++ return;
++ }
++ }
++}
++
++/*
++ * Below here are the more specific external MIME viewers.
++ */
++
++/*
++ * The callback function for external MIME viewers as cache clients.
++ */
++static void=20
++External_viewer_callback(int Op, CacheClient_t *Client) {
++ Dillo_External_Writer_t *external =3D Client->CbData;
++ int bufsize =3D Client->BufSize;
++
++ if ( Op !=3D CA_Send) {
++ char *commandbuf;
++ /* Close or Abort */
++=20=20=20=20
++ /* Do the last line: */
++ if (external->offset < bufsize) {
++ write(external->temp_fd, Client->Buf+external->offset, bufsize-external-=
+>offset);
++ external->offset =3D bufsize;
++ }
++ /* remove this client from our active list */
++ a_Interface_close_client(external->bw, Client->Key);
++ /* set progress bar insensitive */
++ a_Progressbar_update(external->bw->progress, NULL, 0);
++
++ /* Start a new process and remember its filename */
++ commandbuf =3D g_new(char, strlen(external->command)+
++ strlen(external->temp_file_name));
++ sprintf(commandbuf, external->command,=20
++ external->temp_file_name);
++ a_External_make_process(commandbuf, External_viewer_reap_callback,
++ external->temp_file_name);
++=20=20=20=20=20=20
++ g_free(commandbuf);
++ close(external->temp_fd);
++ g_free(external);
++ } else {
++ int written;
++ written =3D write(external->temp_fd, Client->Buf+external->offset, b=
+ufsize-external->offset);
++ external->offset =3D bufsize;
++ }
++}
++
++/*
++ * Creates a new cache client structure, including a temporary file
++ * for downloading.
++ */
++static Dillo_External_Writer_t *
++External_viewer_new(BrowserWindow *bw, char *command) {
++ Dillo_External_Writer_t *external;
++ char *tmp_name_buf =3D g_strdup("/tmp/dillo_XXXXXX");
++
++ external =3D g_new(Dillo_External_Writer_t, 1);
++ external->command =3D command;
++ /* Have to use mkstemp rather than tmpfile, since we want to get at the
++ filename afterwards to give to the external app.
++ */
++ external->temp_fd =3D mkstemp(tmp_name_buf);
++ external->temp_file_name =3D tmp_name_buf;
++ external->bw =3D bw;
++ external->offset =3D 0;
++
++ return external;
++}
++
++/*
++ * The callback for when an external viewer exits. Removes the temporary
++ * file.
++ * We might want to have a function to remove them in the case where Dillo
++ * dies before its children.
++ */
++static void=20
++External_viewer_reap_callback(int status, void *data) {
++ char *filename =3D (char *)data;
++
++ if (filename !=3D NULL) {
++ unlink(filename);
++ g_free(filename);
++ }
++}
++
++/*
++ * Finds the command corresponding to a particular MIME type.
++ * This function is unnecessary is mime.c allows us to use callback data.
++ */
++static char *
++External_viewer_find_command(const char *Type) {
++ int i;
++ char *slashindex;
++ char *major_type;
++ int major_len;
++
++ for (i =3D 0; i < ExternalViewersSize; i++) {
++ if (strcmp(ExternalViewers[i].mime_type, Type) =3D=3D 0)
++ return ExternalViewers[i].command;
++ }
++
++ slashindex =3D strchr(Type, '/');
++ if (slashindex !=3D NULL)
++ major_type =3D g_strndup(Type, slashindex-Type);
++ else=20
++ major_type =3D g_strdup(Type);
++ major_len =3D strlen(major_type);
++
++ for (i =3D 0; i < ExternalViewersSize; i++) {
++ if (strncmp(ExternalViewers[i].mime_type, major_type, major_len) =3D=
+=3D 0) {
++ g_free(major_type);
++ return ExternalViewers[i].command;
++ }
++ }
++ g_free(major_type);
++ return NULL;
++}
++
++/*
++ * Callback function for a mime type.
++ */
++static DwWidget *
++External_viewer(const char *Type, void *Ptr,
++ CA_Callback_t *Call, void **Data) {
++ char *command =3D External_viewer_find_command(Type);
++ DilloWeb *Web =3D (DilloWeb*)Ptr;
++
++ Dillo_External_Writer_t *ext;
++
++ DEBUG_MSG(1, "Found command %s for %s\n", command, Type);
++
++ if (command =3D=3D NULL) {
++ DEBUG_MSG(3, "Not really a viewer for '%s' after all?\n", Type);
++ return NULL;
++ }
++
++ /* Get the data into a temporary file */
++ ext =3D External_viewer_new(Web->bw, command);
++
++ *Call =3D (CA_Callback_t)External_viewer_callback;
++ *Data =3D (void *)ext;
++
++ /* Always return NULL, as these don't use the Dillo window */
++ DEBUG_MSG(5, "Starting external viewer %s for type %s\n", command, Type=
+);
++ return NULL;
++}
++
++/*
++ * Adds an external viewer for a particular mime type.
++ */
++static void=20
++External_viewer_add(const char *Type, const char *command) {
++ DEBUG_MSG(1, "Adding viewer for `%s': %s\n", Type, command);
++ if (strchr(Type, '/') !=3D NULL) {
++ Mime_add_minor_type(Type, External_viewer);
++ } else {
++ Mime_add_major_type(Type, External_viewer);
++ }
++ a_List_add(ExternalViewers, ExternalViewersSize, sizeof(*ExternalViewer=
+s),
++ ExternalViewersMax);
++ ExternalViewers[ExternalViewersSize].mime_type =3D g_strdup(Type);
++ ExternalViewers[ExternalViewersSize].command =3D g_strdup(command);
++ ExternalViewersSize++;
++}
++
++/*
++ * This is a very simple mailcap parser, ignores all print, test etc
++ * and other remarks.
++ */
++static void=20
++External_set_viewers_from_file(char *filename) {
++ FILE *file;
++ char *buf;
++ int buflen =3D 200;
++
++ file =3D fopen(filename, "r");
++ if (file =3D=3D NULL) return;
++
++ buf =3D g_new(char, buflen);
++
++ while (!feof(file)) {
++ int offset =3D 0;
++ char *semi1, *semi2;
++ while (fgets(buf, buflen+offset, file) !=3D NULL) {
++ if (buf[buflen] =3D=3D '\0') {
++ char *buf2;
++ buf2 =3D g_new(char, buflen*2);
++ strncpy(buf2, buf, buflen);
++ buflen *=3D 2;
++ g_free(buf);
++ buf =3D buf2;
++ } else break;
++ }
++ if (*buf =3D=3D '\0' || *buf =3D=3D '#') continue;
++ semi1 =3D strchr(buf, ';');
++ if (semi1 =3D=3D NULL) continue;
++ *semi1 =3D '\0';
++ semi1++;
++ semi2 =3D strchr(semi1, ';');
++ if (semi2 !=3D NULL) *semi2 =3D '\0';
++ semi1 =3D g_strchomp(semi1);
++ External_viewer_add(g_strdup(buf), g_strdup(semi1));
++ }
++ g_free(buf);
++ fclose(file);
++}
++
++/* Sets up external viewers taken from the users mailcap, then from
++ * the system mailcap. Since mime viewers are checked in order,
++ * the users settings have preference (but this is called after Dillos
++ * own viewers are checked).
++ */
++void=20
++a_External_set_viewers() {
++ External_set_viewers_from_file("/home/lrclause/.mailcap");
++ External_set_viewers_from_file("/etc/mailcap");
++}
+diff -rbBu dillo-orig/src/external.h dillo-mime/src/external.h
+--- dillo-orig/src/external.h Sat Dec 8 14:45:43 2001
++++ dillo-mime/src/external.h Sat Dec 8 15:17:44 2001
+@@ -0,0 +1,13 @@
++#ifndef __DILLO_EXTERNAL_H__
++#define __DILLO_EXTERNAL_H__
++
++typedef void (External_Callback_t)(int retval,=20
++ void *callback_data);
++
++extern gboolean a_External_make_process(char *Command,
++ External_Callback_t *CB,
++ void *CBData);
++extern void a_External_set_viewers();
++
++
++#endif
+diff -rbBu dillo-orig/src/menu.c dillo-mime/src/menu.c
+--- dillo-orig/src/menu.c Fri Dec 7 13:23:44 2001
++++ dillo-mime/src/menu.c Sat Dec 8 14:33:32 2001
+@@ -132,10 +132,8 @@
+a_Commands_openfile_callback, bw);
+Menu_add(file_menu, "Open _URL...", "<ctrl>L", bw,
+a_Commands_openurl_callback, bw);
+- /*
+Menu_add(file_menu, "_Preferences", "<ctrl>E", bw,
+a_Commands_prefs_callback, bw);=20
+- */
+Menu_add(file_menu, "Close Window", "<ctrl>Q", bw,
+a_Commands_close_callback, bw);
+Menu_sep(file_menu);
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-08 01:46
+
+> - Clinton Ebadi had offered his future CD store's site, but it has
+> yet to be started and set.
+
+Which now appears as if it will never start. Funding is hard to get, 
+so probably a no go (at least not until mid-year next year). I am 
+still planning to get a 1U rackmount server and colocate it somewhere 
+(if I can find something that will make up for the colo fees). Now, 
+to find a way to cover 80 bucks a month...
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]Getting data from buffer, what goes wrong?
+
+From: Clinton Ebadi <unknown_lamer@ha...> - 2001-12-08 01:44
+
+> > I'm working on a little Christmas present for Dillo (don't tell
+> > it:): External viewers. I've got it pretty well set up, but when I
+....
+
+Why not resume work on plugins? Then you could implement an External 
+Viewer plugin. I tried to integrate dillo with libguile, but that 
+quickly failed (maybe I should finish reading the Gtk tutorial...). 
+
+
+-------------------------------
+#umbclinux on irc.openprojects.net
+lamer.hackedtobits.com
+unknown_lamer@ha...
+AIM: unknownlamer ICQ: 41087914 
+
+
+
+Re: [Dillo-dev]More on the external viewer front
+
+From: Lars Clausen <lrclause@cs...> - 2001-12-07 19:30
+
+On 07 Dec 2001, Lars Clausen wrote:
+
+>=20
+> After getting over my galloping stupidity yesterday, I mostly have the
+> external viewer patch ready. Only one slight problem: I'm supposed to
+> return a DwWidget* from the mime type handler. Since I don't use the
+> browser window (except I'd like to do the progress bar thing), I have
+> been hoping to just return NULL or the old contents. However, NULL fails
+> to an assert immediately, and I can't find the 'old contents' as a
+> DwWidget* in the DilloWeb structure I get passed. What would be the
+> right direction, removing the NULL assert and make sure web.c handles
+> NULL returns, or is there some way I can get my hands on a DwWidget*?
+
+So it turns out that the assertion doesn't really stop anything (it just
+looks really scary, CRITICAL and all). I got the crashing to stop by
+catching SIGCHLD in the child (huh?). It now works quite nicely. The
+locations of the mailcap files (/etc/mailcap, ~/.mailcap) are hardcoded,
+we might want to add a prefs thing to override this. The attached patch
+adds external handling. Enjoy. And please let me know if I broke any of
+the coding practices, I'm trying to stick to them.
+
+> I'll also be doing some profiling to see if the checking for mime types
+> is becoming a problem -- the list becomes rather long when including
+> ~/.mailcap and /etc/mailcap.
+
+Not a problem, it barely registers in gprof. Cool.
+
+-Lars, who thinks aloud too much:)
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile ~/src/external.patch=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+diff -rubB dillo-orig/src/IO/mime.c dillo-mime/src/IO/mime.c
+--- dillo-orig/src/IO/mime.c Sun Mar 4 10:03:44 2001
++++ dillo-mime/src/IO/mime.c Fri Dec 7 13:24:48 2001
+@@ -107,9 +107,16 @@
+Mime_add_minor_type("image/jpg", a_Jpeg_image);
+Mime_add_minor_type("image/png", a_Png_image);
+Mime_add_minor_type("text/html", a_Html_text);
++ /* Add minor types for text styles we know we can handle, but that
++ mailcap tends to overwrite */
++ Mime_add_minor_type("text/plain", a_Plain_text);
++ Mime_add_minor_type("text/C", a_Plain_text);
+=20
+/* Add a major type to handle all the text stuff */
+Mime_add_major_type("text", a_Plain_text);
++
++ /* Add external viewers as defined in mailcap files */
++ a_External_set_viewers();
+}
+=20
+=20
+diff -rubB dillo-orig/src/IO/mime.h dillo-mime/src/IO/mime.h
+--- dillo-orig/src/IO/mime.h Sun Mar 4 10:03:44 2001
++++ dillo-mime/src/IO/mime.h Thu Dec 6 18:21:39 2001
+@@ -26,6 +26,9 @@
+void **Data);
+DwWidget* a_Gif_image (const char *Type,void *web, CA_Callback_t *Call,
+void **Data);
++DwWidget* a_Extern_viewer (const char *Type, void *web, CA_Callback_t *Cal=
+l,
++ void **Data);
++void a_External_set_viewers();
+=20
+/*
+* Functions defined inside Mime module
+@@ -33,5 +36,8 @@
+void a_Mime_init(void);
+DwWidget* a_Mime_set_viewer(const char *content_type, void *Ptr,
+CA_Callback_t *Call, void **Data);
++gint Mime_add_minor_type(const char *Key, Viewer_t Method);
++gint Mime_add_major_type(const char *Key, Viewer_t Method);
++
+=20
+#endif
+diff -rubB dillo-orig/src/Makefile.am dillo-mime/src/Makefile.am
+--- dillo-orig/src/Makefile.am Mon Aug 27 16:44:12 2001
++++ dillo-mime/src/Makefile.am Wed Dec 5 16:00:10 2001
+@@ -87,6 +87,7 @@
+url.c \
+url.h \
+list.h \
+- pixmaps.h
++ pixmaps.h \
++ external.c
+=20
+EXTRA_DIST =3D pixmaps_old.h chg srch
+diff -rubB dillo-orig/src/Makefile.in dillo-mime/src/Makefile.in
+--- dillo-orig/src/Makefile.in Sun Oct 21 12:22:26 2001
++++ dillo-mime/src/Makefile.in Wed Dec 5 16:00:45 2001
+@@ -75,7 +75,7 @@
+=20
+dillo_LDADD =3D IO/libDio.a @LIBJPEG_LIB@
+=20
+-dillo_SOURCES =3D acconfig.h chain.h chain.c commands.c commands.h =
+cache.c cache.h debug.h dw.h dw.c dw_bullet.c dw_bullet.h dw_contain=
+er.c dw_container.h dw_embed_gtk.c dw_embed_gtk.h dw_gtk_scrolled_frame=
+.c dw_gtk_scrolled_frame.h dw_gtk_scrolled_window.c dw_gtk_scrolled_wind=
+ow.h dw_gtk_statuslabel.c dw_gtk_statuslabel.h dw_gtk_viewport.c dw_gtk=
+_viewport.h dw_hruler.c dw_hruler.h dw_image.c dw_image.h dw_marshal.c=
+dw_marshal.h dw_page.c dw_page.h dw_style.c dw_style.h dw_table.c d=
+w_table.h dw_tooltip.c dw_tooltip.h dw_widget.c dw_widget.h findtext.c=
+findtext.h web.c web.h progressbar.c progressbar.h dillo.c dillo.h =
+bookmark.c bookmark.h browser.h dicache.c dicache.h dns.c dns.h gif=
+.c jpeg.c png.c html.c html.h image.c image.h misc.c misc.h interf=
+ace.h interface.c nav.c nav.h plain.c menu.c menu.h prefs.c prefs.h=
+colors.c colors.h bitvec.c bitvec.h klist.c klist.h url.c url.h l=
+ist.h pixmaps.h
++dillo_SOURCES =3D acconfig.h chain.h chain.c commands.c commands.h =
+cache.c cache.h debug.h dw.h dw.c dw_bullet.c dw_bullet.h dw_contain=
+er.c dw_container.h dw_embed_gtk.c dw_embed_gtk.h dw_gtk_scrolled_frame=
+.c dw_gtk_scrolled_frame.h dw_gtk_scrolled_window.c dw_gtk_scrolled_wind=
+ow.h dw_gtk_statuslabel.c dw_gtk_statuslabel.h dw_gtk_viewport.c dw_gtk=
+_viewport.h dw_hruler.c dw_hruler.h dw_image.c dw_image.h dw_marshal.c=
+dw_marshal.h dw_page.c dw_page.h dw_style.c dw_style.h dw_table.c d=
+w_table.h dw_tooltip.c dw_tooltip.h dw_widget.c dw_widget.h findtext.c=
+findtext.h web.c web.h progressbar.c progressbar.h dillo.c dillo.h =
+bookmark.c bookmark.h browser.h dicache.c dicache.h dns.c dns.h gif=
+.c jpeg.c png.c html.c html.h image.c image.h misc.c misc.h interf=
+ace.h interface.c nav.c nav.h plain.c menu.c menu.h prefs.c prefs.h=
+colors.c colors.h bitvec.c bitvec.h klist.c klist.h url.c url.h l=
+ist.h pixmaps.h external.c
+=20
+=20
+EXTRA_DIST =3D pixmaps_old.h chg srch
+@@ -96,7 +96,7 @@
+dw_tooltip.o dw_widget.o findtext.o web.o progressbar.o dillo.o \
+bookmark.o dicache.o dns.o gif.o jpeg.o png.o html.o image.o misc.o \
+interface.o nav.o plain.o menu.o prefs.o colors.o bitvec.o klist.o \
+-url.o
++url.o external.o
+dillo_DEPENDENCIES =3D IO/libDio.a
+dillo_LDFLAGS =3D=20
+CFLAGS =3D @CFLAGS@
+@@ -117,10 +117,10 @@
+.deps/dw_gtk_scrolled_window.P .deps/dw_gtk_statuslabel.P \
+.deps/dw_gtk_viewport.P .deps/dw_hruler.P .deps/dw_image.P \
+.deps/dw_marshal.P .deps/dw_page.P .deps/dw_style.P .deps/dw_table.P \
+-.deps/dw_tooltip.P .deps/dw_widget.P .deps/findtext.P .deps/gif.P \
+-.deps/html.P .deps/image.P .deps/interface.P .deps/jpeg.P .deps/klist.P \
+-.deps/menu.P .deps/misc.P .deps/nav.P .deps/plain.P .deps/png.P \
+-.deps/prefs.P .deps/progressbar.P .deps/url.P .deps/web.P
++.deps/dw_tooltip.P .deps/dw_widget.P .deps/external.P .deps/findtext.P \
++.deps/gif.P .deps/html.P .deps/image.P .deps/interface.P .deps/jpeg.P \
++.deps/klist.P .deps/menu.P .deps/misc.P .deps/nav.P .deps/plain.P \
++.deps/png.P .deps/prefs.P .deps/progressbar.P .deps/url.P .deps/web.P
+SOURCES =3D $(dillo_SOURCES)
+OBJECTS =3D $(dillo_OBJECTS)
+=20
+diff -rubB dillo-orig/src/external.c dillo-mime/src/external.c
+--- dillo-orig/src/external.c Fri Dec 7 13:22:27 2001
++++ dillo-mime/src/external.c Fri Dec 7 13:28:33 2001
+@@ -0,0 +1,298 @@
++/*
++ * File: external.c
++ *
++ * Copyright (C) 2001 Lars Clausen (lrclause@cs.uiuc.edu)
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ */
++
++/* Functions for handling calling external programs (in particular,
++ * external mime handlers and stand-alone programs).
++ */
++
++#include <string.h>
++#include <gtk/gtk.h>
++#include <stdio.h>
++#include <stdarg.h>
++#include <sys/types.h>
++#include <sys/time.h>
++#include <sys/resource.h>
++#include <sys/wait.h>
++#include <errno.h>
++#include <stdlib.h>
++#include <signal.h>
++
++#include "dillo.h"
++#include "dw.h"
++#include "IO/mime.h"
++#include "debug.h"
++#include "list.h"
++#include "interface.h"
++#include "progressbar.h"
++
++/* I'm loath to hack mime.c to add callback data for this, since I don't
++ understand where the CBData comes from. Instead I (for now) hold a list
++ here of the commands. Not fast, but hey, neither is spawning an
++ external viewer.
++*/
++
++typedef struct {
++ char *mime_type;
++ char *command;
++} DilloExternalMimeHandler;
++
++typedef struct {
++ int offset;
++ int temp_fd;
++ char *temp_file_name;
++ BrowserWindow *bw;
++ char *command;
++} DilloExternalWriter;
++
++typedef struct {
++ int pid;
++ char *filename;
++} DilloExternalProgram;
++
++gint ExternalViewersSize =3D 0, ExternalViewersMax =3D 8;
++DilloExternalMimeHandler *ExternalViewers =3D NULL;
++gint ExternalProgramsSize =3D 0, ExternalProgramsMax =3D 8;
++DilloExternalProgram *ExternalPrograms =3D NULL;
++
++static char *External_viewer_find_command(const char *Type);
++static DilloExternalProgram *External_make_process(char *command, char *fi=
+lename);
++static void External_callback(int Op, CacheClient_t *Client);
++static DilloExternalWriter *External_new(BrowserWindow *bw,
++ char *command);
++DwWidget *a_External_viewer(const char *Type, DilloWeb *Web,
++ CA_Callback_t *Call, void **Data);
++void a_External_check_dead_children();
++static void External_viewer_add(const char *Type, const char *command);
++void a_External_set_viewers();
++
++static
++char *External_viewer_find_command(const char *Type) {
++ int i;
++ char *slashindex;
++ char *major_type;
++ int major_len;
++
++ for (i =3D 0; i < ExternalViewersSize; i++) {
++ if (strcmp(ExternalViewers[i].mime_type, Type) =3D=3D 0)
++ return ExternalViewers[i].command;
++ }
++
++ slashindex =3D strchr(Type, '/');
++ if (slashindex !=3D NULL)
++ major_type =3D g_strndup(Type, slashindex-Type);
++ else=20
++ major_type =3D g_strdup(Type);
++ major_len =3D strlen(major_type);
++
++ for (i =3D 0; i < ExternalViewersSize; i++) {
++ if (strncmp(ExternalViewers[i].mime_type, major_type, major_len) =3D=
+=3D 0) {
++ g_free(major_type);
++ return ExternalViewers[i].command;
++ }
++ }
++ g_free(major_type);
++ return NULL;
++}
++
++static DilloExternalProgram *External_make_process(char *command, char *fi=
+lename) {
++ /* va_list args;*/
++ int pid;
++
++ pid =3D fork();
++
++ if (pid < 0) {
++ DEBUG_MSG(10, "Error starting external program %s\n", command);
++ return NULL;
++ }
++ if (pid =3D=3D 0) {
++ /* va_start(args, command);*/
++ char *commandbuf =3D g_new(char, strlen(command)+strlen(filename));
++ int retval;
++
++ signal(SIGCHLD, _exit);
++
++ sprintf(commandbuf, command, filename);
++ retval =3D system(commandbuf);
++ if (retval =3D=3D -1)=20
++ DEBUG_MSG(10, "Error executing external program %s: %s\n",=20
++ commandbuf, strerror(errno));
++ DEBUG_MSG(3, "Returned from %s, return value=3D%d\n", commandbuf, re=
+tval);
++ g_free(commandbuf);
++ unlink(filename);
++ exit(retval);
++ } else {
++ DEBUG_MSG(1, "New external PID is %d\n", pid);
++ a_List_add(ExternalPrograms, ExternalProgramsSize,=20
++ sizeof(*ExternalPrograms), ExternalProgramsMax);
++ ExternalPrograms[ExternalProgramsSize++].pid =3D pid;
++ return &ExternalPrograms[ExternalProgramsSize-1];
++ }
++}
++
++static void External_callback(int Op, CacheClient_t *Client) {
++ DilloExternalWriter *external =3D Client->CbData;
++ DilloExternalProgram *ext_prog;
++ int bufsize =3D Client->BufSize;
++
++ if ( Op !=3D CA_Send) {
++ /* Close or Abort */
++=20=20=20=20
++ /* Do the last line: */
++ if (external->offset < bufsize) {
++ write(external->temp_fd, Client->Buf+external->offset, bufsize-external-=
+>offset);
++ external->offset =3D bufsize;
++ }
++ /* remove this client from our active list */
++ a_Interface_close_client(external->bw, Client->Key);
++ /* set progress bar insensitive */
++ a_Progressbar_update(external->bw->progress, NULL, 0);
++
++ /* Start a new process and remember its filename */
++ ext_prog =3D External_make_process(external->command,
++ external->temp_file_name);
++ if (ext_prog !=3D NULL) {
++ ext_prog->filename =3D external->temp_file_name;
++ }
++=20
++ close(external->temp_fd);
++ g_free(external);
++ } else {
++ int written;
++ written =3D write(external->temp_fd, Client->Buf+external->offset, b=
+ufsize-external->offset);
++ external->offset =3D bufsize;
++ }
++}
++
++static DilloExternalWriter *External_new(BrowserWindow *bw,
++ char *command) {
++ DilloExternalWriter *external;
++ char *tmp_name_buf =3D g_strdup("/tmp/dillo_XXXXXX");
++
++ external =3D g_new(DilloExternalWriter, 1);
++ external->command =3D command;
++ /* Have to use mkstemp rather than tmpfile, since we want to get at the
++ filename afterwards to give to the external app.
++ */
++ external->temp_fd =3D mkstemp(tmp_name_buf);
++ external->temp_file_name =3D tmp_name_buf;
++ external->bw =3D bw;
++ external->offset =3D 0;
++
++ return external;
++}
++
++DwWidget *a_External_viewer(const char *Type, DilloWeb *Web,
++ CA_Callback_t *Call, void **Data)
++{
++ char *command =3D External_viewer_find_command(Type);
++
++ DilloExternalWriter *ext;
++
++ DEBUG_MSG(1, "Found command %s for %s\n", command, Type);
++
++ if (command =3D=3D NULL) {
++ DEBUG_MSG(3, "Not really a viewer for '%s' after all?\n", Type);
++ return NULL;
++ }
++
++ /* Get the data into a temporary file */
++ ext =3D External_new(Web->bw, command);
++
++ *Call =3D (CA_Callback_t)External_callback;
++ *Data =3D (void *)ext;
++
++ /* Always return NULL, as these don't use the Dillo window */
++ DEBUG_MSG(5, "Starting external viewer %s for type %s\n", command, Type=
+);
++ return NULL;
++}
++
++void a_External_check_dead_children() {
++ int status;
++ int dead_pid;
++
++ while ((dead_pid =3D wait3(&status, WNOHANG, NULL)) > 0) {
++ /* Do stuff with the dead child (no, not *that* kind of stuff!:) */
++ int i;
++
++ for (i =3D 0; i < ExternalProgramsSize; i++) {
++ if (ExternalPrograms[i].pid =3D=3D dead_pid) {
++ DEBUG_MSG(1, "Reaping child %d with filename %s\n",=20
++ dead_pid, ExternalPrograms[i].filename);
++ if (ExternalPrograms[i].filename !=3D NULL) {
++ unlink(ExternalPrograms[i].filename);
++ g_free(ExternalPrograms[i].filename);
++ }
++ a_List_remove(ExternalPrograms, i, ExternalProgramsSize);
++ return;
++ }
++ }
++ DEBUG_MSG(2, "Odd, pid %d died, but wasn't found\n", pid);
++ }
++}
++
++static void External_viewer_add(const char *Type, const char *command) {
++ DEBUG_MSG(1, "Adding viewer for `%s': %s\n", Type, command);
++ if (strchr(Type, '/') !=3D NULL) {
++ Mime_add_minor_type(Type, a_External_viewer);
++ } else {
++ Mime_add_major_type(Type, a_External_viewer);
++ }
++ a_List_add(ExternalViewers, ExternalViewersSize, sizeof(*ExternalViewer=
+s),
++ ExternalViewersMax);
++ ExternalViewers[ExternalViewersSize].mime_type =3D g_strdup(Type);
++ ExternalViewers[ExternalViewersSize].command =3D g_strdup(command);
++ ExternalViewersSize++;
++}
++
++/** This is a very simple mailcap parser, ignores all print, test etc
++ * and other remarks.
++ */
++void External_set_viewers_from_file(char *filename) {
++ FILE *file;
++ char *buf;
++ int buflen =3D 200;
++
++ file =3D fopen(filename, "r");
++ if (file =3D=3D NULL) return;
++
++ buf =3D g_new(char, buflen);
++
++ while (!feof(file)) {
++ int offset =3D 0;
++ char *semi1, *semi2;
++ while (fgets(buf, buflen+offset, file) !=3D NULL) {
++ if (buf[buflen] =3D=3D '\0') {
++ char *buf2;
++ buf2 =3D g_new(char, buflen*2);
++ strncpy(buf2, buf, buflen);
++ buflen *=3D 2;
++ g_free(buf);
++ buf =3D buf2;
++ } else break;
++ }
++ if (*buf =3D=3D '\0' || *buf =3D=3D '#') continue;
++ semi1 =3D strchr(buf, ';');
++ if (semi1 =3D=3D NULL) continue;
++ *semi1 =3D '\0';
++ semi1++;
++ semi2 =3D strchr(semi1, ';');
++ if (semi2 !=3D NULL) *semi2 =3D '\0';
++ semi1 =3D g_strchomp(semi1);
++ External_viewer_add(g_strdup(buf), g_strdup(semi1));
++ }
++ g_free(buf);
++ fclose(file);
++}
++
++void a_External_set_viewers() {
++ External_set_viewers_from_file("/home/lrclause/.mailcap");
++ External_set_viewers_from_file("/etc/mailcap");
++}
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+[Dillo-dev]More on the external viewer front
+
+From: Lars Clausen <lrclause@cs...> - 2001-12-07 17:52
+
+After getting over my galloping stupidity yesterday, I mostly have the
+external viewer patch ready. Only one slight problem: I'm supposed to
+return a DwWidget* from the mime type handler. Since I don't use the
+browser window (except I'd like to do the progress bar thing), I have been
+hoping to just return NULL or the old contents. However, NULL fails to an
+assert immediately, and I can't find the 'old contents' as a DwWidget* in
+the DilloWeb structure I get passed. What would be the right direction,
+removing the NULL assert and make sure web.c handles NULL returns, or is
+there some way I can get my hands on a DwWidget*?
+
+I'll also be doing some profiling to see if the checking for mime types is
+becoming a problem -- the list becomes rather long when including
+~/.mailcap and /etc/mailcap.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]odd segfault
+
+From: David Bliss <david@yt...> - 2001-12-07 15:25
+
+I'm making some pretty big changes to Dillo for a medical informatics
+project here (we absolutely need ssl, meta refresh, basic auth, and cookies;
+trying to integrate Lars' cookies and auth patches with our locally-developed
+ssl patches.)
+
+I'm getting a segfault in Cache_process_queue on forms submission (from weblogin.washington.edu):
+
+meta refresh: delay -> 0, url -> https://secure.cirg.washington.edu/~david-admin
+Nav_open_url: Url=>https://secure.cirg.washington.edu/~david-admin<
+meta refresh: delay -> 0, url -> https://weblogin.washington.edu/
+Nav_open_url: Url=>https://weblogin.washington.edu/<
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 1024 (runnable)]
+in meta
+0x40398539 in __morecore () from /lib/libc.so.6
+(gdb) bt
+#0 0x40398539 in __morecore () from /lib/libc.so.6
+#1 0x08067f1c in Cache_process_queue (entry=0x81a5744) at cache.c:785
+#2 0x08067f7f in Cache_delayed_process_queue_callback (data=0x81a5744) at cache.c:803
+#3 0x401dd66c in g_idle_dispatch () from /usr/lib/libglib-1.2.so.0
+#4 0x401dc717 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
+#5 0x401dccdb in g_main_iterate () from /usr/lib/libglib-1.2.so.0
+#6 0x401dce59 in g_main_run () from /usr/lib/libglib-1.2.so.0
+#7 0x4010a069 in gtk_main () from /usr/lib/libgtk-1.2.so.0
+#8 0x080744aa in main (argc=1, argv=0xbffff974) at dillo.c:125
+#9 0x402cd577 in __libc_start_main () from /lib/libc.so.6
+(gdb) 
+
+
+The CacheData_t looks suspicious, especially ->io==NULL.
+
+(gdb) print ((CacheData_t*)data)->Url->url_string->str
+$3 = (gchar *) 0x81affb8 "
+(gdb) print ((CacheData_t*)data)->Type 
+$4 = 0x81dfc80 "text/html"
+(gdb) print ((CacheData_t*)data)->Header->str
+$5 = (
+gchar *) 0x81db960 "HTTP/1.1 200 OK\nDate: Fri, 07 Dec 2001 15:19:12 GMT\nServer: Apache/1.3.20 (Unix) mod_pubcookie/a5release11 PHP/4.0.6 mod_ssl/2.8.4 OpenSSL/0.9.6a\nSet-Cookie: pubcookie_pre_s=fvGX4jdn9iFI1MnhD9JG4SzJpS"...
+(gdb) print ((CacheData_t*)data)->AuthRealm
+$16 = (GString *) 0x0
+(gdb) print ((CacheData_t*)data)->Location 
+$6 = (DilloUrl *) 0x0
+(gdb) print (char*)((CacheData_t*)data)->Data
+$7 = 0x81dc808 "<HTML><HEAD><meta HTTP-EQUIV=\"Refresh\" CONTENT=\"0;URL=></HEAD><BODY BGCOLOR=\"#FFFFFF\"></BODY></HTML>\n"
+(gdb) print ((CacheData_t*)data)->ValidSize
+$8 = 134
+(gdb) print ((CacheData_t*)data)->TotalSize
+$9 = 134
+(gdb) print ((CacheData_t*)data)->BuffSize 
+$10 = 4096
+(gdb) print ((CacheData_t*)data)->Flags 
+$11 = 261
+(gdb) print ((CacheData_t*)data)->io 
+$12 = (IOData_t *) 0x0
+(gdb) print ((CacheData_t*)data)->CCCQuery
+$13 = (ChainLink *) 0x0
+(gdb) print ((CacheData_t*)data)->CCCAnswer
+$14 = (ChainLink *) 0x0
+(gdb) 
+
+
+But I have no idea if this is the actual problem, how it got there, or even what Cache_process_queue is supposed
+to do. Any sage advice?
+
+Thanks,
+David Bliss
+Clinical Informatics Research Group
+Univeristy of Washington 
+
+
+
+[Dillo-dev]Url resolving --Dont panic!
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-07 13:05
+
+Hi,
+
+A few days ago I finished coding the regular-expressions-based
+URL parsing and resolving routines. It's a couple of lines from
+being 100% RFC 2396 compliant, but unfortunately too slow.
+
+I'm absolutely aware of the importance of the speed here. After
+all, there's no point in optimizing the Dw engine and networking
+to our best, while letting the URL resolver take 60% (or more)
+of the rendering time.
+
+I tried to make it faster, developing a new ADT for strings
+(faster than GStrings), but the performance impact was too small
+to make it worth.
+
+A few tests more, and it was clear that the time was being
+dominated by RE parsing.
+
+It was a big effort, but I'm afraid that the way to go now is
+to try to develop a new parser/resolver, without REs, that's as
+RFC compliant as possible.
+
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]About (leaving) SourceForge :-(
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-07 11:45
+
+Hi there!
+
+To SF or not to SF... :)
+
+Considering the alternatives we have, it has become clear that
+if we move, it'd be better to last on the new site for a while.
+It doesn't need to be "the" definitive place, but at least it
+should bring us some settlement peace to keep developing!
+
+- Clinton Ebadi had offered his future CD store's site, but it
+has yet to be started and set.
+- Berlios.de has all the services we require, but it uses SF's
+codebase, so I don't see a clear point in moving there...
+- Savannah doesn't provide CGI, nor ssh account nor statistics.
+(Loic told me). So an hybrid solution comes as the only way here.
+The good point of it is that it's meant to improve, and last.
+
+... and
+
+On Mon, 12 Nov 2001, Eduardo Marcel Ma=E7an wrote:
+
+> If a new home is needed to host dillo from now on, I can arrange for
+> it to be hosted on CIPSGA servers, which already host the
+> debian.org.br primary web mirror, and the pages of the debian-br group.
+> The Debian-br crew is responsible for the maintainance of the servers,
+> I am sure we can quickly arrange space and software to support
+> the development of the dillo web browser.
+>
+> I must say, dillo has somewhat of a cult following among us in the
+> debian-br team :)
+>
+> Regards!
+
+This looks very interesting, it hosts Debian, its devoted to
+helping the GNU/Linux cause, its maintained by the Debian-br crew
+(one less task :), and I love Brazil!
+
+So, Eduardo, please go a step further and investigate what can
+we have there. The key points are:
+
+- CGI enabled web server
+- ssh account to set and maintain it.
+
+
+Best regards
+Jorge.- 
+
+
+
+[Dillo-dev]Re: fonts, the dillo browser, gtk 2.0
+
+From: Havoc Pennington <hp@re...> - 2001-12-07 02:56
+
+Michael Taht <mtaht@mv...> writes:
+> I decided to take a stab at making the dillo web browser
+> (dillo.so....net) compile under gtk 1.3.x this afternoon. Most
+> of it compiled with a very minimal set of changes, but as I haven't
+> been keeping up with changes to GTK, I fell off the end of the world
+> pretty fast, and have since been searching the FAQ and mailing lists
+> with little success. I'm currently reading up on pango and looking in
+> example code, but any help you can provide....
+> The biggest change in GTK 1.3.x seems to be the font handling. OK,
+> style->font doesn't exist anymore. The doc says most of the functions
+> that give you a GdkFont are depriciated, presumably replaced by pango
+> versions. Is there anything resembling a cookbook for porting apps
+> forward from 1.2.x to 1.3.x?
+> 
+
+There's this guide that might be useful:
+
+http://developer.gnome.org/dotplan/porting/
+
+Havoc 
+
+
+
+Re: [Dillo-dev]Getting data from buffer, what goes wrong?
+
+From: Lars Clausen <lrclause@cs...> - 2001-12-07 02:35
+
+On 06 Dec 2001, Lars Clausen wrote:
+
+>=20
+> I'm working on a little Christmas present for Dillo (don't tell it:):
+> External viewers. I've got it pretty well set up, but when I try to
+> download, I get corrupted files.=20
+[...]
+> Are there any tricky little issues I should be cautious about? Or did I
+> make a terrible mistake somewhere? I don't know.
+
+Now I do. I did indeed make a stupid mistake, and now it works. Still a
+few pieces to add.
+
+One thing I wanted to know: Is there any way to add callback data when
+adding a viewer for a mime type? I see callback data being passed around,
+but I'mnot sure where it originates and if I can just use that.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Getting data from buffer, what goes wrong?
+
+From: Lars Clausen <lrclause@cs...> - 2001-12-07 00:59
+
+I'm working on a little Christmas present for Dillo (don't tell it:):
+External viewers. I've got it pretty well set up, but when I try to
+download, I get corrupted files. They are of the same length as the
+original, but differ. The client callback function I use is:
+
+
+static void External_callback(int Op, CacheClient_t *Client) {
+DilloExternalWriter *external =3D Client->CbData;
+DilloExternalProgram *ext_prog;
+int bufsize =3D Client->BufSize;
+
+if ( Op !=3D CA_Send) {
+/* Close or Abort */
+=20=20=20=20
+/* Do the last line: */
+if (external->offset < bufsize) {
+write(external->temp_fd, Client->Buf, bufsize-external->offset);
+external->offset =3D bufsize;
+}
+/* remove this client from our active list */
+a_Interface_close_client(external->bw, Client->Key);
+/* set progress bar insensitive */
+a_Progressbar_update(external->bw->progress, NULL, 0);
+
+/* Start a new process and remember its filename */
+ext_prog =3D External_make_process(external->command,
+external->temp_file_name);
+if (ext_prog !=3D NULL) {
+ext_prog->filename =3D external->temp_file_name;
+}
+=20
+close(external->temp_fd);
+g_free(external);
+} else {
+write(external->temp_fd, Client->Buf, bufsize-external->offset);
+external->offset =3D bufsize;
+}
+}
+
+Are there any tricky little issues I should be cautious about? Or did I
+make a terrible mistake somewhere? I don't know.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]fonts, the dillo browser, gtk 2.0
+
+From: Michael Taht <mtaht@mv...> - 2001-12-07 00:15
+
+I decided to take a stab at making the dillo web browser 
+(dillo.so....net) compile under gtk 1.3.x this afternoon. Most of 
+it compiled with a very minimal set of changes, but as I haven't been 
+keeping up with changes to GTK, I fell off the end of the world pretty 
+fast, and have since been searching the FAQ and mailing lists with 
+little success. I'm currently reading up on pango and looking in example 
+code, but any help you can provide....
+
+The biggest change in GTK 1.3.x seems to be the font handling. OK, 
+style->font doesn't exist anymore. The doc says most of the functions 
+that give you a GdkFont are depriciated, presumably replaced by pango 
+versions. Is there anything resembling a cookbook for porting apps 
+forward from 1.2.x to 1.3.x?
+
+make -k - reports only 12^2 lines of errors to fix... 
+
+
+
+[Dillo-dev]use dillo in other applications?
+
+From: Scott Weisman <sweisman@po...> - 2001-12-06 15:56
+
+Hello,
+
+I think Dillo is great and hope you keep up the development effort.
+
+I have a question that I haven't been able to find an answer on after a
+lot of searching.
+
+Is Dillo embeddable in other applications? I am interested in using it as
+a replacement for gtkhtml, but it seems Dillo is implemented as a
+standalone monolithic application.
+
+Can somebody clarify?
+
+Thanks for the help,
+
+Scott Weisman 
+
+
+
+Re: [Dillo-dev]newline in urlencoded
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-05 16:53
+
+On Wed, 5 Dec 2001, ksr wrote:
+
+> Hi.
+>
+> When posting, the newline character '\n' in multiline text should be
+> converted to \r\n.
+>
+> Best Regards.
+
+Please refer me the SPEC (or RFC) section where it's stated. I
+haven't found it yet :(
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]newline in urlencoded
+
+From: ksr <ksr@po...> - 2001-12-04 15:34
+
+Hi. 
+
+When posting, the newline character '\n' in multiline text should be
+converted to \r\n. 
+
+Best Regards. 
+
+
+
+Re: [Dillo-dev]special characters in URL encode
+
+From: Jorge Arellano Cid <jcid@em...> - 2001-12-04 13:09
+
+On 3 Dec 2001, TANAKA Keishiro wrote:
+
+>
+> According to RFC 2396, special characters in URL encode should be
+>
+> static const guchar special[] = "-_.!~*'()";
+>
+> in Html_urlencode_append in html.c.
+
+Yes.
+
+That's with regard to generic URI parsing though. An
+authoritative slection can be done after studying the whole
+gateway process that the URI may traverse, and probably is not
+bad to add a few more empirically known to cause trouble...
+
+In short I decided to mimic lynx and netscape (they escape
+exactly the same set!) i.e. all but "-_.*".
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]IPv6
+
+From: Tobin Fricke <tobin@sp...> - 2001-12-03 19:17
+
+This weekend I added IPv6 support to Dillo. I'm interested in receiving
+comments on my patch, which is available from:
+
+http://splorg.org/people/tobin/projects/dillo/
+
+-- Tobin 
+
+
+
+[Dillo-dev]special characters in URL encode
+
+From: TANAKA Keishiro <ksr@lp...> - 2001-12-03 06:17
+
+According to RFC 2396, special characters in URL encode should be
+
+static const guchar special[] = "-_.!~*'()";
+
+in Html_urlencode_append in html.c. 
+
+
+
+Re: [Dillo-dev]Fake ID patch - 2nd attempt
+
+From: Lars Clausen <lrclause@cs...> - 2001-12-02 15:47
+
+On Sun, 2 Dec 2001, Andreas Schweitzer wrote:
+
+[...]
+> This one works via the preferences. This is probably
+> the best solution in Dillo's philosophy to keep it small
+> and fast. Once the preferences can be changed from within Dillo,
+> changing its ID-string should be a breeze and possible on the fly.
+
+How hard would it be to have the preferences be reloadable at run-time, but
+still from the file? It would require the same kinds of changes that an
+inline preferences dialog would, but not the bloat of an actual dialog.
+You could even have a stand-alone preferences program, if you were so
+inclined:)=20
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Fake ID patch - 2nd attempt
+
+From: Andreas Schweitzer <andy@ph...> - 2001-12-02 07:45
+
+Hi everybody,
+A few weeks back I submitted a dirty hack to make Dillo
+pretend to be IE.
+
+I just submitted a much cleaner patch to the patch-o-matic
+http://haru.wom.ru/pub/dillo/patches.html
+
+For simplicity, I also include it here.
+This patch is against the CVS snapshot I downloaded
+a few hours ago.
+
+This one works via the preferences. This is probably
+the best solution in Dillo's philosophy to keep it small
+and fast. Once the preferences can be changed from within Dillo,
+changing its ID-string should be a breeze and possible on the fly.
+
+If you find it useful enough to include into the main
+source, I'd be honored.
+
+Cheers
+Andreas
+
+
+
+diff -r -u dillo-orig/dillorc dillo/dillorc
+--- dillo-orig/dillorc Fri Nov 16 08:35:34 2001
++++ dillo/dillorc Sun Dec 2 02:13:23 2001
+@@ -99,5 +99,24 @@
+# for the ION window manager.
+transient_dialogs=NO
+
++#-----------------
++# Fake Dillo's ID
++#-----------------
++# Allowed abbreviations are
++# id_string=IE
++# for pretending to be Internet Explorer 6
++# id_string=NS
++# for pretending to be Netscape 4.78
++# id_string=default 
++# for Dillo's own string
++# any other string will be used directly as ID string,
++# e.g. :
++# id_string="Mozilla/4.78 (X11; Linux 2.4.16; Nav)"
++# if this option is not given, Dillo will default to "default" - obviously
++# quotes are only needed if you want to insert spaces in the ID string
++
++#id_string=NS
++
++
+# -----------------------------------------------------------------------
+# dillorc ends here.
+diff -r -u dillo-orig/src/IO/http.c dillo/src/IO/http.c
+--- dillo-orig/src/IO/http.c Tue Nov 20 09:47:02 2001
++++ dillo/src/IO/http.c Sun Dec 2 02:11:49 2001
+@@ -31,6 +31,7 @@
+#include "../cache.h"
+#include "../web.h"
+#include "../interface.h"
++#include "../prefs.h"
+
+
+/* Used to send a message to the bw's status bar */
+@@ -105,7 +106,8 @@
+gchar *str, *ptr;
+GString *s_port = g_string_new(""),
+*query = g_string_new(""),
+- *full_path = g_string_new("");
++ *full_path = g_string_new(""),
++ *id_string = g_string_new("");
+
+/* Sending the default port in the query may cause a 302-answer. --Jcid */
+if (URL_PORT(url) && URL_PORT(url) != DILLO_URL_HTTP_PORT)
+@@ -122,17 +124,45 @@
+URL_PATH(url) ? URL_PATH(url) : "/");
+}
+
++/*
++ *
++ * #define IE_STRING "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.0)"
++ *
++ * There could be a function, that tests if
++ * - the URL is on a blacklist
++ * - the user invoked a command line switch
++ * - the user pressed a button on the browser window
++ * this function could even return the string
++ *
++ * if ( pretend_incognito(URL_STR(url)) ){
++ * 
++ * As example there is a check if *.msn.com is accessed.
++ *
++ * if ( strstr(URL_STR(url),".msn.com") !=NULL) {
++ * g_string_sprintfa(id_string,"%s", IE_STRING);
++ * } else {
++ * g_string_sprintfa(id_string, "Dillo/%s", VERSION);
++ * }
++ *
++ * In the simplest and leanest incarnation, it simply
++ * reads the preferences. That way, it can even change
++ * its identity on the fly. At least as soon as the preferences
++ * can be changed on the fly.
++ */
++
++ g_string_sprintfa(id_string, "%s", prefs.id_string.str);
++
+if ( URL_FLAGS(url) & URL_Post ){
+g_string_sprintfa(
+query,
+"POST %s HTTP/1.0\r\n"
+"Host: %s%s\r\n"
+- "User-Agent: Dillo/%s\r\n"
++ "User-Agent: %s\r\n"
+"Content-type: application/x-www-form-urlencoded\r\n"
+"Content-length: %ld\r\n"
+"\r\n"
+"%s",
+- full_path->str, URL_HOST(url), s_port->str, VERSION,
++ full_path->str, URL_HOST(url), s_port->str, id_string->str,
+(glong)strlen(URL_DATA(url)), URL_DATA(url));
+
+} else {
+@@ -141,12 +171,12 @@
+"GET %s HTTP/1.0\r\n"
+"%s"
+"Host: %s%s\r\n"
+- "User-Agent: Dillo/%s\r\n"
++ "User-Agent: %s\r\n"
+"\r\n",
+full_path->str,
+(URL_FLAGS(url) & URL_E2EReload) ?
+"Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+- URL_HOST(url), s_port->str, VERSION);
++ URL_HOST(url), s_port->str, id_string->str);
+}
+
+str = query->str;
+diff -r -u dillo-orig/src/prefs.c dillo/src/prefs.c
+--- dillo-orig/src/prefs.c Fri Nov 16 06:01:33 2001
++++ dillo/src/prefs.c Sun Dec 2 02:11:49 2001
+@@ -29,6 +29,9 @@
+#include "dillo.h"
+#include "misc.h"
+
++#define IE_STRING "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.0)"
++#define NS_STRING "Mozilla/4.78 [en] (X11; U; Linux 2.4.16 i686; Nav)"
++
+/* symbol array */
+static const struct {
+gchar *name;
+@@ -61,7 +64,8 @@
+{ "show_clear_url", DRC_TOKEN_SHOW_CLEAR_URL },
+{ "show_url", DRC_TOKEN_SHOW_URL },
+{ "show_progress_box", DRC_TOKEN_SHOW_PROGRESS_BOX },
+- { "transient_dialogs", DRC_TOKEN_TRANSIENT_DIALOGS }
++ { "transient_dialogs", DRC_TOKEN_TRANSIENT_DIALOGS },
++ { "id_string", DRC_TOKEN_ID_STRING }
+};
+
+static const guint n_symbols = sizeof (symbols) / sizeof (symbols[0]);
+@@ -192,6 +196,17 @@
+case DRC_TOKEN_TRANSIENT_DIALOGS:
+prefs.transient_dialogs = (strcmp(scanner->value.v_string, "YES") == 0);
+break;
++ case DRC_TOKEN_ID_STRING:
++ prefs.id_string=*g_string_new("");
++ if (!strcmp(scanner->value.v_string, "IE")) 
++ g_string_sprintfa(&prefs.id_string,"%s", IE_STRING);
++ else if (!strcmp(scanner->value.v_string, "NS")) 
++ g_string_sprintfa(&prefs.id_string,"%s", NS_STRING);
++ else if (!strcmp(scanner->value.v_string, "default"))
++ g_string_sprintfa(&prefs.id_string,"%s", D_ID_STRING);
++ else
++ g_string_sprintfa(&prefs.id_string,"%s", scanner->value.v_string);
++ break; 
+default:
+break; /* Not reached */
+}
+@@ -309,6 +324,7 @@
+prefs.show_url=TRUE;
+prefs.show_progress_box=TRUE;
+prefs.transient_dialogs=FALSE;
++ prefs.id_string=*g_string_new(D_ID_STRING);
+
+Prefs_load();
+}
+diff -r -u dillo-orig/src/prefs.h dillo/src/prefs.h
+--- dillo-orig/src/prefs.h Fri Nov 16 06:01:33 2001
++++ dillo/src/prefs.h Sun Dec 2 02:11:49 2001
+@@ -2,6 +2,7 @@
+#define __DILLO_RC_H__
+
+#include "url.h"
++#include "../config.h"
+
+#ifdef __cplusplus
+extern "C" {
+@@ -16,6 +17,8 @@
+#define DW_COLOR_DEFAULT_PURPLE 0x800080
+#define DW_COLOR_DEFAULT_BGND 0xd6d6c0
+
++#define D_ID_STRING "Dillo/" ## VERSION ## ""
++
+/* define enumeration values to be returned */
+enum {
+PARSE_OK = 0,
+@@ -53,6 +56,7 @@
+DRC_TOKEN_SHOW_URL,
+DRC_TOKEN_SHOW_PROGRESS_BOX,
+DRC_TOKEN_TRANSIENT_DIALOGS,
++ DRC_TOKEN_ID_STRING,
+
+DRC_TOKEN_LAST
+} Dillo_Rc_TokenType;
+@@ -89,6 +93,7 @@
+gboolean show_url;
+gboolean show_progress_box;
+gboolean transient_dialogs;
++ GString id_string;
+};
+
+/* Global Data */ 
+
+
+
+[Dillo-dev]m17n
+
+From: ksr <ksr@po...> - 2001-12-01 01:41
+
+Hello.
+
+I created Japanese support and maybe also m17n patch based on Robert Thomson's.
+
+See http://todo.org/cgi-bin/en/tiki/tiki.cgi?p=Dillo
+
+But I released only package but patch, sorry. 
+file: dillo-0.6.2-uo-branch-1.tgz 
+
diff --git a/old/oldmail/200201.txt b/old/oldmail/200201.txt
new file mode 100644
index 0000000..ab8b2fa
--- /dev/null
+++ b/old/oldmail/200201.txt
@@ -0,0 +1,3654 @@
+Re: [Dillo-dev]Ditching pthreads
+
+From: Sam Dennis <sam@ma...> - 2002-01-31 23:22
+
+Some time around 8 o'clock PM on January 31, a Thursday, Sam Dennis wrote many
+things about using GIOChannels in file.c to replace pthreads without first
+trying to implement it and therefore overlooking the inadequacy of GIOChannels
+with regard to detecting EOF and the fact that we already use them in http.c.
+This shows that the statement most likely to be true in the message was about
+him not being an expect on dillo's IO subsystem. He still holds that we don't
+need threads, though. 
+
+
+
+Re: [Dillo-dev]Ditching pthreads
+
+From: Andreas Schweitzer <andy@ph...> - 2002-01-31 20:41
+
+On Thu, Jan 31, 2002 at 08:35:44PM +0000, Sam Dennis wrote:
+> Since it (pthreads if you missed the subject line) appears to be causing so
+> many problems on unusual systems, why not just remove it?
+
+If you refer to compiling on *BSD systems, I was looking into this.
+Here is a patch that should make compilation on FreeBSD - and possibly
+the others - easier :
+
+--- configure.in.orig Tue Jan 29 18:35:43 2002
++++ configure.in Thu Jan 31 15:36:07 2002
+@@ -4,6 +4,8 @@
+AM_INIT_AUTOMAKE(dillo, 0.6.4)
+AM_CONFIG_HEADER(config.h)
+
++CPPFLAGS=-I/usr/local/include
++LDFLAGS=-L/usr/local/lib
+
+dnl Options
+
+@@ -68,7 +70,7 @@
+fi
+
+
+-AC_CHECK_LIB(pthread, pthread_create)
++AC_SEARCH_LIBS(pthread_create, pthread c_r, thread_ok=yes, thread_ok=no)
+AC_CHECK_LIB(z, zlibVersion)
+AC_CHECK_LIB(png, png_check_sig)
+
+
+Of course, now you have to run autoconf again. It needs some
+testing, though. I only tested on FreeBSD so far.
+
+Now, this is *only* *compiling* ...
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Ditching pthreads
+
+From: Sam Dennis <sam@ma...> - 2002-01-31 20:30
+
+Since it (pthreads if you missed the subject line) appears to be causing so
+many problems on unusual systems, why not just remove it?
+
+I'm no expert on our IO subsystem but we already rely on glib, which has a
+very handy-looking thing called a GIOChannel. We could, of course, manage
+without it but it's there so why not use it?
+
+Of course, I haven't thoroughly scrutinised the code so it may be that there's
+some deeply profound reason for using threaded IO, but I doubt it.
+
+The only other thing we seem to use pthreads for is asynchronous DNS lookups,
+and that is optional but could be handled with, off the top of my head, a
+forked process. 
+
+
+
+Re: [Dillo-dev]dillo on *BSD
+
+From: Andreas Schweitzer <andy@ph...> - 2002-01-31 16:43
+
+Hi again,
+
+I've been looking in making ports for FreeBSD and OpenBSD
+and maybe NetBSD ;-). It seems, there is already something
+happening and NetBSD seems to have a port/package !:
+
+NetBSD :
+http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/dillo/
+I have also found ports to Handhelds and whatnot ;-):
+http://mail-index.netbsd.org/port-hpcmips/2001/12/
+(this is for the MIPS HP/C handhelds like the Cassiopeias)
+
+FreeBSD work in progress :
+http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33122
+
+OpenBSD work in progress :
+http://www.monkey.org/openbsd/archive/ports/0109/msg00198.html
+http://www.monkey.org/openbsd/archive/ports/0110/msg00001.html
+
+I'll probably look into this in more detail on the weekend.
+But the patches they apply should already help.
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Start-up time and gtk_set_locale()
+
+From: Pekka Lampila <medar@ka...> - 2002-01-31 16:22
+
+Hi,
+
+(Ah, I'm finally able to post here, after changing my SMTP server)
+
+I've been thinking if it would be possible to reduce Dillo's start-up
+time, so I tested few things.
+
+If I place return 0; before gtk_main() in dillo.c, average runtime is
+about 2.5 seconds. (When no window manager is running). After removing
+gtk_set_locale() the average time is only about 1.8 secs.
+(My machine is P133 with 72mb of RAM)
+
+gtk_set_locale was added in 0.6.2. So maybe problems that were fixed by
+it could be dealt with some other way?
+
+On the other hand this sounds like the kind of thing that could be
+"fixed" by GTK 2.0 ...
+
+Keep up the good work. :)
+
+-- 
+Pekka Lampila - medar@ka... 
+
+
+
+Re: [Dillo-dev]Dillo on NetBSD
+
+From: Bjoern Weber <foxbow@we...> - 2002-01-31 15:06
+
+Imad <magius@pu...> schrieb am 31.01.02:
+> On Thu, 31 Jan 2002, Andreas Schweitzer wrote:
+> > > Another funny thing is the fact that I can compile only once.
+> > > If I try a second make, it bombs out, complaining about
+> > > defective AMDEP lines in the Makefile. I suppose that my
+> > > automake is outdated, yet shouldn't configure notice that?
+> > Just to check : I have to use gmake on FreeBSD, what about
+> > NetBSD ?
+> My guess would be yes, you need to use gmake, as OpenBSD is pretty
+> similiar to NetBSD and OpenBSD's BSD make will fail.
+
+Makes no real difference with me. I can use both - yet both just
+once. And that *only* happens in the checked out CVS tree, not 
+in the final distributions.
+
+Bjoern
+
+-- 
+A nuclear bomb is really funny but when it comes your way
+Falling on your breakfast table can disturb your day!
+(Off - Bad News)
+______________________________________________________________________________
+All inclusive! 100 MB Speicher, 1000 Mails, Wunschrufnummer, Superstars,
+Events, Preisvorteile und mehr unter http://club.web.de/?mc=021104 
+
+
+
+[Dillo-dev]Success on Solaris
+
+From: Miklos Magyari <miklos.magyari@et...> - 2002-01-31 15:06
+
+hi there,
+
+just to report: 0.6.4 compiles and runs fine on s SparcStation 5 with
+Solaris 8.
+
+cheers,
+Miki 
+
+
+
+Re: [Dillo-dev]Dillo on NetBSD
+
+From: Imad <magius@pu...> - 2002-01-31 14:10
+
+On Thu, 31 Jan 2002, Andreas Schweitzer wrote:
+
+> Hi,
+>
+> > Unfortunately I can't compile the cvs without tweaking.
+> > First of all I need to touch depmod in the root directory
+> > then I need to copy config.h into the src/IO directory.
+> >
+> > Another funny thing is the fact that I can compile only once.
+> > If I try a second make, it bombs out, complaining about
+> > defective AMDEP lines in the Makefile. I suppose that my
+> > automake is outdated, yet shouldn't configure notice that?
+>
+> Just to check : I have to use gmake on FreeBSD, what about
+> NetBSD ?
+
+My guess would be yes, you need to use gmake, as OpenBSD is pretty
+similiar to NetBSD and OpenBSD's BSD make will fail.
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+Re: [Dillo-dev]Dillo on NetBSD
+
+From: Andreas Schweitzer <andy@ph...> - 2002-01-31 14:06
+
+Hi,
+
+> Unfortunately I can't compile the cvs without tweaking.
+> First of all I need to touch depmod in the root directory
+> then I need to copy config.h into the src/IO directory.
+> 
+> Another funny thing is the fact that I can compile only once.
+> If I try a second make, it bombs out, complaining about
+> defective AMDEP lines in the Makefile. I suppose that my
+> automake is outdated, yet shouldn't configure notice that?
+
+Just to check : I have to use gmake on FreeBSD, what about
+NetBSD ?
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]*BSD and dillo's configure
+
+From: Imad <magius@pu...> - 2002-01-31 12:14
+
+Hi!
+
+Running configure as follows worked for me on my SPARCstation 5/OpenBSD
+3.0:
+
+LIBS="-pthread " ./configure --with-jpeg-inc=/usr/local/include
+
+However, although gmake can compile the source, Dillo repeatedly
+core-dumps. It opens up the "about" page fine but as soon as I ask it to
+fetch another page, boom! core dump:
+
+
+Setting locale to C
+dillo_dns_init: Here we go!
+Loading bookmarks...
+Nav_open_url: Url=>about:splash<
+Nav_open_url: Url=>http://dillo.so....net/ChangeLog.html<
+pid 32387: Fatal error p' at line 573 in file (errno = 0)
+1;2c
+
+It does seem possible to sometimes get through to a text-only page, but
+even that occurs very, very rarely. I *know* Dillo isn't this buggy --
+old versions didn't die nearly this easily, and Dillo's gotten better
+with time, so I'm pretty sure that it's a configuration/compile problem,
+likely with pthreads.
+
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+Re: [Dillo-dev]*BSD and dillo's configure
+
+From: Bjoern Weber <foxbow@we...> - 2002-01-31 10:18
+
+Jorge Arellano Cid <jcid@em...> schrieb am 30.01.02:
+> Hi BSDers!
+>=20
+> Within my email collection :), I have several references to
+> problems with *BSD, in what regards to jpeg-library-detection and
+> pthreads.
+>=20
+> Dillo 0.6.4 has a new check for jpeg library that seems to be
+> working (at least here and in some other machines where the
+> problem was present before). Those of you that had problems with
+> it, please test and report how it goes.
+Unfortunately I was tweaking my system instead of the Makefile to
+get rid of that problem as several other packages bombed out similar.
+
+> The pthreads library problem is more complex. As I wrote
+> before:
+[...]
+> Sometime ago Sammy sent me a big patch (60Kb aprox) that solved
+> the pthread library detection. I'm reluctant to include such a
+> big patch, specially knowing that 'configure' already takes 120Kb=20
+> Maybe there's a smaller solution that can do it. As a custom
+> test in configure.in for instance (just an idea).
+Hmmh, before installing the pthread library from NetBSD I just had=20
+to tweak about four lines in the source and kick out on superflous
+include to get things going without pthreads. But.. oh, I guess
+that hack had influences on the file->save behaviour.
+
+[...]
+> Sammy, nstalkie at tvd dot be
+> Richard, rcagny in mtice . fr
+> Bjoern, foxbow on web dot de
+> Brian, brian at budbud . dhs dot org
+[...]
+> Note1: Bjoern told me he was going to work on a solution, so he
+> may have something.
+> Note2: Brian may not have enough time. :(
+Hmmh, since there seems to be sincere interest in that point I
+will pick up my work again and will have a closer look at the
+problems I stated in another mail as well.
+
+Greetings,
+Bjoern
+
+--=20
+A nuclear bomb is really funny but when it comes your way
+Falling on your breakfast table can disturb your day!
+(Off - Bad News)
+=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
+=5F=5F=5F=5F
+E*TRADE - neu in Deutschland. Jetzt Depot er=F6ffnen + Pr=E4mie erhalten=20
+http://etrade.web.de 
+
+
+
+[Dillo-dev]Dillo on NetBSD
+
+From: Bjoern Weber <foxbow@we...> - 2002-01-31 10:00
+
+Just for the records. After I installed the pthreads package and
+linked the jpeg and png libs down to /usr/lib the 0.6.4 version
+compiles from scratch, running like a charm.
+
+Unfortunately I can't compile the cvs without tweaking.
+First of all I need to touch depmod in the root directory
+then I need to copy config.h into the src/IO directory.
+
+Another funny thing is the fact that I can compile only once.
+If I try a second make, it bombs out, complaining about
+defective AMDEP lines in the Makefile. I suppose that my
+automake is outdated, yet shouldn't configure notice that?
+
+This all was tested on a SUN SparcStation 5 running under 
+NetBSD 1.5.2
+
+If my descriptions were too vague just send me a note and I'll
+retry it at home (actually at work, typing from memory)
+
+Greetings,
+Bjoern
+
+P.S.: The QNX x86 0.6.4 runs better than the 0.6.3 I'm about
+to make an official statement about that.
+-- 
+A nuclear bomb is really funny but when it comes your way
+Falling on your breakfast table can disturb your day!
+(Off - Bad News)
+______________________________________________________________________________
+Die Nummer, die sich jeder merkt: Ihre 01212 Wunschrufnummer von WEB.DE! 
+Jetzt sichern: http://freemail.web.de 
+
+
+
+Re: [Dillo-dev]dillo-0.6.4 ????
+
+From: Bill Thompson <billt@ha...> - 2002-01-31 02:17
+
+On Wed, 30 Jan 2002 15:01:49 +0100
+belaruse@we... wrote:
+
+> Hi,
+> 
+> where can I find dillo-0.6.4 ? 
+> http://download.so....net/dillo/ contains only dillo-0.6.3 !
+> 
+> ri
+
+dillo-0.6.4 for Mandrake 8.1 can be found at:
+ftp://ftp.eastwind.net/pub/mirrors/texstar/Mandrake-8.1-i586/dillo-0.6.4-1mdk.i586.rpm
+
+Bill
+-- 
+From the shores of Khlong YaiPhuan, Bangkok, Thailand... 
+
+
+
+Re: [Dillo-dev]dillo on *BSD
+
+From: DraX <drax@wh...> - 2002-01-30 21:37
+
+On OpenBSD you add -pthreads and it works, if memory serves that does
+-lc_r -lpthread -D_REENTERENT_ perhaps more, perhaps less.
+
+On Wed, 30 Jan 2002, John Utz wrote:
+
+> more FreeBSD input....
+> 
+> On Wed, 30 Jan 2002, Andreas Schweitzer wrote:
+> 
+> > Hi everybody,
+> > 
+> > Jorge, as you asked for some BSD fixes here it goes.
+> > 
+> > There are 2 main things that could help a lot :
+> > 
+> > 1. All the libs like jpeg anf gtk etc. live in /usr/local
+> > (/usr/local/lib /usr/local/include and /usr/local/bin/gtk-config)
+> > This is standard on all *BSD's. So, I think if autoconf/automake etc.
+> > simply starts looking in /usr/local/ then things should improve
+> > significantly. (I am not that familiar with these tools, sorry)
+> 
+> i second this, and it seems to not be a problem on any other gtk apps that 
+> use configure....
+> 
+> > 2. The trheads require the
+> > -lc_r
+> > switch instead of -lpthread .... beats me .... at least on FreeBSD.
+> > I'll check the other *BSD's eventually.
+> 
+> nope! not no more! at least in theory :-) FreeBSD-4.5 should be ok with 
+> the -lpthread and not require -lc_r ( i am running a FreeBSD-stable drop 
+> from the middle of december. it's possible that it got pulled, but i 
+> doubt it.
+> 
+> i'll actually have some FACT's in a few weeks when i finally get around to 
+> upgrading to 4.5-RELEASE. others may be able to make this change more 
+> quickly than i can in the near future.
+> 
+> > BTW, there is a port of dillo0.4 in /usr/ports/www in FreeBSD. This
+> > gave away quite a bit ;-) ....
+> 
+> obviously, one of us FreeBSD users needs to run out and fix that :-)
+> 
+> > So far, I usually got dillo compile on the *BSD's if I include a lot
+> > of things like LD_PATH=..... or --with-jpeg-lib=..... GTK_CONFIG=.....
+> 
+> assuming that Jorge patched the LIBJPEG_INCDIR problem, then you should 
+> only need:
+> 
+> ./configure --with-jpeg-include=/usr/local/include and all should be well 
+> with *compiling*, then you have to go back and fix the makefile to fixup 
+> the link problem by adding -lc_r to the LFLAGS *if* it's FreeBSD 
+> 4.4-RELEASE or earlier.
+> 
+> then you get a bunch of warnings about insecure uses of mktmp() and other 
+> things, but i ignore them 'cause the browser works :-)
+> 
+> -- 
+> 
+> John L. Utz III
+> john@ut...
+> 
+> Idiocy is the Impulse Function in the Convolution of Life
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]dillo on *BSD
+
+From: Andreas Schweitzer <andy@ph...> - 2002-01-30 20:07
+
+> > 2. The trheads require the
+> > -lc_r
+> > switch instead of -lpthread .... beats me .... at least on FreeBSD.
+> > I'll check the other *BSD's eventually.
+> 
+> nope! not no more! at least in theory :-) FreeBSD-4.5 should be ok with 
+> the -lpthread and not require -lc_r ( i am running a FreeBSD-stable drop 
+> from the middle of december. it's possible that it got pulled, but i 
+> doubt it.
+
+Well, I still run 4.4+patches though I have an 4.5 ISO image ... :-)
+
+> > BTW, there is a port of dillo0.4 in /usr/ports/www in FreeBSD. This
+> > gave away quite a bit ;-) ....
+> 
+> obviously, one of us FreeBSD users needs to run out and fix that :-)
+
+Is this the time to find out how ports are made ... ?
+
+> then you get a bunch of warnings about insecure uses of mktmp() and other 
+> things, but i ignore them 'cause the browser works :-)
+
+I think, these warnings come from make, but I'm used to them. And yes,
+I also had to use gmake
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]dillo on *BSD
+
+From: John Utz <john@ut...> - 2002-01-30 19:14
+
+more FreeBSD input....
+
+On Wed, 30 Jan 2002, Andreas Schweitzer wrote:
+
+> Hi everybody,
+> 
+> Jorge, as you asked for some BSD fixes here it goes.
+> 
+> There are 2 main things that could help a lot :
+> 
+> 1. All the libs like jpeg anf gtk etc. live in /usr/local
+> (/usr/local/lib /usr/local/include and /usr/local/bin/gtk-config)
+> This is standard on all *BSD's. So, I think if autoconf/automake etc.
+> simply starts looking in /usr/local/ then things should improve
+> significantly. (I am not that familiar with these tools, sorry)
+
+i second this, and it seems to not be a problem on any other gtk apps that 
+use configure....
+
+> 2. The trheads require the
+> -lc_r
+> switch instead of -lpthread .... beats me .... at least on FreeBSD.
+> I'll check the other *BSD's eventually.
+
+nope! not no more! at least in theory :-) FreeBSD-4.5 should be ok with 
+the -lpthread and not require -lc_r ( i am running a FreeBSD-stable drop 
+from the middle of december. it's possible that it got pulled, but i 
+doubt it.
+
+i'll actually have some FACT's in a few weeks when i finally get around to 
+upgrading to 4.5-RELEASE. others may be able to make this change more 
+quickly than i can in the near future.
+
+> BTW, there is a port of dillo0.4 in /usr/ports/www in FreeBSD. This
+> gave away quite a bit ;-) ....
+
+obviously, one of us FreeBSD users needs to run out and fix that :-)
+
+> So far, I usually got dillo compile on the *BSD's if I include a lot
+> of things like LD_PATH=..... or --with-jpeg-lib=..... GTK_CONFIG=.....
+
+assuming that Jorge patched the LIBJPEG_INCDIR problem, then you should 
+only need:
+
+./configure --with-jpeg-include=/usr/local/include and all should be well 
+with *compiling*, then you have to go back and fix the makefile to fixup 
+the link problem by adding -lc_r to the LFLAGS *if* it's FreeBSD 
+4.4-RELEASE or earlier.
+
+then you get a bunch of warnings about insecure uses of mktmp() and other 
+things, but i ignore them 'cause the browser works :-)
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]*BSD and dillo's configure
+
+From: Miklos Magyari <miklos.magyari@et...> - 2002-01-30 16:02
+
+hi all, 
+
+> Within my email collection :), I have several references to
+> problems with *BSD, in what regards to jpeg-library-detection and
+> pthreads.
+> 
+> Dillo 0.6.4 has a new check for jpeg library that seems to be
+> working (at least here and in some other machines where the
+> problem was present before). Those of you that had problems with
+> it, please test and report how it goes.
+
+> 
+> LIBS="-pthread" ./configure
+> 
+
+1) I had a success running configure in a following way:
+
+./configure --with-jpeg-inc=/usr/local/include
+
+(without --with-jpeg-inc configure didn't find the jpeg headers)
+
+2) build succeeded. Still doesn't work with BSD make, though. (Automake
+creates makefiles with some gmake specific things. One example is the
+include directive, which supports including multiple files with one
+directive with gmake, but doesn't with bsd make.)
+
+Additionally, I think GTK_CONFIG should also be set. I've compiled a lot
+of autoconf/automake programs before and got bored with gtk-config. At
+least under my FreeBSD 4.2, the file is actually called gtk12-config, so
+I've created a symlink to make configure work.
+
+cheers,
+Miki 
+
+
+
+[Dillo-dev]dillo on *BSD
+
+From: Andreas Schweitzer <andy@ph...> - 2002-01-30 15:24
+
+Hi everybody,
+
+Jorge, as you asked for some BSD fixes here it goes.
+
+There are 2 main things that could help a lot :
+
+1. All the libs like jpeg anf gtk etc. live in /usr/local
+(/usr/local/lib /usr/local/include and /usr/local/bin/gtk-config)
+This is standard on all *BSD's. So, I think if autoconf/automake etc.
+simply starts looking in /usr/local/ then things should improve
+significantly. (I am not that familiar with these tools, sorry)
+2. The trheads require the
+-lc_r
+switch instead of -lpthread .... beats me .... at least on FreeBSD.
+I'll check the other *BSD's eventually.
+
+BTW, there is a port of dillo0.4 in /usr/ports/www in FreeBSD. This
+gave away quite a bit ;-) ....
+
+So far, I usually got dillo compile on the *BSD's if I include a lot
+of things like LD_PATH=..... or --with-jpeg-lib=..... GTK_CONFIG=.....
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Re: Move from SF.
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-30 15:16
+
+Eduardo,
+
+> I am still here!!! :)
+
+Good!
+
+> I had a very late 2001 and am still having a
+> very turbulent early 2002 in Real Life(tm)... ranging
+> from getting through the bureaucracy of getting a
+> bank to finance an appartment to me, through moving
+> to the new appartment and more recently having a close
+> relative with a delicate health problem.
+
+Receive my best wishes.
+
+> I am still on forced "vacations" from almost all
+> my Free Software activities, but I can still help on the
+> move to cipsga, even if only to put you in touch
+> with the guys who can actively do it. :)
+
+Yes, please send me some names, emails, and whatever you may
+find necessary to do it.
+
+> I owe a new package of dillo to the familiar
+> distribution to the iPAQ... we are still in 0.6.2 there... :(
+
+Mmmm, I hope they can get 0.6.4 soon...
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]*BSD and dillo's configure
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-30 14:17
+
+Hi BSDers!
+
+Within my email collection :), I have several references to
+problems with *BSD, in what regards to jpeg-library-detection and
+pthreads.
+
+Dillo 0.6.4 has a new check for jpeg library that seems to be
+working (at least here and in some other machines where the
+problem was present before). Those of you that had problems with
+it, please test and report how it goes.
+
+The pthreads library problem is more complex. As I wrote
+before:
+
+> AFAIU detecting and configuring is automake&autoconf work (they
+> generate configure). So, I'd suggest to get a few pthreaded SW
+> packages, that use autoconf stuff, and see how do they solve
+> the problem in *BSD.
+
+I don't know if the latest version solves it...
+BTW: it would be very good to test with FreeBSD-4.5! too.
+
+
+Sometime ago Sammy sent me a big patch (60Kb aprox) that solved
+the pthread library detection. I'm reluctant to include such a
+big patch, specially knowing that 'configure' already takes 120Kb
+
+Maybe there's a smaller solution that can do it. As a custom
+test in configure.in for instance (just an idea).
+
+I was also reported that:
+
+> [...]
+> FreeBSD 4.4 with GTK+ 1.2.10, XFree86 4.0.3, libpng 1.2.0, and libjpeg-6b.
+> I am using dillo 0.6.2.
+>
+> A successful compile was achieved with the following parameters:
+> LDFLAGS="-L/usr/local/lib" LIBS="-pthread -ljpeg -lpng" \
+> GTK_CONFIG="/usr/X11R6/bin/gtk12-config" ./configure --with-libjpeglib
+
+so maybe:
+
+LIBS="-pthread" ./configure
+
+can be a good workaround for the interim. Please test it.
+
+
+OK, those of you interested in solving this, may contact:
+
+Sammy, nstalkie at tvd dot be
+Richard, rcagny in mtice . fr
+Bjoern, foxbow on web dot de
+Brian, brian at budbud . dhs dot org
+
+and please feel free to use the list to sort it up, keeping the
+*BSD subject, that is.
+
+
+Note1: Bjoern told me he was going to work on a solution, so he
+may have something.
+Note2: Brian may not have enough time. :(
+
+
+Let it flow!
+
+Jorge.- 
+
+
+
+[Dillo-dev]Re: 0.6.4 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-30 14:17
+
+Hi there,
+
+Sourceforge didn't update the download page, so I redirected
+our download links (from dillo's home page) to the place it can
+be found (at SF).
+
+Agh, I really feel like moving...
+
+
+Sorry for the inconvenience
+Jorge.- 
+
+
+
+[Dillo-dev]dillo-0.6.4 ????
+
+From: <belaruse@we...> - 2002-01-30 14:10
+
+Hi,
+
+where can I find dillo-0.6.4 ? 
+http://download.so....net/dillo/ contains only dillo-0.6.3 !
+
+ri 
+
+
+
+[Dillo-dev]0.6.4 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-30 11:41
+
+Hi folks!
+
+As you may have noticed, dillo-0.6.4 has been released a few
+hours ago. For those of you that haven't tried it yet, it brings
+some new features and bugfixes. As always, my advice is:
+
+Go get it!
+
+& Enjoy
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo plans for 2002
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-01-29 23:24
+
+All,
+
+Thanks Jorge for the informative information on priorities for Dillo in
+2002. I've enjoyed the time I've spent hacking around back in the I/O
+engine. After my first abortive attempt at SSL ran into trouble with
+proxies, I settled back to try it again, this time with tunnelling.
+
+The resultant patch is at
+http://members.bellatlantic.net/~mze2mqqv/dillo-ssl-cookies.2002-01-27.diff
+. I'm posting it to the list, but
+
+!!!THIS IS NOT A PATCH FOR THE FAINT OF HEART!!!
+
+I ended up reorganizing 90% of the I/O engine code, the wisdom of which,
+in retrospect, I'm unsure. For those who want to try it out, download
+the CVS dillo and download the patch into dillo's root directory. Then:
+
+$ cd ~/Projects/dillo # or wherever
+$ curl http://members.bellatlantic.net/~mze2mqqv/dillo-ssl-cookies.2002-01-27.diff
+$ patch -p1 -i ./dillo-ssl-cookies.2002-01-27.diff
+$ automake -a
+$ autoconf
+$ ./configure --enable-ssl
+$ make
+$ ./src/dillo https://www.so....net/
+
+(I love that test case because sourceforge does a redirect at its root.)
+
+I've tested the patch for wwwoffle as a proxy. I'll be putting it
+through a stress test and memory leak tests this weekend. I appreciate
+any bug reports or comments; even if this patch never sees the light of
+day, it was challenging and rewarding to code. Documentation can be
+found in 'dillo/doc/GByteArray-IO.txt'.
+
+It also got me to thinking about your "simple plugins", Jorge, although
+I don't have much history. I'll hit the mailing list archives and web
+site later to get some. By the time I was down with this patch, I was
+establishing "chain-stacks" for all operations. Expressing 'a_Http_ccc'
+as 'Http' for example, the stacks went something like this:
+
+Http: Cache<->Http<->IO<->DNS
+Http (proxy): Cache<->Http<->Proxy<->DNS
+Https: Cache<->Http<->Https<->BIO<->DNS
+Https (proxy): Cache<->Http<->Https<->Tunnel<->BIO<->DNS
+About: Cache<->About
+File: Cache<->File<->IO
+
+While I hardcoded the chains in an array in 'a_Url_get_ccc_chain', it
+certainly seems possible that given a scheme (e.g. 'ftp') a chain could
+be loaded from a symbol ('a_Dillo_Plugin_Chain'?) in an appropriate plugin 
+(e.g. 'ftp.so') and executed. What I'm not clear on is how much additional 
+access to the core dillo symbol table might be required. Are there security 
+concerns? And so on... I'll read the mailing list archives before I bore 
+you with questions.
+
+Regards,
+-jonathan springer 
+
+
+
+Re: [Dillo-dev]Dillo plans for 2002
+
+From: Eduardo Marcel <macan@co...> - 2002-01-29 16:59
+
+I am still here!!! :)
+
+I had a very late 2001 and am still having a
+very turbulent early 2002 in Real Life(tm)... ranging
+from getting through the bureaucracy of getting a
+bank to finance an appartment to me, through moving
+to the new appartment and more recently having a close
+relative with a delicate health problem.
+
+I am still on forced "vacations" from almost all
+my Free Software activities, but I can still help on the
+move to cipsga, even if only to put you in touch
+with the guys who can actively do it. :)
+
+I owe a new package of dillo to the familiar=20
+distribution to the iPAQ... we are still in 0.6.2 there... :(
+
+Regards,
+
+Eduardo
+
+
+
+On Tue, 29 Jan 2002 12:14:09 -0300 (CLST)
+Jorge Arellano Cid <jcid@em...> wrote:
+
+>=20
+> Hi there!
+>=20
+>=20
+> I've been longing to write this email almost from the first
+> week of this year, but I didn't know where (or how) to start, and
+> sort a huge myriad of unrelated things.
+>=20
+> This year began with a hectic pace for dillo. Although the
+> mailing list has show moderate traffic, my INBOX holds more than
+> a hundred emails, and there're a lot of topics pending.
+>=20
+> The only way to cope with all of them, would be to multiplex
+> myself (or clonning ;), but as I'm not able (nor willing) to do
+> either, I'll use the well known "priority list" method to try to
+> start moving it. Please note that this method has its flaws: as
+> not being able to handle every task, the scheduling problems that
+> arise when new, very important, topics spring-in and "non
+> maskarable interrupts", to name a few.
+>=20
+> The good new is that I've munched the 100+ emails into a 30
+> points list, and I'll try to start unrolling it. I say try,
+> because is not easy to handle an issue to another person when
+> he/she is not convinced of doing it. OTOH, it also happens that
+> after a lot of discussion, that person convinces me his way!
+>=20
+> NOTE: some emails will be terribly procrastinated, and some
+> others will remain unanswered. This is not the way I like it, but
+> I _can't_ answer all of them. This warning should be at the web
+> site, but that task has a lower priority than this mail... :(
+> You have been warned.
+>=20
+> NOTE2: well thought, and informed emails (or posts), are easier
+> to answer (and strongly encouraged), because I don't have to dig
+> for information the poster could have got alone.
+> Let me advice not to post your first thought on any matter, but
+> to inform yourself, consider alternatives, give it a second
+> analysis, and post back your well reasoned/backed ideas.
+>=20
+> NOTE3: There's plenty of information at the web site, and those
+> asking for things already answered there (or in the docs), will
+> not be answered.
+>=20
+>=20
+> ****************
+>=20
+>=20
+> Let's start with these:
+>=20
+> * 0.6.4 release
+> * Move from SourceForge
+> * Simple plugins
+> * cookies
+> * SSL
+> * external viewers/programs/handlers
+>=20
+>=20
+> * 0.6.4 release ****
+>=20
+> Almost ready! It'll be mainly a bugfix release (segfaults on
+> imagemaps) with some nice additions (aligning, remembering of
+> page-scrolling-position, ...).
+>=20
+> Most probably Jan 30.
+>=20
+>=20
+> * Move from SourceForge ****
+>=20
+> This had a long thread, and when it was about to be done,
+> Eduardo M. Ma=E7an, vanished !? I made repeated attempts to reach
+> him (yes, with intervals), but got no answer.
+>=20
+> Does anyone here know how to get in touch with him?
+> Eduardo: Cad=E9 voc=EA?
+>=20
+>=20
+> * Simple plugins ****
+>=20
+> Some time ago (long), Eric and I were working steadily on this.
+> Simple plugins could be a _very_ powerful tool for dillo,
+> provided careful design and a considerable amount of work is put
+> on it.
+>=20
+> In brief, "simple plugins" operate very much like a CGI, but
+> without a web server, and they also provide a tiny API that
+> broadens a bit their scope. They're _NOT_ like Netscape plugins.
+>=20
+> The point is they could handle bookmarks, preferences, FTP,
+> downloads and extensibility in a customizable way.
+>=20
+> If it's so great why aren't you working on it?
+> Believe me, if I had a twin brother, he'd be working on it!
+>=20
+> In practise, a lot of expertise and knowledge is required to
+> contribute here. Mainly: CGI/fastCGI, HTML, protocol design,
+> interprocess comunnication, deep CCC knowledge, and general dillo
+> UI knowledge.
+>=20
+> Suitable volunteers would be a bless.
+>=20
+> The second problem is that if I start working on this, all of
+> my other duties get stalled... I plan to move some high priority
+> tasks first, and when they're going to restart the plugins.
+>=20
+> NOTE: human "context switches" take lots of time.
+>=20
+>=20
+>=20
+> * Cookies ****
+>=20
+> J=F6rgen has just sent me the patch that solves almost every
+> known problem for reviewing. Don't expect it on 0.6.4.
+>=20
+> Cookies is a very sensible topic in what regards to security,
+> and privacy. So, appart form the quality/completeness/ review, it
+> _must_ be tested against "cookie abuse".
+>=20
+> Those of you using it, please test it thoroughly (a few google
+> searches will bring enough material to get you started.), and
+> report back your results.
+>=20
+>=20
+> * SSL ****
+>=20
+> This will be focused most probably after cookies.
+>=20
+> As some perspicacious developers had noted, there were several
+> tasks aiming to prepare dillo for SSL (mainly on HTML and URL
+> parsing).
+>=20
+> It becomes evident that when dillo is SSL enabled, people will
+> start to do some "sensible" work with it, and reliability starts
+> to play a primary role.
+>=20
+> Currently, it's very easy to hack-in some SSL support, but when
+> you start using it, you don't want a long and important "session"
+> to suddenly end in a segfault, or submitting wrong values.
+>=20
+> Be careful.
+>=20
+> Also bear in mind that the first SSL-enabled dillo will set a
+> major milestone, and will generate a lot of feedback. Let's take
+> our time and do it right!
+>=20
+>=20
+> * external viewers/programs/handlers ****
+>=20
+> I have at least three implementation ideas (with code) for such
+> ad-hoc functionality waiting for a review.
+>=20
+> Please also note that the "official" idea is to handle all this
+> stuff with "simple-plugins", but considering that SPI has become
+> a sort of highly-desirable-vaporware :), it may not be a bad idea
+> to choose one of these for the interim.
+>=20
+>=20
+>=20
+> ****************
+>=20
+>=20
+> It's been more than two excellent years with full dedication
+> to dillo, and God knows I'd love to keep leading and working it
+> to new heights. The only problem is that I'm running out of money
+> (as all the development had been at my expense), so now there's a
+> dire need for rising funds for dillo project.
+>=20
+> It'd be great to have a way of keeping the main developers
+> working together, and boost this once-tiny-project to a new
+> organization basis that leverages its development.
+>=20
+> There're lots of plans, ideas, and a clean code base to work
+> with.
+>=20
+> I'd love to see benefactor enterprises (or governments) that
+> aware of all the beneffits they can get from dillo as a working
+> tool (fast, reliable, secure), commit themselves to sponsor us
+> with any amount the desire. After all, we don't need lots of
+> money to keep it going, but full time dedication from the core
+> developers is a must.
+>=20
+> Those of you with any information that can help make this
+> happen, please don't hesitate to contact me. If we succeed,
+> there'll be a great dillo for all of us to enjoy!
+>=20
+>=20
+>=20
+> Sincerely
+> Jorge.-
+>=20
+>=20
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>=20
+
+
+--=20
+"If you have an apple and I have an apple and we exchange apples then y=
+ou=20
+and I will still each have one apple. But if you have an idea and I ha=
+ve=20
+an idea and we exchange these ideas, then each of us will have two ideas=
+."
+George Bernard Sh=
+aw=20 
+
+
+
+[Dillo-dev]Dillo plans for 2002
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-29 15:17
+
+Hi there!
+
+
+I've been longing to write this email almost from the first
+week of this year, but I didn't know where (or how) to start, and
+sort a huge myriad of unrelated things.
+
+This year began with a hectic pace for dillo. Although the
+mailing list has show moderate traffic, my INBOX holds more than
+a hundred emails, and there're a lot of topics pending.
+
+The only way to cope with all of them, would be to multiplex
+myself (or clonning ;), but as I'm not able (nor willing) to do
+either, I'll use the well known "priority list" method to try to
+start moving it. Please note that this method has its flaws: as
+not being able to handle every task, the scheduling problems that
+arise when new, very important, topics spring-in and "non
+maskarable interrupts", to name a few.
+
+The good new is that I've munched the 100+ emails into a 30
+points list, and I'll try to start unrolling it. I say try,
+because is not easy to handle an issue to another person when
+he/she is not convinced of doing it. OTOH, it also happens that
+after a lot of discussion, that person convinces me his way!
+
+NOTE: some emails will be terribly procrastinated, and some
+others will remain unanswered. This is not the way I like it, but
+I _can't_ answer all of them. This warning should be at the web
+site, but that task has a lower priority than this mail... :(
+You have been warned.
+
+NOTE2: well thought, and informed emails (or posts), are easier
+to answer (and strongly encouraged), because I don't have to dig
+for information the poster could have got alone.
+Let me advice not to post your first thought on any matter, but
+to inform yourself, consider alternatives, give it a second
+analysis, and post back your well reasoned/backed ideas.
+
+NOTE3: There's plenty of information at the web site, and those
+asking for things already answered there (or in the docs), will
+not be answered.
+
+
+****************
+
+
+Let's start with these:
+
+* 0.6.4 release
+* Move from SourceForge
+* Simple plugins
+* cookies
+* SSL
+* external viewers/programs/handlers
+
+
+* 0.6.4 release ****
+
+Almost ready! It'll be mainly a bugfix release (segfaults on
+imagemaps) with some nice additions (aligning, remembering of
+page-scrolling-position, ...).
+
+Most probably Jan 30.
+
+
+* Move from SourceForge ****
+
+This had a long thread, and when it was about to be done,
+Eduardo M. Ma=E7an, vanished !? I made repeated attempts to reach
+him (yes, with intervals), but got no answer.
+
+Does anyone here know how to get in touch with him?
+Eduardo: Cad=E9 voc=EA?
+
+
+* Simple plugins ****
+
+Some time ago (long), Eric and I were working steadily on this.
+Simple plugins could be a _very_ powerful tool for dillo,
+provided careful design and a considerable amount of work is put
+on it.
+
+In brief, "simple plugins" operate very much like a CGI, but
+without a web server, and they also provide a tiny API that
+broadens a bit their scope. They're _NOT_ like Netscape plugins.
+
+The point is they could handle bookmarks, preferences, FTP,
+downloads and extensibility in a customizable way.
+
+If it's so great why aren't you working on it?
+Believe me, if I had a twin brother, he'd be working on it!
+
+In practise, a lot of expertise and knowledge is required to
+contribute here. Mainly: CGI/fastCGI, HTML, protocol design,
+interprocess comunnication, deep CCC knowledge, and general dillo
+UI knowledge.
+
+Suitable volunteers would be a bless.
+
+The second problem is that if I start working on this, all of
+my other duties get stalled... I plan to move some high priority
+tasks first, and when they're going to restart the plugins.
+
+NOTE: human "context switches" take lots of time.
+
+
+
+* Cookies ****
+
+J=F6rgen has just sent me the patch that solves almost every
+known problem for reviewing. Don't expect it on 0.6.4.
+
+Cookies is a very sensible topic in what regards to security,
+and privacy. So, appart form the quality/completeness/ review, it
+_must_ be tested against "cookie abuse".
+
+Those of you using it, please test it thoroughly (a few google
+searches will bring enough material to get you started.), and
+report back your results.
+
+
+* SSL ****
+
+This will be focused most probably after cookies.
+
+As some perspicacious developers had noted, there were several
+tasks aiming to prepare dillo for SSL (mainly on HTML and URL
+parsing).
+
+It becomes evident that when dillo is SSL enabled, people will
+start to do some "sensible" work with it, and reliability starts
+to play a primary role.
+
+Currently, it's very easy to hack-in some SSL support, but when
+you start using it, you don't want a long and important "session"
+to suddenly end in a segfault, or submitting wrong values.
+
+Be careful.
+
+Also bear in mind that the first SSL-enabled dillo will set a
+major milestone, and will generate a lot of feedback. Let's take
+our time and do it right!
+
+
+* external viewers/programs/handlers ****
+
+I have at least three implementation ideas (with code) for such
+ad-hoc functionality waiting for a review.
+
+Please also note that the "official" idea is to handle all this
+stuff with "simple-plugins", but considering that SPI has become
+a sort of highly-desirable-vaporware :), it may not be a bad idea
+to choose one of these for the interim.
+
+
+
+****************
+
+
+It's been more than two excellent years with full dedication
+to dillo, and God knows I'd love to keep leading and working it
+to new heights. The only problem is that I'm running out of money
+(as all the development had been at my expense), so now there's a
+dire need for rising funds for dillo project.
+
+It'd be great to have a way of keeping the main developers
+working together, and boost this once-tiny-project to a new
+organization basis that leverages its development.
+
+There're lots of plans, ideas, and a clean code base to work
+with.
+
+I'd love to see benefactor enterprises (or governments) that
+aware of all the beneffits they can get from dillo as a working
+tool (fast, reliable, secure), commit themselves to sponsor us
+with any amount the desire. After all, we don't need lots of
+money to keep it going, but full time dedication from the core
+developers is a must.
+
+Those of you with any information that can help make this
+happen, please don't hesitate to contact me. If we succeed,
+there'll be a great dillo for all of us to enjoy!
+
+
+
+Sincerely
+Jorge.- 
+
+
+
+Re: [Dillo-dev]table-rendering?
+
+From: Eric GAUDET <egaudet@in...> - 2002-01-28 19:32
+
+On 28-Jan-2002 Sebastian Geerken wrote:
+> Well, there are some problems, and tables will undergo major changes
+> in the future.
+> 
+> Sebastian
+> 
+
+Hi Sebastian,
+I've been trying to make the page selection for copy and paste, but I
+encountered some problems due to the fact that there is several 'words' arrays:
+one for each DW (table cells).
+Do you plan to implement some sort of DOM methods on top of the DWs, so one
+can 'walk' the page structure?
+What's your recommendation for that in the current implementation?
+
+Best,
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 28-Jan-2002 Time: 11:27:19
+"Le premier qui me reveille pendant
+que je travaille, ca va mal aller !!!"
+---------------------------------- 
+
+
+
+[Dillo-dev]Dillo and GTK+ 2.0pre
+
+From: Michael Krueger <lcarsvision@we...> - 2002-01-28 18:59
+
+Hi,
+
+I compiled GTK+ 2.0pre (aka 1.3.11) with both the linux-fb and directfb port. 
+My goal is to write a small Linux/GNU distribution which fits on two floppies 
+and includes GUI applications. But compiling Dillo v0.6.3 (which would be the 
+included browser) seems to be not possible, even after handcoding fixes in 
+configure for pkg-config and the source. src/IO is compiled without any 
+problems, but the dw* framework files make gcc-2.95 stop. There are many 
+irrelationships with GtkArg{GetFunc,SetFunc} ("function not found") and klass 
+("structure: no member 'klass'"). I don't know how to fix these problems, the 
+GTK+ migration manual does not offer useful information.
+Has somebody ported Dillo to GTK+ 2.0pre? Or has somebody ideas to fix those 
+problems?
+
+Best regards,
+Michael Krueger
+lcarsvision@we... 
+
+
+
+Re: [Dillo-dev]CSS support under development ?
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-01-28 16:31
+
+Hi,
+
+On Thu, Jan 24, 2002 at 07:58:09AM +0200, Teemu Voipio wrote:
+> 
+> I think that having at least some basic CSS support
+> 
+> font-size, text-aling, color,
+> background-color, background (?)
+> margins, paddings, borders,
+> to begin with (and implement more when these work)
+> 
+> would really be nice improvement to this great browser and wouldn't
+> necessarily need to compromise any of it's speed as most of the code
+> needed to actually "draw" these things are actually simple or implemented
+> for HTML anyway.
+
+I have been working on a design for CSS support the last time, I'll
+soon write it down and send it to the list (there are still some
+things I want to clear first). There are different aspects, which are,
+independent of each other, quite complex:
+
+- CSS parsing and evaluating itself,
+- interaction with the HTML parser,
+- mapping on the actual rendering, and
+- the actual rendering.
+
+About the last two points: There is already a structure, DwStyle,
+handling some CSS attributes (e.g. the ones you mentioned), but some
+attributes affect the DwWidget structure itself (see doc/Dw*.txt in
+the tarball). Whether they are supported or not (the latter is likely
+in the first release-ready implementation) should be hidden, so that
+it can be added in the future (even perhaps(!) up to XML/CSS
+rendering).
+
+If you look at the code, the actual rendering is already more and more
+improved to handle things like CSS boxes, alignments etc.
+
+> And do it right from the beginning (ie. cascade them as supposed so we
+> don't end up with something like Netscape 4).
+> 
+> If nobody is doing this I can start developing the CSS parsing and
+> cascading and when I get the properties listed above (or something)
+> working reliably, start implementing them into the renderer.
+
+There will be several tasks, on which different people may work on.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Forms & enter
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-01-28 16:11
+
+On Sat, Jan 19, 2002 at 06:48:29AM -0500, Jonathan P Springer wrote:
+> [...]
+> Just as an aside, the tab behavior seems to be based on the order the elements
+> were encountered in the html, not the order in which they occur 
+> top-bottom,left-right on the screen. This comes into play when two separate
+> forms are rendered side-to-side by the table logic. For example, at the
+> Sourceforge login, I need to tab twice to get from username to password because
+> there's an independant dropdown list in the bar to their right.
+
+This behaviour is (currently) given by Gtk+, which determines the tab
+order (which is the order in which widgets were added to a parent
+widget). AFAIK, Gtk+ 2.0 provides better ways to customise this.
+
+> I know table processing is still in its infancy, but it's a behavior to keep
+> in mind.
+
+This is actually not a table problem. :-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]table-rendering?
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-01-28 15:35
+
+Hi,
+
+On Mon, Jan 28, 2002 at 03:48:28PM +0900, TANAKA Keishiro wrote:
+> >There seems to be some problems with the table rendering.
+> >For example on http://www.linuxdevices.com,in the right column the text is moved gradually farther to the right.
+> 
+> I think at first you need to check syntax of the pages and whether it
+> uses unsupported functionality by dillo.
+> You know, there are many invalid pages on the Net.
+
+Yes, http://validator.w3.org shows some errors (also on tables), but
+the main problem seems to be lists. You can show them in a more
+debuggable way by replacing "#if 0 " in Html_add_indented_widget into
+"#if 1". I haven't yet examined if this is the fault of dillo, or of
+the page.
+
+> And from my
+> experience, dillo table renderer has little problem basically. 
+> If you find the pages are correct then report the problem.
+
+Well, there are some problems, and tables will undergo major changes
+in the future.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]table-rendering?
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-01-28 06:48
+
+Hi.
+
+>There seems to be some problems with the table rendering.
+>For example on http://www.linuxdevices.com,in the right column the text is moved gradually farther to the right.
+
+I think at first you need to check syntax of the pages and whether it
+uses unsupported functionality by dillo.
+You know, there are many invalid pages on the Net. And from my
+experience, dillo table renderer has little problem basically. 
+If you find the pages are correct then report the problem.
+
+Best Regards. 
+
+
+
+[Dillo-dev]CSS support under development ?
+
+From: Teemu Voipio <mystran@wa...> - 2002-01-24 05:59
+
+I think that having at least some basic CSS support
+
+font-size, text-aling, color,
+background-color, background (?)
+margins, paddings, borders,
+to begin with (and implement more when these work)
+
+would really be nice improvement to this great browser and wouldn't
+necessarily need to compromise any of it's speed as most of the code
+needed to actually "draw" these things are actually simple or implemented
+for HTML anyway.
+
+And do it right from the beginning (ie. cascade them as supposed so we
+don't end up with something like Netscape 4).
+
+If nobody is doing this I can start developing the CSS parsing and
+cascading and when I get the properties listed above (or something)
+working reliably, start implementing them into the renderer.
+
+Any interest ?
+
+
+- Teemu Voipio <tvoipio@cc.hut.fi>
+-----------------------------------------------------------------
+Mystran == my very own nick @ IRC == god's gift to net
+does not ==
+use that ==
+MS software software and has == a verb
+at home has to only Linux == Linux from Scratch
+since he be free at home == wasteland.pp.htv.fi
+believes for all therefore. (is encrypted)
+-----------------------------------------##---------------------- 
+
+
+
+[Dillo-dev]Dillo 0.6.3 + bunch of patches ?
+
+From: Teemu Voipio <mystran@wa...> - 2002-01-24 01:32
+
+This browser is great but latest release 0.6.3 (?) is very old.
+
+There are patches available to do this and that (including cookies etc.).
+Not all of these patches apply to the 0.6.3.
+
+Is anybody in the business of trying to bring together any new releases
+that include (some of the most stable and urgent of) those patches with
+it already applied. That would make it a lot easier for people interested
+to try the browser or even to join the development...
+
+PS. please cc replies to me..
+
+- Teemu Voipio <tvoipio@cc.hut.fi>
+-----------------------------------------------------------------
+Mystran == my very own nick @ IRC == god's gift to net
+does not ==
+use that ==
+MS software software and has == a verb
+at home has to only Linux == Linux from Scratch
+since he be free at home == wasteland.pp.htv.fi
+believes for all therefore. (is encrypted)
+-----------------------------------------##---------------------- 
+
+
+
+Re: [Dillo-dev][Patch] Multiple no_proxy domains
+
+From: Nikita Borodikhin <eliterr@tk...> - 2002-01-23 11:33
+
+Hello, Jorge !
+
+On Sun, 20 Jan 2002 17:25:00 -0300 (CLST)
+Jorge Arellano Cid <jcid@em...> wrote:
+
+> I gave it a full review, and commited a new patch to the CVS.
+> Please check it out and test it through beacause I haven't a
+> proxy at hand to do so :(.
+> 
+> The main reasons for the new approach were:
+> 
+> - use the opportunity to clean up the proxy code.
+> - the patch implementation wasn't optimized for speed.
+
+OK, your version of patch is more beautiful :)
+I tested it and found that it works. Thanks.
+
+Nikita V. Borodikhin 
+
+
+
+Re: [Dillo-dev]dillo segfault
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-22 00:51
+
+On Mon, 21 Jan 2002, Eric GAUDET wrote:
+
+> Hi,
+
+Hi Eric!
+
+> I ran into a slight segfault in dillo: go to http://volnorm.so....net.
+> The problem is that an invalid color is used as table background:
+> <table bgcolor="{PAGE_BACkGROUND}" ...
+> and dillo seems to have a bug in a_Color_parse.
+> Anyway, just replace:
+>
+> color.c:248
+> - while (low <= high) {
+> with
+> + while (low < high) {
+
+Actually, that breaks the binary search :(, the fix is:
+
+colorsc:247
+- high = NCOLORS;
++ high = NCOLORS - 1;
+
+Already commited to CVS!
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]dillo segfault
+
+From: Eric GAUDET <egaudet@in...> - 2002-01-21 22:58
+
+Hi,
+I ran into a slight segfault in dillo: go to http://volnorm.so....net.
+The problem is that an invalid color is used as table background:
+<table bgcolor="{PAGE_BACkGROUND}" ...
+and dillo seems to have a bug in a_Color_parse.
+Anyway, just replace:
+
+color.c:248
+- while (low <= high) {
+with
++ while (low < high) {
+
+Best,
+----------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 21-Jan-2002 Time: 14:53:38
+"Le premier qui me reveille pendant
+que je travaille, ca va mal aller !!!"
+---------------------------------- 
+
+
+
+Re: [Dillo-dev]Bus error on Darwin 5.2 (MacOS X)
+
+From: Imran Hasnain <iah21@he...> - 2002-01-21 21:41
+
+It works like a dream :-) thanks very much, Dillo is amazing! I am using
+Darwin 5.2 (MacOS 10.1.2) with XFree 4.1 and XDarwin 1.0.6.1
+
+Imran
+
+
+On 21/1/02 7:39 pm, "Jorge Arellano Cid" <jcid@em...> wrote:
+
+>=20
+> Imran,
+>=20
+>> Firstly well done to you all for producing an excellent browser.
+>=20
+> Thanks!
+>=20
+>> One problem
+>> - in 0.6.2 and 0.6.3 on Darwin 5.2 Dillo exits with a bus error whenever=
+a
+>> link is clicked on - it worked fine in 0.6.1. URLs typed in are fine - a=
+s
+>> are Favourites. On mouseover dillo displays a strange number at the bott=
+om
+>> of the window after the URL - such as
+>> 'http://dillo.so....net/?36848,-1073746304' I don=B9t know if this h=
+as
+>> anything to do with the problem or even if it was there before.
+>>=20
+>> Hope you can help,
+>=20
+> Well, there was a bug with 0.6.3 and image maps (the funny
+> numbers after the '?' character). This has been fixed in the CVS
+> version. Please get it and tell us back how it works.
+>=20
+>=20
+> Cheers
+> Jorge.-
+>=20
+> PS: Are you using Darwin or GNU/Darwin?
+>=20
+>=20
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>=20 
+
+
+
+Re: [Dillo-dev]Bus error on Darwin 5.2 (MacOS X)
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-21 19:42
+
+Imran,
+
+> Firstly well done to you all for producing an excellent browser.
+
+Thanks!
+
+> One problem
+> - in 0.6.2 and 0.6.3 on Darwin 5.2 Dillo exits with a bus error whenever =
+a
+> link is clicked on - it worked fine in 0.6.1. URLs typed in are fine - as
+> are Favourites. On mouseover dillo displays a strange number at the botto=
+m
+> of the window after the URL - such as
+> 'http://dillo.so....net/?36848,-1073746304' I don=B9t know if this =
+has
+> anything to do with the problem or even if it was there before.
+>
+> Hope you can help,
+
+Well, there was a bug with 0.6.3 and image maps (the funny
+numbers after the '?' character). This has been fixed in the CVS
+version. Please get it and tell us back how it works.
+
+
+Cheers
+Jorge.-
+
+PS: Are you using Darwin or GNU/Darwin? 
+
+
+
+[Dillo-dev]Bus error on Darwin 5.2 (MacOS X)
+
+From: Imran Hasnain <iah21@he...> - 2002-01-21 15:50
+
+Firstly well done to you all for producing an excellent browser. One proble=
+m
+- in 0.6.2 and 0.6.3 on Darwin 5.2 Dillo exits with a bus error whenever a
+link is clicked on - it worked fine in 0.6.1. URLs typed in are fine - as
+are Favourites. On mouseover dillo displays a strange number at the bottom
+of the window after the URL - such as
+'http://dillo.so....net/?36848,-1073746304' I don=B9t know if this has
+anything to do with the problem or even if it was there before.
+
+Hope you can help,
+
+Imran 
+
+
+
+Re: [Dillo-dev][Patch] Multiple no_proxy domains
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-20 20:26
+
+Nikita,
+
+> Hello all !
+
+Hi!
+
+> There is a small patch that makes it possible to specify not only one site
+> to use no proxy but several domains. I think it will be useful.
+
+I gave it a full review, and commited a new patch to the CVS.
+Please check it out and test it through beacause I haven't a
+proxy at hand to do so :(.
+
+The main reasons for the new approach were:
+
+- use the opportunity to clean up the proxy code.
+- the patch implementation wasn't optimized for speed.
+
+Thanks in advance
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Segfault on image maps (BUG 277)
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-20 00:14
+
+Johannes,
+
+> Hi,
+
+Hi!
+
+> current dillo seems to have a problem with image maps (see BUG 277).
+> I think the problem is that within a_Url_set_ismap_coords() in url.c
+> it is assumed that u->path points to a position within u->buffer.
+> But then a_Url_set_ismap_coords() makes u->path point to a position
+> within u->url_string->str. So at the next call to
+> a_Url_set_ismap_coords() things go wrong.
+
+Yes, that was a bug that originated in the old http query
+construction code.
+
+> The attached check seems to solve the problem for me.
+
+I gave it a somewhat deep revision, and the problem ended being
+another (hinted above). There's a new patch at the CVS, just give
+it a try!
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Segfault on image maps (BUG 277)
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2002-01-19 11:59
+
+Hi, 
+
+current dillo seems to have a problem with image maps (see BUG 277).
+I think the problem is that within a_Url_set_ismap_coords() in url.c
+it is assumed that u->path points to a position within u->buffer.
+But then a_Url_set_ismap_coords() makes u->path point to a position
+within u->url_string->str. So at the next call to
+a_Url_set_ismap_coords() things go wrong.
+The attached check seems to solve the problem for me.
+
+Regards,
+Johannes Hofmann
+
+
+
+--- url.c.orig Sat Jan 19 11:53:08 2002
++++ url.c Sat Jan 19 12:57:35 2002
+@@ -466,7 +466,9 @@
+if (u->url_string) {
+g_string_truncate(u->url_string, u->ismap_url_len);
+g_string_append(u->url_string, coord_str);
+- u->path = u->url_string->str + (u->path - u->buffer);
++ if ((u->path >= u->buffer) && (u->path < u->buffer +
+strlen(u->buffer))) 
+{
++ u->path = u->url_string->str + (u->path - u->buffer);
++ }
+}
+} 
+
+
+
+Re: [Dillo-dev]Forms & enter
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-01-19 11:48
+
+On Fri, Jan 18, 2002 at 07:42:08PM -0600, Lars Clausen wrote:
+> On Fri, 18 Jan 2002, Jorge Arellano Cid wrote:
+> 
+> > 
+> > Lars,
+> > 
+...
+>
+> Most interfaces I've seen allow TAB to go to the next field, as does Dillo
+> currently. Thus I don't see why Enter should be used for that. In
+> addition, it is common in both other browsers and in all kinds of dialogs
+> to have Enter submit everything.
+
+Just as an aside, the tab behavior seems to be based on the order the elements
+were encountered in the html, not the order in which they occur 
+top-bottom,left-right on the screen. This comes into play when two separate
+forms are rendered side-to-side by the table logic. For example, at the
+Sourceforge login, I need to tab twice to get from username to password because
+there's an independant dropdown list in the bar to their right.
+
+I know table processing is still in its infancy, but it's a behavior to keep
+in mind.
+
+> -Lars
+> 
+
+Ciao,
+-jonathan 
+
+
+
+Re: [Dillo-dev]Forms & enter
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-19 01:42
+
+On Fri, 18 Jan 2002, Jorge Arellano Cid wrote:
+
+>=20
+> Lars,
+>=20
+>> I've been wondering about the design decision to make forms only submit
+>> on Enter when there is no Submit button. It is obviously not becuase it
+>> would be hard to code (just pick the first submit button). The specs
+>> don't (AFAICS) say anything for or against it. It's certainly very
+>> practical to have Enter submit input text. Why has it been explicitly
+>> coded so that it only happens if there is no Submit button?
+>=20
+> The point is that when facing multiple input fields, the form
+> may be submitted incomplete as a result of pressing enter after
+> filling one text entry (almost a reflex-act these days).
+
+Most interfaces I've seen allow TAB to go to the next field, as does Dillo
+currently. Thus I don't see why Enter should be used for that. In
+addition, it is common in both other browsers and in all kinds of dialogs
+to have Enter submit everything.
+
+Also, most places send you back to the input if there's something missing.
+
+> There's also another reason: as javascript is not supported,
+> and as it's often used to verify form submitions, it becomes very
+> important not to try to send an incomplete form.
+
+Well, if javascript is not supported, then it's not supported. I have yet
+to meet a place where I could submit but javascript was the only check on
+the validity of the data.
+
+> Well, that's the idea behind it, but in practice, I must
+> recognize that after some tests, the current implentation is
+> certainly lacking, and that forms without submit, send whatever
+> they have (or not) at enter-press time. Certainly not the desired
+> effect...
+
+Indeed.
+
+> There's also the issue of input types that don't generate enter
+> presses (as selection boxes); when they lack a submit. Current
+> code doesn't submit anything, and as you noticed, the SPECS don't
+> throw any light on that.
+
+We could have them generate a submit when Enter is pressed while they're
+focused.=20
+
+> It'd be very handy to fix all these annoyances at once. I
+> think:
+>=20
+> When there's a submit:
+>=20
+> - Only submit on enter when there's a single enter-press
+> generating input ('text' and 'password').
+> Note: this can be further constrained to "one and only one
+> single enter-press input", but it may be overkill...
+
+That might be sensible. I dunno... quite a few forms make sense when
+half-filled and then Enter is a blessing (keeps you offa the mouse).
+
+> When there's no submit:
+>=20
+> - If there's more than one single enter-press input, render the
+> submit (added internally), and apply the above rules.
+
+This would be a really nice feature. It would get around those silly
+no-submit inputs.
+
+> If you're willing to implement this idea, please let me know.
+> If not, volunteers are welcome ;). Note that this is not complex
+> and very suitable for those of you that feel like helping.
+
+I might. Right now I'm looking at proper frames -- was thinking about
+using GtkFrame, but fitting that and DwWidget together isn't all that
+nice. Reverse DwGtkEmbed, anyone?
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]table-rendering?
+
+From: Hugo Hallqvist <hugha495@st...> - 2002-01-19 01:36
+
+There seems to be some problems with the table rendering.
+For example on http://www.linuxdevices.com,in the right column the text is moved gradually farther to the right.
+
+
+-- 
+//Hugo Hallqvist 
+
+
+
+Re: [Dillo-dev]Forms & enter
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-01-19 00:48
+
+Lars,
+
+> I've been wondering about the design decision to make forms only submit on
+> Enter when there is no Submit button. It is obviously not becuase it would
+> be hard to code (just pick the first submit button). The specs don't
+> (AFAICS) say anything for or against it. It's certainly very practical to
+> have Enter submit input text. Why has it been explicitly coded so that it
+> only happens if there is no Submit button?
+
+The point is that when facing multiple input fields, the form
+may be submitted incomplete as a result of pressing enter after
+filling one text entry (almost a reflex-act these days).
+
+There's also another reason: as javascript is not supported,
+and as it's often used to verify form submitions, it becomes very
+important not to try to send an incomplete form.
+
+Well, that's the idea behind it, but in practice, I must
+recognize that after some tests, the current implentation is
+certainly lacking, and that forms without submit, send whatever
+they have (or not) at enter-press time. Certainly not the desired
+effect...
+
+There's also the issue of input types that don't generate enter
+presses (as selection boxes); when they lack a submit. Current
+code doesn't submit anything, and as you noticed, the SPECS don't
+throw any light on that.
+
+It'd be very handy to fix all these annoyances at once. I
+think:
+
+When there's a submit:
+
+- Only submit on enter when there's a single enter-press
+generating input ('text' and 'password').
+Note: this can be further constrained to "one and only one
+single enter-press input", but it may be overkill...
+
+
+When there's no submit:
+
+- If there's more than one single enter-press input, render the
+submit (added internally), and apply the above rules.
+
+
+If you're willing to implement this idea, please let me know.
+If not, volunteers are welcome ;). Note that this is not complex
+and very suitable for those of you that feel like helping.
+
+
+Sincerely
+Jorge.- 
+
+
+
+[Dillo-dev][Patch] Multiple no_proxy domains
+
+From: Nikita Borodikhin <eliterr@tk...> - 2002-01-18 13:21
+
+Hello all !
+
+There is a small patch that makes it possible to specify not only one site
+to use no proxy but several domains. I think it will be useful.
+
+Nikita V. Borodikhin
+eliterr_at_tkk.ru
+
+
+
+diff -urN dillo.old/dillorc dillo/dillorc
+--- dillo.old/dillorc Thu Jan 17 18:58:47 2002
++++ dillo/dillorc Fri Jan 18 19:52:44 2002
+@@ -44,8 +44,8 @@
+# Set the proxy information for http
+#http_proxy=http://localhost:8080/
+
+-# Set the domain to access without proxy
+-#no_proxy = http://www.mynet.com/
++# Set the domains to access without proxy (',' or ';' separated)
++#no_proxy = ".mynet.com,.mynet2.com"
+
+
+#-------------------------------------------------------------------------
+diff -urN dillo.old/src/IO/http.c dillo/src/IO/http.c
+--- dillo.old/src/IO/http.c Thu Jan 17 18:58:43 2002
++++ dillo/src/IO/http.c Fri Jan 18 19:48:23 2002
+@@ -71,6 +71,41 @@
+static void Http_expect_answer(SocketData_t *S);
+
+
++/*
++ * Return flag whether suffix of url is in no_proxy list
++ * (comma or semicolon separated) or not
++ */
++int Http_search_no_proxy_siffix_in_url (char *url, char *no_proxy)
++{
++ int len;
++ int result = 0;
++ int no_proxy_len = strlen (no_proxy) + 1;
++ char *proxy_suffix = (char *) g_malloc (no_proxy_len);
++
++ while (*no_proxy != 0)
++ {
++ len = 0;
++ memset (proxy_suffix, '\0', no_proxy_len);
++ 
++ while ((no_proxy [len]) && (no_proxy [len] != ',')
++ && (no_proxy [len] != ';'))
++ len++;
++ 
++ if (len != 0)
++ {
++ strncpy (proxy_suffix, no_proxy, len);
++ result = (strstr (url, proxy_suffix) != 0);
++ }
++ 
++ if (result || !(no_proxy [len])) break;
++
++ no_proxy += len + 1;
++ };
++
++ g_free (proxy_suffix);
++
++ return result;
++}
+
+/*
+* Create and init a new SocketData_t struct, insert into ValidSocks,
+@@ -296,7 +331,8 @@
+S->web = ExtraData;
+
+/* Hacked-in support for proxies */
+- if (HTTP_Proxy && !(No_Proxy && strstr(URL_STR(Url), No_Proxy) != NULL)) {
++ if (HTTP_Proxy && !(No_Proxy &&
++ Http_search_no_proxy_siffix_in_url (URL_STR(Url), No_Proxy))) {
+strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname));
+S->port = URL_PORT(HTTP_Proxy);
+S->use_proxy = TRUE; 
+
+
+
+[Dillo-dev]Problems compiling current cvs?
+
+From: Hugo Hallqvist <hugha495@st...> - 2002-01-17 21:02
+
+Hi everyone,
+
+Is there anyone else having problems compiling the current cvs-version of dillo?
+
+I get the following errors:
+
+make[3]: Entering directory `/home/hugha495/cvs/dillo/src/IO'
+source='mime.c' object='mime.o' libtool=no \
+depfile='.deps/mime.Po' tmpdepfile='.deps/mime.TPo' \
+depmode=none /bin/sh ../../depcomp \
+gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -Wall -Waggregate-return -c `test -f mime.c || echo './'`mime.c
+../../depcomp: ../../depcomp: Filen eller katalogen finns inte
+
+Any thoughts?
+
+
+-- 
+//Hugo Hallqvist 
+
+
+
+Re: Re: [Dillo-dev]A suggestion for configuration
+
+From: Paul Chamberlain <tif@ti...> - 2002-01-17 20:56
+
+From: Russell Nelson <nelson@cr...>
+> Paul Chamberlain writes:
+> > Create an interface for local executables
+> > Secure this "local-CGI" to prevent malicious use.
+> Not necessary. It runs as the user, and can only do things the user
+> can do anyway.
+
+Consider a document that says
+
+Beutiful girls are
+<a href="localcgi:saveprefs?&homepage=>here</a>
+
+You should make it so that only local documents are allowed
+to reference local CGIs. ...Or something like that.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]A suggestion for configuration
+
+From: Russell Nelson <nelson@cr...> - 2002-01-17 19:21
+
+Paul Chamberlain writes:
+> Create an interface for local executables
+> Secure this "local-CGI" to prevent malicious use.
+
+Not necessary. It runs as the user, and can only do things the user
+can do anyway.
+
+> This would mean that the only thing added to dillo
+> is the ability to do this local-CGI thing.
+
+And looking at the plugins facility, 90% of the work to add CGI is
+already there.
+
+-- 
+-russ nelson http://russnelson.com | One has to kill more people
+Crynwr sells support for free software | PGPok | to stop them from following
+521 Pleasant Valley Rd. | +1 315 268 1925 voice | profits, than to stop them
+Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | from following prophets. 
+
+
+
+Re: [Dillo-dev]A suggestion for configuration
+
+From: Paul Chamberlain <tif@ti...> - 2002-01-17 17:32
+
+Russell Nelson wrote:
+> I have a suggestion for configuring dillo: use a web form, and local
+> CGI.
+
+I made the exact same suggestion once, only I forgot to
+send it to the list (default reply is to sender). I did
+send it to the guy that mentioned working on preferences:
+
+...
+
+I was wondering if there was a way to keep the
+preferences screens, etc., out of dillo. To do
+this, I came up with the following idea:
+
+Create an interface for local executables
+Secure this "local-CGI" to prevent malicious use.
+Build a preferences editor as one of these local-CGIs.
+Screens in HTML, write results to "~/.dillo/dillorc"
+
+This would mean that the only thing added to dillo
+is the ability to do this local-CGI thing. It could
+also open up lots of other possibilities. Hmm, think
+about a local-CGI that runs "locate"...
+
+Of course, the preference screens would then have to
+live with the limitations of HTML, but I don't think
+that's a huge sacrifice.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+[Dillo-dev]A suggestion for configuration
+
+From: Russell Nelson <nelson@cr...> - 2002-01-17 16:52
+
+I have a suggestion for configuring dillo: use a web form, and local
+CGI. CGI isn't that hard to set up to execute, and it opens up all
+sorts of interesting uses of dillo. Maybe it could be done through a
+plugin? e.g. cgi:/usr/lib/dillo/config.cgi
+
+-- 
+-russ nelson http://russnelson.com | One has to kill more people
+Crynwr sells support for free software | PGPok | to stop them from following
+521 Pleasant Valley Rd. | +1 315 268 1925 voice | profits, than to stop them
+Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | from following prophets. 
+
+
+
+[Dillo-dev]Staying put
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-16 21:09
+
+I just notice that the pages remember their position now. That's real
+neat! Thank you, I've missed that!
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Fake Javascript Patch (Was Re: OpenSSL Patch)
+
+From: John Utz <john@ut...> - 2002-01-16 16:28
+
+oh, cool!
+
+the idea of such a thing(fake javascript) occurred to me last nite whilst
+i was standing in the shower muttering to myself about the insufferable
+lameness of my credit union sticking javascript into some code that need
+only render tables.....grrr....
+
+i'll give this a spin tonite or tomorrow. if it get's me closer, than
+perhaps i can add some additional hacks to get what i need. :-)
+
+On Wed, 16 Jan 2002, Paul Chamberlain wrote:
+
+> John Utz wrote:
+> > and i lied when i said that having https was sufficient for me to do
+> > online banking with my credit union. i needed cookies too :-)
+> > it *still* doesnt work yet. adding cookies at least get's it past the
+> > login screen...a view source indicates.. JAVASCRIPT! CRAP! stupid thing.
+>
+> There is a slim possibility that this fake javascript patch
+> will work for you. It supports URLs of the form:
+>
+> javascript:somefunction(a,b,c,")
+>
+> At the very least, this works for yahoo's links to it's slide
+> shows. See news.yahoo.com for examples.
+> --
+> Paul Chamberlain, tif@ti...
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]A few comments, suggestions, and reflections.
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-16 14:59
+
+On Tue, 15 Jan 2002, paul@sp... wrote:
+
+> I haven't looked at the cookies patches because frankly I haven't been
+> able to get any of the patches people have put out to work (except the
+> forms patch which is great!). Is it possible (I'm sure the answer is
+> yes) to include "imaginary cookies support?" To just placate the web
+> servers and accept the cookies but just hold them in memory (ccache.[ch])
+> until Dillo is closed. There is really no need to keep them. Web pages
+> don't require that you have the cookie already, just that you are willing
+> to accept them.
+
+The cookies patch will do that. In the ~/.dillo/cookie_control file, add
+
+DEFAULT: ACCEPT_SESSION
+
+at the end.
+
+> Maybe this has been covered before and you can all fill my inbox with
+> hate mail if I'm beating a dead horse. But, why doesn't Dillo support
+> the full html code? It seems to me that that should be a primary
+> concern. For instance the <center> tag. Maybe it is more difficult than
+> it sounds. I haven't done any gui programming.
+
+Does now! Yay!
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Fake Javascript Patch (Was Re: OpenSSL Patch)
+
+From: Paul Chamberlain <tif@ti...> - 2002-01-16 14:03
+
+Attachments: javascript.diff      
+
+John Utz wrote:
+> and i lied when i said that having https was sufficient for me to do
+> online banking with my credit union. i needed cookies too :-)
+> it *still* doesnt work yet. adding cookies at least get's it past the
+> login screen...a view source indicates.. JAVASCRIPT! CRAP! stupid thing.
+
+There is a slim possibility that this fake javascript patch
+will work for you. It supports URLs of the form:
+
+javascript:somefunction(a,b,c,")
+
+At the very least, this works for yahoo's links to it's slide
+shows. See news.yahoo.com for examples.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+RE: [Dillo-dev]A few comments, suggestions, and reflections.
+
+From: Vaclav Tvrdik <Vaclav.Tvrdik@ip...> - 2002-01-16 13:48
+
+Dear dillo hackers,
+
+dillo is a great piece of software and I realy like it. Thanks to all who
+develop it. When I first time tried dillo I was little confused about not
+working CENTER flag, but late I got to used to it. I think it is not so bad
+to have all stuff aligned to left especialy on small screens. Maybe iPAQ
+users can say us more (hope soon I will be iPAQ user to :-). On small screen
+you (maybe) can avoid some scroling with scroolbar to left. If that what I
+am writing is true, maybe there could be option in cfg file. At the end let
+me one question. Are there some plans for support of CCS or javascript ?
+
+thanks again and best regards
+
+Vaclav TVRDIK
+PGP Key : 0xA983E45F
+
+
+
+
+-----Original Message-----
+From: Doug Kearns [mailto:djkea2@mu...]
+Sent: Thursday, January 17, 2002 12:27 AM
+To: dillo-dev@so...
+Subject: Re: [Dillo-dev]A few comments, suggestions, and reflections.
+
+
+On Tue, Jan 15, 2002 at 11:05:17PM -0800, Paul wrote:
+> Maybe this has been covered before and you can all fill my inbox with hate
+> mail if I'm beating a dead horse. But, why doesn't Dillo support the full
+> html code? It seems to me that that should be a primary concern. For
+> instance the <center> tag. Maybe it is more difficult than it sounds. I
+> haven't done any gui programming.
+
+Check out the latest CVS - CENTER is now supported.
+It was checked in about a week ago.
+
+Regards,
+Doug
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]A few comments, suggestions, and reflections.
+
+From: Doug Kearns <djkea2@mu...> - 2002-01-16 12:22
+
+On Tue, Jan 15, 2002 at 11:05:17PM -0800, Paul wrote:
+> Maybe this has been covered before and you can all fill my inbox with hate
+> mail if I'm beating a dead horse. But, why doesn't Dillo support the full
+> html code? It seems to me that that should be a primary concern. For
+> instance the <center> tag. Maybe it is more difficult than it sounds. I
+> haven't done any gui programming.
+
+Check out the latest CVS - CENTER is now supported.
+It was checked in about a week ago.
+
+Regards,
+Doug 
+
+
+
+[Dillo-dev]A few comments, suggestions, and reflections.
+
+From: Paul <paul@sp...> - 2002-01-16 07:05
+
+I love Dillo. I use it daily and dread the times when I am forced to crank
+up the diesel engine called Mozilla for programs that require cookies,
+ssl, java, flash, etc. (which is rare by the way) Before Dillo was thrown
+into my lap I was using a script written by Hobbit (l0pht) powered by
+netcat! The extra crap is cute and all but hardly worth the wait. With
+Dillo I don't have to sacrifice speed for legibility.
+
+I haven't looked at the cookies patches because frankly I haven't been
+able to get any of the patches people have put out to work (except the
+forms patch which is great!). Is it possible (I'm sure the answer is yes)
+to include "imaginary cookies support?" To just placate the web servers
+and accept the cookies but just hold them in memory (ccache.[ch]) until
+Dillo is closed. There is really no need to keep them. Web pages don't
+require that you have the cookie already, just that you are willing to
+accept them.
+
+Maybe this has been covered before and you can all fill my inbox with hate
+mail if I'm beating a dead horse. But, why doesn't Dillo support the full
+html code? It seems to me that that should be a primary concern. For
+instance the <center> tag. Maybe it is more difficult than it sounds. I
+haven't done any gui programming.
+
+I love Dillo. I appreciate all the hard work everyone has put into it to
+make it the fine browser it is. Because of the extensive documentation
+and attention to detail I am learning a great deal about all aspects of
+programming.
+
+-Paul (paul@sp...) 
+
+
+
+Re: [Dillo-dev]Dillo/OpenSSL Patch - Latest Version - Take 2
+
+From: John Utz <john@ut...> - 2002-01-16 06:14
+
+hi jonathan!
+
+a bug report, at least with respect to my FreeBSD 4.4-RELEASE setup:
+one thing that i find myself having to do when i use your patches is to
+manually add the new file name to the makefiles, ie https.c https.o,
+etc...
+
+and i lied when i said that having https was sufficient for me to do
+online banking with my credit union. i needed cookies too :-)
+
+it *still* doesnt work yet. adding cookies at least get's it past the
+login screen...a view source indicates.. JAVASCRIPT! CRAP! stupid thing.
+
+i should have checked for that earlier. :-(
+
+On Mon, 14 Jan 2002, Jonathan P Springer wrote:
+
+> It's been brought to my attention that the patch I posted earlier today was
+>
+> 1. Broken
+> 2. Misnamed
+> 3. Came with the wrong instructions
+>
+> I've posted a revised version of the patch. The information that follows
+> has been edited for correctness and completeness. I just completed a test
+> compile and run successfully.
+>
+> Sorry for the inconvenience.
+> -js
+>
+> -----
+>
+> I've completed a few revisions to the HTTPS for Dillo. The latest version of
+> the patch can be obtained from
+>
+> http://members.bellatlantic.net/~vze2mqqv/dillo-ssl-cookies.2002-01-14.diff
+>
+> Changes since the initial patch include:
+>
+> 1. When Dillo is configured to use proxies, all HTTPS requests are sent to
+> the proxy server via HTTP.
+>
+> 2. Changed uint32_t to guint32. This change let me compile on a
+> Cygnus/XFree86 machine.
+>
+> 3. Add 'libcrypto' to the configuration script.
+>
+> The diffs were generated against the current CVS (as of this writing). They
+> may not apply cleanly against 0.6.3. I've also integrated Jorgen Viksell's
+> cookie patch.
+>
+> To apply the patch, download it to the root of the Dillo source tree and...
+>
+> $ patch -p1 -i dillo-ssl-cookies.2002-01-14.diff
+> $ autoconf
+> $ ./configure --enable-ssl
+> $ make
+>
+> Be sure 'gtk.m4' is in your /usr/share/aclocal directory. On many systems,
+> in must be symlinked from /usr/local/share/aclocal.
+>
+> Apologies about the need for autoconf, but shipping diffs for 'configure'
+> seemed counterproductive. Distribution tarballs should not require autoconf.
+>
+> -jonathan
+>
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+> ----- End forwarded message -----
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Dillo/OpenSSL Patch - Latest Version - Take 2
+
+From: Ulrich Schwarz <uschwarz@gm...> - 2002-01-15 11:36
+
+Hi Jonathan,
+
+On Mon, Jan 14, 2002 at 03:16:55PM -0500, Jonathan P Springer wrote:
+
+> 1. When Dillo is configured to use proxies, all HTTPS requests are
+> sent to the proxy server via HTTP.
+
+This doesn't work for any proxy I tried (squid, wwwoffle).
+
+https requests via http-proxies have to be implemented in a
+different way, just like w3m handles them.
+
+So long.
+Ulrich 
+
+
+
+Re: [Dillo-dev]Dillo/OpenSSL Patch - Latest Version - Take 2
+
+From: John Utz <john@ut...> - 2002-01-15 06:02
+
+did i read this correctly? are you running dillo on a win32 box? if
+so..COOL!
+
+On Mon, 14 Jan 2002, Jonathan P Springer wrote:
+
+> It's been brought to my attention that the patch I posted earlier today was
+>
+> 1. Broken
+> 2. Misnamed
+> 3. Came with the wrong instructions
+>
+> I've posted a revised version of the patch. The information that follows
+> has been edited for correctness and completeness. I just completed a test
+> compile and run successfully.
+>
+> Sorry for the inconvenience.
+> -js
+>
+> -----
+>
+> I've completed a few revisions to the HTTPS for Dillo. The latest version of
+> the patch can be obtained from
+>
+> http://members.bellatlantic.net/~vze2mqqv/dillo-ssl-cookies.2002-01-14.diff
+>
+> Changes since the initial patch include:
+>
+> 1. When Dillo is configured to use proxies, all HTTPS requests are sent to
+> the proxy server via HTTP.
+>
+> 2. Changed uint32_t to guint32. This change let me compile on a
+> Cygnus/XFree86 machine.
+>
+> 3. Add 'libcrypto' to the configuration script.
+>
+> The diffs were generated against the current CVS (as of this writing). They
+> may not apply cleanly against 0.6.3. I've also integrated Jorgen Viksell's
+> cookie patch.
+>
+> To apply the patch, download it to the root of the Dillo source tree and...
+>
+> $ patch -p1 -i dillo-ssl-cookies.2002-01-14.diff
+> $ autoconf
+> $ ./configure --enable-ssl
+> $ make
+>
+> Be sure 'gtk.m4' is in your /usr/share/aclocal directory. On many systems,
+> in must be symlinked from /usr/local/share/aclocal.
+>
+> Apologies about the need for autoconf, but shipping diffs for 'configure'
+> seemed counterproductive. Distribution tarballs should not require autoconf.
+>
+> -jonathan
+>
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+> ----- End forwarded message -----
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Dillo/OpenSSL Patch - Latest Version - Take 2
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-15 04:12
+
+On Mon, 14 Jan 2002, Jonathan P. Springer wrote:
+
+> It's been brought to my attention that the patch I posted earlier today
+> was
+>=20
+> 1. Broken
+> 2. Misnamed
+> 3. Came with the wrong instructions
+>=20
+> I've posted a revised version of the patch. The information that follows
+> has been edited for correctness and completeness. I just completed a
+> test compile and run successfully.
+>=20
+> Sorry for the inconvenience.
+> -js
+>=20
+> -----
+>=20
+> I've completed a few revisions to the HTTPS for Dillo. The latest
+> version of the patch can be obtained from
+>=20
+> http://members.bellatlantic.net/~vze2mqqv/dillo-ssl-cookies.2002-01-14.=
+diff
+[...]
+> To apply the patch, download it to the root of the Dillo source tree
+> and...
+>=20
+> $ patch -p1 -i dillo-ssl-cookies.2002-01-14.diff
+> $ autoconf
+> $ ./configure --enable-ssl
+> $ make
+
+The configure script, while it checks for OpenSSL, seems to ignore the
+results and happily try to compile for OpenSSL with headers and library
+missing. Methinks specifying --enable-ssl would mean that you want a
+warning if OpenSSL isn't there.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev][PATCH] dillo-icons-patch
+
+From: ralphtheraccoon <ralphtheraccoon@uk...> - 2002-01-14 23:53
+
+Attachments: dillo-icons-patch      
+
+hi, attached is the icons patch i mentioned a few days ago. I created it with diff -urN
+as it was the only combo i could get to work (and it is the one recomended in the linux
+kernel docs). it seems to patch in well, no compile errors or anything. About "how to install
+images"... well, as dillo is using the xpm file format -- which is text based -- the images
+are compiled into the executable itself.
+
+Dan 
+
+
+
+[Dillo-dev]About frames
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-14 22:21
+
+I've been told that w3m handles frames exactly like it handles tables.
+Might that be an idea for Dillo? I'd love to see better frames.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Dillo/OpenSSL Patch - Latest Version - Take 2
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-01-14 20:17
+
+It's been brought to my attention that the patch I posted earlier today was
+
+1. Broken
+2. Misnamed
+3. Came with the wrong instructions
+
+I've posted a revised version of the patch. The information that follows
+has been edited for correctness and completeness. I just completed a test
+compile and run successfully. 
+
+Sorry for the inconvenience.
+-js
+
+-----
+
+I've completed a few revisions to the HTTPS for Dillo. The latest version of
+the patch can be obtained from 
+
+http://members.bellatlantic.net/~vze2mqqv/dillo-ssl-cookies.2002-01-14.diff
+
+Changes since the initial patch include:
+
+1. When Dillo is configured to use proxies, all HTTPS requests are sent to
+the proxy server via HTTP.
+
+2. Changed uint32_t to guint32. This change let me compile on a 
+Cygnus/XFree86 machine.
+
+3. Add 'libcrypto' to the configuration script.
+
+The diffs were generated against the current CVS (as of this writing). They
+may not apply cleanly against 0.6.3. I've also integrated Jorgen Viksell's
+cookie patch.
+
+To apply the patch, download it to the root of the Dillo source tree and...
+
+$ patch -p1 -i dillo-ssl-cookies.2002-01-14.diff
+$ autoconf
+$ ./configure --enable-ssl
+$ make
+
+Be sure 'gtk.m4' is in your /usr/share/aclocal directory. On many systems,
+in must be symlinked from /usr/local/share/aclocal.
+
+Apologies about the need for autoconf, but shipping diffs for 'configure'
+seemed counterproductive. Distribution tarballs should not require autoconf.
+
+-jonathan
+
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev
+
+----- End forwarded message ----- 
+
+
+
+[Dillo-dev]Dillo/OpenSSL Patch - Latest Version
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-01-14 19:11
+
+I've completed a few revisions to the HTTPS for Dillo. The latest version of
+the patch can be obtained from 
+
+http://members.bellatlantic.net/~vze2mqqv/dillo-ssl-cookies.2001-01-14.diff
+
+Changes since the initial patch include:
+
+1. When Dillo is configured to use proxies, all HTTPS requests are sent to
+the proxy server via HTTP.
+
+2. Changed uint32_t to guint32. This change let me compile on a 
+Cygnus/XFree86 machine.
+
+3. Add 'libcrypto' to the configuration script.
+
+The diffs were generated against the current CVS (as of this writing). They
+may not apply cleanly against 0.6.3. I've also integrated Jorgen Viksell's
+cookie patch.
+
+To apply the patch, download it to the root of the Dillo source tree and...
+
+$ diff -p1 -i dillo-ssl-cookies.2001-01-14.diff
+$ autoconf
+$ ./configure --enable-ssl
+$ make
+
+Be sure 'gtk.m4' is in your /usr/share/aclocal directory. On many systems,
+in must be symlinked from /usr/local/share/aclocal.
+
+Apologies about the need for autoconf, but shipping diffs for 'configure'
+seemed counterproductive. Distribution tarballs should not require autoconf.
+
+-jonathan 
+
+
+
+Re: [Dillo-dev]image scaling?
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-01-14 16:06
+
+Hi!
+
+On Wed, Dec 12, I wrote:
+> Since there are some other problems with images, I've thought of
+> encapsulating the representation of images into a new type, which
+> provides functions for:
+> [...]
+
+I've read the code for image decoding and caching, and looked how to
+realize this idea in the current code. The following targets more on
+simple integration, changes in the current code are minimal.
+
+1. Instead of a guchar array, a new data type, DilloImageBuffer,
+should be used (DICacheEntry::ImageBuffer and DwImage::buffer). Any
+access is done by function calls: Copying the lines (in
+a_Image_write) is done by a_Image_buffer_copy_line etc. The call to
+Image_line becomes obsolete, since DilloImageBuffer will deal with
+different types: indexed, RGB, gray, RGBA, gray-alpha(?). This may
+be useful for a more efficient implementation of DilloImageBuffer.
+
+2. The modules Png, JPeg, Gif, Image and DICache deal with the
+original image size (read by the decoders), while DwImage gets the
+"viewed" size (original size, multiplied by the global image
+scaling factor) from DilloImageBuffer.
+
+3. For DwImage, there are further methods, which replace the current
+direct access. Note to worth:
+
+- Shared buffers are shared, reference counters are used. Copying
+rows will automatically also affect the related scaled buffers.
+
+- There are two methods for drawing: one called after expose events
+(Dw_image_draw), and another called by a_Dw_image_draw_row. The
+exact rules, how the buffer is scaled (this can e.g. differ by a
+pixel or so), is hidden in DilloImageBuffer.
+
+- As noted above, all DwImage code is based on the viewed size.
+
+4. The global image scaling factor is used in two places: The HTML
+parser must apply it on the WIDTH and HEIGHT attributes of the
+<IMG> tag, and DilloImageBuffer must use it to scale the inherent
+size of an image. There are two modes, between the user can switch
+by a dillorc option:
+
+(i) The original image data is preserved, and an additional scaled
+buffer is created:
+
++-------+ +------------------+ additional
+| Image | -- copy --> | DilloImageBuffer | --> scaled
++-------+ rows | (original size) | buffers
++------------------+
+| ^
+| |
+scale requests
+each row for scaled
+| buffers
+| |
+v |
++------------------+
+| DilloImageBuffer |
+| (viewed size) |
++------------------+
+^
+|
++---------+
+| DwImage |
++---------+
+
+(ii) The original data gets lost just after scaling:
+
++-------+ +------------------+
+| Image | -- copy --> | DilloImageBuffer | --> scaled
++-------+ rows | (viewed size) | buffers
++------------------+
+^
+|
++---------+
+| DwImage |
++---------+
+
+(ii) uses generally less memory, while in some cases leads to a
+lower rendering quality, as in this example:
+
+"foo.png" has a size of 100x100 pixels, the image scaling factor is
+50%, and the following HTML sniplet is rendered:
+
+<img src="foo.png">
+<img src="foo.png" width=200 height=200>
+
+The first image is displayed at a size of 50x50, the second at
+100x100. (i) will, for the second, use the original buffer, but
+(ii) will enlarge the buffer, which was scaled down before, so
+resulting in a "pixelized" image.
+
+5. Any implementation of DilloImageBuffer will handle transparency
+independent of the background, i.e. the background colour will not
+be used anymore. The first implementation may be based on GdkRGB
+and (when needed) dithered clipping bitmaps. Better implementations
+may then developed in the future.
+
+6. Background images: The modules Image and DICache do no longer
+access the DwImage directly, all calls are replaced by and
+Interface, which is then implemented by DwImage and an appropriate
+structure for background images (part of DwStyle). The interface is
+in C realized by a struct of function pointers, and a generic
+pointer on DwImage etc. (details will follow).
+
+Perhaps someone, who knows the image code better, finds a bug, or also
+a better solution. Otherwise, I'll probably soon start to implement
+these ideas.
+
+Sebastian 
+
+
+
+[Dillo-dev]Thanks!
+
+From: Peter Graf <p.graf@it...> - 2002-01-14 10:45
+
+Hi folks,
+
+I won't be able to contribute development work. I' just like to say a big
+thanks for Dillo!!! And for the way you implement it!
+
+As a user of an "excotic" platform (Motorola 68040/68060 based), I very
+much appreciate that Dillo is purely written in C, and its small size and
+high efficieny! Great that libs like GNOME are not required.
+
+Of course I am hoping for new features, but I'd also like to state from a
+users point of view that Dillo is already useful right now!
+
+Great work! Please continue the development! Thanks a lot!
+
+Peter 
+
+
+
+[Dillo-dev]Dillo-m17n patch2
+
+From: <jserv.bbs@go...> - 2002-01-10 09:44
+
+Hi, all.
+
+Thanks to <ksr@lp.nm.fujitsu.co.jp>'s contribution to m17n patch. It
+worked well with a little modification, and I intergrated some patches
+into this tarball, as https protocol, cookies, and rendering Traditional
+Chinese (Taiwan). I put it here:
+
+http://ccns.ncku.edu.tw/~jimchyun/dillo/dillo-0.63-m17n.tgz
+
+Also, I modified a configuration tool in Tk, called dillocfg. It can
+be accessed in config/dillocfg after decompression. You can see the screen-
+shot as following link:
+
+http://ccns.ncku.edu.tw/~jimchyun/dillo/snapshot/
+
+i am sorry for this page is in Traditional Chinese encoding, but some-
+how it proves that Dillo could support m17n very well indeed.
+
+Thank you very much for all your hard work, it is deeply appreciated.
+
+Sincerely,
+Jim Huang.
+--
+¡° Origin: ¦¨¥\¤j¾Ç¸ê°T¤uµ{¾Ç¨t[¾K¸ê¤ßBBS] <goodguy.csie.ncku.edu.tw> 
+¡» From: ccns.ncku.edu.tw 
+
+
+
+[Dillo-dev]Latest cookies patch
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-01-09 14:30
+
+Hi all!
+
+The latest cookies patch may be found at this location:
+http://w1.211.telia.com/~u21114235/patch-cookies-8jan
+
+The only real change is that I removed a security check that made some
+sites work incorrectly.=20
+Removing that particular check and applying the patch on top of
+Jonathan Springers SSL patch actually enabled Dillo to log in to
+Hotmail. :-)
+
+Cheers,
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]HTTPS/OpenSSL in Dillo
+
+From: Michael Govorun <mike@sh...> - 2002-01-09 10:59
+
+Sammy Mannaert <nstalkie@tv...> writes:
+
+> microsoft for example used a bsd licensed tcp/ip stack in win nt !
+
+obviously, this is problem with BSD-license!
+
+-- 
+Michael Govorun 
+
+
+
+Re: [Dillo-dev]m17n patch
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-01-09 02:20
+
+Hi.
+
+I mistook the URL.
+
+< http://todo.org/download/dillo/dillo-0.6.3-uo-branch-2.tar.gz
+> http://todo.org/download/dillo/dillo-0.6.3-uo-branch-2.tgz
+
+Thanks. 
+
+
+
+[Dillo-dev]m17n patch
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-01-09 01:35
+
+Hi.
+
+I put the following file,
+http://todo.org/download/dillo/dillo-0.6.3-uo-branch-2.tar.gz
+It works fine.
+
+This supports UTF-8, Japanese charsets and others (Korean etc) like
+Netscape 4.x encoding menu, it is based on Robert Thomson's Japanese
+patch and Grigory Bakunv's encoding patch. Enjoy. 
+
+
+
+Re: [Dillo-dev]HTTPS/OpenSSL in Dillo
+
+From: Sammy Mannaert <nstalkie@tv...> - 2002-01-08 21:29
+
+Jonathan Springer wrote:
+> 
+> Also, this is technically in violation of the GPL until Jorge OKs it. 
+> OpenSSL's license is BSD freeware, which is ever so slightly more 
+> restrictive than GPL. DBIO.c and https.c both require disclaimer 
+> from Jorge and I as copyright holders that it's OK to link them 
+> against libssl.
+
+actually the bsd license is less restrictive than the gpl license :)
+
+gpl:
+use our source, modify our source ... BUT : 
+distribute source if you distribute binaries
+bsd (without advertising clause):
+use our source, modify our source, release in any form
+you want
+
+microsoft for example used a bsd licensed tcp/ip stack in win nt !
+some of the tcp/ip in os2 warp were also bsd licensed if i'm not
+mistaken
+
+the problem is actually with the GPL (as you are linking against
+a non free library)
+
+http://www.openssl.org/support/faq.html#LEGAL2 
+
+
+
+Re: [Dillo-dev]HTTPS/OpenSSL in Dillo
+
+From: John Utz <john@ut...> - 2002-01-08 21:03
+
+greetings;
+
+i wanted to mention that this patch consistently works on *both* my
+redhat-7.0 box at work *and* my FreeBSD-4.4-RELEASE box at home.
+
+this makes me very happy.
+
+the previously proffered patch built ok after some fiddling, but it never
+actually worked.
+
+the one point i would make your patch is that the call to autoconf is
+probably a significant roadmap to wide adoption.
+
+whatever version of autoconf was used at your home is not the
+same one as is available on my RH7.0 or my FreeBSD box, because i had to
+do a ton of stuff by hand to get it to compile.
+
+i assume that the problem would be eliminated if this patch was committed
+to the src tree and the 'conf bits' where done as part of the rest of the
+release generation process.
+
+great patch. tnx for taking the time to provide it! i hope this https
+support gets included in the next release
+
+On Sun, 6 Jan 2002, Jonathan Springer wrote:
+
+> When I couldn't use Dillo to log on to SourceForge, I knew something had to be done about HTTPS support. Attached is the result of a few days work on extending the interface. Originally, I thought I'd just have to replicate HTTP.c and use the FD's from IO.c. Wrong! OpenSSL's libssl has these wonderful things called BIOs, except they don't behave like FDs and you can't count on anyone who doesn't have OpenSSL having them. DBIO.c in the patch replicates IO.c functionality for BIOs.
+>
+> Aargh. To apply the patch, download the attached tarball into your dillo root directory and:
+>
+> $ tar zfx dillo-ssl.tar.gz
+> $ patch -p0 -i dillo.diff
+> $ autoconf
+> $ ./configure --enable-ssl # and your other prefs
+> $ ./src/dillo https://so....net # test case
+>
+> Note that you'll need OpenSSL installed for this to work at all.
+>
+> Also, this is technically in violation of the GPL until Jorge OKs it. OpenSSL's license is BSD freeware, which is ever so slightly more restrictive than GPL. DBIO.c and https.c both require disclaimer from Jorge and I as copyright holders that it's OK to link them against libssl.
+>
+> Feel free to contact me with bugs or concerns. I've just started putting this through its paces.
+>
+> -jonathan springer <jonathan.springer@ve...>
+>
+> N.B. I still can't connect to SourceForge. Cookies are next on the list.
+>
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]toolbar images
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-08 17:01
+
+On Wed, 2 Jan 2002, ralphtheraccoon@uk... wrote:
+
+> Hi, and happy new year!
+>=20
+> I've just started hacking on dillo... I'm not all that good yet, but I've
+> seporated out the images in src/pixmaps.h into .xpm files in a new
+> src/images folder, so as to make it easier for artists to edit them
+> (if needed), and so that editing via gimp or other non-text editors
+> is possible. I've also added in using of gnome-type icons (such as
+> ROX-filer, gmc, and galeon use) so dillo is more consistant with the
+> look of other gnome/gtk apps. I'm still kinda new to this, so how should
+> I create a multi-file patch, and where should I put it?
+
+You create a patch by using diff on the original source and your modified
+source:
+
+$ tar -xzf dillo.tar.gz
+$ mv dillo dillo-orig
+$ tar -xzf dillo.tar.gz
+...modify...
+...remove editors backup files...
+$ cd dillo
+$ make dist-clean
+$ cd ..
+$ diff -Burbn dillo-orig dillo >dillo-icons-patch
+
+The dist-clean is to make sure generated files don't get into the diff,
+while your new icon files do. If you had no new files, you could just use
+
+$ diff -Burb dillo-orig dillo | grep -v '^Only in' >dillo-icons-patch
+
+If it's not not overly long, you can post it here as an attachment,
+otherwise post a link to it.
+
+What do you do for installation of the images? I've never quite figured
+out where to put such.
+
+> PS - the modifications pass the dillo.s...net guidelines ;)
+
+Good!=20=20
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]New patch-o-matic site coming up
+
+From: lrclause+<dillo@cs...> - 2002-01-07 23:50
+
+With the haru.wom.ru patch-o-matic site being down, I decided to finally do
+what I've wanted to do and make my own patch-o-matic. I've hacked up some
+code to have it keep better track of what works, and it's just about
+ready. Since I won't have web-based submission for a while (until I see
+how the base stuff runs), I'd like everybody who's submitted patches to
+send me a copy, preferably with a note of when (what Dillo version) it was
+made and what it does. To avoid flooding the list with old patches, I've
+set the Reply-To: to me (hopefully the list software doesn't kill it).
+
+Happy hacking,
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]forwarded user comments
+
+From: Robert Thomson <bob@go...> - 2002-01-07 22:50
+
+Hi,
+
+Here is an email that was sent to me. I am forwarding it to the list
+because it talks about Dillo, rather than just my Japanese support patch.
+
+Regards,
+
+Bob Thomson.
+
+---------------------------------------------------------------------
+
+Rough translation:
+
+How do you do, my name is Imamichi.
+I found Dillo's record at freshmeat, and
+eventually I found the Japanese patch with google.
+I usually use Mozilla, but Dillo's lightness was exciting.
+Keep up the good work please!
+
+---------------------------------------------------------------------
+
+> From imamichi@li... Sat Jan 5 23:22:33 2002
+> Date: Mon, 24 Dec 2001 11:58:04 +0900
+> From: "今道貴司" <imamichi@li...>
+> To: Robert.Thomson@ee.ed.ac.uk
+> Subject: dillo 日本語版
+>
+> 初めまして、今道と申します。
+> freshmeatにdilloが登録されていて、
+> その日本語パッチをgoogleで検索してたどりつきました。
+> 普段はMozillaを使っていますが、dilloの軽さに感動しました。
+> これからも頑張ってください。
+>
+> -- 
+> /-----------------------------------------
+> 今道 貴司
+> 京都大学工学部情報学科
+> 数理工学コース 2回生
+> imamichi@li...
+> -----------------------------------------/ 
+
+
+
+[Dillo-dev]Forms enter patch
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-06 18:49
+
+Hope everybody had a merry Christmas and a happy New Year. Here's a small
+patch that lets you use Enter to submit a form, even if there are submit
+buttons.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket?
+
+=3D=3D=3DFile ~/src/dillo-enter-patch=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+diff -rbBu dillo-orig/src/html.c dillo-enter/src/html.c
+--- dillo-orig/src/html.c Wed Jan 2 10:57:17 2002
++++ dillo-enter/src/html.c Sun Jan 6 12:31:01 2002
+@@ -352,7 +352,6 @@
+html_lb->forms[nf].num_inputs =3D 0;
+html_lb->forms[nf].num_inputs_max =3D 4;
+html_lb->forms[nf].inputs =3D NULL;
+- html_lb->forms[nf].HasSubmitButton =3D FALSE;
+html_lb->num_forms++;
+=20
+// g_print("Html_form_new: action=3D%s nform=3D%d\n", action, nf);
+@@ -2595,7 +2594,6 @@
+if ( (i =3D Html_find_form(submit, html_lb)) =3D=3D -1 )
+return;
+=20
+- if ( html_lb->forms[i].HasSubmitButton =3D=3D FALSE )
+Html_submit_form(submit, html_lb);
+}
+=20
+@@ -2670,7 +2668,6 @@
+init_str =3D g_strdup(Html_get_attr2(html, tag, tagsize, "value",=
+0));
+} else if (!g_strcasecmp(type, "submit")) {
+inp_type =3D DILLO_HTML_INPUT_SUBMIT;
+- form->HasSubmitButton =3D TRUE;
+init_str =3D (value) ? value : g_strdup("submit");
+widget =3D gtk_button_new_with_label(init_str);
+gtk_widget_set_sensitive(widget, FALSE); /* Until end of FORM! */
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
+
+
+
+[Dillo-dev]HTTPS/OpenSSL in Dillo
+
+From: Jonathan Springer <jonathan.springer@ve...> - 2002-01-06 18:37
+
+Attachments: dillo-ssl.tar.gz      
+
+When I couldn't use Dillo to log on to SourceForge, I knew something had to be done about HTTPS support. Attached is the result of a few days work on extending the interface. Originally, I thought I'd just have to replicate HTTP.c and use the FD's from IO.c. Wrong! OpenSSL's libssl has these wonderful things called BIOs, except they don't behave like FDs and you can't count on anyone who doesn't have OpenSSL having them. DBIO.c in the patch replicates IO.c functionality for BIOs.
+
+Aargh. To apply the patch, download the attached tarball into your dillo root directory and:
+
+$ tar zfx dillo-ssl.tar.gz
+$ patch -p0 -i dillo.diff
+$ autoconf
+$ ./configure --enable-ssl # and your other prefs
+$ ./src/dillo https://so....net # test case
+
+Note that you'll need OpenSSL installed for this to work at all.
+
+Also, this is technically in violation of the GPL until Jorge OKs it. OpenSSL's license is BSD freeware, which is ever so slightly more restrictive than GPL. DBIO.c and https.c both require disclaimer from Jorge and I as copyright holders that it's OK to link them against libssl.
+
+Feel free to contact me with bugs or concerns. I've just started putting this through its paces.
+
+-jonathan springer <jonathan.springer@ve...>
+
+N.B. I still can't connect to SourceForge. Cookies are next on the list. 
+
+
+
+Re: Found the problem! But why is CPPFLAGS used in a C only project?Re: [Dillo-dev]0.6.3 configure and jpeg headers
+
+From: John Utz <john@ut...> - 2002-01-04 20:13
+
+i love mailing lists!
+
+On Fri, 4 Jan 2002, Lionel Ulmer wrote:
+
+> > dillo is written in C, not C++, so there is no reason that i can
+> > comprehend for the CPPFLAGS env variable to *ever*be used in configuring
+> > or compiling this project.
+>
+> Well, it's just that CPPFLAGS are the flags given to the C PreProcessor (the
+> 'cpp' command)... So all -I directives should be in CPPFLAGS.
+>
+> CFLAGS are the parameter given to the C compiler.
+>
+> And CXXFLAGS are the one for the C++ compiler.
+>
+> At least this is my understanding of all this :-)
+
+i think that your understanding is correct. i think that CPPFLAGS gets
+misused for c++ stuff so much that i have misunderstood it's use for quite
+some time!
+
+then the fix would be to assign -ILIBJPEG_INCDIR to CPPFLAGS instead of
+CFLAGS and then the problem would be fixed
+
+> Lionel
+>
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: Found the problem! But why is CPPFLAGS used in a C only project?Re: [Dillo-dev]0.6.3 configure and jpeg headers
+
+From: Lionel Ulmer <lionel.ulmer@fr...> - 2002-01-04 20:03
+
+> dillo is written in C, not C++, so there is no reason that i can
+> comprehend for the CPPFLAGS env variable to *ever*be used in configuring
+> or compiling this project.
+
+Well, it's just that CPPFLAGS are the flags given to the C PreProcessor (the
+'cpp' command)... So all -I directives should be in CPPFLAGS.
+
+CFLAGS are the parameter given to the C compiler.
+
+And CXXFLAGS are the one for the C++ compiler.
+
+At least this is my understanding of all this :-)
+
+Lionel
+
+-- 
+Lionel Ulmer - http://www.bbrox.org/ 
+
+
+
+Found the problem! But why is CPPFLAGS used in a C only project?Re: [Dillo-dev]0.6.3 configure and jpeg headers
+
+From: John Utz <john@ut...> - 2002-01-04 19:55
+
+As i indicated i would, i poked around in the configure script on my ride
+home on the bus yesterday afternoon.
+
+I will describe the misconfiguration in a moment, but i think the question
+i ask in the header is a fundamental one, so we should tackle that first.
+
+dillo is written in C, not C++, so there is no reason that i can
+comprehend for the CPPFLAGS env variable to *ever*be used in configuring
+or compiling this project.
+
+this is a strong statement, and there may be things that i dont understand
+that somebody else could point out that makes CPPFLAGS appropriate
+(ie something broken in some compiler somewhere that requires the use of
+CPPFLAGS to compile C code).
+
+absent any compelling reason to use it, I feel that any CPP stuff should
+be removed from the configure.
+
+so, why is configure --with-jpeg-include=/usr/local/include failing to
+help gcc find my jpeg headers?
+
+because the configure correctly sets CFLAGS:
+LIBJPEG_INCDIR=$withval
+if test -n "$LIBJPEG_INCDIR"; then
+CFLAGS="$CFLAGS -I$LIBJPEG_INCDIR"
+
+but it uses the cpp compile command to build conftest for jpeg includes!
+
+for ac_header in jpeglib.h jconfig.h jerror.h jmorecfg.h
+do
+ac_ac_Header=`echo "ac_cv_header_$ac_header" | $ac_tr_sh`
+echo "$as_me:2656: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$ac_ac_Header+set}\" = set"; then
+echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+cat >conftest.$ac_ext <<_ACEOF
+#line 2662 "configure"
+#include "confdefs.h"
+#include <$ac_header>
+_ACEOF
+if { (eval echo "$as_me:2666: \"$ac_cpp conftest.$ac_ext\"") >&5
+(eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+
+
+$ac_cpp should be $ac_c !!!
+
+i'll go file a bug now
+
+On Thu, 3 Jan 2002, John Utz wrote:
+
+> hi;
+>
+> IIRC, the issue with configure not finding jpeg and png ligs and headers
+> was supposed to be fixed in 0.6.3.
+>
+> that doesnt seem to be completely true for me. it finds png headers and
+> libs ok, and it finds jpeg *libs* ok, but it cant seem to find the jpeg
+> headers.
+>
+> the JPEGLIB_INC variable is getting set correctly to /usr/local/include
+> when i specify --with-jpeg-inc, but the configure process reports no no no
+> for all of the headers.
+>
+> i'll will hopefully find out a more specific problem when i poke more
+> echo's into configure this afternoon
+>
+>
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]0.6.3 configure and jpeg headers
+
+From: John Utz <john@ut...> - 2002-01-03 20:00
+
+hi;
+
+IIRC, the issue with configure not finding jpeg and png ligs and headers
+was supposed to be fixed in 0.6.3.
+
+that doesnt seem to be completely true for me. it finds png headers and
+libs ok, and it finds jpeg *libs* ok, but it cant seem to find the jpeg
+headers.
+
+the JPEGLIB_INC variable is getting set correctly to /usr/local/include
+when i specify --with-jpeg-inc, but the configure process reports no no no
+for all of the headers.
+
+i'll will hopefully find out a more specific problem when i poke more
+echo's into configure this afternoon
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]toolbar images
+
+From: ralphtheraccoon <ralphtheraccoon@uk...> - 2002-01-02 16:38
+
+Hi, and happy new year!
+
+I've just started hacking on dillo... I'm not all that good yet, but I've
+seporated out the images in src/pixmaps.h into .xpm files in a new
+src/images folder, so as to make it easier for artists to edit them
+(if needed), and so that editing via gimp or other non-text editors
+is possible. I've also added in using of gnome-type icons (such as
+ROX-filer, gmc, and galeon use) so dillo is more consistant with the
+look of other gnome/gtk apps. I'm still kinda new to this, so how should
+I create a multi-file patch, and where should I put it?
+
+Dan
+
+PS - the modifications pass the dillo.s...net guidelines ;) 
+
+
+
+[Dillo-dev]Forms & enter
+
+From: Lars Clausen <lrclause@cs...> - 2002-01-02 13:51
+
+First off, happy new year to everybody! May Dillo make as much progress in
+the new year as in the last.
+
+I've been wondering about the design decision to make forms only submit on
+Enter when there is no Submit button. It is obviously not becuase it would
+be hard to code (just pick the first submit button). The specs don't
+(AFAICS) say anything for or against it. It's certainly very practical to
+have Enter submit input text. Why has it been explicitly coded so that it
+only happens if there is no Submit button?
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
diff --git a/old/oldmail/200202.txt b/old/oldmail/200202.txt
new file mode 100644
index 0000000..a01734f
--- /dev/null
+++ b/old/oldmail/200202.txt
@@ -0,0 +1,5334 @@
+Re: [Dillo-dev][RFC] Limiting the size of Cache
+
+From: Pekka Lampila <medar@ka...> - 2002-02-28 23:04
+
+On Sat, 23 Feb 2002 14:50:04 +0200
+Pekka Lampila <medar@ka...> wrote:
+
+> I'll try to clean up my patch tomorrow and post it here.
+
+Took little longer, but here it is.
+http://kirjasto.org/medar/dillo/cache-limit.medar.2002-02-28.diff
+5 files changed, 117 insertions(+), 1 deletion(-)
+
+There are surely some bugs and shortcomings included. General idea
+should be clear though.
+
+It doesn't file sizes in account when making up removing order. That
+would be easy to add, but could be an overkill.
+
+But anyway Livio's approach is propably much better. Or better suited
+for Dillo atleast.
+
+cache_size="-1" -> cache everything (default)
+cache_size="0" -> cache nothing
+cache_size="x" -> cache size x kilobytes
+
+-- 
+Pekka Lampila
+medar@ka... 
+
+
+
+[Dillo-dev]Small make install issue
+
+From: Michael Duelli <m.duelli@we...> - 2002-02-28 11:03
+
+Hi all,
+
+when installing dillo as root using ginstall from install (GNU fileutils) 
+4.0 I get this tiny error message
+
+--------------snip----------------
+make[1]: Entering directory `/usr/src/packages/SOURCES/DEV/dillo'
+make[2]: Entering directory `/usr/src/packages/SOURCES/DEV/dillo'
+make[2]: Nothing to be done for `install-exec-am'.
+if [ -d /usr/local/etc ]; then \
+/usr/bin/ginstall -c -m 644 --backup=t ./dillorc /usr/local/etc/; \
+elif [ -d /etc/ ]; then \
+/usr/bin/ginstall -c -m 644 --backup=t ./dillorc /etc/; \
+fi
+make[2]: Leaving directory `/usr/src/packages/SOURCES/DEV/dillo'
+make[1]: Leaving directory `/usr/src/packages/SOURCES/DEV/dillo'
+--------------snap----------------
+
+It seems like you have to export the argument for backup as 
+SIMPLE_BACKUP_SUFFIX.
+Maybe this is different with newer versions of ginstall.
+
+TIA,
+Michael
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net - A 3D chess interface 
+
+
+
+[Dillo-dev]aa font question
+
+From: Sajed Chowdhury <src@ac...> - 2002-02-27 20:42
+
+Hi,
+
+I've just installed dillo and I think it has the potential to be a great 
+minimalistic browser.
+I question I have is how can I make dillo display anti-aliased ttf fonts?
+
+thanks,
+
+-Sajed 
+
+
+
+[Dillo-dev]Dillo (in the) News!
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-27 18:22
+
+Hello everyone,
+
+I guess Dillo is more famous then I had imagined! We are making
+headlines! ;-)
+
+There is an article published yesterday on the Linux Journal about
+Dillo! It's a review by a Ralph Krause, made yesterday (26/02/2002):
+http://www.linuxjournal.com/article.php?sid=5847
+
+I caught this link from the front page of NewsForge (newsforge.net):
+http://www.newsforge.com/article.pl?sid=02/02/26/2358247&mode=thread
+
+And another article mentions Dillo, made by Kevin Reichard at
+BrowserWatch:
+http://browserwatch.internet.com/news/stories2002/news-20020122-4.html
+
+I don't know if Dillo is still too "ripe" for this kind of
+attention, but, as the saying goes: "Bad press is better then no
+press"! ;-)
+
+Congratulations to all Dillo developers! Hope we grow a lot more
+this year and make more users (and headlines ;).
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-27 15:21
+
+Sebastian (Leske),
+
+> >
+> > g_strtod() from glib does almost the same. It tries to call strtod
+> > with the current locale and if that fails it does the above trick.
+> >
+> > J=F6rgen
+>
+> I fear that is not the proper way to do it; strtod may work with the
+> correct locale, but produce incorrect results. You cannot expect it to
+> fail when used with the wrong locale.
+> Example:
+> "1.001" would be a correct string representation of a decimal number in
+> both the C and the DE locale, but in C it would mean 1.001 (e.g. 1 +
+> 1/1000), whereas in DE it would mean 1,001 (e.g. 1000 + 1), since in
+> German, the dot is used to make big numbers more readable (like the
+> comma in English).
+>
+> So I think you really need to explicitly disable the locale for parsing
+> the conf file.
+
+I just commited a patch to the CVS, please check if it solves
+the problem as I can't reproduce it here.
+
+Thanks
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Makefile problem??
+
+From: John Utz <john@ut...> - 2002-02-26 17:19
+
+you need gnu make it's available as a pkg called gmake
+
+On Mon, 25 Feb 2002, Yu-Fong Cho wrote:
+
+> Hi,
+> 
+> This is not an exact development question.
+> 
+> I downloaded Dillo 0.64 from sourceforge ftp and tried to compile it on
+> FreeBSD 4.5.
+> Everytime it said:
+> 
+> "Makefile", line 306: Need an operator
+> make: fatal errors encountered -- cannot continue
+> *** Error code 1
+> 
+> Is makefile broken? or I miss something?
+> 
+> Thanks
+> 
+> 
+> Yu-Fong
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Makefile problem??
+
+From: Miklos Magyari <miklos.magyari@et...> - 2002-02-26 07:38
+
+hi,
+
+> I downloaded Dillo 0.64 from sourceforge ftp and tried to compile it on
+> FreeBSD 4.5.
+> Everytime it said:
+> 
+> "Makefile", line 306: Need an operator
+> make: fatal errors encountered -- cannot continue
+> *** Error code 1
+> 
+> Is makefile broken? or I miss something?
+
+Dillo's Makefile is not compatible with the BSD make. You have to use
+GNU make.
+
+cheers,
+Miki 
+
+
+
+[Dillo-dev]Makefile problem??
+
+From: Yu-Fong Cho <yfcho@ms...> - 2002-02-26 04:45
+
+Hi,
+
+This is not an exact development question.
+
+I downloaded Dillo 0.64 from sourceforge ftp and tried to compile it on
+FreeBSD 4.5.
+Everytime it said:
+
+"Makefile", line 306: Need an operator
+make: fatal errors encountered -- cannot continue
+*** Error code 1
+
+Is makefile broken? or I miss something?
+
+Thanks
+
+
+Yu-Fong 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Sebastian Leske <sleske@en...> - 2002-02-24 15:18
+
+Hi,
+
+> > > The proper solution, of course, would be to disable locale for
+> > > the parsing of the conf file. This can be done using the
+> > > setlocale function.=20
+[...]
+> > The way we do it in Dia:
+> >
+> > #include <locale.h>
+> > [...]
+> > char *old_locale;
+> > old_locale =3D setlocale(LC_NUMERIC, "C");
+> > [... locale-free parsing ...]
+> > setlocale(LC_NUMERIC, old_locale);
+>
+> g_strtod() from glib does almost the same. It tries to call strtod
+> with the current locale and if that fails it does the above trick.
+>
+> J=F6rgen
+
+I fear that is not the proper way to do it; strtod may work with the=20
+correct locale, but produce incorrect results. You cannot expect it to=20
+fail when used with the wrong locale.
+Example:
+"1.001" would be a correct string representation of a decimal number in=20
+both the C and the DE locale, but in C it would mean 1.001 (e.g. 1 +=20
+1/1000), whereas in DE it would mean 1,001 (e.g. 1000 + 1), since in=20
+German, the dot is used to make big numbers more readable (like the=20
+comma in English).
+
+So I think you really need to explicitly disable the locale for parsing=20
+the conf file.
+
+Greetings,
+
+Sebastian Leske 
+
+
+
+Re: [Dillo-dev][RFC] Limiting the size of Cache
+
+From: Pekka Lampila <medar@ka...> - 2002-02-23 12:49
+
+Hi,
+
+On Wed, 20 Feb 2002 15:22:58 -0300
+Livio Baldini Soares <livio@im...> wrote:
+
+> I have started writing a patch that adds a `cache_size' to Dillo's
+> options, because currently the cache has no limit, therefore,
+> everything you download gets cached into memory. I've made a very
+> premature patch, which has a few know bugs...
+
+I too looked to this issue, and even wrote little patch. Though never
+got it ready to send here. My patch has little different approach.
+
+
+> But what I want to know is, is this a wanted feature? Now that I've
+> made Dicache optional, does anyone still see Dillo hogging up RAM?
+> Before the Dicache removal, I could get 40MiB of use from Dillo after
+> a fews hours of browsing. But now the _maximum_ I've hit is 20MiB.
+
+I think this is definately needed. 20 megs can be just too much for old
+systems. And if you have fast connection (local proxy maybe), and not
+too slow machine, there is no reason to waste the memory. :)
+
+> The problem with making this patch, is that it'll eventually be an
+> overhead, especially for low cache_sizes... Maybe I'll have to try
+> harder to make a "low/no-overhead" solution.
+
+I haven't had time to test your patch (only read it through). But I
+don't think it will make too much overhead.
+
+My implementation is based on counting the references on cache entrys.
+So it has separate mode for totally disabling cache (always removes
+cache entry when no references left). This should limit the need to use
+very small cache sizes. And even with small cache size profiling looked
+very good.
+
+Another feature which could also be implemented without need to refcount
+(I think). Is prioritising the removal of cache entrys by their sizes.
+Don't know if this is usefull or not.
+
+Your patch is much more cleaner and smaller than mine. I never even
+though of doing this some other way than refcounting. Don't know what
+style should be used for final implementation.
+
+I'll try to clean up my patch tomorrow and post it here.
+
+-- 
+Pekka Lampila
+medar@ka... 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-02-23 08:00
+
+fre 2002-02-22 klockan 16.54 skrev Lars Clausen:
+> On Fri, 22 Feb 2002, Sebastian Leske wrote:
+> > Hi,
+> >=20
+> > recently I had the same problem with the font sizes.
+> > I managed to track it down, and it really is a locale problem, as Lars
+> > Clausen pointed out.
+> [...]
+> > The proper solution, of course, would be to disable locale for the
+> > parsing of the conf file. This can be done using the setlocale
+> > function. I don't know enough C to implement a patch, but there is an
+> > example for temporarily changing the locale in the glic Texinfo
+> > documentation (Main Menu / Locales / Setting the Locale ). This would
+> > probably only need minor adaption. In the meantime, I would propose to
+> > patch Dillo to deactivate locales.
+>=20
+> The way we do it in Dia:
+>=20
+> #include <locale.h>
+> [...]
+> char *old_locale;
+> old_locale =3D setlocale(LC_NUMERIC, "C");
+> [... locale-free parsing ...]
+> setlocale(LC_NUMERIC, old_locale);
+
+g_strtod() from glib does almost the same. It tries to call strtod with
+the current locale and if that fails it does the above trick.
+
+J=F6rgen
+
+> -Lars
+>=20
+> --=20
+> Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+> "I do not agree with a word that you say, but I |----------------------=
+------
+> will defend to the death your right to say it." | Where are we going, a=
+nd
+> --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket?
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev] off-topic: font size doesn't adapt to ~/.dillo/dillorc
+
+From: higuita <higuita@GM...> - 2002-02-22 20:47
+
+On Wed, 20 Feb 2002 23:51:42 -0300, Livio Baldini Soares
+<livio@im...> wrote:> Andreas Goesele writes:
+> Guten Tag! (Hey... everyone's learning portuguese in the world lately!
+> I think I better start learning some other languages too...)
+
+hey, Portuguese is about the 4º most spoken language in the
+world, so this is a good reason to learn it ;)
+
+if we could, we spoke about 10 languages, but we have no time
+to learn then all (yet, just wait for the "uploading things to the
+brain" technology )
+
+um abraco
+
+higuita
+-- 
+One Unix to rule them all, One Resolver to find them,
+One IP to bring them all and in the zone bind them. 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-22 15:54
+
+On Fri, 22 Feb 2002, Sebastian Leske wrote:
+> Hi,
+>=20
+> recently I had the same problem with the font sizes.
+> I managed to track it down, and it really is a locale problem, as Lars
+> Clausen pointed out.
+[...]
+> The proper solution, of course, would be to disable locale for the
+> parsing of the conf file. This can be done using the setlocale
+> function. I don't know enough C to implement a patch, but there is an
+> example for temporarily changing the locale in the glic Texinfo
+> documentation (Main Menu / Locales / Setting the Locale ). This would
+> probably only need minor adaption. In the meantime, I would propose to
+> patch Dillo to deactivate locales.
+
+The way we do it in Dia:
+
+#include <locale.h>
+[...]
+char *old_locale;
+old_locale =3D setlocale(LC_NUMERIC, "C");
+[... locale-free parsing ...]
+setlocale(LC_NUMERIC, old_locale);
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+RE: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Sebastian Leske <Sebastian.Leske@bi...> - 2002-02-22 14:56
+
+Hi,
+
+recently I had the same problem with the font sizes.
+I managed to track it down, and it really is a locale problem, as Lars
+Clausen pointed out.
+
+The problem is in prefs.c, lines 159 ff. (as of Dillo 0.6.4):
+
+case DRC_TOKEN_FONT_FACTOR:
+prefs.font_factor =3D strtod(scanner->value.v_string, NULL);
+break;
+
+As you can see, Dillo uses the strtod function from the C library to pars=
+e
+the string you supply as a font factor.
+As the manpage for strtod states:
+
+The expected form of the string is optional leading white
+space as checked by isspace(3), an optional plus (``+'')
+or minus sign (``-'') followed by a sequence of digits
+optionally containing a decimal-point character, option=AD
+ally followed by an exponent.
+[...]=20
+If the locale is not "C" or "POSIX", different formats may be
+used.
+
+Note the last line!
+In this case, the user used a locale setting where the decimal separator
+character is not a point ".", as in English. Therefore Dillo cannot parse
+a floating point number using "." .=20
+
+Workaround:
+Using a comma instead of a point does not seem to work, maybe other parts
+of Dillo expect a point. What does work is to disable locales (which are
+not really used anyway at the moment).=20
+To do this:
+
+either
+
+* execute
+unset LANG LC_ALL LANGUAGE LC_NUMERIC
+before starting Dillo (this will only affect the terminal window where
+you type this). If you put it in a script, like this:
+
+#!/bin/sh
+unset LANG LC_ALL LANGUAGE LC_NUMERIC
+exec dillo
+
+you can run Dillo through this wrapper, and nothing else will be distur=
+bed
+
+or=20
+
+* patch Dillo not to use locale:
+In dillo.c , comment out or delete the line containing
+gtk_set_locale (in Dillo 0.6.4 it's line 70).
+
+The proper solution, of course, would be to disable locale for the parsin=
+g
+of the conf file. This can be done using the setlocale function. I don't
+know enough C to implement a patch, but there is an example for
+temporarily changing the locale in the glic Texinfo documentation (Main
+Menu / Locales / Setting the Locale ).
+This would probably only need minor adaption. In the meantime, I would
+propose to patch Dillo to deactivate locales.
+
+Greetings,
+
+Sebastian Leske 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Andreas Goesele <Goesele@hf...> - 2002-02-21 20:19
+
+Lars Clausen <lrclause@cs.uiuc.edu> writes:
+
+> On 21 Feb 2002, Andreas Goesele wrote:
+
+> > I now see that it is a locale problem: If I move from de_DE to C dillo
+> > shows the right font sizes. (I recompiled my dillo 0.6.1 and it's not
+> > affected: It shows independently from the locale setting the right
+> > size.)
+> 
+> Sounds like the problem we had in Dia a while back: Numbers are parsed
+> according to the locale, however sometimes you don't want that. Try
+> setting
+> 
+> font_factor=2,0
+> 
+> (I believe German uses the comma for the decimal separator, right?). The
+> correct way to fix this in Dillo would be to set the locale to C just
+> before parsing the prefs.
+
+Yes, German uses the comma for the decimal separator. But using it in
+the font_factor doesn't help. Starting dillo then gives the following
+output:
+
+Setting locale to de_DE
+dillorc:24: unexpected character `1', expected string constant
+dillorc:24: unexpected character `,', expected symbol
+dillorc:24: unexpected character `8', expected symbol
+
+And I already had hoped this would be a workaround ...
+
+Andreas Goesele 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-21 18:08
+
+On 21 Feb 2002, Andreas Goesele wrote:
+> Livio Baldini Soares <livio@im...> writes:
+>=20
+>> and see if you get any fonts available. But, hey, these are only
+>> guesses too.
+>=20
+> I now see that it is a locale problem: If I move from de_DE to C dillo
+> shows the right font sizes. (I recompiled my dillo 0.6.1 and it's not
+> affected: It shows independently from the locale setting the right
+> size.)
+
+Sounds like the problem we had in Dia a while back: Numbers are parsed
+according to the locale, however sometimes you don't want that. Try
+setting
+
+font_factor=3D2,0
+
+(I believe German uses the comma for the decimal separator, right?). The
+correct way to fix this in Dillo would be to set the locale to C just
+before parsing the prefs.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+[Dillo-dev]Excellent Browser! (fwd)
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-21 13:13
+
+---------- Forwarded message ----------
+Date: Mon, 18 Feb 2002 07:20:29 -0600
+From: ron <ronlankford@at...>
+To: jcid@us...
+Subject: Excellent Browser!
+
+
+I just wanted to take a moment to say what an excellent
+browser you and your Dillo team have put together. I found
+out about Dillo from the XFce site.
+
+With the help of some documentation from a newbie site, I
+was able to compile Dillo after loading a few libraries,
+and was surprised at how easy the process was. Dillo IS a
+very fast browser. Dillo and XFce make my old Pentium I
+machine usable again, and my Pentium III is really fast
+with the two of them.
+
+I was surprised at the functionality of Dillo...you said
+version 0.6.4 is alpha code, but for viewing and navigating
+web pages, it is very stable and (again) fast! The
+about:splash screen and the dillorc file make configuring
+Dillo easy.
+
+Again, many thanks to the Dillo team for a most excellent
+project. Please keep up the good work.
+
+Ron. 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Martin Samuelsson <cosis@ly...> - 2002-02-21 04:57
+
+On Thu, Feb 21, 2002 at 04:22:16AM +0100, Andreas Goesele wrote:
+> > http://www.ime.usp.br/~livio/dillo/patches/check_font_factor.diff
+> 
+> Actually I wanted to move to precompiled binaries ...
+
+did you deinstall gcc?
+
+try cutting and pasting the following lines as root.
+
+cd /usr/src
+wget http://www.ime.usp.br/~livio/dillo/patches/check_font_factor.diff
+apt-get source dillo
+cd dillo*
+patch -p1 < ../check_font_factor.diff
+dpkg-buildpackage
+cd ..
+dpkg -i dillo*deb 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Andreas Goesele <Goesele@hf...> - 2002-02-21 03:25
+
+Livio Baldini Soares <livio@im...> writes:
+
+> Guten Tag! (Hey... everyone's learning portuguese in the world lately! =
+I
+> think I better start learning some other languages too...)
+
+Tr=EAs n=E3o bastam? :-)
+=20
+> > Anything else I could try?
+>=20
+> Well, you can try this patch (against Dillo 0.6.4):
+> http://www.ime.usp.br/~livio/dillo/patches/check_font_factor.diff
+
+Actually I wanted to move to precompiled binaries ...
+=20
+> It will spill out one or maybe two different types of messages.
+> It will always print out what's the value of prefs.font_factor. It
+> should be the same as in the dillorc.
+>=20
+> The second message will only appear if Dillo can't load the desired
+> font. It should spill out the name of the font which it tried to
+> search for. My guess is that probably you don't have any iso8859-1
+> fonts installed.
+>=20
+> You could try doing something like:
+
+> # xlsfonts | grep iso8859-1 | grep helvetica
+
+$ xlsfonts | grep iso8859-1$ | grep -c helvetica
+120
+
+> and see if you get any fonts available. But, hey, these are only
+> guesses too.
+
+I now see that it is a locale problem: If I move from de_DE to C dillo
+shows the right font sizes. (I recompiled my dillo 0.6.1 and it's not
+affected: It shows independently from the locale setting the right
+size.)
+
+Does it still make sense to compile dillo with your patch?
+
+Mais uma vez: Obrigado!
+
+Andreas Goesele 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-21 02:51
+
+Andreas Goesele writes:
+> Olá Livio,
+
+Guten Tag! (Hey... everyone's learning portuguese in the world lately! I
+think I better start learning some other languages too...)
+
+> Livio Baldini Soares <livio@im...> writes:
+
+[...]
+
+> > What bugs me though is that you said that the dillorc worked in
+> > 0.6.1, so that's probably not the problem.
+> > 
+> > Did you try various values to font_factor, even extreme ones like:
+> > 
+> > font_factor=4.0
+> > font_factor=0.6 # this one should be unreadably tiny
+> 
+> Tried those, no effect.
+> 
+> > I'm just shooting in the dark here, though, cause I can't see where
+> > the problem could be.
+> 
+> Anything else I could try?
+
+Well, you can try this patch (against Dillo 0.6.4):
+http://www.ime.usp.br/~livio/dillo/patches/check_font_factor.diff
+
+It will spill out one or maybe two different types of messages.
+It will always print out what's the value of prefs.font_factor. It
+should be the same as in the dillorc.
+
+The second message will only appear if Dillo can't load the desired
+font. It should spill out the name of the font which it tried to
+search for. My guess is that probably you don't have any iso8859-1
+fonts installed.
+
+You could try doing something like:
+
+# xlsfonts | grep iso8859-1
+
+or, more specifically:
+
+# xlsfonts | grep iso8859-1 | grep helvetica
+
+and see if you get any fonts available. But, hey, these are only
+guesses too.
+
+> Obrigado!
+
+Bitte schön!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Andreas Goesele <Goesele@hf...> - 2002-02-21 02:21
+
+Jorge Arellano Cid <jcid@em...> writes:
+
+> On 21 Feb 2002, Andreas Goesele wrote:
+
+> > I recently moved to dillo 0.6.4 (Debian package) from 0.6.1 (self
+> > compiled).
+> >
+> > 0.6.1 respected the font_factor setting in ~/.dillo/dillorc, 0.6.4
+> > doesn't. Is this a bug (as I assume), or is there some way to get
+> > 0.6.4 to honor the font_factor setting.
+> 
+> It works perfect here.
+> 
+> If 0.6.1 still works for you (with the same dillorc), I'm
+> puzzled...
+
+I recompiled 0.6.1 and the font_factor is heeded if I start this
+version.
+
+> If not, check the spellings, the font factor to use a period,
+> and the font to be installed.
+
+How could I check the font to be installed?
+
+Thanks!
+
+Andreas Goesele 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Andreas Goesele <Goesele@hf...> - 2002-02-21 02:12
+
+Ol=E1 Livio,
+
+Livio Baldini Soares <livio@im...> writes:
+
+> This is awfully odd. I have 0.6.4-1 from Debian Woody installed here
+> at home and it seems to be working just fine (the font_factor, I
+> mean). Also, we haven't had any complaints about this particular issue
+> before...
+>=20
+> Well, just to sort out some obvious mistakes:
+>=20
+> [1] Make sure you are changing ~/.dillo/dillorc and not /etc/dillorc
+> (the latter is only parsed if the first doesn't exist!)
+
+I'm changing ~/.dillo/dillorc and I'm shure that it is parsed, as the
+geometry setting is heeded.
+
+> [2] The font_factor which is active is the _last_ font_factor defined
+> in the dillorc file. So:
+>=20
+> font_factor=3D2.0
+> font_factor=3D1.0
+>=20
+> Gives you a final font_factor containing `1.0'.
+
+There's only one font_factor line in dillorc
+
+> What bugs me though is that you said that the dillorc worked in
+> 0.6.1, so that's probably not the problem.
+>=20
+> Did you try various values to font_factor, even extreme ones like:
+>=20
+> font_factor=3D4.0
+> font_factor=3D0.6 # this one should be unreadably tiny
+
+Tried those, no effect.
+
+> I'm just shooting in the dark here, though, cause I can't see where
+> the problem could be.
+
+Anything else I could try?
+
+> best of luck!
+
+Obrigado!
+
+Andreas Goesele 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-21 01:45
+
+Andreas Goesele writes:
+> Hi,
+
+Hello Andreas!
+
+> I recently moved to dillo 0.6.4 (Debian package) from 0.6.1 (self
+> compiled).
+> 
+> 0.6.1 respected the font_factor setting in ~/.dillo/dillorc, 0.6.4
+> doesn't. Is this a bug (as I assume), or is there some way to get
+> 0.6.4 to honor the font_factor setting.
+
+This is awfully odd. I have 0.6.4-1 from Debian Woody installed here
+at home and it seems to be working just fine (the font_factor, I
+mean). Also, we haven't had any complaints about this particular issue
+before...
+
+Well, just to sort out some obvious mistakes:
+
+[1] Make sure you are changing ~/.dillo/dillorc and not /etc/dillorc
+(the latter is only parsed if the first doesn't exist!)
+
+[2] The font_factor which is active is the _last_ font_factor defined
+in the dillorc file. So:
+
+font_factor=2.0
+font_factor=1.0
+
+Gives you a final font_factor containing `1.0'.
+
+What bugs me though is that you said that the dillorc worked in
+0.6.1, so that's probably not the problem.
+
+Did you try various values to font_factor, even extreme ones like:
+
+font_factor=4.0
+font_factor=0.6 # this one should be unreadably tiny
+
+I'm just shooting in the dark here, though, cause I can't see where
+the problem could be.
+
+best of luck!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-21 01:39
+
+On 21 Feb 2002, Andreas Goesele wrote:
+
+> Hi,
+>
+> I recently moved to dillo 0.6.4 (Debian package) from 0.6.1 (self
+> compiled).
+>
+> 0.6.1 respected the font_factor setting in ~/.dillo/dillorc, 0.6.4
+> doesn't. Is this a bug (as I assume), or is there some way to get
+> 0.6.4 to honor the font_factor setting.
+
+It works perfect here.
+
+If 0.6.1 still works for you (with the same dillorc), I'm
+puzzled...
+
+If not, check the spellings, the font factor to use a period,
+and the font to be installed.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]font size doesn't adapt to ~/.dillo/dillorc
+
+From: Andreas Goesele <Goesele@hf...> - 2002-02-21 01:10
+
+Hi,
+
+I recently moved to dillo 0.6.4 (Debian package) from 0.6.1 (self
+compiled).
+
+0.6.1 respected the font_factor setting in ~/.dillo/dillorc, 0.6.4
+doesn't. Is this a bug (as I assume), or is there some way to get
+0.6.4 to honor the font_factor setting.
+
+Because the default fonts are way too small for me, dillo is unusable
+for me at the moment. Any suggestion would be welcome.
+
+Andreas Goesele
+
+PS: As I'm not subscribed, please include an Cc: to my e-mail address. 
+
+
+
+[Dillo-dev]Re: Help
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-20 22:35
+
+Attachments: Message as HTML      dillo-external-patch-2      Message as HTML      
+
+
+
+
+
+[Dillo-dev]Help
+
+From: Miguel Angel Hernando Fernandez <mhernand@gs...> - 2002-02-20 20:29
+
+Attachments: Message as HTML      
+
+Hello,
+I used the external vierwers patch and what I added
+was:
+IO/mime.c=20
+posteriormente esta funcion la trato de esta forma
+=20
+DwWidget* a_Mpg_video(const char *Type,void *web,
+CA_Callback_t *Call, void **Data)
+{
+a_External_make_process("xine",*Call,*Data);
+return NULL;
+}
+
+I think something isn't working. I execute xine but it
+doesn't receive anything from the conection. What I
+think isn't working is the second parameter.
+Could you help me with this problem?. The only thing I
+try to achieve is read from the conection and pass the
+flow to xine.
+Do you have any alternative solution?. What I still
+don't get is: the secuence of the parameters and the
+way it works.
+
+Tranks
+> El vie, 15-02-2002 a las 19:21, Lars Clausen escribi=F3:
+>> On 15 Feb 2002, Miguel Angel Hernando Fernandez wrote:
+>> > Hello,
+>> > Iam a student of Informatcs in Spain and I am doing a
+>> > proyect with dillo and Compaq iPAQ.
+>> > What I intend to do is when I receive a video type:
+>> > video/mpg, I jump to a funcion that should read this
+>> > conexion and transfer everything read to a programm
+>> > that shows the video received.
+>> > This is my problem: the funcion I deal with is mime
+>> > video/mpg and I need to know a tip or funcion to allow
+>> > me to read the conection. Something like a key to
+>> > bring me back the conection FD so I can read from it.
+>> > Something like that...
+>>=20
+>> Take a look at the external viewers patch at
+>> <URL:http://shasta.cs.uiuc.edu/~lrclause/dillo-patchomatic>. It has
+>>in
+>> src/external.c a function that feeds the stream to an external
+>>program.
+>> You may be able to just set the mime type handler to point to your
+>> program.
+
+--=20
+Miguel Angel Hernando Fernandez
+Escuela Superior de Ciencias Experimentales y Tecnologicas(ESCET)
+Universidad Rey Juan Carlos 
+
+
+
+[Dillo-dev][RFC] Limiting the size of Cache
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-20 18:23
+
+Hello everyone!
+
+I have started writing a patch that adds a `cache_size' to Dillo's
+options, because currently the cache has no limit, therefore,
+everything you download gets cached into memory. I've made a very
+premature patch, which has a few know bugs...
+
+But what I want to know is, is this a wanted feature? Now that I've
+made Dicache optional, does anyone still see Dillo hogging up RAM?
+Before the Dicache removal, I could get 40MiB of use from Dillo after
+a fews hours of browsing. But now the _maximum_ I've hit is 20MiB.
+(which isn't a lot, if you consider that Netscape 4.77 here at home
+eats 20Mib if I _only_ open freshmeat.net and slashdot.org :(
+
+The problem with making this patch, is that it'll eventually be an
+overhead, especially for low cache_sizes... Maybe I'll have to try
+harder to make a "low/no-overhead" solution.
+
+What are the opinions of the Dillo users/developers?
+
+The patch is at (against _today's_ cvs, 20-Feb-2002, I've made some
+changes to the cache module, so it won't work with prior versions of
+Dillo):
+
+http://www.ime.usp.br/~livio/dillo/patches/cache-size-limit.diff
+
+Missing from the patch is the option in dillorc. As said, the option
+is `cache_size' and should contain number of _bytes_. If no option is
+given in the dillorc, cache_size gets set to 3145728 (3MiB). So if you
+can 5MiB of cache, just do:
+
+cache_size=5242880
+
+Or if you want to set it up zero, just do:
+
+cache_size=00 #just plain `0' will make the parser yell :(
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Return of Patch-o-matic!
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-19 00:07
+
+On Tue, 12 Feb 2002, Andreas Schweitzer wrote:
+> On Tue, Feb 12, 2002 at 08:30:03PM -0600, Lars Clausen wrote:
+>>=20
+>> Since the old patchomatic site seems to be gone to a happier place, I'=
+ve
+>> started to make a replacement. It's not as prettily laid out, but on
+>> the
+>=20
+> Cool !
+>=20
+> Can I actually update my patch via the web ?
+
+No, that would need more interface (esp. authentication) than I feel like
+putting in right now.
+
+> Also, it is not quite clear what patch-error and compile-error
+> imply. Does the process actually stop when there are patch errors ?
+> Or do you try to compile anyways ?
+
+I've cleared that up. After a patch-error compiling would be rather
+pointless.=20
+
+> Because my patch has a compile error (for one version) and I cannot
+> tell why mine fails - possibly because the patching failed before (whic=
+h
+> most likely happened) ?
+
+This is now fixed.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+[Dillo-dev]Referer patch
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-19 00:00
+
+Attachments: Message as HTML      dillo-referer-patch      Message as HTML      
+
+
+
+
+
+Re: [Dillo-dev][RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Jyri Jokinen <autumn.rider@su...> - 2002-02-18 17:05
+
+On Mon, Feb 18, 2002 at 12:17:54PM -0300, Livio Baldini Soares wrote:
+> Jyri, I hope (and expect) this helps you a bit with respect to
+> CPU-hogging. 
+
+It's much better, thank you. Can hardly tell a difference between normal
+and patched.
+
+Thank you again.
+
+-- 
+jyri jokinen 
+
+
+
+Re: [Dillo-dev][RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-18 15:18
+
+Hello!
+
+Jorge Arellano Cid writes:
+>
+> > So what? What's this poll() have to do with anything? Well the
+> > poll() system call is using in Glib's main loop when you register a IO
+> > watch via g_io_add_watch(). AND Glib has a (stupid) behavior of
+> > making each poll _independent_. So, it add a distinct pollfd for each
+> > file-descriptor. Most of the time we have 2 watches on each socket
+> > (one for G_IO_IN and another for G_IO_OUT), Glib does not
+> > "concatenate" the pollfd's, so we will have two times as many fd's in
+> > poll then we have open.
+> 
+> It's not a glib problem.
+
+No, it's not a Glib problem. It's a kernel bug. Nevertheless I think
+that trying to aggroup calls with the same FD into PollFDs would be a
+smart think to do. Because we would have to copy less data into/from
+kernel-space. I imagine with an HTTP server having thousands of
+pending sockets, this may be an issue. Unfortunately I have no time to
+re-right the g_main_loop() in Glib to perform some stats. I'm still
+not convinced which method brings out more overhead.
+
+> Thanks a lot for your excellent work Livio!
+
+You're welcome! It's my pleasure... I got to look into some kernel
+stuff and learn a little more into poll()/select(). :-)
+
+> AFAIS it's a kernel bug (it had caused trouble to other apps.),
+> so I'll write a warning about it in the README file, with a
+> link to your patch, for those that can't upgrade the kernel.
+
+All right. But Jyri has mailed me about serious CPU hog-gage problems,
+and I've seen them too. To that respect, I've made the patch a _lot_
+less CPU intensive, but the code is uglier, adds about 64KiB and
+accepts of most 1024 connections. The new patch is at:
+
+http://www.ime.usp.br/~livio/dillo/patches/poll-fix-fast.diff
+
+I've tested a little and it seems to be more CPU intensive then
+normal Dillo, but by just a tad. So Jorge, if you intend to point to a
+patch in the README, please point to this one.
+
+Jyri, I hope (and expect) this helps you a bit with respect to
+CPU-hogging. 
+
+And this is my _final_ patch about this issue. I think I can try to
+contribute to Dillo better if I tackle other issues. So if anyone
+wants to improve/maintain this patch, feel free to do it.
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Facing problem while loading
+
+From: Pradeep <pradeep@nc...> - 2002-02-18 13:03
+
+Hi all,
+
+I figured out the problem , the target machine which I am using
+is SA1100 based monochrome display device , when I cross
+compiled Dillo and run it on my Customboard it gets killed ,
+that is the function gdk_draw_rgb_image does not return ,
+
+The samething works just fine for me on my iPAQ .
+
+I tried to change it to gdk_draw_gray_image , even that did not return ,
+
+Can anyone tell me what the problem could be , how to use
+gdk_draw_gray_image
+function in Dillo source , waiting for your reply .
+
+thanks,
+
+
+Pradeep
+
+
+
+
+Michael Duelli wrote:
+
+> Hi,
+>
+> I am sorry I only use the x86 platform. I have never even cross-compiled a
+> program so far!
+> So I got to admit that I was not fully aware of this bug's dimension.
+>
+> Regards,
+> Michael
+> ___________________________________
+> Michael Duelli
+> m.duelli@we...
+> http://glchess.s...net - A 3D chess interface
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]Facing problem while loading
+
+From: Michael Duelli <m.duelli@we...> - 2002-02-18 10:16
+
+Hi,
+
+I am sorry I only use the x86 platform. I have never even cross-compiled a 
+program so far!
+So I got to admit that I was not fully aware of this bug's dimension.
+
+Regards,
+Michael
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net - A 3D chess interface 
+
+
+
+[Dillo-dev]Dillo web browser compiles easily and works on Debian hppa platform!
+
+From: B. Douglas Hilton <doug.hilton@en...> - 2002-02-18 06:27
+
+I thought I would mention it, as the only browsers available
+so far appear to be Emacs, konqueror, and Lynx.
+
+Requirements:
+libglib1.2-dev
+libgtk1.2-dev
+libpng-dev
+libjpeg-dev
+xlibs-dev
+
+I just did a "./configure; make" and it built and works!
+
+Very nice - what a nifty little browser, and IMHO much
+more pretty than Lynx! Possibly the ultimate lightweight browser,
+and on a 715/80 you need all the speed you can get!
+
+http://dillo.so....net
+
+Test System: HP 9000 715/80 with Debian "testing" 
+
+
+
+Re: [Dillo-dev]Facing problem while loading
+
+From: Pradeep <pradeep@nc...> - 2002-02-18 04:08
+
+Hi ,
+
+I went throught the BUG81 , its very much the same bug ,
+on x86 dillo works fine for me also , but the problem is when
+cross compiled , I can set up an http server in the target machine
+and browse the txt files , but not for gif,png and jpg when cross
+compiled
+to SA1100 for both http request and an ordinary request .
+
+Waiting for your reply .
+
+Thanks,
+
+Pradeep
+
+
+
+Michael Duelli wrote:
+
+> Hi,
+>
+> I am using dillo on x86 and I can't see any problems directly viewing
+> gifs, jpgs or pngs via the command line, even non-html files!!
+>
+> I actually thought that this might have already been the end of BUG#81
+>
+> Am 2002-02-15, 13:06:29 schrieb(en) Pradeep:
+> > Hi all ,
+> >
+> > I have compiled Dillo for arm target , when I run dillo as
+> > it is (without file name or url) it executes , but when
+> > I open with command ./dillo some.gif or ./dillo some.png ,
+> >
+> > It gets killed some how ? I am wondering whats the problem ?
+> >
+> > Waiting for your reply ,
+> >
+> > Thanks,
+> >
+> > PRADEEP
+> >
+> >
+> >
+> >
+> > _______________________________________________
+> > Dillo-dev mailing list
+> > Dillo-dev@li...
+> > https://lists.so....net/lists/listinfo/dillo-dev
+> >
+> ___________________________________
+> Michael Duelli
+> m.duelli@we...
+> http://glchess.s...net - A 3D chess interface
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev][RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-16 16:55
+
+On Fri, 15 Feb 2002, Livio Baldini Soares wrote:
+
+> Hello Jorge and Jyri!
+
+Hi.
+
+> [I'm including the list on this issue, might be good for everyone to
+> know this, or maybe someone has a clearer view as to what's going on]
+>
+> [...]
+>
+> Linux 2.2.X series have a bug in the system call poll(). It only
+> allows the user to poll on as many files descriptors as it has
+> open. At first this seemed reasonable to me. But we will see that it
+> might be useful to not impose such a limit. This "feature"/"bug" is
+> fixed in 2.4.X kernels. Here's a piece of sys_poll() from Linux 2.2.19
+> (linux/fs/select.c):
+>
+> asmlinkage int sys_poll(struct pollfd * ufds, unsigned int nfds, long timeout)
+> {
+>
+> (...)
+> lock_kernel();
+> /* Do a sanity check on nfds ... */
+> err = -EINVAL;
+> if (nfds > current->files->max_fds)
+> goto out;
+>
+> (...)
+>
+> out:
+> if (wait)
+> free_wait(wait_table);
+> unlock_kernel();
+> return err;
+> }
+>
+> The variable current->file->max_fds is initialized during fork
+> (linux/kernel/fork.c) at copy_files() with NR_OPEN_DEFAULT ==
+> BITS_PER_LONG == 32 (on the i386). But it _might_ get expanded if the
+> parent process has a lot of file descriptors open.
+
+It's a kernel BUG!
+
+More info at:
+
+http://www.geocrawler.com/archives/3/35/1999/11/50/2931849/
+
+http://www.cs.helsinki.fi/linux/linux-kernel/2001-32/0572.html (patch)
+
+
+BTW, Changelog 2.4.9-pre4 says:
+
+"David Miller: undo poll() limit braindamage."
+
+and, FWIW, the final patch in 2.4.9 was:
+
+/* Do a sanity check on nfds ... */
+if (nfds > NR_OPEN)
+return -EINVAL;
+
+
+> So what? What's this poll() have to do with anything? Well the
+> poll() system call is using in Glib's main loop when you register a IO
+> watch via g_io_add_watch(). AND Glib has a (stupid) behavior of
+> making each poll _independent_. So, it add a distinct pollfd for each
+> file-descriptor. Most of the time we have 2 watches on each socket
+> (one for G_IO_IN and another for G_IO_OUT), Glib does not
+> "concatenate" the pollfd's, so we will have two times as many fd's in
+> poll then we have open.
+
+It's not a glib problem.
+
+Glib tries hard to be portable, and it's specially designed to
+do that. IMHO, finding and reporting a bug in glib is a very
+delicate matter.
+
+For instance: some time ago, I felt like reporting that
+_delivering events on already closed FDs_ was a bug, but thinking
+twice, and thrice, led me to think it was ok as it is, because
+some programs may need the exact information on what's been
+delivered (or happened) at lower level layers...
+
+
+> As you can see, it is not proxy related. I can reproduce this
+> easily with:
+>
+> ./strace dillo
+> or
+> gdb ./dillo
+>
+> With a site which has more than 16 distinct pictures. Observe that
+> with normal shell invocation, it will take a site with more than 128
+> distinct pictures (or have Dillo concurrently accessing 128 sockets
+> with all it's windows).
+>
+> It took me an entire day to discover what was going on with this
+> bug! :-(
+
+Thanks a lot for your excellent work Livio!
+
+> It took me another day to fix it. But I'm not sure that I have a
+> good solution for this. So I would like to hear comments from all of
+> you.
+>
+> [...]
+>
+> But I want to know is what do you guys think about this? And am I
+> correct about this bug? How do we fix it? _Should_ we fix it? Does
+> anyone see a better fix?
+
+AFAIS it's a kernel bug (it had caused trouble to other apps.),
+so I'll write a warning about it in the README file, with a
+link to your patch, for those that can't upgrade the kernel.
+
+
+Best
+Jorge.- 
+
+
+
+[Dillo-dev]Re: [RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Jyri Jokinen <autumn.rider@su...> - 2002-02-16 00:17
+
+On Sat, Feb 16, 2002 at 01:59:53AM +0200, Jyri Jokinen wrote:
+> > Yes, it fixes. It works perfectly. No more freeze-ups!
+> Tried browsing the dillo-dev mailign list archives, and CPU jumps to
+> 100% and stays there. Doesn't come down but after like 5 minutes or so.
+
+Right! This doesn't happen enymore. That's it. I'm sure we all agree by
+now that i'm going to take a good night sleep, and try this all again
+tomorrow after work and a nice afternoon nap. Sorry for all the lint.
+
+-- 
+jyri jokinen
+say no to spam - http://www.politik-digital.de/spam/ 
+
+
+
+Re: [Dillo-dev]Re: [RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Jyri Jokinen <autumn.rider@su...> - 2002-02-16 00:05
+
+On Sat, Feb 16, 2002 at 01:17:30AM +0200, Jyri Jokinen wrote:
+> > [ livio writes: ]
+> > My patch is at (against todays CVS):
+> > http://www.ime.usp.br/~livio/dillo/patches/poll-fix.diff
+> > Jyri, this patch fixes my problems here, do they fix yours?
+
+> Yes, it fixes. It works perfectly. No more freeze-ups!
+
+Then again, the first impression might be decieving...
+
+I tried surfing a bit more.. patch does fix the problem with
+http://www.openssl.org, but makes other pages work unnice.
+
+Tried browsing the dillo-dev mailign list archives, and CPU jumps to
+100% and stays there. Doesn't come down but after like 5 minutes or so.
+
+Oh well, attleast it doesn't freeze anymore.
+
+Want to try out the mailing list archives Livio? Do you get the same?
+
+-- 
+jyri jokinen
+say no to spam - http://www.politik-digital.de/spam/ 
+
+
+
+[Dillo-dev]Re: [RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Jyri Jokinen <autumn.rider@su...> - 2002-02-15 23:23
+
+On Fri, Feb 15, 2002 at 06:34:38PM -0300, Livio Baldini Soares wrote:
+> Some days ago, Jorge asked me to look up a (very good) bug report
+> from Jyri. He even had the trouble to make a page:
+> http://surffi.net/~arider/dillo/
+
+... that lacks some important things I see now. No kernel version.. no,
+actually, not even an indicator it's Linux in question. Maybe next time.
+
+Good thing there were smart people reading it.
+
+> My patch is at (against todays CVS):
+> http://www.ime.usp.br/~livio/dillo/patches/poll-fix.diff
+> Jyri, this patch fixes my problems here, do they fix yours?
+
+Yes, it fixes. It works perfectly. No more freeze-ups!
+
+Thank you Livio for taking so much of your time and effort into this.
+
+-- 
+jyri jokinen
+say no to spam - http://www.politik-digital.de/spam/ 
+
+
+
+[Dillo-dev][RFC][PATH] Bug with "Dillo" in Linux 2.2.X and Glib
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-15 21:34
+
+Hello Jorge and Jyri!
+
+[I'm including the list on this issue, might be good for everyone to
+know this, or maybe someone has a clearer view as to what's going on]
+
+Some days ago, Jorge asked me to look up a (very good) bug report
+from Jyri. He even had the trouble to make a page:
+http://surffi.net/~arider/dillo/
+
+The bug report so so detailed, I thought.. this one will be a piece
+of cake! To cut a long story short, it wasn't. I have browsed sources
+from Linux kernel 2.2.19 and 2.4.17, Glib 1.2 and 1.3, strace,
+bash... and then I discovered the error.. it's not pretty.
+
+So the problem is the following: 
+
+Linux 2.2.X series have a bug in the system call poll(). It only
+allows the user to poll on as many files descriptors as it has
+open. At first this seemed reasonable to me. But we will see that it
+might be useful to not impose such a limit. This "feature"/"bug" is
+fixed in 2.4.X kernels. Here's a piece of sys_poll() from Linux 2.2.19
+(linux/fs/select.c):
+
+asmlinkage int sys_poll(struct pollfd * ufds, unsigned int nfds, long timeout)
+{
+
+(...)
+lock_kernel();
+/* Do a sanity check on nfds ... */
+err = -EINVAL;
+if (nfds > current->files->max_fds)
+goto out;
+
+(...)
+
+out:
+if (wait)
+free_wait(wait_table);
+unlock_kernel();
+return err;
+}
+
+The variable current->file->max_fds is initialized during fork
+(linux/kernel/fork.c) at copy_files() with NR_OPEN_DEFAULT ==
+BITS_PER_LONG == 32 (on the i386). But it _might_ get expanded if the
+parent process has a lot of file descriptors open.
+
+So what? What's this poll() have to do with anything? Well the
+poll() system call is using in Glib's main loop when you register a IO
+watch via g_io_add_watch(). AND Glib has a (stupid) behavior of
+making each poll _independent_. So, it add a distinct pollfd for each
+file-descriptor. Most of the time we have 2 watches on each socket
+(one for G_IO_IN and another for G_IO_OUT), Glib does not
+"concatenate" the pollfd's, so we will have two times as many fd's in
+poll then we have open.
+
+As you can see, it is not proxy related. I can reproduce this
+easily with:
+
+./strace dillo
+or
+gdb ./dillo
+
+With a site which has more than 16 distinct pictures. Observe that
+with normal shell invocation, it will take a site with more than 128
+distinct pictures (or have Dillo concurrently accessing 128 sockets
+with all it's windows).
+
+It took me an entire day to discover what was going on with this
+bug! :-( 
+
+It took me another day to fix it. But I'm not sure that I have a
+good solution for this. So I would like to hear comments from all of
+you.
+
+Solution 1) Glib let's you replace the poll() function by anything
+else you desire. So I thought of making a wrapper around poll(), which
+would get the fd_array from GLib's main loop, look for matching
+file-descriptors and OR the events. The call poll. Get the result and
+see which revents do we set.
+
+I did not choose this solution. It seems like too much of an
+overhead, analyzing _every_ poll. And believe if you've ever seen a
+strace output on Dillo, it's probably the most called syscall...
+(heheh just for, here is the output of:
+# cat /tmp/dillo.strace | cut -f 1 -d'(' | sort | uniq -c | sort -r | head -10
+
+34610 gettimeofday
+17630 poll
+17541 ioctl
+2317 read
+608 write
+364 select
+303 writev
+227 fcntl
+134 brk
+131 readv
+
+Solution 2) Define a new gio. This is the solution I chose. I've
+copied giounix.c from the newest stable (1.2.10) and made an
+giodillo.c. I have had to change most of the functions so that we
+would register one pollfd per file-descriptor. This seems that some
+watches shared pollfd, and caused the implementation to look a little
+ugly...
+
+
+My patch is at (against todays CVS):
+http://www.ime.usp.br/~livio/dillo/patches/poll-fix.diff
+
+It's kind of big (11Kib) because it introduces the module
+giodillo.[ch]. But as you can see it changes only one line in IO.c and
+another in http.c
+
+Jyri, this patch fixes my problems here, do they fix yours?
+
+But I want to know is what do you guys think about this? And am I
+correct about this bug? How do we fix it? _Should_ we fix it? Does
+anyone see a better fix?
+
+Any comments an this issue is appreciated.
+
+best regards to all,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]help
+
+From: Miguel Angel Hernando Fernandez <mhernand@gs...> - 2002-02-15 21:01
+
+Attachments: Message as HTML      
+
+El vie, 15-02-2002 a las 19:21, Lars Clausen escribi=F3:
+> On 15 Feb 2002, Miguel Angel Hernando Fernandez wrote:
+> > Hello,
+> > Iam a student of Informatcs in Spain and I am doing a
+> > proyect with dillo and Compaq iPAQ.
+> > What I intend to do is when I receive a video type:
+> > video/mpg, I jump to a funcion that should read this
+> > conexion and transfer everything read to a programm
+> > that shows the video received.
+> > This is my problem: the funcion I deal with is mime
+> > video/mpg and I need to know a tip or funcion to allow
+> > me to read the conection. Something like a key to
+> > bring me back the conection FD so I can read from it.
+> > Something like that...
+>=20
+> Take a look at the external viewers patch at
+> <URL:http://shasta.cs.uiuc.edu/~lrclause/dillo-patchomatic>. It has in
+> src/external.c a function that feeds the stream to an external program.
+> You may be able to just set the mime type handler to point to your progra=
+m.
+>=20
+> -Lars
+With a_External_make_process??, What params??
+What CA_Callback??.
+
+Thank you very much.
+--=20
+Miguel Angel Hernando Fernandez
+Escuela Superior de Ciencias Experimentales y Tecnologicas(ESCET)
+Universidad Rey Juan Carlos 
+
+
+
+Re: [Dillo-dev]Facing problem while loading
+
+From: Michael Duelli <m.duelli@we...> - 2002-02-15 18:27
+
+Hi,
+
+I am using dillo on x86 and I can't see any problems directly viewing 
+gifs, jpgs or pngs via the command line, even non-html files!!
+
+I actually thought that this might have already been the end of BUG#81
+
+Am 2002-02-15, 13:06:29 schrieb(en) Pradeep:
+> Hi all ,
+> 
+> I have compiled Dillo for arm target , when I run dillo as
+> it is (without file name or url) it executes , but when
+> I open with command ./dillo some.gif or ./dillo some.png ,
+> 
+> It gets killed some how ? I am wondering whats the problem ?
+> 
+> Waiting for your reply ,
+> 
+> Thanks,
+> 
+> PRADEEP
+> 
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net - A 3D chess interface 
+
+
+
+Re: [Dillo-dev]help
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-15 18:22
+
+On 15 Feb 2002, Miguel Angel Hernando Fernandez wrote:
+> Hello,
+> Iam a student of Informatcs in Spain and I am doing a
+> proyect with dillo and Compaq iPAQ.
+> What I intend to do is when I receive a video type:
+> video/mpg, I jump to a funcion that should read this
+> conexion and transfer everything read to a programm
+> that shows the video received.
+> This is my problem: the funcion I deal with is mime
+> video/mpg and I need to know a tip or funcion to allow
+> me to read the conection. Something like a key to
+> bring me back the conection FD so I can read from it.
+> Something like that...
+
+Take a look at the external viewers patch at
+<URL:http://shasta.cs.uiuc.edu/~lrclause/dillo-patchomatic>. It has in
+src/external.c a function that feeds the stream to an external program.
+You may be able to just set the mime type handler to point to your progra=
+m.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+[Dillo-dev]help
+
+From: Miguel Angel Hernando Fernandez <mhernand@gs...> - 2002-02-15 17:43
+
+Attachments: Message as HTML      
+
+Hello,
+Iam a student of Informatcs in Spain and I am doing a
+proyect with dillo and Compaq iPAQ.
+What I intend to do is when I receive a video type:
+video/mpg, I jump to a funcion that should read this
+conexion and transfer everything read to a programm
+that shows the video received.
+This is my problem: the funcion I deal with is mime
+video/mpg and I need to know a tip or funcion to allow
+me to read the conection. Something like a key to
+bring me back the conection FD so I can read from it.
+Something like that...
+Thank you very much.
+--=20
+Miguel Angel Hernando Fernandez
+Escuela Superior de Ciencias Experimentales y Tecnologicas(ESCET)
+Universidad Rey Juan Carlos 
+
+
+
+[Dillo-dev]Facing problem while loading
+
+From: Pradeep <pradeep@nc...> - 2002-02-15 12:07
+
+Hi all ,
+
+I have compiled Dillo for arm target , when I run dillo as
+it is (without file name or url) it executes , but when
+I open with command ./dillo some.gif or ./dillo some.png ,
+
+It gets killed some how ? I am wondering whats the problem ?
+
+Waiting for your reply ,
+
+Thanks,
+
+PRADEEP 
+
+
+
+Re: [Dillo-dev]spaces in URL
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-15 01:13
+
+Ok, I understand that we don't want to put too much efforts to support br=
+oken
+html all right
+But not supporting borken html _on_purpose_ is kind of different. Here it=
+'s
+almost the same code (so it's not a "bloating issue") to fix either all u=
+rls
+(even comming from the page itself) or the location bar only.
+I'm not sure we want to put too much effort to prevent broken pages to be
+displayed either.
+
+Best,
+Eric
+
+On 13-Feb-2002 Livio Baldini Soares wrote:
+> Hi Eric & people,
+>=20
+> Eric GAUDET writes:
+>> Jorge,
+>> I get your point about not supporting broken html. However, somebody i=
+n the
+>> list pointed that pasting a URL from a text source (say an email forma=
+tted
+>> to
+>> 80 characters wide) often leaded to \n characters in the string, which=
+is a
+>> annoyance common enough so you might want to reconsider including Livi=
+o=B4s
+>> patch.
+>=20
+> Yeah, but Livio is doing it the wrong way! This has moved from the
+> URL/HTML realm to the UI-space. Therefore Livio's patch is not the way
+> to go about fixing this issue... but my new patch, for instance, I
+> think is something completely allowable in Dillo.
+>=20
+> All I do is rip the "illegal" chars from the URL coming from an
+> _entry_ in Dillo's interface. This would take care of pasting and
+> accidentally hitting space. _Plus_ it prevents Dillo from sending out
+> bogus URLs to HTTP servers out there (heheh.. not really ;).
+>=20
+> I'm sending this for comments, since it's a small patch.
+>=20
+> PS: Does anyone think I should rip out _all_ the chars considered
+> illegal from RFC-2396, or just these which I've selected?
+>=20
+> best regards,
+>=20
+> -- =20
+> Livio <livio@im...>
+
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 14-Feb-2002 Time: 17:07:58
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!=
+"
+------------------------------------------------------------------- 
+
+
+
+Re: [Dillo-dev]spaces in URL
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-15 00:35
+
+Hi there!
+
+> Eric GAUDET writes:
+> > Jorge,
+> > I get your point about not supporting broken html. However, somebody in=
+the
+> > list pointed that pasting a URL from a text source (say an email format=
+ted to
+> > 80 characters wide) often leaded to \n characters in the string, which =
+is a
+> > annoyance common enough so you might want to reconsider including Livio=
+=B4s patch.
+
+I agree, and as Livio points:
+
+> [Livio writes :)]
+> Yeah, but Livio is doing it the wrong way! This has moved from the
+> URL/HTML realm to the UI-space. Therefore Livio's patch is not the way
+> to go about fixing this issue... but my new patch, for instance, I
+> think is something completely allowable in Dillo.
+
+Bingo! The UI-space.
+
+> All I do is rip the "illegal" chars from the URL coming from an
+> _entry_ in Dillo's interface. This would take care of pasting and
+> accidentally hitting space. _Plus_ it prevents Dillo from sending out
+> bogus URLs to HTTP servers out there (heheh.. not really ;).
+>
+> I'm sending this for comments, since it's a small patch.
+>
+> PS: Does anyone think I should rip out _all_ the chars considered
+> illegal from RFC-2396, or just these which I've selected?
+
+I think it's OK as it solves the main problem of pasting...
+
+BTW: it's on CVS.
+
+One thing more:
+
+> [Livio writes]
+>
+> Well because a_Url_new() processes _all_ URLs inside Dillo. So if
+> Dillo doesn't want to support broken HTML my proposed changes can't go
+> in a_Url_new(). As a matter of fact, now that you mention it, these two
+> lines are broken from a_Url_new():url.c:
+>
+> /* ensure no leading whitespace */
+> for (urlstring =3D (gchar *)url_str; isspace(*urlstring); ++urlstring);
+>
+> They should be _removed_, if we want to be consistent.
+>
+> I inserted the "clean" to URLs in the Interface part, because that's
+> where it's supposed to be if we want to be strict with the HTML pages
+> and not the user (I believe that there is no such thing as a broken
+> user... ;).
+
+That was a side effect of a not yet finished Html_get_attr2();
+the SPEC says the user-agent MAY strip leading and trailig white
+space from CDATA, and as I prefered to strip, I left the
+stripping code inside the URI parser for the interim.
+
+Well, now I finished Html_get_attr2() and removed the stripping
+from url.c.
+
+> Jorge, this patch cleans the whitespace removal from
+> a_Url_new(). With the previous patch I've sent (to "clean" URLs in
+> a_Interface_entry_open_url()) this removal is correct, I think.
+>
+> Attached is the 2-liner.
+
+That patch leaves 'urlstring' uninitialized...
+
+But don't worry, the CVS has all of these updated,
+just hope it works! ;)
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Broken CVS -- fontname selection
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-14 17:03
+
+Attachments: font-typo.diff      
+
+Howdy,
+
+with today's CVS, if your dillorc doesn't have the vw_fontname set,
+Dillo gets a SegV right at the start. It took me about 10-20 minutes to
+find the typo which caused the problem. prefs.vw_fontname is NULL
+because it's not correctly declared in a_Prefs_init():prefs.c.
+
+The following patch fixes the typo and adds NULL check for font name
+in Dw_style_font_new_internal(). It still exits, but it exits spitting
+out useful information for detecting the problem. By The Way, the
+actual SegV comes from inside g_str_hash() from Glib, which can't
+handle NULL pointers. 
+
+Best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]spaces in URL
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-13 20:30
+
+Attachments: url-no-clean-whites.diff      
+
+Eric GAUDET writes:
+> On 13-Feb-2002 Livio Baldini Soares wrote:
+> > Hi Eric & people,
+
+(...)
+
+> > Yeah, but Livio is doing it the wrong way! This has moved from the
+> > URL/HTML realm to the UI-space. Therefore Livio's patch is not the way
+> > to go about fixing this issue... but my new patch, for instance, I
+> > think is something completely allowable in Dillo.
+> > 
+> > All I do is rip the "illegal" chars from the URL coming from an
+> > _entry_ in Dillo's interface. This would take care of pasting and
+> > accidentally hitting space. _Plus_ it prevents Dillo from sending out
+> > bogus URLs to HTTP servers out there (heheh.. not really ;).
+> > 
+> > I'm sending this for comments, since it's a small patch.
+> 
+> Ok. Why don't you just do that in a_Url_new where you remove the leading
+> white spaces, kinda like you did before?
+
+Well because a_Url_new() processes _all_ URLs inside Dillo. So if
+Dillo doesn't want to support broken HTML my proposed changes can't go
+in a_Url_new(). As a matter of fact, now that you mention it, these two
+lines are broken from a_Url_new():url.c:
+
+/* ensure no leading whitespace */
+for (urlstring = (gchar *)url_str; isspace(*urlstring); ++urlstring);
+
+They should be _removed_, if we want to be consistent.
+
+I inserted the "clean" to URLs in the Interface part, because that's
+where it's supposed to be if we want to be strict with the HTML pages
+and not the user (I believe that there is no such thing as a broken
+user... ;).
+
+I don't want to start a flame-war about providing support for broken
+HTML (I have mixed feelings about this issue myself), but since
+Dillo's philosophy is to be strict with respect to RFCs, let's do that
+and be consistent in all places.
+
+Jorge, this patch cleans the whitespace removal from
+a_Url_new(). With the previous patch I've sent (to "clean" URLs in
+a_Interface_entry_open_url()) this removal is correct, I think.
+
+Attached is the 2-liner.
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]spaces in URL
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-13 19:33
+
+On 13-Feb-2002 Livio Baldini Soares wrote:
+> Hi Eric & people,
+>=20
+> Eric GAUDET writes:
+>> Jorge,
+>> I get your point about not supporting broken html. However, somebody i=
+n the
+>> list pointed that pasting a URL from a text source (say an email forma=
+tted
+>> to
+>> 80 characters wide) often leaded to \n characters in the string, which=
+is a
+>> annoyance common enough so you might want to reconsider including Livi=
+o=B4s
+>> patch.
+>=20
+> Yeah, but Livio is doing it the wrong way! This has moved from the
+> URL/HTML realm to the UI-space. Therefore Livio's patch is not the way
+> to go about fixing this issue... but my new patch, for instance, I
+> think is something completely allowable in Dillo.
+>=20
+> All I do is rip the "illegal" chars from the URL coming from an
+> _entry_ in Dillo's interface. This would take care of pasting and
+> accidentally hitting space. _Plus_ it prevents Dillo from sending out
+> bogus URLs to HTTP servers out there (heheh.. not really ;).
+>=20
+> I'm sending this for comments, since it's a small patch.
+
+Ok. Why don't you just do that in a_Url_new where you remove the leading
+whitepsaces, kinda like you did before?
+
+>=20
+> PS: Does anyone think I should rip out _all_ the chars considered
+> illegal from RFC-2396, or just these which I've selected?
+>=20
+> best regards,
+>=20
+> -- =20
+> Livio <livio@im...>
+
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 13-Feb-2002 Time: 11:31:14
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!=
+"
+------------------------------------------------------------------- 
+
+
+
+Re: [Dillo-dev]spaces in URL
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-13 19:04
+
+Attachments: url-entry-exclude-chars.diff      
+
+Hi Eric & people,
+
+Eric GAUDET writes:
+> Jorge,
+> I get your point about not supporting broken html. However, somebody in the
+> list pointed that pasting a URL from a text source (say an email formatted to
+> 80 characters wide) often leaded to \n characters in the string, which is a
+> annoyance common enough so you might want to reconsider including Livio´s patch.
+
+Yeah, but Livio is doing it the wrong way! This has moved from the
+URL/HTML realm to the UI-space. Therefore Livio's patch is not the way
+to go about fixing this issue... but my new patch, for instance, I
+think is something completely allowable in Dillo.
+
+All I do is rip the "illegal" chars from the URL coming from an
+_entry_ in Dillo's interface. This would take care of pasting and
+accidentally hitting space. _Plus_ it prevents Dillo from sending out
+bogus URLs to HTTP servers out there (heheh.. not really ;).
+
+I'm sending this for comments, since it's a small patch.
+
+PS: Does anyone think I should rip out _all_ the chars considered
+illegal from RFC-2396, or just these which I've selected?
+
+best regards,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Return of Patch-o-matic!
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-13 03:30
+
+Attachments: dillo-fake-id.v1.2.diff      
+
+On Tue, Feb 12, 2002 at 08:30:03PM -0600, Lars Clausen wrote:
+> 
+> Since the old patchomatic site seems to be gone to a happier place, I've
+> started to make a replacement. It's not as prettily laid out, but on the
+
+Cool !
+
+Can I actually update my patch via the web ?
+Also, it is not quite clear what patch-error and compile-error
+imply. Does the process actually stop when there are patch errors ?
+Or do you try to compile anyways ?
+Because my patch has a compile error (for one version) and I cannot
+tell why mine fails - possibly because the patching failed before (which
+most likely happened) ?
+
+I have a newer one, anyways. And for simplicity, I attach a patch
+against the current CVS version.
+
+And I completely agree with Jorge that this will never go into
+dillo. Yet, I'll keep this patch more or less up to date.
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Return of Patch-o-matic!
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-13 02:30
+
+Since the old patchomatic site seems to be gone to a happier place, I've
+started to make a replacement. It's not as prettily laid out, but on the
+other hand it will actually verify whether the patch applies and compiles=
+,
+and automatically update itself as CVS updates. Look at
+<URL:http://shasta.cs.uiuc.edu/~lrclause/dillo-patchomatic>.
+I've been scrounging around for patches, but I'm sure I didn't get all of
+them. If anybody has an interesting patch (for 0.6.0+) that I haven't
+included, please mail me!
+
+On a related note, I've noticed that several generated files are in CVS.
+That creates trouble when making a patch where you've modified a
+Makefile.am, for instance, as things like ./configure will be different.
+Could we take those out? I've even been getting conflicts in the directo=
+ry
+where I never make changes, only update and compile.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+[Dillo-dev]Description File
+
+From: Miguel Angel Hernando Fernandez <mhernand@gs...> - 2002-02-12 23:13
+
+Attachments: Message as HTML      
+
+Hello People.
+
+I am student of computer in Spain. I am having a project with dillo and
+Compaq iPAQ in my university .
+
+My question:
+
+I have one function that read of the connection http, i need the
+description file of this connection for read.What functions need???
+
+Excuse me, my English is bad :-)
+
+Thanks you
+--=20
+Miguel Angel Hernando Fernandez
+Escuela Superior de Ciencias Experimentales y Tecnologicas(ESCET)
+Universidad Rey Juan Carlos 
+
+
+
+[Dillo-dev](no subject)
+
+From: chris lapthorn <chris.lapthorn@nt...> - 2002-02-11 10:33
+
+unsubscribe Dillo-dev chrislapthorn@si... 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-10 20:16
+
+On Sun, 10 Feb 2002, Mark Schreiber wrote:
+> Thanks for the repost, Jorge!
+>=20
+> This does make more sense. I was under the impression that enter
+> always submitted in a text field in other browsers, even if there were
+> multiple fields...so I did some testing on the browsers installed on
+> my system. Turns out that I was wrong.
+>=20
+> lynx: Enter advances to the next text field
+> links: Enter advances to the next text field
+> navigator: Enter advances to the next text field
+> galeon: Enter always submits
+> mozilla: Enter always submits
+
+Oooh, data points:)
+
+w3m: Text is entered in a separate line, terminated by enter.
+konqueror: Enter always submits
+arena: Couldn't easily install this, but it would be an interesting point.
+chimera: Enter does nothing (ugh! What a nasty browser:)
+
+Cornell University Ergonomics (useful guidelines for general UI issues)
+http://ergo.human.cornell.edu/ahtutorials/interface.html
+
+There are two points of UI design that conflict here:
+
+Strive for consistency (Enter should always do the same thing)
+Reduce errors (Don't send a half-filled form)
+
+The more I think about it, the more I prefer the idea that enter submits =
+on
+the last text field only. Most forms that we want to go through quickly
+are single-textfield anyway. I'm of two minds whether enter should submi=
+t
+if there are non-text entries after the last text field.=20
+
+> Jorge Arellano Cid writes:
+>>=20
+>>=20
+>> If you're willing to implement this idea, please let me know.
+>> If not, volunteers are welcome ;). Note that this is not complex
+>> and very suitable for those of you that feel like helping.
+>=20
+> Anyway, this sounds reasonable, and I'd be happy to take a stab at a
+> patch, but I'm probably not going to get a chance for a week or so.
+> If anyone's going to be faster than that, you're welcome to beat me to
+> the punch.
+
+I'm going to look at my patch browser again. It still too flakey to real=
+ly
+use. So please go ahead and do this.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Paul <paul@sp...> - 2002-02-10 20:05
+
+What if an enter key toggled the next empty input box. When all are full,
+enter submits.
+
+-Paul
+
+On Sun, 10 Feb 2002, Jorge Arellano Cid wrote:
+
+> The point is that when facing multiple input fields, the form
+> may be submitted incomplete as a result of pressing enter after
+> filling one text entry (almost a reflex-act these days). 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Mark Schreiber <mark7@an...> - 2002-02-10 19:32
+
+Thanks for the repost, Jorge!
+
+This does make more sense. I was under the impression that enter
+always submitted in a text field in other browsers, even if there were
+multiple fields...so I did some testing on the browsers installed on
+my system. Turns out that I was wrong.
+
+lynx: Enter advances to the next text field
+links: Enter advances to the next text field
+navigator: Enter advances to the next text field
+galeon: Enter always submits
+mozilla: Enter always submits
+
+Jorge Arellano Cid writes:
+> 
+> 
+> If you're willing to implement this idea, please let me know.
+> If not, volunteers are welcome ;). Note that this is not complex
+> and very suitable for those of you that feel like helping.
+
+Anyway, this sounds reasonable, and I'd be happy to take a stab at a
+patch, but I'm probably not going to get a chance for a week or so.
+If anyone's going to be faster than that, you're welcome to beat me to
+the punch.
+
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-10 16:52
+
+Hi there,
+
+Considering that searching the mailing list archives has become
+somewhat hard, I decided to repost some things...
+
+(I hope the mailing list problems to finish when we move from
+SF, and set a new mailing list...)
+
+
+
+On 9 Feb 2002, Lars Clausen wrote:
+
+> On Sat, 9 Feb 2002, Mark Schreiber wrote:
+> > Is there a reason dillo avoids submitting a form when the enter key is
+> > pressed in a form's text field and a submit button exists?
+> >
+> > I see the code to do this, so I'd imagine that someone wanted this
+> > behavior, but I can't see the rationale, and I know that
+> > Navigator/Moz/etc always have the enter key in a text field submit the
+> > form.
+>
+> There was a discussion of this a bit back. I submitted a patch to make
+> enter always mean submit, but the official stance seems to be that enter
+> should work like tab if there's more than one text field.
+
+Actually, my original answer was:
+
+>>
+From jcid@em... Sun Feb 10 13:25:56 2002
+Date: Fri, 18 Jan 2002 21:25:23 -0300 (CLST)
+From: Jorge Arellano Cid <jcid@em...>
+To: Dillo mailing list <dillo-dev@li...>
+Subject: Re: [Dillo-dev]Forms & enter
+
+
+Lars,
+
+> I've been wondering about the design decision to make forms only submit on
+> Enter when there is no Submit button. It is obviously not becuase it would
+> be hard to code (just pick the first submit button). The specs don't
+> (AFAICS) say anything for or against it. It's certainly very practical to
+> have Enter submit input text. Why has it been explicitly coded so that it
+> only happens if there is no Submit button?
+
+The point is that when facing multiple input fields, the form
+may be submitted incomplete as a result of pressing enter after
+filling one text entry (almost a reflex-act these days).
+
+There's also another reason: as javascript is not supported,
+and as it's often used to verify form submitions, it becomes very
+important not to try to send an incomplete form.
+
+Well, that's the idea behind it, but in practice, I must
+recognize that after some tests, the current implentation is
+certainly lacking, and that forms without submit, send whatever
+they have (or not) at enter-press time. Certainly not the desired
+effect...
+
+There's also the issue of input types that don't generate enter
+presses (as selection boxes); when they lack a submit. Current
+code doesn't submit anything, and as you noticed, the SPECS don't
+throw any light on that.
+
+It'd be very handy to fix all these annoyances at once. I
+think:
+
+When there's a submit:
+
+- Only submit on enter when there's a single enter-press
+generating input ('text' and 'password').
+Note: this can be further constrained to "one and only one
+single enter-press input", but it may be overkill...
+
+
+When there's no submit:
+
+- If there's more than one single enter-press input, render the
+submit (added internally), and apply the above rules.
+
+
+If you're willing to implement this idea, please let me know.
+If not, volunteers are welcome ;). Note that this is not complex
+and very suitable for those of you that feel like helping.
+
+
+Sincerely
+Jorge.-
+<<
+
+
+Although Lars told me he "might" (!?) do it, I haven't received
+a patch that implements it as described above.
+
+Note that the described procedure allows google's form
+submition with enter (single "text" entry case).
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Doug Kearns <djkea2@mu...> - 2002-02-10 09:28
+
+On Sun, Feb 10, 2002 at 12:36:09AM -0600, John Utz wrote:
+
+<snip>
+
+> well, i feel that if there is a spec that says that it *shouldnt* work 
+> that way then to make enter do the submit would be in conflict with a 
+> core dillo objective. but, if this behavior is undefined and everybody 
+> else (meaning, 
+> NS,Opera,IE,moz, etc) has chosen to implement submit via enter well, then 
+> that seems awfully reasonable.
+> 
+> i know that it's something that *i* really miss, but i am just one 
+> person....
+
+Not without support though :-)
+
+Regards,
+Doug 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: John Utz <john@ut...> - 2002-02-10 06:36
+
+:-)
+
+On Sat, 9 Feb 2002, Mark Schreiber wrote:
+
+> Hmm...well, currently on even CVS dillo, enter doesn't advance to the
+> next field or anything. Right now, it's just a dead key...and
+> searching on google and having to go find the mouse to click submit is
+> kind of frusterating.
+
+yup! esp. after you use the submit button and then google helpfully tells
+you that all you have to do on most browsers is hit the enter key to 
+submit ( oh yeah? not on the browser *i* am running, buddy! )
+
+> So, since enter isn't currently doing anything (including advancing),
+> does anyone have a problem with it submitting? I could see this being
+> a prefs option if someone wants to have code that advances through
+> fields, and make the behavior changeable.
+
+well, i feel that if there is a spec that says that it *shouldnt* work 
+that way then to make enter do the submit would be in conflict with a 
+core dillo objective. but, if this behavior is undefined and everybody 
+else (meaning, 
+NS,Opera,IE,moz, etc) has chosen to implement submit via enter well, then 
+that seems awfully reasonable.
+
+i know that it's something that *i* really miss, but i am just one 
+person....
+
+
+> Mark Schreiber writes:
+> > Hmm...well, currently on even CVS dillo, enter doesn't advance to the
+> > next field or anything. Right now, it's just a dead key...and
+> > searching on google and having to go find the mouse to click submit is
+> > kind of frusterating.
+> > 
+> > So, since enter isn't currently doing anything (including advancing),
+> > does anyone have a problem with it submitting? I could see this being
+> > a prefs option if someone wants to have code that advances through
+> > fields, and make the behavior changeable.
+> 
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]Memory leak patch
+
+From: Mark Schreiber <mark7@an...> - 2002-02-10 04:37
+
+Attachments: dillo-leak-patch.cvsdiff.gz      Message as HTML      
+
+This patch eliminates a minor memory leak that occurs if the user
+specifies multiple proxies in their dillorc. 
+
+
+
+[Dillo-dev]Selectable fonts patch
+
+From: Mark Schreiber <mark7@an...> - 2002-02-10 04:20
+
+Attachments: dillo-fontspatch.cvsdiff.gz      Message as HTML      
+
+The attached patch lets users select their desired render font via
+dillorc instead of at compile time. 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Mark Schreiber <mark7@an...> - 2002-02-10 03:42
+
+Hmm...well, currently on even CVS dillo, enter doesn't advance to the
+next field or anything. Right now, it's just a dead key...and
+searching on google and having to go find the mouse to click submit is
+kind of frusterating.
+
+So, since enter isn't currently doing anything (including advancing),
+does anyone have a problem with it submitting? I could see this being
+a prefs option if someone wants to have code that advances through
+fields, and make the behavior changeable.
+
+Mark Schreiber writes:
+> Hmm...well, currently on even CVS dillo, enter doesn't advance to the
+> next field or anything. Right now, it's just a dead key...and
+> searching on google and having to go find the mouse to click submit is
+> kind of frusterating.
+> 
+> So, since enter isn't currently doing anything (including advancing),
+> does anyone have a problem with it submitting? I could see this being
+> a prefs option if someone wants to have code that advances through
+> fields, and make the behavior changeable.
+
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+Re: [Dillo-dev]Enter key submissions?
+
+From: Lars Clausen <lrclause@cs...> - 2002-02-10 02:50
+
+On Sat, 9 Feb 2002, Mark Schreiber wrote:
+> Is there a reason dillo avoids submitting a form when the enter key is
+> pressed in a form's text field and a submit button exists?
+>=20
+> I see the code to do this, so I'd imagine that someone wanted this
+> behavior, but I can't see the rationale, and I know that
+> Navigator/Moz/etc always have the enter key in a text field submit the
+> form.
+
+There was a discussion of this a bit back. I submitted a patch to make
+enter always mean submit, but the official stance seems to be that enter
+should work like tab if there's more than one text field.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+[Dillo-dev]Enter key submissions?
+
+From: Mark Schreiber <mark7@an...> - 2002-02-10 02:45
+
+Is there a reason dillo avoids submitting a form when the enter key is
+pressed in a form's text field and a submit button exists?
+
+I see the code to do this, so I'd imagine that someone wanted this
+behavior, but I can't see the rationale, and I know that
+Navigator/Moz/etc always have the enter key in a text field submit the
+form.
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Sam Dennis <sam@ma...> - 2002-02-09 05:23
+
+Some time around 3 o'clock AM on February 8, a Friday, Jorge Arellano Cid wrote:
+> 
+> 
+> On Thu, 7 Feb 2002, Livio Baldini Soares wrote:
+> 
+> >
+> > <A HREF="ftp://some.server.com/some/directory/Some%20Artist%20-%20Some%20Title.mp3">
+> >
+> > If I'm not mistaken (which I could, of course), anything other than
+> > this is just plain wrong.
+> >
+> > BTW: It seems Jorge has removed bug #292 from the bugtrack... Jorge
+> > what's your take on this? If you didn't like the patch, I can try to
+> > redo it...
+> 
+> The same as always Livio: to follow the standards and not to
+> try to render badly formed HTML.
+> 
+> AFAIS current code parses the href as SGML CDATA, and parses
+> the URI as RFC-2396 says afterwards.
+> 
+> If there's a SPEC, or RFC that states to remove spaces
+> from URIs, we follow.
+
+Apart from the fact that the behaviour is obviously wrong, there is evidence
+to suggest that merely encoding whitespace is the preferred behaviour in RFC
+1738, which calls a space (and various other characters) "unsafe" and suggests
+that it be encoded. This is possibly a difference between URIs and URLs?
+
+-- 
+r@,,+2 'a,kd" 
+
+
+
+[Dillo-dev]spaces in URL
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-09 04:25
+
+Jorge,
+I get your point about not supporting broken html. However, somebody in t=
+he
+list pointed that pasting a URL from a text source (say an email formatte=
+d to
+80 characters wide) often leaded to \n characters in the string, which is=
+a
+annoyance common enough so you might want to reconsider including Livio=B4=
+s patch.
+
+just my 2 cents.
+
+Best,
+------------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Le 08-Feb-2002 a 20:19:35
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-08 03:44
+
+On Thu, 7 Feb 2002, Livio Baldini Soares wrote:
+
+>
+> <A HREF="ftp://some.server.com/some/directory/Some%20Artist%20-%20Some%20Title.mp3">
+>
+> If I'm not mistaken (which I could, of course), anything other than
+> this is just plain wrong.
+>
+> BTW: It seems Jorge has removed bug #292 from the bugtrack... Jorge
+> what's your take on this? If you didn't like the patch, I can try to
+> redo it...
+
+The same as always Livio: to follow the standards and not to
+try to render badly formed HTML.
+
+AFAIS current code parses the href as SGML CDATA, and parses
+the URI as RFC-2396 says afterwards.
+
+If there's a SPEC, or RFC that states to remove spaces
+from URIs, we follow.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Pthreads broken on Solaris
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-08 01:08
+
+> things... Changing the pthread detection back to simple
+> (AC_CHECK_LIB(pthread, pthread_create)) makes Solaris happy.
+
+I have been looking into this and come to the comclusion that
+Solaris sucks ;-) .... the thing is it seems gcc on
+Solaris will link a program which has pthread_create even when
+there is no -lpthread in the linker line - try it out yourslef !
+(at least here it does do it so ....)
+
+This make things tough.
+
+Another thing is : unregogized options will simly be reported
+by gcc and do not change the exit status.
+
+That means -pthread will return an unregoginzed option but yet
+will link the very first thread test. And although solaris
+claims it could link the thing, it will not work as you asid.
+
+A radical suggestion : put 
+AC_CHECK_LIB(pthread, pthread_create)
+before any subsequent thread testing - like a "one catch all brain
+dead implementations" ...
+
+One caveat : I do have access to a solaris box - but this box
+does not have GTK or jpeg. So I can't really test dillo. I only
+could test how much configure finds.
+
+Another thing : the line that includes /usr/local/lib should be
+-L/usr/local/lib not -I/usr/local/lib - my fault.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-08 01:06
+
+Hi Ivo!
+
+Ivo van Poorten writes:
+> On Thursday 07 February 2002 00:28, Livio Baldini Soares wrote:
+
+(...)
+
+> > Paul Chamberlain, thanks for the remarks, and I think you'll be
+> > happy to know that this patch works with
+> >
+> > h t t p: / /sl as h d ot.o rg /
+> >
+> > just fine. The patch is small (1.8KiB), so I'm sending it
+> > attached. As always, comments are greatly appreciated!
+> 
+> I'm not an active developer on dillo, though I appreciate your
+> efforts alot!
+
+Thanks a lot! We're always glad to hear!
+
+> I was just wondering, what would happen to URL's like this:
+> 
+> <A HREF="ftp://some.server.com/some/directory/Some Artist - Some Title.mp3">
+> 
+> Depending on your hobbies, you will run across such links a lot. With spaces 
+> removed, the link won't work I suppose?
+
+Hehe, well, it won't work. But it shouldn't work! (At least that's
+what the RFS states). What should be done in these cases, is what's
+called `escaping', i.e. something like %HEX_CODE, so this example
+should be coded (correctly) as:
+
+<A HREF="ftp://some.server.com/some/directory/Some%20Artist%20-%20Some%20Title.mp3">
+
+If I'm not mistaken (which I could, of course), anything other than
+this is just plain wrong.
+
+BTW: It seems Jorge has removed bug #292 from the bugtrack... Jorge
+what's your take on this? If you didn't like the patch, I can try to
+redo it...
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-08 01:02
+
+On 08-Feb-2002 Ivo van Poorten wrote:
+> On Thursday 07 February 2002 00:28, Livio Baldini Soares wrote:
+>> everything lower than 0x1F, 0x7F, ' ', '<', '>', and '"'
+>>
+>> Is there a portable way of doing this? Should I ignore other chars?
+>> Oh, and this is only applied to URL's. Parsing of other kinds of
+>> attributes were left unchanged... (aiieee... I think we're going to
+>> discuss attribute parsing again? ;)
+>>
+>> Paul Chamberlain, thanks for the remarks, and I think you'll be
+>> happy to know that this patch works with
+>>
+>> h t t p: / /sl as h d ot.o rg /
+>>
+>> just fine. The patch is small (1.8KiB), so I'm sending it
+>> attached. As always, comments are greatly appreciated!
+> 
+> I'm not an active developer on dillo, though I appreciate your efforts alot!
+> I was just wondering, what would happen to URL's like this:
+> 
+> <A HREF="ftp://some.server.com/some/directory/Some Artist - Some Title.mp3">
+> 
+> Depending on your hobbies, you will run across such links a lot. With spaces 
+> removed, the link won't work I suppose?
+> 
+
+Such links are not conform with the RFC. IMHO dillo should not support this
+link.
+
+The proper way to write such a link would be to escape the forbidden characters:
+<A HREF="ftp://some.server.com/some/directory/Some Artist%20-%20Some Title.mp3">
+
+> Regards,
+> --Ivo
+> 
+> -- 
+> Codito, ergo sum
+> 2:25am up 106 days, 2:51, 3 users, load average: 0.00, 0.00, 0.00
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 07-Feb-2002 Time: 16:58:08
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!"
+------------------------------------------------------------------- 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Ivo van Poorten <ivop@eu...> - 2002-02-08 00:53
+
+On Thursday 07 February 2002 00:28, Livio Baldini Soares wrote:
+> everything lower than 0x1F, 0x7F, ' ', '<', '>', and '"'
+>
+> Is there a portable way of doing this? Should I ignore other chars?
+> Oh, and this is only applied to URL's. Parsing of other kinds of
+> attributes were left unchanged... (aiieee... I think we're going to
+> discuss attribute parsing again? ;)
+>
+> Paul Chamberlain, thanks for the remarks, and I think you'll be
+> happy to know that this patch works with
+>
+> h t t p: / /sl as h d ot.o rg /
+>
+> just fine. The patch is small (1.8KiB), so I'm sending it
+> attached. As always, comments are greatly appreciated!
+
+I'm not an active developer on dillo, though I appreciate your efforts alot!
+I was just wondering, what would happen to URL's like this:
+
+<A HREF="ftp://some.server.com/some/directory/Some Artist - Some Title.mp3">
+
+Depending on your hobbies, you will run across such links a lot. With spaces 
+removed, the link won't work I suppose?
+
+Regards,
+--Ivo
+
+-- 
+Codito, ergo sum
+2:25am up 106 days, 2:51, 3 users, load average: 0.00, 0.00, 0.00 
+
+
+
+Re: [Dillo-dev]Special characters in dillo
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-02-08 00:36
+
+Hi.
+
+The result multibytes sequence should depend on the locale.
+The length of the result sequence is undecided. Not a character.
+I tried to convert the isocode to utf-8 and then to convert from the
+utf-8 sequence to the locale specific sequence by iconv.
+But it could not work well on some characters. So if you fix it, please
+consider at the point.
+
+If you are intrested in, see
+http://todo.org/en/tiki.cgi?p=3DDillo dillo-0.6.3-uo-branch-2 html.c
+Html_store_isocode
+
+Michael Raidel <raidel@i-...> writes:
+
+> Hello!
+> =
+
+> I have just tried to patch dillo for the following behaviour: html-code=
+s =
+
+> such as &#8217; &#8220; and so on are correctly shown by other browsers=
+=
+
+> I use (fe: &#8217; =3D =B4 ). This was very easy by adding a switch to =
+the =
+
+> "// Numeric token" section in Html_parse_entity() in html.c which check=
+s =
+
+> all of the tags i know if the existing check returned -1. But I don't =
+
+> think this is good way to code, because the list of codes is not so eas=
+y =
+
+> to maintain.
+> =
+
+> So I went for the second solution, which does works sometimes but not =
+
+> always and I don't understand why (I am learning C/C++ since two weeks.=
+=2E).
+> = 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: jason shen <shenkr@ih...> - 2002-02-08 00:29
+
+Hi, have modified the file and recompiled. It works and has better look
+now Thanks. Jason.
+
+=A6b =B6g=A5|, 2002-02-07 21:18, TANAKA Keishiro =BCg=B9D=A1G
+> Hi.
+>=20
+> >May I know where to find the document to set fonts ? I've no problem to
+> >display big-5 Chinese but it looks terrible. Thanks.=20
+>=20
+> I think, at this stage, you have to add font name by hand to
+> dillo source.=20
+> # I don't know the Hungarian font name...
+>=20
+> dw_style.c: Search gdk_fontset_load function.
+> > sprintf (fontname,=20
+> > ("-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,"
+> > "-*-*-%s-%s-*-*-%d-*-*-*-*-*-jisx0208.1983-*"), # the line
+> > font->name, font->bold ? "bold" : "medium",
+> > font->italic ? ItalicChar : "r", font->size,=20
+> > font->bold ? "bold" : "medium", font->italic ? ItalicChar : "r",
+> > font->size);
+> You have to change the line to the your prefered font name.
+>=20
+> And type on command line
+>=20
+> setenv LANG your_locale; dillo &
+>=20
+>=20
+>=20
+>=20
+>=20
+>=20 
+
+
+
+[Dillo-dev][nettaxi] warning
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-07 22:32
+
+Hi,
+
+Those of you that had used my nettaxi address, please review
+your sent-mail because it has lost all the email since maybe more
+than a full month.
+
+Yes, I haven't used it quite a good amount of time, but the
+address may remain in ancient emails, and thus, replies may end
+somewhere near /dev/null.
+
+
+That's all
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: HORVATH Szabolcs <horvaths@fi...> - 2002-02-07 19:22
+
+* TANAKA Keishiro (ksr@lp.nm.fujitsu.co.jp) [20020207 16:03]:
+> I wonder I don't know correctly what you want.
+> 
+> m17n dillo is available. Maybe Hungarian will be supported by setting
+> suitable locale and fonts selection.
+
+No, I think Miklos thought to localization project (gettext, po/*).
+I've just finished dillo+l10n patch, you can download from:
+http://fi.inf.elte.hu/~horvaths/dillo/
+(patch and the complete source tree can be found)
+
+Sorry for my bad English and I hope you'll see what I mean.
+
+Take care.
+
+-- 
+Horváth Szabolcs, <horvaths@fi.inf.elte.hu> 
+
+
+
+Re: [Dillo-dev]Pthreads broken on Solaris
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-07 16:49
+
+On Thu, Feb 07, 2002 at 01:22:10PM -0300, Jorge Arellano Cid wrote:
+> 
+> Andreas, Livio:
+> 
+> > >
+> > > checking whether threads work with -pthread... yes
+> > >
+> > > BUT, here's what really happened in config.log:
+> > >
+> > > gcc: unrecognized option `-pthread'
+> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+I just tried it on a Solaris 2.6 - same result :
+gcc: unrecognized option `-pthread'
+configure:2744: $? = 0
+configure:2747: test -s conftest
+configure:2750: $? = 0
+configure:2760: result: yes
+
+which looks pretty much like bogus to me ....
+
+I also modified configure.in to a non-existent option on my linux
+box and it does fall back to checking the libraries.
+
+> > hmmm ... that should end up in a in, "no, it's not working with -pthread"
+> > and it should proceed to check the libs individually .... bummer ....
+> > I'll check that.
+> 
+> I noticed current AC_TRY_LINK call shifts one parameter, so:
+> 
+> -AC_TRY_LINK_FUNC(pthread_create, pthread_ok=yes, pthread_ok=no)
+> +AC_TRY_LINK_FUNC(, pthread_create, pthread_ok=yes, pthread_ok=no)
+> 
+> and, just in case the linker doesn't report an error with an
+> exit code. Settings can be tested with:
+> 
+> AC_TRY_RUN(
+> [int main() {return !pthread_equal(pthread_self(), pthread_self());}],
+> AC_MSG_RESULT(yes),
+> AC_MSG_RESULT(no),
+> AC_MSG_RESULT(crosscompiling: no run-test))
+
+Maybe this is what we need.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-07 16:30
+
+On Thu, Feb 07, 2002 at 11:08:41AM -0500, Jonathan P Springer wrote:
+> On Thu, Feb 07, 2002 at 12:45:14PM -0300, Jorge Arellano Cid wrote:
+> > 
+> > It'd be easy to test for the 3 image formats, and after that
+> > for "<HTML" somewhere in the beginning (provided the former chars
+> > are space-chars or within ASCII for instance); if neither test
+> > cucceeds and it has only ASCII, it can try text/plain.
+> 
+> Probably want to test for a few HTML tags. TITLE? H1? IMG? Many pages
+> are still poorly formed HTML.
+
+Well, this test is only a last resort anyways. In the case that the server
+doesn't give as a content/type header field.
+I looked at the garbage that IIS delivers from ebay's sites and it seems
+it is the re-direct pages that don't have content/type (so that does not
+matter anyways) but the final stopper is the login page where IIS has
+all these cookie settings in the header and forgets the content/type
+over all this cookie trouble ;-) ....
+What I want to say : hopefully, the hand coded pages will have a server
+that always sends the content type.
+
+Anyways, here is how OpenBSD's (as a random OS - they all do it almost
+identical) magic file detects HTML :
+0 string \<!DOCTYPE\ HTML HTML document text
+0 string \<!doctype\ html HTML document text
+0 string \<HEAD HTML document text 
+0 string \<head HTML document text
+0 string \<TITLE HTML document text
+0 string \<title HTML document text
+0 string \<html HTML document text 
+0 string \<HTML HTML document text 
+
+Hey, and if you can't code correct HTML you are not worthy being
+looked at ;-) ....
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]Pthreads broken on Solaris
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-07 16:25
+
+Andreas, Livio:
+
+> >
+> > checking whether threads work with -pthread... yes
+> >
+> > BUT, here's what really happened in config.log:
+> >
+> > gcc: unrecognized option `-pthread'
+> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>
+> hmmm ... that should end up in a in, "no, it's not working with -pthread"
+> and it should proceed to check the libs individually .... bummer ....
+> I'll check that.
+
+I noticed current AC_TRY_LINK call shifts one parameter, so:
+
+-AC_TRY_LINK_FUNC(pthread_create, pthread_ok=yes, pthread_ok=no)
++AC_TRY_LINK_FUNC(, pthread_create, pthread_ok=yes, pthread_ok=no)
+
+and, just in case the linker doesn't report an error with an
+exit code. Settings can be tested with:
+
+AC_TRY_RUN(
+[int main() {return !pthread_equal(pthread_self(), pthread_self());}],
+AC_MSG_RESULT(yes),
+AC_MSG_RESULT(no),
+AC_MSG_RESULT(crosscompiling: no run-test))
+
+
+Hope this helps
+Jorge.- 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-07 16:24
+
+On Thu, Feb 07, 2002 at 12:45:14PM -0300, Jorge Arellano Cid wrote:
+> 
+> Note that this doesn't need any external magic files, just a
+> self contained function that performs the above-mentioned tests.
+
+If we/I code that elegantly enough, then it doesn't really matter :-)
+and we can exchange the self contained test with a magic.mime test
+easily.
+
+> PS: Andreas: the *BSD patch is already on CVS.
+
+I noticed it ! Cool ! :-)
+
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-02-07 16:08
+
+On Thu, Feb 07, 2002 at 12:45:14PM -0300, Jorge Arellano Cid wrote:
+> 
+> It'd be easy to test for the 3 image formats, and after that
+> for "<HTML" somewhere in the beginning (provided the former chars
+> are space-chars or within ASCII for instance); if neither test
+> cucceeds and it has only ASCII, it can try text/plain.
+
+Probably want to test for a few HTML tags. TITLE? H1? IMG? Many pages
+are still poorly formed HTML.
+
+--
+-Jonathan P Springer <jonathan.springer@ve...>
+------------------------------------------------------------------------------
+"A standard is an arbitrary solution to a recurring problem." - Joe Hazen 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-07 15:47
+
+On Wed, 6 Feb 2002, Andreas Schweitzer wrote:
+
+> On Wed, Feb 06, 2002 at 04:00:49PM -0800, Eric GAUDET wrote:
+> > > --------------------------------------
+> > > Bug 216 (answers without content/type)
+> > > --------------------------------------
+> > Ok, I'm volunteering ... to have a look at that ;-)
+>
+> I was thinking about volunteering (I would not be able to *deliver*
+> until the end of the month, though ....) and I was reading the man
+> page magic(5) and peeking into how file(1) works. Now, the problem is
+> that it first checks the first byte(s) and by doing so
+> killing a gazillion types. Only after that it cecks if it is an ASCII
+> (without the use of the magic(5) file).
+> Unless I'm missing something it may not be trivial to find
+> out weather dillo is looking at an ASCII file or not by only
+> eliminating 3 image formats.
+
+It'd be easy to test for the 3 image formats, and after that
+for "<HTML" somewhere in the beginning (provided the former chars
+are space-chars or within ASCII for instance); if neither test
+cucceeds and it has only ASCII, it can try text/plain.
+Finally, if it doesn't fit any of the above, default to
+"application/octet-stream".
+
+Note that this doesn't need any external magic files, just a
+self contained function that performs the above-mentioned tests.
+
+> OTOH, isn't Netscape just dumping everything that it doesn't know ?
+
+That's what the RFC says!
+
+
+Cheers
+Jorge.-
+
+
+PS: Andreas: the *BSD patch is already on CVS. 
+
+
+
+Re: [Dillo-dev]Pthreads broken on Solaris
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-07 15:17
+
+> 
+> checking whether threads work with -pthread... yes
+> 
+> BUT, here's what really happened in config.log:
+> 
+> gcc: unrecognized option `-pthread'
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+hmmm ... that should end up in a in, "no, it's not working with -pthread"
+and it should proceed to check the libs individually .... bummer ....
+I'll check that.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Special characters in dillo
+
+From: Michael Raidel <raidel@i-...> - 2002-02-07 14:43
+
+Hello!
+
+I have just tried to patch dillo for the following behaviour: html-codes 
+such as &#8217; &#8220; and so on are correctly shown by other browsers 
+I use (fe: &#8217; = ´ ). This was very easy by adding a switch to the 
+"// Numeric token" section in Html_parse_entity() in html.c which checks 
+all of the tags i know if the existing check returned -1. But I don't 
+think this is good way to code, because the list of codes is not so easy 
+to maintain.
+
+So I went for the second solution, which does works sometimes but not 
+always and I don't understand why (I am learning C/C++ since two weeks..).
+
+all of the following happens in html.c of dillo0.6.4:
+
+line 604:
+
+#define NumEnt 257 // added 5 to the original 252 elements
+static const Ent_t Entities[NumEnt] = {
+{"#8217",39}, {"#8220",34}, {"#8221",34}, {"#8211",45}, 
+{"#8216",39},
+{"AElig",0306}, {"Aacute",0301}, {"Acirc",0302}, {"Agrave",0300}, 
+// and so on, I didn't change the array after this line..
+
+line 700:
+static gint Html_parse_entity(const gchar *token, gint toksize)
+{
+gint base, isocode, i;
+gchar *eoe, *name;
+
+g_return_val_if_fail (token[0] == '&', -1);
+
+eoe = (toksize) ? memchr(token, ';', toksize) : strchr(token, ';');
+if (eoe) {
+// I changed the order of the if expression, it now checks first 
+for the named entity:
+
+// Search for named entity
+name = g_strndup(token + 1, eoe - token - 1);
+i = Html_entity_search(name);
+g_free(name);
+
+if (token[1] == '#' && i == -1) { // it searches only for 
+numeric tokens if it hasn't already found the token in the Entities-array
+// Numeric token
+base = (token[2] == 'x' || token[2] == 'X') ? 16 : 10;
+
+isocode = strtol(token + 2 + (base==16), NULL, base);
+
+return (isocode > 0 && isocode <= 255) ? isocode : -1;
+}
+return (i != -1) ? Entities[i].isocode : -1;
+
+
+}
+return -1;
+}
+
+
+My trouble is: it doesn't work really good: if I use only one additional 
+element in the entities array (fe &#8217;) it works correct, when I add 
+some elements it stops working for some of the characters or all of 
+them. I used printf(name); and it was always the correct output (fe: 
+#8217, which is exactly one of the elements in the entities-Array..
+
+Maybe some of you can help me completing it, so the dillo-crew can 
+integrate it in the browser if they want to do so. 
+
+
+
+[Dillo-dev]Pthreads broken on Solaris
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-07 14:23
+
+Hello,
+
+I'm sad to say that the current changes to support *BSD has broken
+Dillo on Solaris. I think the stuff changed in configure.in broke
+things... Changing the pthread detection back to simple
+(AC_CHECK_LIB(pthread, pthread_create)) makes Solaris happy.
+To sum up things, here's the output from configure:
+
+checking whether threads work with -pthread... yes
+
+BUT, here's what really happened in config.log:
+
+configure:1654: checking whether threads work with -pthread
+configure:1669: gcc -o conftest -I/usr/openwin/include -I/usr/local/lib/glib/include -I/usr/local/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -I/usr/local/include -I/usr/local/lib -pthread conftest.c -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lgmodule -lglib -ldl -lintl -lXext -lX11 -lsocket -lnsl -lw -lm 1>&5
+gcc: unrecognized option `-pthread'
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+That's what I get during normal Dillo compilation. It compiles
+fines, but never gets support for pthreads, therefore, DNS is broken,
+and Dillo can't open anything :-(
+
+What I did was hand edited src/Makefile from:
+LDFLAGS = -I/usr/local/lib -pthread
+to
+LDFLAGS = -I/usr/local/lib -lpthread
+
+And everything worked. I know it's not the fix, but I have no time
+right now to fix this (maybe next week).
+
+best regards to all,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-02-07 13:22
+
+On Wed, Feb 06, 2002 at 05:31:29PM -0800, Eric GAUDET wrote:
+> On 07-Feb-2002 Andreas Schweitzer wrote:
+> > On Wed, Feb 06, 2002 at 04:00:49PM -0800, Eric GAUDET wrote:
+> >> > --------------------------------------
+> >> > Bug 216 (answers without content/type)
+> >> > --------------------------------------
+> >> Ok, I'm volunteering ... to have a look at that ;-)
+> > 
+> > I was thinking about volunteering (I would not be able to *deliver*
+> > until the end of the month, though ....) and I was reading the man
+> 
+> We can probably join our efforts, because I don't have much time either.
+> 
+> > page magic(5) and peeking into how file(1) works. Now, the problem is
+> > that it first checks the first byte(s) and by doing so
+> > killing a gazillion types. Only after that it cecks if it is an ASCII
+> > (without the use of the magic(5) file).
+> > Unless I'm missing something it may not be trivial to find
+> > out weather dillo is looking at an ASCII file or not by only
+> > eliminating 3 image formats.
+> > 
+> 
+> I think we should proceed this way:
+> 
+> 1) add a entry in the preference file for the path to the magic.mime:
+> magicmime=/usr/share/misc/magic.mime
+> and have the pref.c find it and call the loading function
+> 
+> 2) build a function loading the magic.mime and fill an array of structures for
+> each mime type.
+> 
+> 3) build the a_Mime_get_type function that will use the array to decide what
+> mime type to return.
+> 
+> 4) have Jorge find some time to make the data passed to this function.
+> 
+
+This looks like the way 'gnome_mime_type_from_magic' works. You may
+want to look there for code to liberate.
+
+-js
+
+
+--
+-Jonathan P Springer <jonathan.springer@ve...>
+------------------------------------------------------------------------------
+"A standard is an arbitrary solution to a recurring problem." - Joe Hazen 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-02-07 11:07
+
+Hi.
+
+>AFAIK uo-branch use my font_charset and encodings_selection
+>patches. Both work nice together ;)
+Ok, Where can I get it ?
+
+The second image of
+http://ccns.ncku.edu.tw/~jimchyun/dillo/snapshot/
+shows the charset encoding selection menu of 0.6.3-m17n. It uses your
+(before) encoding selection patch. 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: Grigory Bakunov <black@as...> - 2002-02-07 10:37
+
+On =FE=D4=D7, 2002-02-07 at 13:31, TANAKA Keishiro wrote:
+> Hi.
+>=20
+> > > setenv LANG your_locale; dillo &
+> > Ugly.
+> Yeah. It is for 0.6.3-uo-branch-2. 0.6.3-m17n has smarter solution,
+> 0.6.3-m17n can choose one of CKJ, maybe.
+>=20
+> m17n effort has not been adopted to the tree.
+> =20
+> > See patch in attachment.
+> > in dillorc add
+> > font_charset=3Djisx0208.1983-*
+> It is just kludge, you know.=20
+> Dynamic font selection menu cooperating with charset encoding is
+> required. (0.6.4 has it?)
+
+AFAIK uo-branch use my font_charset and encodings_selection
+patches. Both work nice together ;)
+
+--=20
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-02-07 10:31
+
+Hi.
+
+> > setenv LANG your_locale; dillo &
+> Ugly.
+Yeah. It is for 0.6.3-uo-branch-2. 0.6.3-m17n has smarter solution,
+0.6.3-m17n can choose one of CKJ, maybe.
+
+m17n effort has not been adopted to the tree.
+
+> See patch in attachment.
+> in dillorc add
+> font_charset=jisx0208.1983-*
+It is just kludge, you know. 
+Dynamic font selection menu cooperating with charset encoding is
+required. (0.6.4 has it?)
+
+Best Regards. 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: Grigory Bakunov <black@as...> - 2002-02-07 08:39
+
+Attachments: dillo_0.64.charset_selection.patch      
+
+On =FE=D4=D7, 2002-02-07 at 11:18, TANAKA Keishiro wrote:
+> Hi.
+>=20
+> >May I know where to find the document to set fonts ? I've no problem to
+> >display big-5 Chinese but it looks terrible. Thanks.=20
+>=20
+> I think, at this stage, you have to add font name by hand to
+> dillo source.=20
+> # I don't know the Hungarian font name...
+>=20
+> dw_style.c: Search gdk_fontset_load function.
+> > sprintf (fontname,=20
+> > ("-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,"
+> > "-*-*-%s-%s-*-*-%d-*-*-*-*-*-jisx0208.1983-*"), # the line
+> > font->name, font->bold ? "bold" : "medium",
+> > font->italic ? ItalicChar : "r", font->size,=20
+> > font->bold ? "bold" : "medium", font->italic ? ItalicChar : "r",
+> > font->size);
+> You have to change the line to the your prefered font name.
+>=20
+> And type on command line
+>=20
+> setenv LANG your_locale; dillo &
+Ugly.
+
+See patch in attachment.
+in dillorc add
+font_charset=3Djisx0208.1983-*
+
+>=20
+--=20
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-02-07 08:19
+
+Hi.
+
+>May I know where to find the document to set fonts ? I've no problem to
+>display big-5 Chinese but it looks terrible. Thanks. 
+
+I think, at this stage, you have to add font name by hand to
+dillo source. 
+# I don't know the Hungarian font name...
+
+dw_style.c: Search gdk_fontset_load function.
+> sprintf (fontname, 
+> ("-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,"
+> "-*-*-%s-%s-*-*-%d-*-*-*-*-*-jisx0208.1983-*"), # the line
+> font->name, font->bold ? "bold" : "medium",
+> font->italic ? ItalicChar : "r", font->size, 
+> font->bold ? "bold" : "medium", font->italic ? ItalicChar : "r",
+> font->size);
+You have to change the line to the your prefered font name.
+
+And type on command line
+
+setenv LANG your_locale; dillo & 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: jason shen <shenkr@ih...> - 2002-02-07 07:44
+
+Hi,
+May I know where to find the document to set fonts ? I've no problem to
+display big-5 Chinese but it looks terrible. Thanks. 
+Jason
+-------------
+On 07 Feb 2002 16:03:41 +0900
+TANAKA Keishiro <ksr@lp.nm.fujitsu.co.jp> wrote:
+
+> Hi.
+> I wonder I don't know correctly what you want.
+> 
+> m17n dillo is available. Maybe Hungarian will be supported by setting
+> suitable locale and fonts selection.
+> 
+> See http://ccns.ncku.edu.tw/~jimchyun/dillo/dillo-0.63-m17n.tgz
+> or http://todo.org/cgi-bin/en/tiki.cgi?p=Dillo
+> 
+> Localization of menu string and other GUI properties etc has not been
+> supported yet.
+> 
+> Miklos Magyari <miklos.magyari@et...> writes:
+> 
+> > hi,
+> > 
+> > are there any plans for translating Dillo to other languages? I
+guess it> > wouldn't be so hard to create the translations (and the code
+that> > supports compile-time language selection) and that would only
+add some> > kilobytes to the source.
+> > I would be happy to create the Hungarian version, but first I want
+to> > make sure that I'm not working on a completely unsupported thing.
+> > 
+> > cheers,
+> > Miki
+> > 
+> > _______________________________________________
+> > Dillo-dev mailing list
+> > Dillo-dev@li...
+> > https://lists.so....net/lists/listinfo/dillo-dev
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Non-English Dillo?
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-02-07 07:03
+
+Hi.
+I wonder I don't know correctly what you want.
+
+m17n dillo is available. Maybe Hungarian will be supported by setting
+suitable locale and fonts selection.
+
+See http://ccns.ncku.edu.tw/~jimchyun/dillo/dillo-0.63-m17n.tgz
+or http://todo.org/cgi-bin/en/tiki.cgi?p=Dillo
+
+Localization of menu string and other GUI properties etc has not been
+supported yet.
+
+Miklos Magyari <miklos.magyari@et...> writes:
+
+> hi,
+> 
+> are there any plans for translating Dillo to other languages? I guess it
+> wouldn't be so hard to create the translations (and the code that
+> supports compile-time language selection) and that would only add some
+> kilobytes to the source.
+> I would be happy to create the Hungarian version, but first I want to
+> make sure that I'm not working on a completely unsupported thing.
+> 
+> cheers,
+> Miki
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-07 01:31
+
+On 07-Feb-2002 Andreas Schweitzer wrote:
+> On Wed, Feb 06, 2002 at 04:00:49PM -0800, Eric GAUDET wrote:
+>> > --------------------------------------
+>> > Bug 216 (answers without content/type)
+>> > --------------------------------------
+>> Ok, I'm volunteering ... to have a look at that ;-)
+> 
+> I was thinking about volunteering (I would not be able to *deliver*
+> until the end of the month, though ....) and I was reading the man
+
+We can probably join our efforts, because I don't have much time either.
+
+> page magic(5) and peeking into how file(1) works. Now, the problem is
+> that it first checks the first byte(s) and by doing so
+> killing a gazillion types. Only after that it cecks if it is an ASCII
+> (without the use of the magic(5) file).
+> Unless I'm missing something it may not be trivial to find
+> out weather dillo is looking at an ASCII file or not by only
+> eliminating 3 image formats.
+> 
+
+I think we should proceed this way:
+
+1) add a entry in the preference file for the path to the magic.mime:
+magicmime=/usr/share/misc/magic.mime
+and have the pref.c find it and call the loading function
+
+2) build a function loading the magic.mime and fill an array of structures for
+each mime type.
+
+3) build the a_Mime_get_type function that will use the array to decide what
+mime type to return.
+
+4) have Jorge find some time to make the data passed to this function.
+
+> OTOH, isn't Netscape just dumping everything that it doesn't know ?
+> Like tgz files displayed in binary ;-) .... not that dillo should
+> behave like Netscape ....
+> 
+
+Isn't our goal to replace Netscape? ;-)
+
+> Cheers
+> Andreas
+> 
+> 
+> -- 
+> Department of Physics & Astronomy and Center for Simulational Physics
+> University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+> Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+> USA http://dilbert.physast.uga.edu/~andy/
+
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 06-Feb-2002 Time: 17:23:59
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!"
+------------------------------------------------------------------- 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-07 01:22
+
+On Wed, Feb 06, 2002 at 04:00:49PM -0800, Eric GAUDET wrote:
+> > --------------------------------------
+> > Bug 216 (answers without content/type)
+> > --------------------------------------
+> Ok, I'm volunteering ... to have a look at that ;-)
+
+I was thinking about volunteering (I would not be able to *deliver*
+until the end of the month, though ....) and I was reading the man
+page magic(5) and peeking into how file(1) works. Now, the problem is
+that it first checks the first byte(s) and by doing so
+killing a gazillion types. Only after that it cecks if it is an ASCII
+(without the use of the magic(5) file).
+Unless I'm missing something it may not be trivial to find
+out weather dillo is looking at an ASCII file or not by only
+eliminating 3 image formats.
+
+OTOH, isn't Netscape just dumping everything that it doesn't know ?
+Like tgz files displayed in binary ;-) .... not that dillo should
+behave like Netscape ....
+
+Cheers
+Andreas
+
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-07 00:00
+
+Ok, I'm volunteering ... to have a look at that ;-)
+
+On 06-Feb-2002 Jorge Arellano Cid wrote:
+> 
+> Hi there!
+> 
+...
+>> Anyway, someone (don't look at me!!1) should really implement proper
+>> mime-type detection.
+> 
+> This is quite easy!
+> And since I wrote the following quote on 22 Sep 2001, I've been
+> surprised for the lack of volunteers.
+> 
+>>>
+> --------------------------------------
+> Bug 216 (answers without content/type)
+> --------------------------------------
+> 
+> Yes, I also had this problem with ebay (made a little hack, and
+> won my bid!). Since that moment the idea of handling this case
+> the rigth way is present. Note that the problem arises from a
+> http answer lacking the content/type info; the RFC says it SHOULD
+> be present, so it's not an error :(
+> 
+> The solution is simple, do you remember magic numbers and the
+> 'file' command? Well, that's the way to go. I don't mean calling
+> 'file' and parsing its output, but to examine the magic numbers
+> file uses (and its format) for the small set of MIME types dillo
+> supports:
+> 
+> image/{png, jpeg, gif}
+> text/{plain, html}
+> 
+> and afterward, to create a custom function that returns the
+> MIME type of a file, by examining a few bytes from the start of
+> it. Ex:
+> 
+> gchar *a_Mime_get_content_type(const gchar *FewBytesString);
+> 
+> After having this function, it's just a matter of binding it to
+> header parsing.
+>>>
+> 
+> 
+> That's all folks.
+> 
+> Cheers
+> Jorge.-
+> 
+> PS: don't get scared, just give me the function, and I bind it!
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 06-Feb-2002 Time: 16:00:09
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!"
+------------------------------------------------------------------- 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-06 23:34
+
+On 06-Feb-2002 Livio Baldini Soares wrote:
+> Oh, and this is only applied to URL's. Parsing of other kinds of
+> attributes were left unchanged... (aiieee... I think we're going to
+> discuss attribute parsing again? ;)
+> 
+
+That's fine: we don't want to parse attributes that contain text to be
+displayed, such as img alts.
+
+Best,
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 06-Feb-2002 Time: 15:33:08
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!"
+------------------------------------------------------------------- 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-06 23:28
+
+Attachments: url-exclude-chars.diff      
+
+Hello Eric! (and Paul)
+
+Eric GAUDET writes:
+> On 06-Feb-2002 Livio Baldini Soares wrote:
+> > Howdy guys,
+> > 
+> > bug #292 is bogus, Jorge feel free to remove it. I was finishing up
+> > an implementation, but then resolved to check the specs...
+> > 
+> 
+> What do you mean is bogus? do you mean we don't want to support such broken
+> links?
+
+Err... yes that's what I meant, but...
+
+> Still, some pages have hrefs with disallowed characters, and my interpretation
+> of the rfc is that dillo should ignore them (by removing them from the
+> attributes).
+
+I think I like your interpretation of the RFC better! I've made a
+small patch to clear out _some_ of the excluded chars. I don't know,
+but something like '#' can't be cleared out.. My patch ignores:
+
+everything lower than 0x1F, 0x7F, ' ', '<', '>', and '"'
+
+Is there a portable way of doing this? Should I ignore other chars?
+Oh, and this is only applied to URL's. Parsing of other kinds of
+attributes were left unchanged... (aiieee... I think we're going to
+discuss attribute parsing again? ;)
+
+Paul Chamberlain, thanks for the remarks, and I think you'll be
+happy to know that this patch works with
+
+h t t p: / /sl as h d ot.o rg /
+
+just fine. The patch is small (1.8KiB), so I'm sending it
+attached. As always, comments are greatly appreciated!
+
+kind regards,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]About Bug #292
+
+From: Paul Chamberlain <tif@ti...> - 2002-02-06 21:51
+
+Livio Baldini Soares wrote:
+> As you can see whitespaces are disallowed and so are Line Feeds (0x0A) and
+> Carriage Returns (0x0D), which are in the 00-1F range.
+
+I'd like to see these characters silently deleted from URLs.
+Having said that, I should point out that I haven't really
+thought through all the implications of that, I'm merely
+reacting to a gripe I have about Netscape. When I paste a
+URL into Netscape that I've selected from an xterm and it
+was long enough that it was wrapped around on the screen,
+I end up with a space (I think) in the URL where it was
+wrapped and the server almost always gives an error. Then I
+have to find the space in the URL and delete it manually.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+RE: [Dillo-dev]About Bug #292
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-06 21:32
+
+On 06-Feb-2002 Livio Baldini Soares wrote:
+> Howdy guys,
+> 
+> bug #292 is bogus, Jorge feel free to remove it. I was finishing up
+> an implementation, but then resolved to check the specs...
+> 
+
+What do you mean is bogus? do you mean we don't want to support such broken
+links?
+Still, some pages have hrefs with disallowed characters, and my interpretation
+of the rfc is that dillo should ignore them (by removing them from the
+attributes).
+
+> His is an excerpt from RFC 2396 (Uniform Resource Identifiers (URI):
+> Generic Syntax), section 2.4.3:
+> 
+... blah blah, snip, snip ...
+> 
+> As you can see whitespaces are disallowed and so are Line Feeds (0x0A) and
+> Carriage Returns (0x0D), which are in the 00-1F range.
+> 
+> best regards to all!
+> 
+> -- 
+> Livio <livio@im...>
+> 
+-------------------------------------------------------------------
+Eric GAUDET <egaudet@in...>
+Date: 06-Feb-2002 Time: 13:30:03
+"Le premier qui me reveille pendant que je travaille, ca va mal aller !!!"
+------------------------------------------------------------------- 
+
+
+
+[Dillo-dev]About Bug #292
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-06 21:24
+
+Howdy guys,
+
+bug #292 is bogus, Jorge feel free to remove it. I was finishing up
+an implementation, but then resolved to check the specs...
+
+His is an excerpt from RFC 2396 (Uniform Resource Identifiers (URI):
+Generic Syntax), section 2.4.3:
+
+***************************************
+2.4.3. Excluded US-ASCII Characters
+
+Although they are disallowed within the URI syntax, we include here
+a description of those US-ASCII characters that have been excluded
+and the reasons for their exclusion.
+
+The control characters in the US-ASCII coded character set are not
+used within a URI, both because they are non-printable and because
+they are likely to be misinterpreted by some control mechanisms.
+
+control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
+
+The space character is excluded because significant spaces may
+disappear and insignificant spaces may be introduced when URI are
+transcribed or typeset or subjected to the treatment of word-
+processing programs. Whitespace is also used to delimit URI in
+many contexts.
+
+space = <US-ASCII coded character 20 hexadecimal>
+***************************************
+
+As you can see whitespaces are disallowed and so are Line Feeds (0x0A) and
+Carriage Returns (0x0D), which are in the 00-1F range.
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-06 13:09
+
+Hi there!
+
+
+
+On Wed, 6 Feb 2002, Pekka Lampila wrote:
+
+> Hi,
+> On 05.02.2002, Eric GAUDET wrote:
+> > here=B4s a quick and dirty patch I want to share with all of you who wa=
+nt to
+> > browse ebay.com [BUG#261]:
+> > In IO/mime.c, line 150, add the following:
+> >
+> > return a_Mime_set_viewer("text/html", Ptr, Call, Data);
+>
+> There's already hack for this in source (but commented out):
+>
+> cache.c:484:
+> // entry->Type =3D Type ? Type : g_strdup("text/html"); Hack
+> for ebay --Jcid
+>
+> > The trade-off is that any link to a binary file will be loaded by dillo=
+and
+> > displayed.
+>
+> Your patch will make every unhandled mime-type handled as text/html (if I
+> understood correctly), while the one in cache.c will only mark file as
+> text/html if server doesn't tell what mime-type it is.
+
+The commented hack is there from a long time ago (I used it to
+win a bid on ebay!, and commented it out afterwards.
+
+
+> Anyway, someone (don't look at me!!1) should really implement proper
+> mime-type detection.
+
+This is quite easy!
+And since I wrote the following quote on 22 Sep 2001, I've been
+surprised for the lack of volunteers.
+
+>>
+--------------------------------------
+Bug 216 (answers without content/type)
+--------------------------------------
+
+Yes, I also had this problem with ebay (made a little hack, and
+won my bid!). Since that moment the idea of handling this case
+the rigth way is present. Note that the problem arises from a
+http answer lacking the content/type info; the RFC says it SHOULD
+be present, so it's not an error :(
+
+The solution is simple, do you remember magic numbers and the
+'file' command? Well, that's the way to go. I don't mean calling
+'file' and parsing its output, but to examine the magic numbers
+file uses (and its format) for the small set of MIME types dillo
+supports:
+
+image/{png, jpeg, gif}
+text/{plain, html}
+
+and afterward, to create a custom function that returns the
+MIME type of a file, by examining a few bytes from the start of
+it. Ex:
+
+gchar *a_Mime_get_content_type(const gchar *FewBytesString);
+
+After having this function, it's just a matter of binding it to
+header parsing.
+>>
+
+
+That's all folks.
+
+Cheers
+Jorge.-
+
+PS: don't get scared, just give me the function, and I bind it! 
+
+
+
+[Dillo-dev]Non-English Dillo?
+
+From: Miklos Magyari <miklos.magyari@et...> - 2002-02-06 09:20
+
+hi,
+
+are there any plans for translating Dillo to other languages? I guess it
+wouldn't be so hard to create the translations (and the code that
+supports compile-time language selection) and that would only add some
+kilobytes to the source.
+I would be happy to create the Hungarian version, but first I want to
+make sure that I'm not working on a completely unsupported thing.
+
+cheers,
+Miki 
+
+
+
+Re: [Dillo-dev]the bad and the ugly
+
+From: Pekka Lampila <medar@ka...> - 2002-02-06 06:15
+
+Hi,
+
+On 05.02.2002, Eric GAUDET wrote:
+> here=B4s a quick and dirty patch I want to share with all of you who wa=
+nt to
+> browse ebay.com [BUG#261]:
+> In IO/mime.c, line 150, add the following:
+>=20
+> return a_Mime_set_viewer("text/html", Ptr, Call, Data);
+
+There's already hack for this in source (but commented out):
+
+cache.c:484:
+// entry->Type =3D Type ? Type : g_strdup("text/html"); Hack
+for ebay --Jcid
+
+> The trade-off is that any link to a binary file will be loaded by dillo=
+and
+> displayed.
+
+Your patch will make every unhandled mime-type handled as text/html (if I
+understood correctly), while the one in cache.c will only mark file as
+text/html if server doesn't tell what mime-type it is.
+
+> =B4cause ebay.com is sending a mime type of application/octet-stream fo=
+r some
+> of its pages
+
+If it would do this, nobody shouldn't display those pages in text/html,
+but actually it just doesn't send Content-Type-header. (Which for some
+reason isn't absolutely required in RFCs)
+
+$ w3m -no-proxy -dump_head "http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?View=
+Item&item=3D2000276751"
+HTTP/1.0 200 OK
+Connection: close
+Server: Microsoft-IIS/4.0
+Date: Wed, 06 Feb 2002 06:03:04 GMT
+
+
+Anyway, someone (don't look at me!!1) should really implement proper
+mime-type detection.
+
+--=20
+Pekka Lampila - medar@ka... 
+
+
+
+[Dillo-dev]the bad and the ugly
+
+From: Eric GAUDET <egaudet@in...> - 2002-02-06 05:43
+
+Hi all,
+here=B4s a quick and dirty patch I want to share with all of you who =
+want to
+browse ebay.com [BUG#261]:
+In IO/mime.c, line 150, add the following:
+
+return a_Mime_set_viewer("text/html", Ptr, Call, Data);
+
+The trade-off is that any link to a binary file will be loaded by dil=
+lo and
+displayed.
+
+I know Jorge wants a clean mime detection, and I=B4m all for it, but =
+right now we
+only have this.=20
+=B4cause ebay.com is sending a mime type of application/octet-stream =
+for some of
+its pages, and the only way to prove the bastard wrong is to parse th=
+e begining
+of the file, which we don=B4t have when the http header is received.
+
+BTW, ebay category links have the nasty habit of containing carriage =
+returns
+[BUG#292] that dillo doesn=B4t filter: just edit the navbar to remove=
+them.
+
+Hope this helps, (it helps me, at least ;-)
+---------------------------------------------------------------------=
+---
+Eric GAUDET <egaudet@in...>
+Le 05-Feb-2002 a 21:28:44
+"Parler pour ne rien dire et ne rien dire pour parler=20
+sont les deux principes majeurs et rigoureux de tous ceux
+qui feraient mieux de la fermer avant de l'ouvrir."
+---------------------------------------------------------------------=
+--- 
+
+
+
+Re: [Dillo-dev]pthread detection and compilation on BSD's
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-05 20:48
+
+Imad,
+
+> Casting the -1 as pthread_t removes the warning, but dillo still
+> crashes.
+
+Ok, what dillo are we talking about?
+d065a2 or 0.6.4 with Andreas patch?
+The first also adds -D_THREAD_SAFE and who knows...
+
+> > Specially since you're using a Sparc, and if I'm not
+> > mistaken, sparcs are 64 bits no?
+>
+> OT: Ultrasparcs and newer are 64 bits, but the microSPARC II
+> processor (or compatible) in the Sparc 5s is only 32 bits.
+
+Considering this feedback:
+
+Krzysztof:
+FreeBSD 4.4 without any updates.
+Dillo on my system is stable. No crashes. (d065a2)
+Out of the box compile.
+
+Miklos:
+0.6.4 compiles and runs fine on s SparcStation 5 with Solaris 8.
+
+Andreas:
+FreeBSD 4.3, OpenBSD 3.0, Mandrake 7.2
+
+Imad:
+OpenBSD 3.0, Sparc 5 it crashes.
+
+Note that there's one OpenBSD 3.0 where it works and other that
+don't. Also note that Andreas has up to patch-012. What about
+your system Imad?
+
+
+> > If this doesn't work, could you please get a backtrace and post it
+> > on the list?
+>
+> Sure!
+>
+> (gdb) r
+> Starting program: /home/magius/DOWNLOAD/dillo-0.6.4/src/dillo
+> [...]
+
+Hmmm, backtraces seem to point to a thread problem and not a
+typesize. I may be wrong though.
+
+I'd check the OS patch level first, then the gcc compiler
+version, then comparing the gcc invocations for linking (and
+compiling), then the typesizes and finally a mail to openbsd.org!
+
+
+Cheers
+Jorge.-
+
+PS: Has someone tested NetBSD? 
+
+
+
+Re: [Dillo-dev]Dillo and GTK+ 2.0pre
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-02-05 18:38
+
+Hi,
+
+On Mon, Jan 28, 2002 at 07:58:44PM +0100, Michael Krueger wrote:
+> I compiled GTK+ 2.0pre (aka 1.3.11) with both the linux-fb and directfb port. 
+> My goal is to write a small Linux/GNU distribution which fits on two floppies 
+> and includes GUI applications. But compiling Dillo v0.6.3 (which would be the 
+> included browser) seems to be not possible, even after handcoding fixes in 
+> configure for pkg-config and the source. src/IO is compiled without any 
+> problems, but the dw* framework files make gcc-2.95 stop. There are many 
+> irrelationships with GtkArg{GetFunc,SetFunc} ("function not found") and klass 
+> ("structure: no member 'klass'"). I don't know how to fix these problems, the 
+> GTK+ migration manual does not offer useful information.
+> Has somebody ported Dillo to GTK+ 2.0pre? Or has somebody ideas to fix those 
+> problems?
+
+Porting to Gtk+ 2.0 is a very large work, since Dw makes much use of
+Gtk+ (GtkObject and much use of Gdk drawing functions). From my first
+glance, the migration manual focuses on programs with less use of
+low-level features, so the only way is to look what has changed in
+detail. AFAIK, nobody works on this, at least there is no entry in the
+bug tracking engine.
+
+BTW: Gtk+ 2.0 will be the base for unicode support, see
+http://dillo.so....net/Notes.txt.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]pthread detection and compilation on BSD's
+
+From: Imad <magius@pu...> - 2002-02-05 17:06
+
+On Tue, 5 Feb 2002, Livio Baldini Soares wrote:
+
+Hi, Livio!
+
+Casting the -1 as pthread_t removes the warning, but dillo still
+crashes.
+
+> Specially since you're using a Sparc, and if I'm not
+> mistaken, sparcs are 64 bits no?
+
+OT: Ultrasparcs and newer are 64 bits, but the microSPARC II
+processor (or compatible) in the Sparc 5s is only 32 bits.
+
+> If this doesn't work, could you please get a backtrace and post it
+> on the list?
+
+Sure!
+
+(gdb) r
+Starting program: /home/magius/DOWNLOAD/dillo-0.6.4/src/dillo
+Setting locale to C
+dillo_dns_init: Here we go!
+Loading bookmarks...
+Nav_open_url: Url=>about:splash<
+Nav_open_url: Url=>http://dillo.so....net/<
+Dns_server [0]: dillo.so....net is d888abc9
+Dns_server [0]: so....net is d888abc4
+
+Program received signal SIGBUS, Bus error.
+0x8071014 in jinit_upsampler ()
+(gdb) bt
+#0 0x8071014 in jinit_upsampler ()
+#1 0x807068c in jpeg_idct_1x1 ()
+#2 0x806cda8 in jinit_phuff_decoder ()
+#3 0x8066cdc in jpeg_read_scanlines ()
+#4 0x184d8 in Jpeg_write (jpeg=0x98000, Buf=0xf0000, BufSize=7160) at
+jpeg.c:302
+#5 0x18304 in Jpeg_callback (Op=0, Client=0xf0000) at jpeg.c:236
+#6 0x4574 in Cache_process_queue (entry=0x8f060) at cache.c:731
+#7 0x4384 in Cache_process_io (Op=0, VPtr=0x8b940) at cache.c:636
+#8 0x48ac in a_Cache_ccc (Op=2, Branch=2, Info=0xae420, Data=0x8b940,
+ExtraData=0x0) at cache.c:902
+#9 0x2ab8 in a_Chain_fcb (Op=2, Branch=2, Info=0xae400, Data=0x8b940,
+ExtraData=0x0) at chain.c:71
+#10 0x2fb74 in a_IO_ccc (Op=2, Branch=2, Info=0xae400, Data=0x8b940,
+ExtraData=0x0) at IO.c:314
+#11 0x2f87c in IO_read (io=0x8b940) at IO.c:160
+#12 0x2f990 in IO_callback (src=0x0, cond=G_IO_IN, data=0x8b940) at
+IO.c:237
+#13 0x828dea8 in g_io_add_watch ()
+#14 0x828fe00 in g_get_current_time ()
+#15 0x8290704 in g_get_current_time ()
+#16 0x8290a4c in g_main_run ()
+#17 0x814ada0 in gtk_main ()
+#18 0x152a8 in main (argc=1, argv=0xf7fffb44) at dillo.c:120
+(gdb)
+
+Trying again, this time with a local file:
+
+...
+Nav_open_url: Url=>file:/home/magius/DOWNLOAD/dillo-0.6.4/src/Makefile<
+pid 29026: Fatal error 'Thread has returned from sigreturn or switch'
+at line 573 in file /usr/src/lib/libc_r/uthread/uthread_kern.c (errno =
+0)
+
+Program received signal SIGABRT, Aborted.
+0x8434064 in _thread_exit ()
+(gdb) bt
+#0 0x8434064 in _thread_exit ()
+#1 0x84354ec in _thread_kern_sched ()
+#2 0x8430cfc in realloc ()
+#3 0x829188c in g_realloc ()
+#4 0x829f4a0 in g_string_chunk_insert_const ()
+#5 0x829fb8c in g_string_append_c ()
+#6 0x232b0 in a_Misc_expand_tabs (str=0x92280 "Makefile:
+$(srcdir)/Makefile.in $(top_builddir)/config.status
+$(BUILT_SOURCES)") at misc.c:68
+#7 0x28e70 in Plain_write (plain=0x9d660, Buf=0x605, BufSize=10364,
+Eof=0) at plain.c:178
+#8 0x28db8 in Plain_callback (Op=634368, Client=0x87c40) at
+plain.c:147
+#9 0x4574 in Cache_process_queue (entry=0x8f030) at cache.c:731
+#10 0x4384 in Cache_process_io (Op=0, VPtr=0xb8bc0) at cache.c:636
+#11 0x48ac in a_Cache_ccc (Op=2, Branch=2, Info=0x9da00, Data=0xb8bc0,
+ExtraData=0x0) at cache.c:902
+#12 0x2ab8 in a_Chain_fcb (Op=2, Branch=2, Info=0x879a0, Data=0xb8bc0,
+ExtraData=0x0) at chain.c:71
+#13 0x2fb74 in a_IO_ccc (Op=2, Branch=2, Info=0x879a0, Data=0xb8bc0,
+ExtraData=0x0) at IO.c:314
+#14 0x2f898 in IO_read (io=0xb8bc0) at IO.c:165
+#15 0x2f990 in IO_callback (src=0x0, cond=G_IO_IN, data=0xb8bc0) at
+IO.c:237
+#16 0x828dea8 in g_io_add_watch ()
+#17 0x828fe00 in g_get_current_time ()
+#18 0x8290704 in g_get_current_time ()
+#19 0x8290a4c in g_main_run ()
+#20 0x814ada0 in gtk_main ()
+#21 0x152a8 in main (argc=1, argv=0xf7fffb44) at dillo.c:120
+(gdb)
+
+
+> best regards and thanks in advance!
+
+No, thank you!
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+Re: [Dillo-dev]pthread detection and compilation on BSD's
+
+From: Livio Baldini Soares <livio@im...> - 2002-02-05 12:37
+
+Hi Imad!
+
+Imad writes:
+> 
+> The patch is nice in that it alleviates the need for lots of weird
+> configuration options. However, I still get a few errors...
+> 
+> During the compile process:
+> 
+> dns.c: In function `a_Dns_init':
+> dns.c:211: warning: assignment makes pointer from integer without a
+> cast
+> 
+> For reference, this is the assignment "dns_server[i].th1 = -1" that's
+> being referred to.
+>
+> Running dillo results in a core dump rather quick:
+
+(...)
+
+> All of the above applies to my Sparc 5 running OpenBSD 3.0. I wonder if
+> fixing that cast would fix all my problems, since the error seems to lie
+> in DNS resolution...
+
+Maybe. Specially since you're using a Sparc, and if I'm not
+mistaken, sparcs are 64 bits no? Plus I think pthread_t is defined as
+a long... Humm, if you have any time, could you please try the
+following "patch":
+
+Change line 211 from:
+dns_server[i].th1 = -1;
+to:
+dns_server[i].th1 = (pthread_t) -1;
+
+This works here on my Linux and on Solaris (running also in a Sparc
+5). If this doesn't work, could you please get a backtrace and post it
+on the list? Something like:
+
+$ cd dillo/src; gdb
+
+(gdb) r
+:
+: (do your stuff till dillo crashes)
+:
+(gdb) bt
+
+Then you'll the trace of the current frames. This helps a lot for
+diagnosing the problem,
+
+best regards and thanks in advance!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]pthread detection and compilation on BSD's
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-05 05:31
+
+On Mon, Feb 04, 2002 at 10:07:38PM -0500, Imad wrote:
+> 
+> The patch is nice in that it alleviates the need for lots of weird
+> configuration options. However, I still get a few errors...
+> 
+> During the compile process:
+> 
+> dns.c: In function `a_Dns_init':
+> dns.c:211: warning: assignment makes pointer from integer without a
+> cast
+
+Yep, I get the same warning on a i386 OpenBSD 3.0
+
+> All of the above applies to my Sparc 5 running OpenBSD 3.0. I wonder if
+> fixing that cast would fix all my problems, since the error seems to lie
+> in DNS resolution...
+
+However, I can run it just fine. I have a local namerver in my home
+network - if that makes a difference.
+
+As I said - OpenBSD 3.0 with patches up to patch-012 (013 came out
+just today ...)
+
+I'll post if FreeBSD or Linux give trouble.
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]pthread detection and compilation on BSD's
+
+From: Imad <magius@pu...> - 2002-02-05 03:07
+
+The patch is nice in that it alleviates the need for lots of weird
+configuration options. However, I still get a few errors...
+
+During the compile process:
+
+dns.c: In function `a_Dns_init':
+dns.c:211: warning: assignment makes pointer from integer without a
+cast
+
+For reference, this is the assignment "dns_server[i].th1 = -1" that's
+being referred to.
+
+Running dillo results in a core dump rather quick:
+
+> dillo
+Setting locale to C
+Dillo: error reading /home/magius/.dillo: No such file or directory
+dillo_dns_init: Here we go!
+Loading bookmarks...
+Nav_open_url: Url=>about:splash<
+Nav_open_url: Url=>http://dillo.so....net/<
+Dns_server [0]: dillo.so....net is d888abc9
+pid 16806: Fatal error 'accelerator != NULL' at line 573 in file
+gtk_accel_groups_from_object (errno = 0)
+Abort (core dumped)
+
+Trying again...
+
+> dillo README
+Setting locale to C
+dillo_dns_init: Here we go!
+Loading bookmarks...
+Nav_open_url: Url=>about:splash<
+Nav_open_url: Url=>file:/home/magius/DOWNLOAD/dillo-0.6.4/README<
+Nav_open_url: Url=>http://www.penny-arcade.com<
+Dns_server [0]: http://www.penny-arcade.com is c6ca270
+pid 31888: Fatal error 'SM_CLIENT_ID' at line 573 in file (errno = 0)
+Abort (core dumped)
+
+I get a memory fault if I dare to start dillo with a web address on the
+command line:
+
+Dns_server [0]: http://www.penny-arcade.com is c6ca277
+Memory fault (core dumped)
+
+On the other hand, as long as I simply navigate my local files,
+everything works fine.
+
+
+All of the above applies to my Sparc 5 running OpenBSD 3.0. I wonder if
+fixing that cast would fix all my problems, since the error seems to lie
+in DNS resolution...
+
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+Re: [Dillo-dev]pthread detection and compilation on BSD's
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-04 21:37
+
+Andreas and *BSDers!
+
+> I have spent some time getting dillo compile out of the
+> box on Linux, FreeBSD and OpenBSD - sorry, I currently
+> don't have a NetBSD on a computer.
+
+So we need a NetBSD tester... Anyone?
+
+> Jorge, I have to admit I did not test your patch. I think,
+> the -D_THREAD_SAFE (or however the syntax was) should be ok.
+
+We've debugged it a bit with a poland user, but I decided to
+merge it with your patch.
+
+It needs testing though, so, everybody in the house c'mon let
+it have a try!
+
+http://dillo.so....net/d065a2.tar.gz
+
+(it's dillo-0.6.4 with the new patch applied).
+
+Test it and report back.
+
+> [...]
+> It works on my Mandrake 7.2, my
+> FreeBSD 4.3 (I really should upgrade) and OpenBSD 3.0.
+> [...]
+
+> Maybe I'll be making now nice ports for FreeBSD and OpenBSD.
+> Once this is settled we should mail the ports mainainers - or are
+> they on this list here ??? :-)
+
+Don't know. I'd rather prefer the patch to work out of the box.
+
+
+Good luck
+Jorge.- 
+
+
+
+[Dillo-dev]pthread detection and compilation on BSD's
+
+From: Andreas Schweitzer <andy@ph...> - 2002-02-03 22:41
+
+Attachments: configure.in.diff      
+
+Hi,
+I have spent some time getting dillo compile out of the
+box on Linux, FreeBSD and OpenBSD - sorry, I currently
+don't have a NetBSD on a computer.
+
+Jorge, I have to admit I did not test your patch. I think,
+the -D_THREAD_SAFE (or however the syntax was) should be ok.
+However, I don't think testing for an OS is the cleanest way.
+I came up with a test to check for features. I think my
+test is quite clean ;-). It works on my Mandrake 7.2, my
+FreeBSD 4.3 (I really should upgrade) and OpenBSD 3.0.
+
+It has 3 parts. The first part is quite arguable. Essentially
+it unconditionally adds /usr/local/lib and /usr/local/include which
+should be ok. On OpenBSD only the include part is needed, on
+FreeBSD both.
+
+The 2nd part of the patch tries to detect non-standard naming
+conventions of gtk-config. This is needed for FreeBSD which allows
+you to have both gtk1.2 and gtk1.3 (and gtk2 ??).
+
+The 3rd part is which I insist on ;-) ... it does a very clean
+detection of how to use pthreads. Actually, it turns out that
+all 3 OS's only need the -pthread linking option.
+However, this implementation may work on a number of untested
+OS's, too. Also, the AC_SEARCH_LIB test should allow you to
+easily add another library candidate.
+
+Maybe I'll be making now nice ports for FreeBSD and OpenBSD.
+Once this is settled we should mail the ports mainainers - or are
+they on this list here ??? :-)
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Re: Move from SF.
+
+From: Gustavo Noronha Silva <kov@de...> - 2002-02-03 13:43
+
+On Sat, 2 Feb 2002 16:04:19 -0200
+Eduardo Marcel Maçan <macan@co...> wrote:
+
+> I guess you should contact these two persons:
+> 
+> Henrique <hmh@de...> 
+> and
+> Gustavo <kov@de...>
+> 
+> They know what to do, specially Gustavo
+> which happens to be a dillo fan too. Henrique will
+> be very useful too, since he spends more time online
+> and works very closely to some of our servers. I think
+> Gustavo knows our plan of hosting dillo better than
+> Henrique, talk to him first.
+Hello all,
+
+Jorge, you can count on me on moving from SF. Henrique
+nows more about CIPSGA's machines, but I'm here to help
+on whatever you need...
+
+where is this going to happen? denver? ima? ima2? ima2
+I think, right?
+
+[]s!
+
+-- 
+Gustavo Noronha Silva - kov <http://www.metainfo.org/kov>
+*---------* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
+| .''`. | Debian GNU/Linux: <http://www.debian.org> |
+| : :' : + Debian BR.......: <http://debian-br.cipsga.org.br>+
+| `. `'` + Q: "Why did the chicken cross the road?" +
+| `- | A: "Upstream's decision." -- hmh |
+*---------* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+ 
+
+
+
+[Dillo-dev]Re: Move from SF.
+
+From: Eduardo Marcel <macan@co...> - 2002-02-02 18:05
+
+I guess you should contact these two persons:
+
+Henrique <hmh@de...> 
+and
+Gustavo <kov@de...>
+
+They know what to do, specially Gustavo
+which happens to be a dillo fan too. Henrique will
+be very useful too, since he spends more time online
+and works very closely to some of our servers. I think
+Gustavo knows our plan of hosting dillo better than
+Henrique, talk to him first.
+
+Regards,
+
+Eduardo
+
+
+
+On Sat, 2 Feb 2002 10:25:25 -0300 (CLST)
+Jorge Arellano Cid <jcid@em...> wrote:
+
+> 
+> Eduardo,
+> 
+> 
+> > I am still on forced "vacations" from almost all
+> > my Free Software activities, but I can still help on the
+> > move to cipsga, even if only to put you in touch
+> > with the guys who can actively do it. :)
+> 
+> Yes, please send me some names, emails, and whatever you may
+> find necessary to do it.
+> 
+> 
+> Cheers
+> Jorge.-
+> 
+> 
+> 
+
+
+-- 
+"If you have an apple and I have an apple and we exchange apples then you 
+and I will still each have one apple. But if you have an idea and I have 
+an idea and we exchange these ideas, then each of us will have two ideas."
+George Bernard Shaw 
+
+
+
+Re: [Dillo-dev]Ditching pthreads (asynchronous dns)
+
+From: Tobin Fricke <tobin@sp...> - 2002-02-02 14:05
+
+On Fri, 1 Feb 2002, Sam Dennis wrote:
+
+> systems. IIRC, glibc does include facilities for asynchronous lookup but
+> these seem to use pthreads internally.
+
+I just happened across a library today called "adns", the GNU "advanced,
+alternative, asynchronous resolver".
+
+Some features that might be useful in Dillo includes:
+
+* It can be used in an asynchronous, non-blocking, manner. Many
+queries can be handled simultaneously.
+
+* There is no global state in the library; resolver state is an
+opaque data structure which the client creates explicitly. A
+program can have several instances of the resolver.
+
+http://www.chiark.greenend.org.uk/~ian/adns/
+
+I don't know anything about it other than what's in the README and on the
+webpage, but it sounded relevant to the current discussion here, so I
+thought I'd post a note about it, maybe we can learn something from it
+even if we don't use it.
+
+-- tobin 
+
+
+
+[Dillo-dev]Re: Move from SF.
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-02 13:27
+
+Eduardo,
+
+
+> I am still on forced "vacations" from almost all
+> my Free Software activities, but I can still help on the
+> move to cipsga, even if only to put you in touch
+> with the guys who can actively do it. :)
+
+Yes, please send me some names, emails, and whatever you may
+find necessary to do it.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Ditching pthreads
+
+From: Eduardo Marcel <macan@co...> - 2002-02-01 18:49
+
+Hello
+
+John Utz <john@ut...> wrote:
+> does getting rid of pthreads allow dillo to run on a bunch of new
+> machines?
+> 
+> using gnome functionality would certainly cut a bunch of machines out.
+
+Sure, being simple is what makes dillo the ideal choice for devices
+like the iPAQ, in which each kb saved on flash is a victory. It would not
+be that successful on this arena if it depended on gnome.
+
+-- 
+"If you have an apple and I have an apple and we exchange apples then you 
+and I will still each have one apple. But if you have an idea and I have 
+an idea and we exchange these ideas, then each of us will have two ideas."
+George Bernard Shaw 
+
+
+
+Re: [Dillo-dev]Ditching pthreads
+
+From: John Utz <john@ut...> - 2002-02-01 18:19
+
+ooohhhh.....must restrain self......
+
+On Fri, 1 Feb 2002, Jonathan P Springer wrote:
+
+> Does anyone know of any other libraries that support non-blocking DNS?
+> I'm not sure of the wisdom of potentially tying dillo to GNOME as well
+> as to GTK. 
+
+gnome is very nice for many people and i am greatful for all of the 
+hard work that has been done to provide a comfortable interface for folks 
+that feel that they need such of thing.
+
+but man, that thing is a vigourous consumer of ram, cpu, disk, screen real 
+estate.....you name it.
+
+(there, i said it in a non confrontational, positive way :-) )
+
+also, note that the dillo home page sez that it doesnt use gnome.
+
+> Maybe we should just lift the code for the non-blocking DNS.
+
+it's a solution. but what is the problem? 
+
+threaded programming is indeed more complicated than non threads.
+
+but it allows the *functions* that do the jobs to be more simple because 
+they dont have to take responsibility for managing themselves *and* 
+managing the relationship with the other functions that have to implement 
+code that manages itself *and* manages the relationship between it's self 
+and other f..... ok, enuf goofy recursion :-)
+
+does getting rid of pthreads allow dillo to run on a bunch of new 
+machines?
+
+using gnome functionality would certainly cut a bunch of machines out.
+
+> -jonathan
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]dillo on *BSD
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-02-01 15:55
+
+Attachments: configure.in.diff      
+
+Hi there!
+
+Considering the interest in the *BSD threads configuration
+issue, and these facts:
+
+On FreeBSD:
+
+* gcc has a specific option "-pthread" to avoid problems.
+* it also needs (or needed) '-lpthread' to the linker
+* and -D_THREAD_SAFE in CFLAGS
+
+On OpenBSD:
+
+* I was reported that CFLAGS="-pthread" has worked.
+
+
+I'm attaching a skeleton-patch (not tested) for your hacking
+pleasure :-).
+
+At least it works on Linux. :-) !!!
+
+Ok, please remember to autoreconf and clearing the cache before
+trying it.
+
+BTW: the first test should have beeen getting the newest
+autoconf/automake/ stuff and seeing if it solves the problem with
+current configure.in.
+
+
+Cheers & good luck
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Ditching pthreads
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-02-01 15:52
+
+On Fri, Feb 01, 2002 at 02:42:19PM +0000, Sam Dennis wrote:
+> Some time around 2 o'clock PM on February 1, a Friday, Jonathan P Springer wrote:
+> > On Thu, Jan 31, 2002 at 11:28:24PM +0000, Sam Dennis wrote:
+...
+> > As for the pthreads question, I discovered this morning that the GNOME
+> > UI library has a non-blocking DNS call. In hacking through the code,
+> > the two places I'd found pthreads were in file reads and DNS. The
+> > former can be dealt with effectively by pacing reads using the glib
+> > idle loop; the latter could be accomplished using the GNOME UI call. It
+> > could be a conditional compile based on whether GNOME UI is available.
+> > 
+> > Does anyone know of any other libraries that support non-blocking DNS?
+> > I'm not sure of the wisdom of potentially tying dillo to GNOME as well
+> > as to GTK. Maybe we should just lift the code for the non-blocking DNS.
+> 
+> Ack! Please not GNOME, some of us don't want that sort of bloat on our
+> systems. IIRC, glibc does include facilities for asynchronous lookup but
+> these seem to use pthreads internally.
+> 
+> There do seem to be a good few libraries out there that will do this for us
+> though. (And not depend on something like GNOME.) If we decide to take this
+> route, it's just a matter of choosing which one is the most useful and
+> portable.
+> 
+
+The resounding gNO(me) has been heard and acknowledged. I'll do some more
+nosing around, including sneaking a peek into the GNOME code to see how
+they do it. I suspect they've built it on top of GIOChannel and the
+GLib idle loop. If that's the case (and it's not too bloated), we could
+swipe it (with appropriate credit, of course :-) ).
+
+Looks like I've just laid out my weekend...
+
+-jonathan 
+
+
+
+Re: [Dillo-dev]Ditching pthreads
+
+From: Sam Dennis <sam@ma...> - 2002-02-01 14:36
+
+Some time around 2 o'clock PM on February 1, a Friday, Jonathan P Springer wrote:
+> On Thu, Jan 31, 2002 at 11:28:24PM +0000, Sam Dennis wrote:
+> > Some time around 8 o'clock PM on January 31, a Thursday, Sam Dennis wrote many
+> > things about using GIOChannels in file.c to replace pthreads without first
+> > trying to implement it and therefore overlooking the inadequacy of GIOChannels
+> > with regard to detecting EOF and the fact that we already use them in http.c.
+> > This shows that the statement most likely to be true in the message was about
+> > him not being an expect on dillo's IO subsystem. He still holds that we don't
+> > need threads, though.
+> > 
+> 
+> Sam, I appreciate your humility; it's a lesson to us all.
+> 
+> As for the pthreads question, I discovered this morning that the GNOME
+> UI library has a non-blocking DNS call. In hacking through the code,
+> the two places I'd found pthreads were in file reads and DNS. The
+> former can be dealt with effectively by pacing reads using the glib
+> idle loop; the latter could be accomplished using the GNOME UI call. It
+> could be a conditional compile based on whether GNOME UI is available.
+> 
+> Does anyone know of any other libraries that support non-blocking DNS?
+> I'm not sure of the wisdom of potentially tying dillo to GNOME as well
+> as to GTK. Maybe we should just lift the code for the non-blocking DNS.
+
+Ack! Please not GNOME, some of us don't want that sort of bloat on our
+systems. IIRC, glibc does include facilities for asynchronous lookup but
+these seem to use pthreads internally.
+
+There do seem to be a good few libraries out there that will do this for us
+though. (And not depend on something like GNOME.) If we decide to take this
+route, it's just a matter of choosing which one is the most useful and
+portable. 
+
+
+
+Re: [Dillo-dev]Ditching pthreads
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-02-01 14:14
+
+On Thu, Jan 31, 2002 at 11:28:24PM +0000, Sam Dennis wrote:
+> Some time around 8 o'clock PM on January 31, a Thursday, Sam Dennis wrote many
+> things about using GIOChannels in file.c to replace pthreads without first
+> trying to implement it and therefore overlooking the inadequacy of GIOChannels
+> with regard to detecting EOF and the fact that we already use them in http.c.
+> This shows that the statement most likely to be true in the message was about
+> him not being an expect on dillo's IO subsystem. He still holds that we don't
+> need threads, though.
+> 
+
+Sam, I appreciate your humility; it's a lesson to us all.
+
+As for the pthreads question, I discovered this morning that the GNOME
+UI library has a non-blocking DNS call. In hacking through the code,
+the two places I'd found pthreads were in file reads and DNS. The
+former can be dealt with effectively by pacing reads using the glib
+idle loop; the latter could be accomplished using the GNOME UI call. It
+could be a conditional compile based on whether GNOME UI is available.
+
+Does anyone know of any other libraries that support non-blocking DNS?
+I'm not sure of the wisdom of potentially tying dillo to GNOME as well
+as to GTK. Maybe we should just lift the code for the non-blocking DNS.
+
+-jonathan 
+
+
+
+Re: [Dillo-dev]dillo 0.6.4 compilation on solaris
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-02-01 11:49
+
+fre 2002-02-01 klockan 12.30 skrev K. Prasad:
+> Hi,
+>=20
+> I figured that out. I removed the G_GNUC_UNUSED and
+> got dillo to compile. I did find G_GNUC_UNUSED in
+> glib.h in my glib installation. it was under some
+> other ifdefs that i couldn't really understand. My
+> idea is that G_GNUC_UNUSED is a #define , so couldn't
+> understand=20
+> G_GNUC_UNUSED static <fn_name>.
+> what is it supposed to do?
+
+If GCC is used, it should expand to __attribute__((unused)), which just
+tells the compiler to not spew out a warning about unused function.
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]dillo 0.6.4 compilation on solaris
+
+From: K. Prasad <mvkp@ya...> - 2002-02-01 11:30
+
+Hi,
+
+I figured that out. I removed the G_GNUC_UNUSED and
+got dillo to compile. I did find G_GNUC_UNUSED in
+glib.h in my glib installation. it was under some
+other ifdefs that i couldn't really understand. My
+idea is that G_GNUC_UNUSED is a #define , so couldn't
+understand 
+G_GNUC_UNUSED static <fn_name>.
+what is it supposed to do?
+
+regards
+
+K Prasad
+
+--- Jorgen Viksell <jorgen.viksell@te...> wrote:
+> fre 2002-02-01 klockan 09.05 skrev K. Prasad:
+> > Hi,
+> > 
+> > Iam getting a problem in compiling dillo 0.6.4 on
+> > solaris duu to the undefined symbol G_GNUC_UNUSED.
+> 
+> Strange. It should be defined in glib.h. Are you
+> sure
+> that you have all the glib headers installed?
+> 
+> If that is the only problem, you can safely remove 
+> G_GNUC_UNUSED from the source, it's only there to 
+> prevent some warnings.
+> 
+> Regards,
+> Jörgen
+> 
+> > my configuration is:
+> > Solaris 2.5.1,gtk 1.2.10,gcc version 2.7.2
+> > 
+> > regards
+> > 
+> > K Prasad
+> 
+> 
+
+
+__________________________________________________
+Do You Yahoo!?
+Great stuff seeking new owners in Yahoo! Auctions! 
+http://auctions.yahoo.com 
+
+
+
+Re: [Dillo-dev]dillo 0.6.4 compilation on solaris
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-02-01 09:48
+
+fre 2002-02-01 klockan 09.05 skrev K. Prasad:
+> Hi,
+>=20
+> Iam getting a problem in compiling dillo 0.6.4 on
+> solaris duu to the undefined symbol G_GNUC_UNUSED.
+
+Strange. It should be defined in glib.h. Are you sure
+that you have all the glib headers installed?
+
+If that is the only problem, you can safely remove=20
+G_GNUC_UNUSED from the source, it's only there to=20
+prevent some warnings.
+
+Regards,
+J=F6rgen
+
+> my configuration is:
+> Solaris 2.5.1,gtk 1.2.10,gcc version 2.7.2
+>=20
+> regards
+>=20
+> K Prasad 
+
+
+
+[Dillo-dev]dillo 0.6.4 compilation on solaris
+
+From: K. Prasad <mvkp@ya...> - 2002-02-01 08:05
+
+Hi,
+
+Iam getting a problem in compiling dillo 0.6.4 on
+solaris duu to the undefined symbol G_GNUC_UNUSED.
+
+my configuration is:
+Solaris 2.5.1,gtk 1.2.10,gcc version 2.7.2
+
+regards
+
+K Prasad
+
+
+__________________________________________________
+Do You Yahoo!?
+Great stuff seeking new owners in Yahoo! Auctions! 
+http://auctions.yahoo.com 
+
diff --git a/old/oldmail/200203.txt b/old/oldmail/200203.txt
new file mode 100644
index 0000000..f37889d
--- /dev/null
+++ b/old/oldmail/200203.txt
@@ -0,0 +1,3136 @@
+[Dillo-dev]Re: Dillo configuration (fwd)
+
+From: Tomas <tomas@pu...> - 2002-03-31 12:45
+
+Attachments: Message as HTML      
+
+On Wed, Mar 27, 2002 at 10:23:20AM -0400, Jorge Arellano Cid wrote:
+> ---------- Forwarded message ----------
+> Date: Tue, 5 Feb 2002 16:04:30 -0300 (CLST)
+> From: Jorge Arellano Cid <jcid@em...>
+> To: Chris Wareham <chris.wareham@io...>
+> Subject: Re: Dillo configuration
+
+=2E..
+
+>=20
+> * There's a third history mechanism that hasn't made it into
+> the code yet: linear history. It's designed to provide a
+> chronological list of visited urls, with its own button a the
+> leftmost part. The problem with it is that it should provide
+> scrolling, highlighting of the current-page-item inside the
+> history list and display the url at the status bar.
+> A nice solution would be to have a sort of popup that can be
+> constrained to a certain number of items, with scrolling,
+> highlighting and url-showing (so it can be used for
+> back/Fwd/linear history widgets).
+> If you can do that, it'd be very helpful. Just tell me and I
+> send you the code I have.
+
+Could you send me the code you have already done, did you ask in
+gtk-list if there is a widget like this or should i do that.
+
+
+greets
+
+Tomas 
+
+
+
+[Dillo-dev][PATCH] block non local browsing
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-03-30 21:13
+
+Hi,
+
+Finally, I first made a patch to block all non local (non 127.x.x.x)
+requests. So browsing files or http pages on the localhost is still
+permitted. Non local (dns) requests are reported unknown (dns returns
+0). This behavior is available using -l (for local) command line
+option. This feature should be used when browsing untrusted pages. If
+there is an interest, I'll try to make it a run-time option. 
+
+Patch (4k) against cvs (cvs diff -c) is located at:
+
+http://melvin.hadasht.free.fr/dillo/dillo-local-cvs-30-03-2002.patch
+
+and
+
+http://freefluid.dyndns.org/dillo/dillo-local-cvs-30-03-2002.patch
+
+Next step is providing remote control to dillo.
+
+Cheers.
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]New site link
+
+From: Calvin Arndt <calarndt@pr...> - 2002-03-30 21:09
+
+dillo.s...net site needs to be updated with a link to the new dillo.cipsga.org.br site.
+New site is very hard to find (Even google search does not return a link!) 
+
+
+
+Re: [Dillo-dev]Bookmarks menuitem in state bar and scroll menu
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-30 14:06
+
+Tomas,
+
+
+> One of my doubts before doing it was if i should patch against
+> 0.6.4 or against the latest CVS code. I never worked before with CVS and
+> diff so if i did something wrong just tell me so the next time i will
+> try to do it better :)
+>
+> What i did was:
+>
+> - get the code from CVS in ~/dillo/dillo-cvs
+> - copy to another directory ~/dillo/dillo-tomas
+> - work on ~/dillo/dillo-tomas
+> - diff -pru dillo dillo-tomas (i saw the -pru flags for diff in another
+> patch)
+
+That's exactly the way I do it!
+
+BTW, I also put the '-pru' flags in the patching section of the
+new site (it was somewhat hidden in a README file; funny but
+true! ;)
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bookmarks menuitem in state bar and scroll menu
+
+From: Tomas <tomas@pu...> - 2002-03-30 00:49
+
+Attachments: Message as HTML      
+
+On Fri, Mar 29, 2002 at 10:07:15AM -0400, Jorge Arellano Cid wrote:
+>=20
+>=20
+> On Thu, 28 Mar 2002, Tomas wrote:
+>=20
+> > I have added scroll to the bookmark menu and the status bar now reflects
+> > the url is pointed with the mouse as in Back/Forwd history.
+> >
+> > The problem i see is when the menus are big enough to do scroll
+> > then covers the state bar so it's not posible to see the address.
+> >
+> > This is my first patch so any sugestion is very apreciated :) it's
+> > with the CVS code.
+^^^^
+
+Sorry i was trying to say that the patch i did was against the CVS code
+from
+that day and not against the stable version (0.6.4)
+
+One of my doubts before doing it was if i should patch against
+0.6.4 or against the latest CVS code. I never worked before with CVS and
+diff so if i did something wrong just tell me so the next time i will=20
+try to do it better :)=20
+
+What i did was:
+
+- get the code from CVS in ~/dillo/dillo-cvs
+- copy to another directory ~/dillo/dillo-tomas
+- work on ~/dillo/dillo-tomas
+- diff -pru dillo dillo-tomas (i saw the -pru flags for diff in another
+patch)
+=20
+
+
+>=20
+> The code is not in CVS now, as we're still working on it with
+> Tomas. The idea is to make a generic popup that allows scrolling,
+> shows the URL in the status bar, and that has a customizable
+> number of displayed-entries.
+>=20
+>=20
+> Cheers
+> Jorge.-
+>=20 
+
+
+
+[Dillo-dev]Re: CSS
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-03-28 22:22
+
+connected fine, comments please on CSS1 and CSS2 which do not seem to be 
+supported at present...
+
+will they be? and if so when-ish?
+
+really its a fabulous browser - good stuff
+
+thanks again 
+
+
+
+[Dillo-dev]CSS
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-03-28 21:58
+
+Does Dillo support CSS1 or CSS2? if not is there a planned for day.
+I've no idea of the workload, or bloat factor, but would like to use it.
+
+I'm busy rebuilding our website, and can't just get dillo to connect to 
+the internet.
+damn, ipaq and ssh is fine, as is the web connection, they just wont 
+talk to each other.
+oh well maybe tomorrow.
+
+thanks 
+
+
+
+Re: [Dillo-dev]Bookmarks menuitem in state bar and scroll menu
+
+From: Lars Clausen <lrclause@cs...> - 2002-03-28 18:05
+
+On Thu, 28 Mar 2002, tomas@pu... wrote:
+> Hi all,
+>=20
+> I have added scroll to the bookmark menu and the status bar now reflects
+> the url is pointed with the mouse as in Back/Forwd history.
+
+Cool, my bookmarks are getting to that state soon.
+
+If you feel like hacking more at the bookmarks, I'd love to see submenus in
+the bookmarks. Galeon does a good job of handling them, if you want
+inspiration.=20
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Bookmarks menuitem in state bar and scroll menu
+
+From: Tomas <tomas@pu...> - 2002-03-28 15:48
+
+Attachments: Message as HTML      Message as HTML      
+
+
+
+
+
+[Dillo-dev]patch: embedding dillo
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-03-28 00:03
+
+Hi,
+
+Thanks for this great piece of software. I use it all day (as long as
+the pages do not require java/javascript). It is really amazing fast and
+renders correctly the majority of the sites I visit. Please continue
+such a good work!
+
+I came to the idea that dillo can be used as an embedded html viewer in
+email MUA, for example. So I used the Gtk_Socket/Gtk_Plug feature to
+make a very small patch that allows dillo to be embedded in an existing
+gtk_socket window. It adds a '-xid' command line option (should be
+placed after the URI) which need the xid of a window (provided by the
+GDK_WINDOW_XWINDOW(GdkWindow *) macro). That way, any GTK application
+can create a gtk_socket, then it launches dillo with the -xid option and
+the first dillo window will be embedded. This worked so far quiet good:
+I hacked my Sylpheed-Claws version to support it.
+
+The dillo patch against cvs is at:
+
+http://melvin.hadasht.free.fr/dillo/dillo-embed-cvs-27-03-2002.patch
+
+or at 
+
+http://freefluid.dyndns.org/dillo/dillo-embed-cvs-27-03-2002.patch
+
+(the latter being not up 24/24).
+
+But as html mail is so dangerous, I wanted to ask you: is there any plan
+to make dillo able to run in offline mode? For example by using a
+command line. 
+
+To continue with my plan to use dillo as a versatile tool, I plan to
+make another patch where dillo will be able to listen on a Unix socket
+for commands sent by other processes. These commands would be very
+simple:
+
+- open an URL in current window, 
+
+- open an URL in a new window (with the xid supplied, xid = 0 being in a
+new GTK_TOP_LEVEL)
+
+- close window xid (!= 0), or quit (xid = 0). 
+
+The patch should not be big (at first sight), but I don't know when I
+will have time to do it.
+
+So, is there any interest in such features? 
+Any suggestions or comments to the patch or to my ideas are welcome!
+
+Thanks.
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev][RFC] Pixmap (XPM) image support / Broken pixmap
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-03-26 18:21
+
+Hi,
+
+On Mon, Mar 25, 2002 at 03:50:11PM -0800, Michael Taht wrote:
+> I don't know if this has been discussed before, but why not bite the
+> bullet and evolve up to the gdk-pixbuf library? 
+
+I'd second Livio, simply for the reason that the the current code
+works (rather) well, and that it is simple enough to maintain, but
+otherwise gives more control over it.
+
+On Mon, Mar 25, 2002 at 09:39:00PM -0300, Livio Baldini Soares wrote:
+> Howdy Dillo people,
+> 
+> This patch is an incremental patch to my previous patch which adds
+> pixmap (XPM) support to Dillo (see:
+> http://www.geocrawler.com/lists/3/SourceForge/702/0/8209368/).
+> 
+> It relies on that support to effectively display a "404" pixmap on
+> 404 or redirections for non-root URLs. It basically adds a pixmap in
+> src/xpm.h called notfound_xpm. I tried to do frowning face by hand (I
+> know it's ugly, but it's just for testing). You can replace it with
+> whichever XPM you prefer.
+> 
+> But the "real" changes are located in the cache.c, they're only
+> about 5 lines "setting up" the entry data. The patch is at:
+> 
+> http://www.ime.usp.br/~livio/dillo/patches/notfound-pixmap.diff
+> 
+> As always, please send feedback!
+
+I planned to reuse the code which reads the image data (anything
+before DwImage) for background images, and I doubt that such a
+background is pleasant for the user ;-) Rather, backgrounds should
+then simply not be seen (perhaps, the user could silently be
+notified).
+
+An idea I had already, was to implement the display of failures in
+DwImage. Some time ago, I wrote something about an interface, which
+replaces (mostly) DwImage in the image code which does not actually
+display images, and is implemented by DwImage and the code handling
+backgrounds. An idea is to add a failed message, which is called for
+any broken images (40x, corrupt data), which is ignored by
+backgrounds, but puts an DwImage into a state, in which is showed that
+an error has occurred.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev][RFC] Pixmap (XPM) image support [Patch 1/3]
+
+From: Pekka Lampila <medar@ka...> - 2002-03-26 17:17
+
+On Mon, 25 Mar 2002 22:09:26 -0300
+Livio Baldini Soares <livio@im...> wrote:
+
+> Does anyone know here "de facto" if gdk-pixbuf does progressive
+> loading of images from an in-memory buffer? Or of another "well
+> established" light library which does this?
+
+http://developer.gnome.org/doc/API/gdk-pixbuf/gdkpixbufloader.html
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+Re: [Dillo-dev][RFC] Pixmap (XPM) image support [Patch 1/3]
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-26 01:09
+
+Hello Michael!
+
+Michael Taht writes:
+> I don't know if this has been discussed before, but why not bite the
+> bullet and evolve up to the gdk-pixbuf library? 
+
+Well to tell you the truth, I have been giving thought about this
+issue too... to use an external image library, like gdk-pixbuf or
+imlib, etc.
+
+I see advantages and disadvantages to this, but I haven't really
+convinced myself which is better. Some people seem to like that Dillo
+does not depend on big graphics libraries. On the other hand,
+maintaining various image codes is not very good for development... 
+
+What are opinions from other developers? Jorge? Sebastian?
+
+> I believe it supports progressive loading of a variety of image
+> types.
+
+Well _this_ (IMHO) is the main reason for not changing to an image
+library. I haven't seen any library which does progressive in-memory
+loading of any type of images. This information can be wrong, but
+look at the gdk-pixbuf/io-xpm.c comment (from GTK 2.0.0):
+
+/*
+* FIXME xpm loading progressively is not properly implemented.
+* Instead we will buffer to a file then load that file when done.
+* This is very broken but it should be relayively simple to fix
+* in the future.
+*/
+
+(Which is quite horrible.. they use a temporary file in /tmp/... :(
+
+Anyway, my knowledge of most image libraries is _very_ limited, so
+I'll stop guessing and ask:
+
+Does anyone know here "de facto" if gdk-pixbuf does progressive
+loading of images from an in-memory buffer? Or of another "well
+established" light library which does this?
+
+If we find a good candidate, it might help out our discussion.
+
+best regards,
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev][RFC] Broken pixmap on 404 non-root URLs [Patch 2/3]
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-26 00:39
+
+Howdy Dillo people,
+
+This patch is an incremental patch to my previous patch which adds
+pixmap (XPM) support to Dillo (see:
+http://www.geocrawler.com/lists/3/SourceForge/702/0/8209368/).
+
+It relies on that support to effectively display a "404" pixmap on
+404 or redirections for non-root URLs. It basically adds a pixmap in
+src/xpm.h called notfound_xpm. I tried to do frowning face by hand (I
+know it's ugly, but it's just for testing). You can replace it with
+whichever XPM you prefer.
+
+But the "real" changes are located in the cache.c, they're only
+about 5 lines "setting up" the entry data. The patch is at:
+
+http://www.ime.usp.br/~livio/dillo/patches/notfound-pixmap.diff
+
+As always, please send feedback!
+
+The next patch should be the unhandled MIME type patch... but it
+might be ready only for tomorrow.
+
+kind regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev][RFC] Pixmap (XPM) image support [Patch 1/3]
+
+From: Michael Taht <mtaht@mv...> - 2002-03-25 23:50
+
+I don't know if this has been discussed before, but why not bite the
+bullet and evolve up to the gdk-pixbuf library? 
+
+I believe it supports progressive loading of a variety of image types.
+
+On Mon, 2002-03-25 at 15:02, Livio Baldini Soares wrote:
+> Hello Dillo people!
+> 
+> On my quest to squash bug #81 (see
+> http://www.geocrawler.com/lists/3/SourceForge/702/0/8169781/ for
+> previous post), Andreas suggested I try to combine my fix with bug
+> #245 (broken images). So I have adopted that bug too, and will try to
+> kill them all with a bottom-up strategy.
+> 
+> First of all, I needed a generic way to insert an image inside
+> Dillo's page from within the cache module ('cause the cache is the one
+> which will detect missing images/unhandled mime types, etc). I thought
+> of various ways to do this, but the most natural was using a pixmap
+> (XPM) renderer. This is my motivation: _internal use_.
+> 
+> I have passed the last weekend implementing this. Basically I
+> started from GTK's 1.2.10 gdkpixmap.c and GTK's 2.0.0
+> gdk-pixbuf/io-xpm.c. There were two problems there. First there was a
+> lot of stuff which could be simplified for Dillo's use. I've tried to
+> do this and I think only two functions are still similar to the GTK's
+> version.
+> 
+> The second (and most important and troublesome), was that GTK's
+> pixmap render is synchronous, ie, it must have _all_ the data before
+> it can start rendering. I've made it possible to do a progressive
+> render.
+> 
+> So, now dillo has support for <image/x-xpixmap>. I know that noone
+> actually uses xpm's out there, and probably no other browser
+> implements it, but I figured since I implemented for internal use, why
+> not do it "right" and make it robust/progressive.
+> 
+> The patch is at (against CVS from 25-Mar-2002):
+> http://www.ime.usp.br/~livio/dillo/patches/pixmap-support.diff
+> 
+> There is a test page here:
+> http://www.ime.usp.br/~livio/dillo/xpm-test/
+> 
+> The first two images will not appear (there are purposely broken to
+> test the next patch I'll be sending to the list), but the next 5 xpms
+> should render perfectly.
+> 
+> Does anybody see a better way of doing this in Dillo than what I
+> proposed? Comments are always very welcome!
+> 
+> PS: There seems to be a _very_ rare "glitch" in my code. I can't
+> reproduce it, but sometimes the XPM is rendered incorrectly... by
+> pressing Back and Forward, or Reload, it re-renders fine. I stared at
+> the code for about 2 hours and couldn't see what's causing it. If
+> anyone sees this problem and has either a fix or a reproducible case,
+> please contact me!
+> 
+> best regards to all,
+> 
+> -- 
+> Livio <livio@im...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev][RFC] Pixmap (XPM) image support [Patch 1/3]
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-25 23:02
+
+Hello Dillo people!
+
+On my quest to squash bug #81 (see
+http://www.geocrawler.com/lists/3/SourceForge/702/0/8169781/ for
+previous post), Andreas suggested I try to combine my fix with bug
+#245 (broken images). So I have adopted that bug too, and will try to
+kill them all with a bottom-up strategy.
+
+First of all, I needed a generic way to insert an image inside
+Dillo's page from within the cache module ('cause the cache is the one
+which will detect missing images/unhandled mime types, etc). I thought
+of various ways to do this, but the most natural was using a pixmap
+(XPM) renderer. This is my motivation: _internal use_.
+
+I have passed the last weekend implementing this. Basically I
+started from GTK's 1.2.10 gdkpixmap.c and GTK's 2.0.0
+gdk-pixbuf/io-xpm.c. There were two problems there. First there was a
+lot of stuff which could be simplified for Dillo's use. I've tried to
+do this and I think only two functions are still similar to the GTK's
+version.
+
+The second (and most important and troublesome), was that GTK's
+pixmap render is synchronous, ie, it must have _all_ the data before
+it can start rendering. I've made it possible to do a progressive
+render.
+
+So, now dillo has support for <image/x-xpixmap>. I know that noone
+actually uses xpm's out there, and probably no other browser
+implements it, but I figured since I implemented for internal use, why
+not do it "right" and make it robust/progressive.
+
+The patch is at (against CVS from 25-Mar-2002):
+http://www.ime.usp.br/~livio/dillo/patches/pixmap-support.diff
+
+There is a test page here:
+http://www.ime.usp.br/~livio/dillo/xpm-test/
+
+The first two images will not appear (there are purposely broken to
+test the next patch I'll be sending to the list), but the next 5 xpms
+should render perfectly.
+
+Does anybody see a better way of doing this in Dillo than what I
+proposed? Comments are always very welcome!
+
+PS: There seems to be a _very_ rare "glitch" in my code. I can't
+reproduce it, but sometimes the XPM is rendered incorrectly... by
+pressing Back and Forward, or Reload, it re-renders fine. I stared at
+the code for about 2 hours and couldn't see what's causing it. If
+anyone sees this problem and has either a fix or a reproducible case,
+please contact me!
+
+best regards to all,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]OpenSSL/Cookies Patch for Dillo 0.6.4
+
+From: Willem van Engen <wvengen@st...> - 2002-03-25 14:19
+
+Thanks for the patch! However, my configure fails; there seems to be an
+error in the automake/autoconf generated configure. I tried to hack around
+this one error, but there are many other errors. So the generated
+configure looks really broken. What version of autoconf and automake did
+you use? I currently have automake 1.5 and autoconf 2.53.
+
+- Willem van Engen
+
+(After successful patching)
+
+/usr/ports/www/dillo/work/dillo-0.6.4# uname -a
+
+FreeBSD foo 4.5-STABLE FreeBSD 4.5-STABLE #1: Sat Feb 2 06:36:47 CET 2002
+wvengen@foo:/usr/obj/usr/src/sys/FOO i386
+
+/usr/ports/www/dillo/work/dillo-0.6.4# automake
+
+automake: configure.in: required file `./depcomp' not found
+/usr/local/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
+/usr/local/share/automake/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL
+
+/usr/ports/www/dillo/work/dillo-0.6.4# autoconf
+
+/usr/ports/www/dillo/work/dillo-0.6.4# ./configure --includedir="/usr/local/include" --libdir="/usr/local/lib" --with-jpeg-inc="/usr/local/include" --enable-ssl
+
+checking for a BSD-compatible install... /usr/bin/install -c
+checking whether build environment is sane... yes
+checking whether make sets ${MAKE}... yes
+checking for working aclocal... found
+checking for working autoconf... found
+checking for working automake... found
+checking for working autoheader... found
+checking for working makeinfo... found
+checking for gcc... gcc
+checking for C compiler default output... a.out
+checking whether the C compiler works... yes
+checking whether we are cross compiling... no
+checking for suffix of executables... 
+checking for suffix of object files... o
+checking whether we are using the GNU C compiler... yes
+checking whether gcc accepts -g... yes
+checking for gcc option to accept ANSI C... none needed
+checking for ranlib... ranlib
+checking for gtk-config... /usr/X11R6/bin/gtk-config
+checking for GTK - version >= 1.2.0... yes
+checking for jpeg_destroy_decompress in -ljpeg... yes
+checking how to run the C preprocessor... gcc -E
+checking for ANSI C header files... yes
+checking for sys/types.h... yes
+checking for sys/stat.h... yes
+checking for stdlib.h... yes
+checking for string.h... yes
+checking for memory.h... yes
+checking for strings.h... yes
+checking for inttypes.h... yes
+checking for stdint.h... no
+checking for unistd.h... yes
+checking jpeglib.h usability... yes
+checking jpeglib.h presence... yes
+checking for jpeglib.h... yes
+checking jconfig.h usability... yes
+checking jconfig.h presence... yes
+checking for jconfig.h... yes
+checking jerror.h usability... yes
+checking jerror.h presence... yes
+checking for jerror.h... yes
+checking jmorecfg.h usability... yes
+checking jmorecfg.h presence... yes
+checking for jmorecfg.h... yes
+./configure: line 3439: syntax error near unexpected token `;}'
+./configure: line 3439: `LIBS="-lssl rejected by the preprocessor!" >&2;}'
+
+/usr/ports/www/dillo/work/dillo-0.6.4# cat configure | head -n 3445 | tail -n 10
+
+echo $ECHO_N "checking for SSL_connect in -lssl... $ECHO_C" >&6
+if test "${ac_cv_lib_ssl_SSL_connect+set}" = set; then
+echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ac_check_lib_save_LIBS=$LIBS
+LIBS="-lssl rejected by the preprocessor!" >&2;}
+{ echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
+no:yes $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+
+/usr/ports/www/dillo/work/dillo-0.6.4# 
+
+
+
+Re: Re: [Dillo-dev]download behavior
+
+From: Paul Chamberlain <tif@ti...> - 2002-03-24 23:12
+
+From Mark Schreiber <mark7@an...> -----
+> * Use MIME types, file extensions, *and* protocol names to specify the
+> helper program.
+
+plural... I think I should be able to specify several handlers
+for a mime type, file extension, etc. and have the menu offer
+each of them. Sometimes I want to view it, sometimes I want
+to edit it, sometimes I want to print it, etc. In particular,
+I have several image-viewers with different strengths.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+[Dillo-dev]OpenSSL/Cookies Patch for Dillo 0.6.4
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-03-24 15:20
+
+At the request of a Dillo user, I've posted my OpenSSL/Cookies patch for
+version 0.6.4 at
+
+http://members.bellatlantic.net/~vze2mqqv/dillo-ssl-cookies.0.6.4.diff
+
+This is not a patch for the faint of heart. To deal with SSL Proxy
+Tunnelling, I essentially had to rewrite the I/O engine. I will not be
+maintaining this patch against CVS versions, as I believe Jorge has his
+own plans for SSL. If that's not the case, I'll recreate it for the
+next major release.
+
+To apply the patch, download it into your dillo source root directory and...
+
+patch -p1 <./dillo-ssl-cookies.0.6.4.diff
+automake
+autoconf
+./configure --enable-ssl
+make
+./src/dillo https://www.so....net/ # simple test case
+make install
+
+Best of luck.
+
+-js
+
+-- 
+-Jonathan P Springer <jonathan.springer@ve...>
+------------------------------------------------------------------------------
+"A standard is an arbitrary solution to a recurring problem." - Joe Hazen 
+
+
+
+Re: [Dillo-dev]download behavior
+
+From: Stephen Lewis <slewis@pa...> - 2002-03-23 20:56
+
+On Sat, 23 Mar 2002 15:40:53 -0500
+Mark Schreiber <mark7@an...> wrote:
+
+> * Be able to download a file and then hand it to a helper program *or*
+> just pass the URL as an argument to the helper program.
+
+I think rather than having an exclusive choice like that, it'd be nice to
+have two separate modules - 'download', and 'post-process'.
+This would let you use, say, wget to download, and then still be
+able to execute an external app after its done downloading based on its 
+mime-type to display the downloaded file.
+
+Stephen Lewis 
+
+
+
+Re: [Dillo-dev]download behavior
+
+From: Mark Schreiber <mark7@an...> - 2002-03-23 20:41
+
+On Fri, Mar 22, 2002 at 08:06:54AM -0500, Imad Hussain wrote:
+> On Fri, 22 Mar 2002 13:24:45 +0100
+> Tomas <tomas@pu...> wrote:
+> <SNIP>
+> > I just wondering if this behaviour is what you want or is going to be
+> > change in the future.
+> > 
+> > Also ask if there is any planning of implement resume for file
+> > downloading.
+> 
+> Y'know, it would be pretty nice if you could force dillo to use an
+> external utility (e.g. wget) to take care of file downloads completely.
+> I'd imagine the changes necessary to the source would not be monumental
+> in scope -- and for those without wget (or whatever), this could be
+> controlled by an option in .dillorc. It takes much of the burden off of
+> dillo itself; after all, why reinvent the wheel?
+
+A navigator style interface would be really nice, with "helpers".
+I've wished for the ability to make mailto: links open in mutt for
+some time.
+
+I'd suggest that such a system:
+
+* Be able to download a file and then hand it to a helper program *or*
+just pass the URL as an argument to the helper program.
+
+* Be able to hand components of URLs to external programs. If you
+take a look in Navigator's preferences dialog, you'll see lines like
+
+telnet rxvt -e telnet %h %p
+
+This lets navigator hand just the host and the port off. Since a
+lot of programs can't take a whole URL, this is really useful.
+%h host
+%u username
+%p port
+%s download file and replace with name of local file
+
+* Use MIME types, file extensions, *and* protocol names to specify the
+helper program.
+
+* Use /etc/mime.types if present to obtain mime type/extension
+mappings.
+
+* To improve startup speed (Navigator starts slowly because it has to
+parse zillions of files each startup), it might be worthwhile to do
+all the parsing work lazily -- don't do it for an instance of dillo
+until dillo runs across something it doesn't understand how to
+handle locally.
+
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+Re: [Dillo-dev]navigation feature
+
+From: Mark Schreiber <mark7@an...> - 2002-03-23 19:25
+
+On Thu, Mar 21, 2002 at 06:05:51PM -0600, John Utz wrote:
+> i sent a patch in months ago to do the 'back' part.
+> 
+> but it never showed up in the release (dillo-6.3).
+> 
+> sort of takes the wind out of one's sails when it comes to contributing 
+> patches.....
+
+Speaking of which, is there any reason that the dillo project avoids
+using the sourceforge patch/bug tracking engines?
+
+I'll grant that the bug tracking engine it does use is fast and
+lightweight...but the sourceforge system does have some nice features:
+
+* I really wish I could follow-up on bugs with questions or comments.
+The SF bug tracker lets people view bugs and comment on them. Jorge
+has stated that he'd like to keep this ML low traffic -- which means
+not sending all replies about patches to the list. However, if you
+reply directly to the person, you do not allow anyone else to
+identify problems with your comments or answer your questions. SF's
+bug tracker could handle this.
+
+* It feels more rewarding to have a patch sitting in the patch manager
+than to email it away and not see it again until it gets in the
+source.
+
+* Dropping patches in a patch manager lets other people possibly
+identify problems without Jorge having to run through them all
+first.
+
+* I accidently sent a partial patch to Jorge some time ago. Since I
+was using email, I had to send an entire second copy, which puts the
+burden of dealing with the mistake on him -- not ideal. Using a
+patch manager, I could have removed the incorrect file and attached
+the correct one, adding a followup noting what I did.
+
+* If a patch is in the patch manager, it lets people try it out if
+they want to (or desperately need that specific functionality, and
+aren't worried about it passing the maintainer's scrutiny).
+Granted, you can email dillo-dev, but that cuts into the low-traffic
+guideline.
+
+* Adds documentation that the person did some work on a piece of
+software, which always feels good. That patch entry will probably
+be around (though closed) for as long as sourceforge is around.
+
+* It's easy to see what patches were added for the last release. My
+table rendering patch made it into CVS (Woohoo! Thanks Jorge!), but
+there isn't a Changelog entry or any other way of knowing that the
+table rendering code differs in this release. If all of a sudden a
+webpage starts crashing CVS dillo, and the only changes since the
+last working copy were two config file parsing changes and some
+rendering change it's handy to have a document that you can glance
+at and say "ah, must be the XYZ changes...I'll start looking there
+for the source of the problem".
+
+* Security. Not all patch managers do this, but SF's allows you to
+log in and submit authenticated patches. Maybe not a huge deal for
+dillo since dillo isn't a server, but it avoids spoofed email "from
+core developers" to Jorge that could introduce unwanted
+"functionality".
+
+* Reliability. Right now, pending patches are spread out around the
+world on various hard drives (or may even have been deleted). Jorge
+probably has a complete set, but what if he suffers a hard drive
+crash? If SF has a set of patches, suddenly having everything
+vanish in one catastrophic incident isn't an issue.
+
+* Finally, with a patch manager, you know that the patch got there.
+There's no "was my mailserver misbehaving, or is the maintainer just
+busy ATM?" worries.
+
+Cons:
+
+* Dillo doesn't currently do https, which you have to do if you want
+patches attributed to a SF account and authenticated. Dunno whether
+you can submit non-logged in patches with dillo -- I haven't tried.
+(Cookie support may even be required...again, I haven't looked) I
+can see that it might be a bit embarassing to currently have to use
+a browser other than dillo to submit patches for dillo.
+
+Anyway, is there some reason I'm missing?
+
+My own currently pending dillo patches are up at
+<http://ion.res.cmu.edu/schreib1/current_patches/>, if anyone wants to
+try 'em or send feedback.
+
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+Re: [Dillo-dev]CVS
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-03-23 02:39
+
+Hi!
+
+fre 2002-03-22 klockan 08.43 skrev Calvin Arndt:
+> downloaded CVS yesterday... says 0.6.5pre1!!!!!!!!!
+>=20
+> compiled -- successfully
+>=20
+> executed -- successfully
+>=20
+> tried http://www.google.com
+>=20
+> tried to set my preferences on google.com
+>=20
+> :-(=20
+>=20
+> google say's cookies aren't enabled (even though they are in dillorc)
+>=20
+> google.com ACCEPT
+
+You mention dillorc, so just to be sure, That line should be in
+~/.dillo/cookiesrc
+
+Also, the line should probably be one of:
+.google.com ACCEPT
+http://www.google.com ACCEPT
+
+HTH,
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]download behavior
+
+From: Imad Hussain <magius@pu...> - 2002-03-22 13:03
+
+On Fri, 22 Mar 2002 13:24:45 +0100
+Tomas <tomas@pu...> wrote:
+<SNIP>
+> I just wondering if this behaviour is what you want or is going to be
+> change in the future.
+> 
+> Also ask if there is any planning of implement resume for file
+> downloading.
+
+Y'know, it would be pretty nice if you could force dillo to use an
+external utility (e.g. wget) to take care of file downloads completely.
+I'd imagine the changes necessary to the source would not be monumental
+in scope -- and for those without wget (or whatever), this could be
+controlled by an option in .dillorc. It takes much of the burden off of
+dillo itself; after all, why reinvent the wheel?
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+[Dillo-dev]download behavior
+
+From: Tomas <tomas@pu...> - 2002-03-22 12:24
+
+Attachments: Message as HTML      
+
+Hi all,
+
+I'm trying to do a downloading button in the toolbar like it's said in the
+documentation just to understand dillo source.
+
+Now the files are cached so if you donwload a couple of big files the
+amount of memory used by dillo grows in the same size.=20
+Also if you try to save a very big file like an iso-image of 600Mb it
+fails to allocate this amount of memory:=20
+
+GLib-ERROR **: could not allocate 667461632 bytes
+aborting...
+Aborted
+
+I just wondering if this behaviour is what you want or is going to be
+change in the future.
+
+Also ask if there is any planning of implement resume for file
+downloading.
+
+
+greets=20
+
+Tomas 
+
+
+
+[Dillo-dev]CVS
+
+From: Calvin Arndt <calarndt@ya...> - 2002-03-22 07:43
+
+downloaded CVS yesterday... says 0.6.5pre1!!!!!!!!!
+
+compiled -- successfully
+
+executed -- successfully
+
+tried http://www.google.com
+
+tried to set my preferences on google.com
+
+:-( 
+
+google say's cookies aren't enabled (even though they are in dillorc)
+
+google.com ACCEPT
+
+set number of results=100
+
+saved prefs
+
+no of results returned == 10
+
+:-(
+:-(
+
+cookies are not detected by google!
+
+just thought you might like to know...
+
+cal...
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Movies - coverage of the 74th Academy Awards®
+http://movies.yahoo.com/ 
+
+
+
+Re: [Dillo-dev]navigation feature
+
+From: John Utz <john@ut...> - 2002-03-22 00:06
+
+i sent a patch in months ago to do the 'back' part.
+
+but it never showed up in the release (dillo-6.3).
+
+sort of takes the wind out of one's sails when it comes to contributing 
+patches.....
+
+On Thu, 21 Mar 2002, Imad Hussain wrote:
+
+> On Thu, 21 Mar 2002 00:04:25 +0200 (GMT-2)
+> madis@cy... wrote:
+> 
+> > 
+> > here is a small patch to add back/forward commands as first items into
+> > dillo context menu. why? because i got quite used to opera mouse
+> > gestures and after that found in galeon, that this kind of context
+> > menu usage is quite comfortable, when compared with moveing mouse over
+> > the screen to back button... and then back to scroll... i have used
+> > this patch now some time and it seems to be good for myself, so maybe
+> > its useful?
+> 
+> Oh, I'd been looking for a similar patch -- glad to see it's so simple.
+> ;) Didn't Dillo used to have back and forward on the context menu? Or
+> was that something just in the literature a few versions back?
+> 
+> 
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]navigation feature
+
+From: Imad Hussain <magius@pu...> - 2002-03-21 23:51
+
+On Thu, 21 Mar 2002 00:04:25 +0200 (GMT-2)
+madis@cy... wrote:
+
+> 
+> here is a small patch to add back/forward commands as first items into
+> dillo context menu. why? because i got quite used to opera mouse
+> gestures and after that found in galeon, that this kind of context
+> menu usage is quite comfortable, when compared with moveing mouse over
+> the screen to back button... and then back to scroll... i have used
+> this patch now some time and it seems to be good for myself, so maybe
+> its useful?
+
+Oh, I'd been looking for a similar patch -- glad to see it's so simple.
+;) Didn't Dillo used to have back and forward on the context menu? Or
+was that something just in the literature a few versions back?
+
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+[Dillo-dev]plugin interface redesign?
+
+From: Geoff Lane <zzassgl@tw...> - 2002-03-21 15:34
+
+How is the new plugin interface coming along?
+
+I have some ideas about pop3:, imap: and news: I'd like to try which really
+should be implemented as plugins but have been reluctant to start without at
+least a hint of what the new interface will look like.
+
+Thanks
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\ 
+
+
+
+Re: [Dillo-dev]About bug #81
+
+From: Andreas Schweitzer <andy@ph...> - 2002-03-21 14:44
+
+????
+What the ... did my mail client just do ?
+
+I wanted to suggest solution 3 in combination with Bug 245
+(broken images). And one could also have 2 icons - one
+for broken image and one for unkmown type.
+
+Cheers
+Andreas
+
+(Hoping that bottom quoting makes this mail go through ...)
+
+On Thu, Mar 21, 2002 at 09:38:49AM -0500, Andreas Schweitzer wrote:
+> Hi
+> 
+> > Ok, that seems quite fine to me, but there is a little problem with
+> > non-root URL's. For example:
+> > http://www.libmng.com/MNGsuite/basic_img.html
+> > 
+> > Has 3 non-root images. What should I do in this case? 
+> > 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]About bug #81
+
+From: Andreas Schweitzer <andy@ph...> - 2002-03-21 14:38
+
+Hi
+
+> Ok, that seems quite fine to me, but there is a little problem with
+> non-root URL's. For example:
+> http://www.libmng.com/MNGsuite/basic_img.html
+> 
+> Has 3 non-root images. What should I do in this case? 
+> 
+
+
+
+[Dillo-dev]About bug #81
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-21 12:38
+
+Hello!
+
+I've started fixing bug #8 yesterday (trying to view anything other
+than text, images or HTML). What I did was to offer the user a
+`download' option. So far it's working out ok, and I try to click on a
+link that points to a FLASH file, PS, PDF, etc, it instantly opens up
+the "Save File as..." window.
+
+Ok, that seems quite fine to me, but there is a little problem with
+non-root URL's. For example:
+http://www.libmng.com/MNGsuite/basic_img.html
+
+Has 3 non-root images. What should I do in this case? 
+
+[1] Should I make instantly open 3 "Save as..." windows? (not very
+nice for the user.. imagine 20 MNG images on a single page :(.
+
+[2] Should I open the windows one at a time? (ugly solution too...)
+
+[3] Should I ignore non-root files?
+
+I'm leaning towards solution number 3. So my patch would only change
+Dillo's behaviour with regard to root URLs, i.e. when the user
+consciously clicks on a certain link/file which Dillo doesn't treat.
+
+But I'm not sure this is the best solution. Anyone have any
+suggestions? Better ideas are welcome! ;)
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]CIPSGA
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-20 22:45
+
+Hi everyone!
+[there's more to this mail than what's apparent to the eye]
+
+On Wed, 20 Mar 2002, Livio Baldini Soares wrote:
+
+> > > > Congratulations on this patch J=F6rgen and Lars!
+> >
+> > FWIW, I made a 35Kb patch over the original 31Kb original
+> > version, fixing a big list of problems, and no one noticed? :(
+>
+> Of course we notice (at least I do!), Jorge. But you get no thanks,
+> you're the maintainer! It's your _job_! ;-)
+
+! :-)
+
+> Seriously though, I have a feeling that Dillo has less developers
+> than most open source projects I've seen out there (I could be
+> wrong). So I have an "evil plan" to stimulate our current developers to
+> produce more & better (giving them lots of thanks.. and who knows,
+> beer too! ;). Hope it starts working soon!
+
+Pay attention please!
+
+There's a lot of background activity here, and one of those
+things is the move from SF to a new site. Livio has uploaded the
+site already (facilities were provided by cipsga, thanks go to
+Marcelo, Kov and Henrique).
+
+The new site's at: http://dillo.cipsga.org.br/
+
+It hasn't yet been blessed as our official site, but please go
+there and test it, specially those of you from Europe, so we can
+get a feel of how the connection behaves.
+
+As for the bugtrack, keep using the SF one, until we decide to
+keep going from cipsga.
+
+
+The next step is to create the mailing-lists there, and to set
+search capabilities. Probably CVS will be the last thing to move.
+
+I wish to release the next dillo version from cipsga, and thus
+make it official "urbi et orbi".
+
+Most of you ignore the fact that SF download counters had been
+wrong for more than a year (yes I know what I'm saying); just
+think of all the statistics, project ratings, press coverage et
+related stuff that has been silently delivered broken...
+
+Well, I hope we can finally get a good estimate of our current
+user base. From the extensive mail archive I have here, comes the
+fact that dillo is known in at least 37 different countries!!!
+(yes, from every continent!)
+
+Dillo project is steadily gaining more attention, and I'm sure
+that the new release will be another big step forward as lots of
+people will be able to start using their web-based mail with
+dillo.
+
+As for new developers, I've always said that this is not an
+easy project to work in. The average is 6 months for new
+developers to start sending clean patches, and now, I'm crossing
+fingers for some freshmen to surpass the magic threshold.
+
+With regard to funding (remember 2002 plans?), I'm working on a
+presentation page to address meta information as: objectives,
+current state, future plans, whys, whats, advantages,
+proyections, required money, etc. In summary, very interesting
+info, aimed to the non-technical reader but worth reading to all
+of us.
+
+
+Best
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Dillo on Solaris 8..
+
+From: Yu-Fong Cho <yfcho@ms...> - 2002-03-20 22:11
+
+Please give me some information about this.
+
+I know this is not a development problem, but I am trying install Dillo on
+different platforms for interest. I have done on FreeBSD 4.5 and now are
+trying on Solaris 8 x86. Just give me some information about this and I'll
+appreciate it.
+
+Thank you.
+
+
+-----Original Message-----
+From: dillo-dev-admin@li...
+[mailto:dillo-dev-admin@li...]On Behalf Of Yu-Fong Cho
+Sent: Tuesday, March 19, 2002 12:46 PM
+To: Dillo Dev
+Subject: [Dillo-dev]Dillo on Solaris 8..
+
+
+Hi,
+
+Has anyone tried run Dillo 0.6.4 on Solaris 8 before?
+
+I compiled and installed it. It seems be ok except the way it handle jpeg
+image.
+The jpeg image shows only black and while mode and has some vertical line on
+it. It isn't right.
+
+I have GNU jpeg and zlib installed. Does anyone know what is going on?
+I tried Dillo on FreeBSD 4.5 before and it was ok.
+
+Appreciate any information. Thank you.
+
+
+Yu-Fong Cho
+
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]navigation feature
+
+From: <madis@cy...> - 2002-03-20 21:53
+
+Attachments: patch-dillo-menu      
+
+here is a small patch to add back/forward commands as first items into 
+dillo context menu. why? because i got quite used to opera mouse gestures 
+and after that found in galeon, that this kind of context menu usage is 
+quite comfortable, when compared with moveing mouse over the screen to 
+back button... and then back to scroll... i have used this patch now some 
+time and it seems to be good for myself, so maybe its useful?
+
+--
+mzz 
+
+
+
+Re: [Dillo-dev]Cookies patch on Solaris
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-20 21:22
+
+Howdy!
+
+Jorge Arellano Cid writes:
+> 
+> Hi there,
+> 
+> > Otherwise, I could use dillo with cookies happily (on AIX with strsep) and
+> > it only was "vulnerable" to the NULL pointer bug that was fixed
+> > recently.
+> >
+> > > Congratulations on this patch Jörgen and Lars!
+> 
+> FWIW, I made a 35Kb patch over the original 31Kb original
+> version, fixing a big list of problems, and no one noticed? :(
+
+Of course we notice (at least I do!), Jorge. But you get no thanks,
+you're the maintainer! It's your _job_! ;-)
+
+Seriously though, I have a feeling that Dillo has less developers
+than most open source projects I've seen out there (I could be
+wrong). So I have an "evil plan" to stimulate our current developers to
+produce more & better (giving them lots of thanks.. and who knows,
+beer too! ;). Hope it starts working soon!
+
+BTW: Oh Jorge... congratulations you too on this nice patch!
+(HEheh.. my evil plan is being extended to maintainers ;)
+
+(... sorry 'bout the nonsense e-mail ...)
+
+best regards to all! 
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Cookies patch on Solaris
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-20 20:48
+
+Hi there,
+
+> Otherwise, I could use dillo with cookies happily (on AIX with strsep) an=
+d
+> it only was "vulnerable" to the NULL pointer bug that was fixed
+> recently.
+>
+> > Congratulations on this patch J=F6rgen and Lars!
+
+FWIW, I made a 35Kb patch over the original 31Kb original
+version, fixing a big list of problems, and no one noticed? :(
+
+This is very important to me because that was the main reason
+for the cookies patch not being integrated earlier; there was a
+lot to do, fix and stabilize. Not lack of interest!
+
+BTW, the bugtrack shows 95%. i.e. there're still things to work
+on; as the strsep() for instance.
+
+
+Thanks
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Cookies patch on Solaris
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-20 20:48
+
+Hi,
+
+On Tue, 19 Mar 2002, Livio Baldini Soares wrote:
+
+> Anyway, CVS Dillo works well with Linux, but doesn't compile on
+> Solaris (5.7), unless I --disable-cookies. The problem is that the new
+> cookies.c uses the strsep() function, which is not available. I have
+> substituted the strsep() with strtok() which, if I'm not mistaken, is
+> a POSIX call, and does the "same" thing, no?
+>
+> This is an _untested_ patch:
+> http://www.ime.usp.br/~livio/dillo/patches/strsep_to_strtok.diff
+
+We had get rid of strtok() due to its potential problems, so
+I decided to implement a custom strsep in misc.c. Now in CVS!
+Please test it.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Cookies patch on Solaris
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-20 17:31
+
+Jorgen Viksell writes:
+> Hi!
+
+[...]
+
+> Unfortunately, strtok() doesn't handle empty pieces (in this case, two
+> tabs in a row).
+
+Ah.. you're right! :(
+
+> Looks like we have to write our own stuff here. Shouldn't take too long
+> though...
+
+Well it seems that someone (?) implemented a simple version of
+strsep() inside misc.c, and now the Solaris version is working fine
+once again.
+
+best regards,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Cookies patch on Solaris
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-03-20 15:48
+
+Hi!
+
+ons 2002-03-20 klockan 03.19 skrev Livio Baldini Soares:
+> Hello!
+>=20
+> Well, I'm happy to see that Dillo CVS now has Cookies :-)=20
+> I haven't been able to test them though, but I guess they be very
+> useful to me when authentication and SSL are implemented.
+>=20
+> Anyway, CVS Dillo works well with Linux, but doesn't compile on
+> Solaris (5.7), unless I --disable-cookies. The problem is that the new
+> cookies.c uses the strsep() function, which is not available. I have
+> substituted the strsep() with strtok() which, if I'm not mistaken, is
+> a POSIX call, and does the "same" thing, no?
+
+Unfortunately, strtok() doesn't handle empty pieces (in this case, two
+tabs in a row).
+Looks like we have to write our own stuff here. Shouldn't take too long
+though...
+
+> This is an _untested_ patch:
+> http://www.ime.usp.br/~livio/dillo/patches/strsep_to_strtok.diff
+>=20
+> Congratulations on this patch J=F6rgen and Lars!
+
+Thanks! :-)
+
+> best regards! =20
+>=20
+> -- =20
+> Livio <livio@im...>
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Cookies patch on Solaris
+
+From: Andreas Schweitzer <andy@ph...> - 2002-03-20 06:37
+
+Hi
+
+> Anyway, CVS Dillo works well with Linux, but doesn't compile on
+> Solaris (5.7), unless I --disable-cookies. The problem is that the new
+> cookies.c uses the strsep() function, which is not available. I have
+> substituted the strsep() with strtok() which, if I'm not mistaken, is
+> a POSIX call, and does the "same" thing, no?
+
+I did the same thing on AIX. However, AIX has also other issues :-)
+
+Otherwise, I could use dillo with cookies happily (on AIX with strsep) an=
+d
+it only was "vulnerable" to the NULL pointer bug that was fixed
+recently.
+
+> Congratulations on this patch J=F6rgen and Lars!
+
+I second that ! :-)
+
+Cheers
+Andreas
+
+--=20
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Cookies patch on Solaris
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-20 02:19
+
+Hello!
+
+Well, I'm happy to see that Dillo CVS now has Cookies :-) 
+I haven't been able to test them though, but I guess they be very
+useful to me when authentication and SSL are implemented.
+
+Anyway, CVS Dillo works well with Linux, but doesn't compile on
+Solaris (5.7), unless I --disable-cookies. The problem is that the new
+cookies.c uses the strsep() function, which is not available. I have
+substituted the strsep() with strtok() which, if I'm not mistaken, is
+a POSIX call, and does the "same" thing, no?
+
+This is an _untested_ patch:
+http://www.ime.usp.br/~livio/dillo/patches/strsep_to_strtok.diff
+
+Congratulations on this patch Jörgen and Lars!
+
+best regards! 
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Dillo on Solaris 8..
+
+From: Yu-Fong Cho <yfcho@ms...> - 2002-03-19 17:46
+
+Hi,
+
+Has anyone tried run Dillo 0.6.4 on Solaris 8 before?
+
+I compiled and installed it. It seems be ok except the way it handle jpeg
+image.
+The jpeg image shows only black and while mode and has some vertical line on
+it. It isn't right.
+
+I have GNU jpeg and zlib installed. Does anyone know what is going on?
+I tried Dillo on FreeBSD 4.5 before and it was ok.
+
+Appreciate any information. Thank you.
+
+
+Yu-Fong Cho 
+
+
+
+[Dillo-dev]Re : Dillo library and binding
+
+From: Christophe Baillon <cbaillon@it...> - 2002-03-18 13:48
+
+Thanks for your help.
+Your code works fine !
+
+I know Dw is immature, but Dillo is the only light browser
+I have found interesting. 
+
+Dillo is exactly what i need for my work !
+
+We use Dillo 0.6.4 for the Dillo library and binding.
+
+The Functionnalities provided by widgets in 0.6.4 are far above
+our expectations.
+
+
+Regards
+
+
+
+>Hi Christophe,
+
+>On Fri, Mar 08, 2002 at 10:42:30PM +0000, Christophe Baillon wrote:
+>> I am working on a Ada 95 binding of Dillo widgets. (In GPL of course!)
+>> To realize it, I need to isolate widgets in a C library.
+>> I have almost achieved it.
+>> 
+>> Libdw contains only dillo widget, without IO and cache (I removed
+>> Dw_Image at the moment) I kept few important dillo file,
+>> like url.c, findtext.c ...
+>> 
+>> The goal is to profit of specific dillo widget to make
+>> rendering in embedded applications.
+>
+>Just a few warnings before: 1. Dw is very immature, and will change
+>often. 2. Dw contains many ad hoc implementations, partly only
+>suitable for the code of dillo. E.g., there are problems when adding
+>other widgets than DwPage's to a table (will change a bit).
+>
+>Of course, if you have suggestions or improvements, send them to me.
+>
+>> I've done a C test program . It can create new dw_style,
+>> but there is a "segmentation fault" when using
+>> a_Dw_gtk_scrolled_window_set_dw to set a dw children (Dw_Ruler for
+>> instance).
+>> [...]
+>
+>The attached example works. See comments for details (especially: a
+>widget must always have a style).
+>
+>Sebastian 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-15 14:39
+
+Livio,
+
+> Jorge Arellano Cid writes:
+> >
+> > As indexed GIFs have at most 256 colors, and a corrupted gif
+> > can declare less colors (or zero), and try to access out of
+> > bounds bytes afterwards, the 256 constant provides a kind of
+> > protection against SEGFAULTS.
+>
+> [...]
+> The bug is this. Suppose an Image has only 5 colors. So you have the
+> image buffer (which is actually entry->Data, or CacheClient->Buf),
+> which is allocated in the IO system having a fixed size (say 200). So
+> we're trying to copy 256 bytes out of a 200 byte long buffer... see
+> the problem?
+>
+> I have a quick fix which was, copy _only_ gif->NumColors from the
+> image Buf, that way we don't memcpy() from invalid memory, _but also_
+> alloc more colors (and set them o zero) so if a problem GIF tries to
+> access an out of bounds colors we get no segfault.
+>
+> Watcha think?
+
+OK, I just made a few changes and commited to CVS.
+Please test it.
+
+
+Regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-15 03:32
+
+Hello!
+
+Jorge Arellano Cid writes:
+> 
+> As indexed GIFs have at most 256 colors, and a corrupted gif
+> can declare less colors (or zero), and try to access out of
+> bounds bytes afterwards, the 256 constant provides a kind of
+> protection against SEGFAULTS.
+> 
+> After a fast revision, I can't find anything wrong with it yet,
+> but what looks very suspicious to me is the 'version' number that
+> a_Dicache_set_cmap is receiving.
+> --i.e. #1 in http://www.zone.ee/myzz/dillo/cache-crash-gdb
+> 
+> That number comes from a_Dicache_add_entry and it should be
+> a simple counter (AFAIR). Livio is the author of that code, so
+> this question is for him! :)
+> 
+
+Jorge, I fixed that some time ago. Look here:
+http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/dillo/src/dicache.c.diff?r1=1.19&r2=1.20
+
+And that actually doesn't matter at all. It's just a version number
+(doesn't necessarily have to small, or even positive for the matter).
+
+The bug is this. Suppose an Image has only 5 colors. So you have the
+image buffer (which is actually entry->Data, or CacheClient->Buf),
+which is allocated in the IO system having a fixed size (say 200). So
+we're trying to copy 256 bytes out of a 200 byte long buffer... see
+the problem?
+
+I have a quick fix which was, copy _only_ gif->NumColors from the
+image Buf, that way we don't memcpy() from invalid memory, _but also_
+alloc more colors (and set them o zero) so if a problem GIF tries to
+access an out of bounds colors we get no segfault.
+
+Watcha think? 
+
+The patch is at:
+http://www.ime.usp.br/~livio/dillo/patches/gif_seg.diff
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-15 02:01
+
+On Wed, 13 Mar 2002 madis@cy... wrote:
+
+> On 11 Mar 2002, Lars Clausen wrote:
+>
+> > Yes, we've noticed that NULL bug, and how there doesn't seem to be a way to
+> > get a NULL cookie in the first place. I'm leaning towards an explanation
+> > of general memory corruption. Did you try running without the cookies
+> > patch, but linked with efence? I notice that a_Dicache_set_cmap is called
+> > only from gif.c, and there with num_colors = 256 rather than
+> > gif->NumColors. That could cause the memcpy to run over the edge of cmap,
+> > maybe.
+>
+> i tried now dillo without cookies and with efence, and the memcpy bug
+> didn't go away with cookies ;) anyway, replacing this constant 256 in
+> gif.c with "gif->NumColors < 256 ? gif->NumColors : 256" seems to
+> solve this memory corruption problem, but since i don't know exactly why
+> this constant was put there in first place i'm not sure, whether this is a
+> good fix (or is this < 256 check needed at all, i put it there because
+> gifs shouldn't have more colors and suspected that constant 256 was
+> there because some invalid gif caused NumColors go over 256).
+> http://www.zone.ee/myzz/dillo/patch-dillo-gif
+
+As indexed GIFs have at most 256 colors, and a corrupted gif
+can declare less colors (or zero), and try to access out of
+bounds bytes afterwards, the 256 constant provides a kind of
+protection against SEGFAULTS.
+
+After a fast revision, I can't find anything wrong with it yet,
+but what looks very suspicious to me is the 'version' number that
+a_Dicache_set_cmap is receiving.
+--i.e. #1 in http://www.zone.ee/myzz/dillo/cache-crash-gdb
+
+That number comes from a_Dicache_add_entry and it should be
+a simple counter (AFAIR). Livio is the author of that code, so
+this question is for him! :)
+
+
+> but fixing this gif issue didn't fixed segfault totally - when i went to
+> http://www.delfi.ee site the efence linked dillo crashed happily again and i
+> discovered bug in IO.c function IO_callback: when IO_read function decided
+> to close and delete io, following error check tried to access this deleted
+> structure and set its Status field to -EIO, which wasn't nice at all.
+> using IO_get again when error occured and checking whether it returned
+> NULL solved this.
+> http://www.zone.ee/myzz/dillo/patch-dillo-IO
+
+I reviewed this one too, and you're right. The only thing I
+need is your name for the Changelog entry!
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-14 13:47
+
+Hi there!
+
+On 12 Mar 2002, Jorgen Viksell wrote:
+
+> Hi,
+>
+> tis 2002-03-12 klockan 01.45 skrev madis@cy...:
+> >
+> > i use dillo-0.6.4 patched with patch-cookies-8jan (without openssl
+> > patch) and it crashed occasionally, most often on theregister.co.uk. so=
+i
+> > tried to use gdb to find out why, and yes, there was a NULL pointer
+> > reference in a_Cookies_get function (look http://www.zone.ee/myzz/dillo=
+/cookie-crash-gdb).
+> > but after reading code in cookies.c i had no clue, how this pointer cou=
+ld
+> > be NULL without segfaulting before [snip]
+>
+> I believe that I've found the problem. It's in a_Cookies_set(), where an
+> old cookie gets replaced. We remove it from the list but we never
+> re-insert the new start of the list in the hash table.
+>
+> There is a new patch up at:
+> http://w1.211.telia.com/~u21114235/patch-cookies-12mar.gz
+> Lots of changes made.
+
+Just to complete the information, specially for those that got
+eager for the original patch to be commited:
+
+I reviewed the first cookie full-patch, it was 31Kb, and found
+a big list of problems, so I gave it some hard work and ended up
+with a 35Kb patch on top of it, and there were still plenty of
+things to do! Now J=F6rgen has sent me a new patch (on top of both)
+that'll be reviewed ASAP.
+
+
+See ya'
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Bug 306 - ">" sign in attribute string
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-13 17:21
+
+Andreas,
+
+> I found a bug and instered it as bug 306. The good news : I also
+> have a patch. But it may be tricky, so I send it in as food for thought.
+>
+> The problem is that dillo gets confused when the > sign is in an attribute
+> string (like http://www.xwinman.org). Simply accepting a > inside a string
+> will break way too many web pages. E.g. "slahsdot->Read more" on any
+> article has
+> <INPUT TYPE="HIDDEN" NAME="op" VALUE="userlogin" %]">
+> Near the login form. Looks like broken HTML to me ...
+
+Yeah, that page is broken...
+
+But, the http://www.xwinman.org case may be different. Considering the
+XML SPEC for XHTML, we find:
+
+AttValue ::== '"' ([^<&"] | Reference)* '"' |
+"'" ([^<&'] | Reference)* "'"
+
+
+i.e. a bare '>' is allowed, but not a bare '<'.
+
+That's what I did!
+Please test the CVS and let me know how it went.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Presentation
+
+From: Tomas <tomas@pu...> - 2002-03-13 12:05
+
+Attachments: Message as HTML      
+
+Hi all,
+
+
+I'm spanish (sorry for my english in advance ;) and just finished computer =
+science,
+i'm involved in a non-profit project of a free internet workplace in
+Utrecht (Netherlands) http://www.puscii.nl and i normailly used GNU/Debian =
+as OS.
+
+First of all congratulations to all the people involved in dillo for all
+this good work, i found needed an alternative graphical web wrobser with lo=
+w-resources
+requirements in the free-software scene so i think dillo cover this
+hole. And is quite usefull now even thought is in alpha state.
+
+Now that i have time i will like to contribute to dillo project so
+i'm subscribed to dillo-dev list and now i'm reading and trying to understa=
+nd
+the code of dillo, also reading gtk manual and html specifications as
+you wrote in the documentation. I've found the code quite clean but i need
+some time to understand it all, i also need time to be fluence with gdb, CV=
+S and=20
+other tools normailly used (any sugestion is apreciated :)
+
+greets
+
+Tomas 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: <madis@cy...> - 2002-03-13 01:41
+
+On 11 Mar 2002, Lars Clausen wrote:
+
+> Yes, we've noticed that NULL bug, and how there doesn't seem to be a way to
+> get a NULL cookie in the first place. I'm leaning towards an explanation
+> of general memory corruption. Did you try running without the cookies
+> patch, but linked with efence? I notice that a_Dicache_set_cmap is called
+> only from gif.c, and there with num_colors = 256 rather than
+> gif->NumColors. That could cause the memcpy to run over the edge of cmap,
+> maybe.
+
+i tried now dillo without cookies and with efence, and the memcpy bug
+didn't go away with cookies ;) anyway, replacing this constant 256 in 
+gif.c with "gif->NumColors < 256 ? gif->NumColors : 256" seems to 
+solve this memory corruption problem, but since i don't know exactly why 
+this constant was put there in first place i'm not sure, whether this is a 
+good fix (or is this < 256 check needed at all, i put it there because 
+gifs shouldn't have more colors and suspected that constant 256 was 
+there because some invalid gif caused NumColors go over 256).
+http://www.zone.ee/myzz/dillo/patch-dillo-gif
+
+but fixing this gif issue didn't fixed segfault totally - when i went to 
+http://www.delfi.ee site the efence linked dillo crashed happily again and i 
+discovered bug in IO.c function IO_callback: when IO_read function decided 
+to close and delete io, following error check tried to access this deleted 
+structure and set its Status field to -EIO, which wasn't nice at all.
+using IO_get again when error occured and checking whether it returned 
+NULL solved this.
+http://www.zone.ee/myzz/dillo/patch-dillo-IO
+
+i'll try this new cookies patch tomorrow night... currently morning is 
+too close :) 
+
+
+
+[Dillo-dev]Multidimensional Bookmarks
+
+From: Bruce Alon King <balon@cy...> - 2002-03-13 01:26
+
+I've been using Dillo for a couple of months now, resorting to Opera or
+Mozilla when necessary. I started running it because of low memory; now
+that I've upgraded my RAM I run it because I want to. So: KUDOS!
+
+So: I've always wanted some sort of reading system. Basically, I want
+a bookmark system that saves state so that I can not only remember the
+page, but where I was on that page, as well as a history of the pages
+visited. That way, say I'm browsing through Gtk documentation, I read
+through several pages, skip around, and then have to go to bed. I can
+save my bookmark in a .bkmk file (or whatever) and the next morning,
+bright and early, start exactly where I left off. I can even click the
+back button, yada yada.
+
+I'm trying to find some time to read through the source code and start
+contributing to this project so I'm perfectly willing to implement it
+sooner or later. I just wondered, does this idea interest anybody else
+or is it just me? I've been reading more and more books online
+(Structure and Interpretation of Computer Programs, Baen Free Library,
+et al) and I find it increasingly frustrating that I have to spend time
+navigating to where I once was in order to start reading again. In a
+paper book, I turn to my bookmark and there I am, within millimeters of
+the correct location.
+
+The other question is: any guesses on how hard this would be to
+implement? It seems like it should be pretty simple, but I haven't yet
+had the time to go through any of the dillo source code.
+
+-- 
+Bruce Alon King <balon@cy...>
+
+The frogs are dancing and
+frollicking among the weeds.
+They smile. 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-03-12 20:35
+
+Hi,
+
+tis 2002-03-12 klockan 01.45 skrev madis@cy...:
+>=20
+> i use dillo-0.6.4 patched with patch-cookies-8jan (without openssl=20
+> patch) and it crashed occasionally, most often on theregister.co.uk. so i=
+=20
+> tried to use gdb to find out why, and yes, there was a NULL pointer=20
+> reference in a_Cookies_get function (look http://www.zone.ee/myzz/dillo/c=
+ookie-crash-gdb).
+> but after reading code in cookies.c i had no clue, how this pointer could=
+=20
+> be NULL without segfaulting before [snip]
+
+I believe that I've found the problem. It's in a_Cookies_set(), where an
+old cookie gets replaced. We remove it from the list but we never
+re-insert the new start of the list in the hash table.
+
+There is a new patch up at:
+http://w1.211.telia.com/~u21114235/patch-cookies-12mar.gz
+Lots of changes made.
+
+Cheers,
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Dillo on Debian/Hurd - Compiled (see below) but malfunctions...
+
+From: Sam Dennis <sam@ma...> - 2002-03-12 19:40
+
+Some time around 7 o'clock PM on March 12, a Tuesday, Sammy Mannaert wrote:
+> "B. Douglas Hilton" wrote:
+> > 
+> > 
+> > It cheerfully complied with no problems, loads up the default
+> > window in X, and then kind of goes out to lunch if you try
+> > to open a file or url.
+> 
+> you can also compile dillo by changing defines in src/dns.c
+> (outcommenting #define G_DNS_THREADED)
+> this way dillo will not use multithreading :)
+
+Unfortunately, asynchronous DNS is not the only thing dillo uses threads for.
+IO/file.c contains other code, and no alternative method.
+
+-- 
+r@,,+2 'a,kd" 
+
+
+
+Re: [Dillo-dev]Dillo on Debian/Hurd - Compiled (see below) but malfunctions...
+
+From: Sammy Mannaert <nstalkie@tv...> - 2002-03-12 18:21
+
+"B. Douglas Hilton" wrote:
+> 
+> 
+> It cheerfully complied with no problems, loads up the default
+> window in X, and then kind of goes out to lunch if you try
+> to open a file or url.
+
+you can also compile dillo by changing defines in src/dns.c
+(outcommenting #define G_DNS_THREADED)
+this way dillo will not use multithreading :) 
+
+
+
+Re: [Dillo-dev]Dillo library, and binding
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-03-12 18:11
+
+Attachments: test_dw.c      
+
+Hi Christophe,
+
+On Fri, Mar 08, 2002 at 10:42:30PM +0000, Christophe Baillon wrote:
+> I am working on a Ada 95 binding of Dillo widgets. (In GPL of course!)
+> To realize it, I need to isolate widgets in a C library.
+> I have almost achieved it.
+> 
+> Libdw contains only dillo widget, without IO and cache (I removed
+> Dw_Image at the moment) I kept few important dillo file,
+> like url.c, findtext.c ...
+> 
+> The goal is to profit of specific dillo widget to make
+> rendering in embedded applications.
+
+Just a few warnings before: 1. Dw is very immature, and will change
+often. 2. Dw contains many ad hoc implementations, partly only
+suitable for the code of dillo. E.g., there are problems when adding
+other widgets than DwPage's to a table (will change a bit).
+
+Of course, if you have suggestions or improvements, send them to me.
+
+> I've done a C test program . It can create new dw_style,
+> but there is a "segmentation fault" when using
+> a_Dw_gtk_scrolled_window_set_dw to set a dw children (Dw_Ruler for
+> instance).
+> [...]
+
+The attached example works. See comments for details (especially: a
+widget must always have a style).
+
+Sebastian 
+
+
+
+[Dillo-dev]Dillo on Debian/Hurd - Compiled (see below) but malfunctions...
+
+From: B. Douglas Hilton <doug.hilton@en...> - 2002-03-12 01:02
+
+Just thought I'd post a heads up on what I did. A few
+weeks ago I made an experimental patch to GNU Posix
+Threads (Pth), which provides a non-preemptive pthread
+compatibility layer, so that it would compile on the GNU
+Hurd OS.
+
+Hurd only has c-threads built into the gnumach microkernel,
+and several high-powered Debian developers are working
+on making the ultimate pthreads implementation, which
+will likely be a while before its ready :-)
+
+So, hacker that I am, I made some really dangerous hacks
+to pth and got it to compile (not saying it works right), and
+used that to build Dillo on Hurd.
+
+It cheerfully complied with no problems, loads up the default
+window in X, and then kind of goes out to lunch if you try
+to open a file or url.
+
+Still, I thought it was pretty cool. Like the browser, it is
+awesome... right on with the nix philosophy: make a small
+powerfull tool to do exactly one thing, and then make it
+ubiquitous because its so small and fast!
+
+Later!
+
+- Doug 
+
+
+
+Re: [Dillo-dev]crash & efence
+
+From: Lars Clausen <lrclause@cs...> - 2002-03-12 00:45
+
+On Tue, 12 Mar 2002, madis@cy... wrote:
+>=20
+> i use dillo-0.6.4 patched with patch-cookies-8jan (without openssl patch)
+> and it crashed occasionally, most often on theregister.co.uk. so i tried
+> to use gdb to find out why, and yes, there was a NULL pointer reference
+> in a_Cookies_get function (look
+> http://www.zone.ee/myzz/dillo/cookie-crash-gdb). but after reading code
+> in cookies.c i had no clue, how this pointer could be NULL without
+> segfaulting before and tried linking with electric fence memory debugger
+> using -lefence. when linked with efence dillo segfaulted on all web pages
+> with gif images in a_Dicache_set_cmap function
+> (http://www.zone.ee/myzz/dillo/cache-crash-gdb). sorrily i had not enough
+> understanding about dicache to debug it... but seems that there is some
+> bug.
+
+Yes, we've noticed that NULL bug, and how there doesn't seem to be a way to
+get a NULL cookie in the first place. I'm leaning towards an explanation
+of general memory corruption. Did you try running without the cookies
+patch, but linked with efence? I notice that a_Dicache_set_cmap is called
+only from gif.c, and there with num_colors =3D 256 rather than
+gif->NumColors. That could cause the memcpy to run over the edge of cmap,
+maybe.=20
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]crash & efence
+
+From: <madis@cy...> - 2002-03-12 00:35
+
+i use dillo-0.6.4 patched with patch-cookies-8jan (without openssl 
+patch) and it crashed occasionally, most often on theregister.co.uk. so i 
+tried to use gdb to find out why, and yes, there was a NULL pointer 
+reference in a_Cookies_get function (look http://www.zone.ee/myzz/dillo/cookie-crash-gdb).
+but after reading code in cookies.c i had no clue, how this pointer could 
+be NULL without segfaulting before and tried linking with electric fence 
+memory debugger using -lefence. when linked with efence dillo segfaulted 
+on all web pages with gif images in a_Dicache_set_cmap function 
+(http://www.zone.ee/myzz/dillo/cache-crash-gdb). sorrily i had not enough 
+understanding about dicache to debug it... but seems that there is some 
+bug. 
+
+
+
+Re: [Dillo-dev]'&nbsp'; or '&nbsp ': Comforming to standart
+
+From: Eduardo Marcel <macan@co...> - 2002-03-11 11:32
+
+I guess we should support the standard. Adopting this kind of workaround =
+on such=20
+common mistakes would only make the mistakes more common. IMHO It's the o=
+ther
+browsers' mistake. Dillo is correct :) =20
+
+Regards,
+
+Eduardo.
+
+On Mon, 11 Mar 2002 16:59:06 +0600 "Nikita V. Borodikhin" <eliterr@tk...=
+> wrote:
+> Hello, All !
+>=20
+> Should Dillo follow to official standart, where non-breakable
+> space is '&nbsp;' only or it should follow de-facto standart,
+> where such a space could be written as '&nbsp' + any non-letter
+> chacter, e.g. a ' ' sharacter ?
+>=20
+> That non-official form of nonbreakable space is succesfully eaten
+> by IE, NS, Opera, links, lynx and may be many others and is widely
+> used in the WEB.
+>=20
+> =3D=3D=3D
+> Nikita V. Borodikhin
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>=20
+
+
+--=20
+Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager
+macan@co... Col=E9gio Bandeirantes 
+
+
+
+Re: [Dillo-dev]'&nbsp'; or '&nbsp ': Comforming to standart
+
+From: Grigory Bakunov <black@as...> - 2002-03-11 11:18
+
+Date |Mon, 11 Mar 2002 16:59:06 +0600
+From |"Nikita V. Borodikhin" <eliterr@tk...>
+
+Hello!
+
+NVB> Hello, All !
+
+NVB> Should Dillo follow to official standart, where non-breakable
+NVB> space is '&nbsp;' only or it should follow de-facto standart,
+NVB> where such a space could be written as '&nbsp' + any non-letter
+NVB> chacter, e.g. a ' ' sharacter ?
+
+NVB> That non-official form of nonbreakable space is succesfully eaten
+NVB> by IE, NS, Opera, links, lynx and may be many others and is widely
+NVB> used in the WEB.
+
+My vote to &nbsp;
+Look to w3c standarts. It's only one source of power ;)
+
+-------------------------------------------------------
+Grigory Bakunov
+ASPLinux Support Team
+http://www.asplinux.ru 
+
+
+
+[Dillo-dev]'&nbsp'; or '&nbsp ': Comforming to standart
+
+From: Nikita V. Borodikhin <eliterr@tk...> - 2002-03-11 11:07
+
+Hello, All !
+
+Should Dillo follow to official standart, where non-breakable
+space is '&nbsp;' only or it should follow de-facto standart,
+where such a space could be written as '&nbsp' + any non-letter
+chacter, e.g. a ' ' sharacter ?
+
+That non-official form of nonbreakable space is succesfully eaten
+by IE, NS, Opera, links, lynx and may be many others and is widely
+used in the WEB.
+
+===
+Nikita V. Borodikhin 
+
+
+
+[Dillo-dev]Non iso-8859 rendering/pango
+
+From: Mark Schreiber <mark7@an...> - 2002-03-10 17:46
+
+After looking at bug #299 for an hour or two ("dillo can't render iso
+entities > 255"), I suspect that the easiest thing to do may be to
+support pango, which would provide Unicode support, but would entail a
+*lot* of work and rewriting, both in layout and in internal storage of
+string data. A great deal of logic would have to be entirely
+different, at least to do things properly. AFAIK, pango 1.0 is out
+(ftp://ftp.gtk.org/pub/gtk/v2.0), but not widely used yet.
+
+Is anyone currently doing pango support? If not, I'm thinking about
+maybe making a few small interim patches to handle 8859 approximations
+of non-iso-8859 characters, like double dashes for an mdash and
+straight quotes for printers' (aka curly) quotes.
+
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+[Dillo-dev]Dillo library, and binding
+
+From: Christophe Baillon <cbaillon@it...> - 2002-03-08 21:44
+
+Hi !
+First, thanks to dillo developpers for this fast browser !
+
+I am working on a Ada 95 binding of Dillo widgets. (In GPL of course!)
+To realize it, I need to isolate widgets in a C library.
+I have almost achieved it.
+
+Libdw contains only dillo widget, without IO and cache (I removed
+Dw_Image at the moment) I kept few important dillo file,
+like url.c, findtext.c ...
+
+The goal is to profit of specific dillo widget to make
+rendering in embedded applications.
+
+I've done a C test program . It can create new dw_style,
+but there is a "segmentation fault" when using
+a_Dw_gtk_scrolled_window_set_dw to set a dw children (Dw_Ruler for
+instance).
+
+What is wrong in my code ?
+
+I think everything is initialized ?
+
+Is there special things to do before adding a Dillo Widget to
+a container ?
+
+
+gdb said it fails in a_Dw_widget_realize, at :
+if (widget->parent =3D=3D NULL && widget->style->background_color !=3D NULL=
+)
+
+
+Code :
+
+
+#include "dw.h"
+#include "dw_widget.h"
+#include "dw_gtk_scrolled_window.h"
+
+
+#include "gtk/gtkscrolledwindow.h"
+
+// Compiler avec :
+// gcc -L../lib test.c -g -I ../src `gtk-config --cflags` `gtk-config
+// --libs` -ldw -o test=20
+
+main(int argc, char **argv)
+{
+=20
+GtkWidget *fenetre;
+GtkWidget *label;
+=20
+DwWidget *ma_table;
+DwWidget *ma_page;
+DwWidget *ma_ruler;
+GtkWidget *mon_scroll;
+
+DwStyle style_attrs, *mon_style;
+DwStyleFont font_attrs;
+
+=20
+gtk_init(&argc, &argv);
+gdk_rgb_init();
+a_Dw_init();
+=20
+=20
+fenetre =3D gtk_window_new (GTK_WINDOW_TOPLEVEL);
+label =3D gtk_label_new ("Bonjour, ceci est un test");
+
+ma_table =3D a_Dw_table_new();
+ma_page =3D a_Dw_page_new();
+ma_ruler =3D a_Dw_hruler_new();
+mon_scroll =3D a_Dw_gtk_scrolled_window_new();
+gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(mon_scroll),
+GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);
+
+gtk_container_add (fenetre, mon_scroll);
+
+gtk_widget_show_all(fenetre);
+
+a_Dw_gtk_scrolled_window_set_dw (GTK_DW_SCROLLED_WINDOW(mon_scroll),
+ma_ruler);
+// Here is segmentation fault=20
+=20
+
+=20
+///////////////////////////////////
+// Initialisation du Dw_Style //
+/////////////////////////////////
+=20
+
+/* Create the font and attribute for the page. */
+font_attrs.name =3D "courier";
+font_attrs.size =3D 14;
+font_attrs.bold =3D FALSE;
+font_attrs.italic =3D FALSE;
+=20
+a_Dw_style_init_values (&style_attrs, fenetre->window);
+style_attrs.font =3D a_Dw_style_font_new (&font_attrs);
+style_attrs.color =3D a_Dw_style_color_new (0x0000ff,
+fenetre->window);
+mon_style =3D a_Dw_style_new (&style_attrs,
+fenetre->window);
+//a_Dw_widget_set_style (plain->dw, plain->style);
+=20
+/////////////////////////////////////////////////////////////
+=20
+=20
+
+//a_Dw_page_add_widget (ma_page,
+// ma_ruler,
+// mon_style);
+=20
+// If i uncomment it, =3D> segmentation fault
+=20
+
+gtk_main();
+
+}
+
+
+Is anybody make similar works ?
+
+Thanks for your help !
+
+Regards
+
+
+
+--=20
+*********************************
+*** Christophe Baillon ***
+*** ITRIS ***
+*** Informatique Temps R=E9el ***
+*** Informatique Syst=E8me ***
+********************************* 
+
+
+
+Re: [Dillo-dev]dillo (0.6.4) not showing background images ?
+
+From: John Utz <john@ut...> - 2002-03-08 19:21
+
+for starters, it's a gif! so it aint gonna get displayed unless you add
+gif functionality to your copy of dillo....
+
+
+
+On Fri, 8 Mar 2002, Peter Schb wrote:
+
+> hi,
+>=20
+> i=B4m using dillo 0.6.4 on SUSE linux 7.3 (kernel 2.4.10).
+> dillo is *not* showing background images ! (other images work fine)
+>=20
+> <body background=3D"back01.gif"> ... </body>
+>=20
+> is this still a missing feature or is something wrong with my configura=
+tion ??
+>=20
+> please respond to mailto:schb@gm...
+>=20
+> thanks
+> peter
+>=20
+>=20
+
+--=20
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]dillo (0.6.4) not showing background images ?
+
+From: Peter Schb <schb@gm...> - 2002-03-08 17:59
+
+Attachments: Message as HTML      
+
+hi,
+
+i=B4m using dillo 0.6.4 on SUSE linux 7.3 (kernel 2.4.10).
+dillo is *not* showing background images ! (other images work fine)
+
+<body background=3D"back01.gif"> ... </body>
+
+is this still a missing feature or is something wrong with my =
+configuration ??
+
+please respond to mailto:schb@gm...
+
+thanks
+peter 
+
+
+
+Re: [Dillo-dev]bug track review
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-03-08 17:36
+
+On Fri, Mar 01, 2002 at 11:50:46AM -0800, Eric GAUDET wrote:
+> -- En reponse de "[Dillo-dev]bug track review" de Sebastian Geerken, le
+> >> 202
+> >> Impact: soft error
+> >> At: run time
+> >> Type: render bug
+> >> Comments: When an image is loading over a slow connection, and you
+> >> start scrolling up and down while it draws, some parts of it may not
+> >> get updated. HTReproduce: Any big image will do. For instance, try:
+> >> http://www.photo.net/photo/pcd1765/walk-away-44.tcl
+> >> WorkedBy: nobody
+> > 
+> > This is a problem of Dw_widget_queue_draw_area, which would quite hard
+> > to solve. If somebody is *really* interested in solving this, just ask
+> > me for a more detailed explanation.
+
+An exact explanation of the problem: Dw widgets should normally use
+the function Dw_widget_queue_draw_area and not draw directly, this is
+a bit more efficient. This pattern was taken from Gtk+. The
+implementation of Dw_widget_queue_draw_area is rather simple: It just
+passes the transformed area to gtk_widget_queue_draw.
+
+The problem is, that Gtk+ deals with the coordinates within the Gtk+
+widget, what are for Dw viewport coordinates (see doc/Dw.txt for the
+definitions). What has actually to be queued, are world coordinates,
+but when the viewport position changes between queueing and actual
+drawing, we get wrong world coordinates. As in this drawing:
+
+When queueing:
+
++----------------+<-- viewport
+| +----------+ |
+| | |<-+--- image
+| | | |
+| | | |
+| +----------+ |
+| | <---------- area to be redrawn
+| +----------+ |
+| |
+| |
+| |
++----------------+
+
+When drawing, after viewport position has changed:
+
++----------------+
+| |
+| |
+| +----------+ |
+| | | |
+| +----------+ |
+| | <----------- area which is redrawn
+| +----------+ |
+| +----------+ |
+| | <----------- this area should be redrawn
+| +----------+ |
++----------------+
+
+The best fix would of course to re-implement the whole queueing
+mechanism, this is what I meant with "hard to solve".
+
+> My first guess would be to add an int y_painted in the DwImage, to keep track
+> of what?s already painted, and use that as an origin and update it in
+> Dw_widget_queue_draw_area. 
+> Another possibility would be toto add a boolean that would be set when
+> scrolled, and when an image is finished loading invoke a_Dw_widget_queue_draw ?
+> (Or, I don?t like it so much, but no boolean and force a redraw for when images
+> finished downloading, perhaps after testing if they are visible)
+> ... or did I miss something?
+
+This is no image specific bug, but IIRC, DwImage is the only widget
+which calls Dw_widget_queue_draw, the others call
+Dw_widget_queue_resize, which implies a redraw, but works different.
+
+> >> 289
+> >> Impact: soft error
+> >> At: run time
+> >> Type: render bug
+> >> Comments: when an image tooltip is display and you scroll the page
+> >> with the keyboard, dillo fails to render the new scrolled content.
+> >> HTReproduce: Go to dillo home page, move the mouse cursor on the top
+> >> image, when the tooltip is displayed, press PgDown: the page scrolls
+> >> but the bottom is empty.
+> >> WorkedBy: nobody
+> > 
+> > This is a Gtk+ bug, it can be simply be reproduced (combination of
+> > tooltips and a GtkLayout, in which is painted).
+> > 
+> 
+> Ok. Is it possible to find a workaround ? Like remove the tooltip as soon as a
+> key even is received. That would also solve the sticky tooltips ?feature?.
+
+Or fix it in Gtk+ :-)
+
+The sticky tooltips are probably a dillo bug, in the Dw event system,
+probably some events are still missing.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]bug track review
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-03-08 17:04
+
+On Fri, Mar 01, 2002 at 03:11:28PM -0600, Lars Clausen wrote:
+> On Fri, 1 Mar 2002, Sebastian Geerken wrote:
+> >> 233 Impact: soft error At: run time Type: render bug Comments: dillo
+> >> doesn't render side-by-side tables (with align=left) correctly. Dillo
+> >> renders one table per line, no matter what. It seems to be a standard to
+> >> render such tables on the same line. HTReproduce:
+> >> http://www.rti-zone.org/dillo/Html.testsuite/table-side.html
+> >> http://www.dpreview.com/ WorkedBy: nobody
+> > 
+> > Such a behavior would be actually not quite standard compliant, see
+> > http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#edef-TABLE:
+> > 
+> > align = left|center|right [CI]
+> > Deprecated. This attribute specifies the position of the table
+> > with respect to the document. Permitted values:
+> > * left: The table is to the left of the document.
+> > * center: The table is to the center of the document.
+> > * right: The table is to the right of the document.
+> > 
+> > I'm not sure whether we should follow the standard, or common
+> > use. Anyway, floats will be used for some other purposes.
+> 
+> Since this is part of an older standard, and in very frequent use, I think
+> we should support it. And since this kind of floating is (I believe) part
+> of CSS, we will need it then anyway. This is probably the most common
+> layout fault I find when using Dillo, I'd *love* to see it fixed. I even
+> looked into how to do it, but couldn't figure out how to change the
+> margins. http://www.w3.org/TR/html40/present/graphics.html#h-15.1.3 has
+> a little more info on floating.
+
+Yes, floats will be supported in the future, this is indeed a bit
+tricky (I also made some thoughts on it). The implementation will use
+a "float" member in the DwStyle (names should already be similar to
+attribute names in CSS), so this is an issue which is simple to change
+in the HTML parser (using "float" or "text_align").
+
+Sebastian 
+
+
+
+[Dillo-dev]Thanks, good work and good luck.
+
+From: Stephen Young <revoquer@gm...> - 2002-03-08 04:13
+
+To all developers of dillo,
+
+Good work. I can't even remember the first time that I used dillo(must of been a one year-two years ago).
+Each release that i've tried has been getting better and better. Up until now however using dillo wasn't
+really all that realistic for most of my browsing. However, with this release, it has been quite pleasant with
+its stability and speed. I usually use Opera/Netscape combination but now I'll be using Dillo/Netscape.
+
+Thanks,
+Stephen Young 
+
+
+
+[Dillo-dev]Dillo support
+
+From: Pradeep <pradeep@nc...> - 2002-03-07 11:48
+
+Hi ,
+
+I am trying to port Dillo to a custom board , does Dillo
+support static gray visuals , waiting for your reply.
+
+Thanks
+
+Pradeep 
+
+
+
+Re: [Dillo-dev]Small make install issue
+
+From: Michael Duelli <m.duelli@we...> - 2002-03-04 21:11
+
+D'oh!!
+
+I forgot to include the relevant part of the output :-)
+
+make install says:
+...
+make[2]: Entering directory `/usr/src/packages/SOURCES/DEV/dillo'
+make[2]: Nothing to be done for `install-exec-am'.
+if [ -d /usr/local/etc ]; then \
+/usr/bin/ginstall -c -m 644 --backup=t ./dillorc /usr/local/etc/; 
+\
+elif [ -d /etc/ ]; then \
+/usr/bin/ginstall -c -m 644 --backup=t ./dillorc /etc/; \
+fi
+/usr/bin/ginstall: option `--backup' doesn't allow an argument
+Try `/usr/bin/ginstall --help' for more information.
+make[2]: [install-data-local] Error 1 (ignored)
+make[2]: Leaving directory `/usr/src/packages/SOURCES/DEV/dillo'
+make[1]: Leaving directory `/usr/src/packages/SOURCES/DEV/dillo'
+
+And I don't know why but ginstall --backup gets a t value. ginstall help 
+tells me something about version control and the t value, but not with the 
+--backup flag.
+
+BTW, I only do:
+./configure
+make
+make install
+
+I don't specify any special directories or something like that.
+
+Of course, it's not a real error. dillo installs and runs just fine. I 
+just wanted to tell you.
+
+TIA,
+Michael
+___________________________________
+Michael Duelli
+m.duelli@we...
+http://glchess.s...net - A 3D chess interface 
+
+
+
+Re: [Dillo-dev]Small make install issue
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-04 18:53
+
+Hello Michael!
+
+Michael Duelli writes:
+> Hi all,
+> 
+> when installing dillo as root using ginstall from install (GNU fileutils) 
+> 4.0 I get this tiny error message
+
+Hum... where is the error? Isn't this the usual output for 'make
+install' (or did you accidently do 'make -n install')? Or am I missing
+something?
+
+Does it get to installing the dillorc file at all?
+
+> --------------snip----------------
+> make[1]: Entering directory `/usr/src/packages/SOURCES/DEV/dillo'
+> make[2]: Entering directory `/usr/src/packages/SOURCES/DEV/dillo'
+> make[2]: Nothing to be done for `install-exec-am'.
+> if [ -d /usr/local/etc ]; then \
+> /usr/bin/ginstall -c -m 644 --backup=t ./dillorc /usr/local/etc/; \
+> elif [ -d /etc/ ]; then \
+> /usr/bin/ginstall -c -m 644 --backup=t ./dillorc /etc/; \
+> fi
+> make[2]: Leaving directory `/usr/src/packages/SOURCES/DEV/dillo'
+> make[1]: Leaving directory `/usr/src/packages/SOURCES/DEV/dillo'
+> --------------snap----------------
+> 
+> It seems like you have to export the argument for backup as 
+> SIMPLE_BACKUP_SUFFIX.
+
+You have to export SIMPLE_BACKUP_SUFFIX _only_ if you'd like to
+change the default backup suffix (the default is '~').
+
+> Maybe this is different with newer versions of ginstall.
+
+Err.. I have access to three diferent machines using three diferent
+fileutils (3.6 on Solaris, 4.0l on Debian[Potato]/Linux, and 4.1-9 on
+Debian[Woody]/Linux), and they all work :( 
+
+Please try to check if the dillorc gets copied. I would like to help
+you out, but I need to understand what's wrong and how to reproduce
+your error.
+
+best regards,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Solaris & dillo
+
+From: Livio Baldini Soares <livio@im...> - 2002-03-04 18:25
+
+Jorge Arellano Cid writes:
+> 
+> Hi there!
+
+Hello Jorge!
+
+> Some of the autconf changes (in CVS) broke Solaris detection.
+> Now there's new code to fix this. It has been partly tested, but
+> there's a need for a run-test. Someone with a SunOS box please
+> test it and report back how it goes.
+
+# uname -a
+SunOS jaca 5.7 Generic_106541-04 sun4u sparc
+
+Everything seems to be just fine from here. No problems at all!
+Pthreads are now working again.
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Solaris & dillo
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-03-04 17:08
+
+Hi there!
+
+Some of the autconf changes (in CVS) broke Solaris detection.
+Now there's new code to fix this. It has been partly tested, but
+there's a need for a run-test. Someone with a SunOS box please
+test it and report back how it goes.
+
+Thanks
+Jorge.- 
+
+
+
+[Dillo-dev]Bug 306 - ">" sign in attribute string
+
+From: Andreas Schweitzer <andy@ph...> - 2002-03-04 04:46
+
+Attachments: html.c.diff      
+
+Hi,
+I found a bug and instered it as bug 306. The good news : I also
+have a patch. But it may be tricky, so I send it in as food for thought.
+
+The problem is that dillo gets confused when the > sign is in an attribute
+string (like http://www.xwinman.org). Simply accepting a > inside a string
+will break way too many web pages. E.g. "slahsdot->Read more" on any
+article has
+<INPUT TYPE="HIDDEN" NAME="op" VALUE="userlogin" %]">
+Near the login form. Looks like broken HTML to me ...
+
+Anyways, I attach a patch which looks ahead to determine the order
+of ", > and < 
+What do you think ?
+
+Cheers,
+Andreas
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]bug track review
+
+From: Lars Clausen <lrclause@cs...> - 2002-03-01 21:11
+
+On Fri, 1 Mar 2002, Sebastian Geerken wrote:
+> Hi,
+>=20
+> I just took some time to take a look on the bug tracking engine. Here
+> are some comments on a few.
+[...]
+>> 233 Impact: soft error At: run time Type: render bug Comments: dillo
+>> doesn't render side-by-side tables (with align=3Dleft) correctly. Dill=
+o
+>> renders one table per line, no matter what. It seems to be a standard =
+to
+>> render such tables on the same line. HTReproduce:
+>> http://www.rti-zone.org/dillo/Html.testsuite/table-side.html
+>> http://www.dpreview.com/ WorkedBy: nobody
+>=20
+> Such a behavior would be actually not quite standard compliant, see
+> http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#edef-=
+TABLE:
+>=20
+> align =3D left|center|right [CI]
+> Deprecated. This attribute specifies the position of the table
+> with respect to the document. Permitted values:
+> * left: The table is to the left of the document.
+> * center: The table is to the center of the document.
+> * right: The table is to the right of the document.
+>=20
+> I'm not sure whether we should follow the standard, or common
+> use. Anyway, floats will be used for some other purposes.
+
+Since this is part of an older standard, and in very frequent use, I thin=
+k
+we should support it. And since this kind of floating is (I believe) par=
+t
+of CSS, we will need it then anyway. This is probably the most common
+layout fault I find when using Dillo, I'd *love* to see it fixed. I even
+looked into how to do it, but couldn't figure out how to change the
+margins. http://www.w3.org/TR/html40/present/graphics.html#h-15.1.3 has
+a little more info on floating.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+RE: [Dillo-dev]bug track review
+
+From: Eric GAUDET <eric.gaudet@vn...> - 2002-03-01 19:52
+
+-- En reponse de "[Dillo-dev]bug track review" de Sebastian Geerken, le
+01-Mar-2002 :
+> Hi,
+>=20
+> I just took some time to take a look on the bug tracking engine. Here
+> are some comments on a few.
+>=20
+>> 202
+>> Impact: soft error
+>> At: run time
+>> Type: render bug
+>> Comments: When an image is loading over a slow connection, and you
+>> start scrolling up and down while it draws, some parts of it may not
+>> get updated. HTReproduce: Any big image will do. For instance, try:
+>> http://www.photo.net/photo/pcd1765/walk-away-44.tcl
+>> WorkedBy: nobody
+>=20
+> This is a problem of Dw_widget_queue_draw_area, which would quite hard
+> to solve. If somebody is *really* interested in solving this, just ask
+> me for a more detailed explanation.
+>=20
+
+My first guess would be to add an int y_painted in the DwImage, to keep t=
+rack
+of what=B4s already painted, and use that as an origin and update it in
+Dw_widget_queue_draw_area.=20
+Another possibility would be toto add a boolean that would be set when
+scrolled, and when an image is finished loading invoke a_Dw_widget_queue_=
+draw ?
+(Or, I don=B4t like it so much, but no boolean and force a redraw for whe=
+n images
+finished downloading, perhaps after testing if they are visible)
+... or did I miss something?
+
+>> 233
+>> Impact: soft error
+>> At: run time
+>> Type: render bug
+>> Comments: dillo doesn't render side-by-side tables (with align=3Dleft)
+>> correctly. Dillo renders one table per line, no matter what. It seems
+>> to be a standard to render such tables on the same line.
+>> HTReproduce: http://www.rti-zone.org/dillo/Html.testsuite/table-side.h=
+tml
+>> http://www.dpreview.com/
+>> WorkedBy: nobody
+>=20
+> Such a behavior would be actually not quite standard compliant, see
+> http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#edef-=
+TABLE:
+>=20
+> align =3D left|center|right [CI]
+> Deprecated. This attribute specifies the position of the table
+> with respect to the document. Permitted values:
+> * left: The table is to the left of the document.
+> * center: The table is to the center of the document.
+> * right: The table is to the right of the document.
+>=20
+> I'm not sure whether we should follow the standard, or common
+> use. Anyway, floats will be used for some other purposes.
+>=20
+
+I=B4m affraid I see that in a lot of sites. I=B4d prefer we support it.
+
+>> 289
+>> Impact: soft error
+>> At: run time
+>> Type: render bug
+>> Comments: when an image tooltip is display and you scroll the page
+>> with the keyboard, dillo fails to render the new scrolled content.
+>> HTReproduce: Go to dillo home page, move the mouse cursor on the top
+>> image, when the tooltip is displayed, press PgDown: the page scrolls
+>> but the bottom is empty.
+>> WorkedBy: nobody
+>=20
+> This is a Gtk+ bug, it can be simply be reproduced (combination of
+> tooltips and a GtkLayout, in which is painted).
+>=20
+
+Ok. Is it possible to find a workaround ? Like remove the tooltip as soon=
+as a
+key even is received. That would also solve the sticky tooltips =B4featur=
+e=B4.
+
+Best,
+------------------------------------------------------------------------
+Eric GAUDET <eric.gaudet@vn...>
+Le 01-Mar-2002 a 11:32:55
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+[Dillo-dev]bug track review
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-03-01 18:21
+
+Hi,
+
+I just took some time to take a look on the bug tracking engine. Here
+are some comments on a few.
+
+> 202
+> Impact: soft error
+> At: run time
+> Type: render bug
+> Comments: When an image is loading over a slow connection, and you
+> start scrolling up and down while it draws, some parts of it may not
+> get updated. HTReproduce: Any big image will do. For instance, try:
+> http://www.photo.net/photo/pcd1765/walk-away-44.tcl
+> WorkedBy: nobody
+
+This is a problem of Dw_widget_queue_draw_area, which would quite hard
+to solve. If somebody is *really* interested in solving this, just ask
+me for a more detailed explanation.
+
+> 231
+> Impact: soft error
+> At: run time
+> Type: misbehaviour
+> Comments: dillo doesnt render http://www.fuckedcompany.com the leftmost 5% of
+> the page appears to be cut off HTReproduce: view http://www.fuckedcompany.com
+> WorkedBy: nobody
+
+Dillo does render it, but below the main part of the page. Same as the
+following:
+
+> 233
+> Impact: soft error
+> At: run time
+> Type: render bug
+> Comments: dillo doesn't render side-by-side tables (with align=left)
+> correctly. Dillo renders one table per line, no matter what. It seems
+> to be a standard to render such tables on the same line.
+> HTReproduce: http://www.rti-zone.org/dillo/Html.testsuite/table-side.html
+> http://www.dpreview.com/
+> WorkedBy: nobody
+
+Such a behavior would be actually not quite standard compliant, see
+http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#edef-TABLE:
+
+align = left|center|right [CI]
+Deprecated. This attribute specifies the position of the table
+with respect to the document. Permitted values:
+* left: The table is to the left of the document.
+* center: The table is to the center of the document.
+* right: The table is to the right of the document.
+
+I'm not sure whether we should follow the standard, or common
+use. Anyway, floats will be used for some other purposes.
+
+> 289
+> Impact: soft error
+> At: run time
+> Type: render bug
+> Comments: when an image tooltip is display and you scroll the page
+> with the keyboard, dillo fails to render the new scrolled content.
+> HTReproduce: Go to dillo home page, move the mouse cursor on the top
+> image, when the tooltip is displayed, press PgDown: the page scrolls
+> but the bottom is empty.
+> WorkedBy: nobody
+
+This is a Gtk+ bug, it can be simply be reproduced (combination of
+tooltips and a GtkLayout, in which is painted).
+
+
+Sebastian 
+
diff --git a/old/oldmail/200204.txt b/old/oldmail/200204.txt
new file mode 100644
index 0000000..3969cb2
--- /dev/null
+++ b/old/oldmail/200204.txt
@@ -0,0 +1,4243 @@
+[Dillo-dev]Faces
+
+From: Chris Hawks <chrish@sy...> - 2002-04-30 22:43
+
+Just a question for a new (and very impressed) user...
+
+
+Why is the font face code commented out in html.c (about line 1720). I
+un-commented it and it seems to work correctly...
+
+Chris
+
+Christopher R. Hawks Software Engineer
+Syscon Plantstar a Division of Syscon International
+-------------------------------------------------------------------------
+Red meat is not bad for you. Blue-green fuzzy meat is bad for you. 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: John Utz <john@ut...> - 2002-04-30 21:08
+
+On Sat, 27 Apr 2002, madis wrote:
+
+> On Sat, 27 Apr 2002, Ivo van Poorten wrote:
+> 
+> > Furthermore, I added two lines to menu.c at line 172:
+> > 
+> > Menu_add(menu, "Back", NULL, bw, a_Commands_back_callback, bw);
+> > Menu_add(menu, "Forward", NULL, bw, a_Commands_forw_callback, bw);
+> > 
+> > It makes browsing more convenient this way, IMHO.
+> > I have not thoroughly examined all the sourcecode and I have no serious 
+> > plans to start coding on dillo, so maybe somebody could look into this and 
+> > maybe make a patch to the CVS code. One question though, is there a reason 
+> > why the icons in pixmap.h use so little colours?
+> 
+> you have been at least 3th person reinventing exactly this patch :)
+> imho it should go into main dillo tree.
+
+somebodies patch. anybodies patch! plz!
+
+i'll write it again and send it anywhere, it's even been mentioned in some 
+documentation, but it never shows up.
+
+> --
+> mzz
+> 
+> 
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Error
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-30 17:12
+
+Hi,
+
+On Sat, Apr 27, 2002 at 08:29:35PM +0300, Armish wrote:
+> when i write the command "dillo" to the command,the dillo opens and closes in 
+> a minute and gives this error messages to the terminal ;
+> dillo_dns_init: Here we go!
+> Loading bookmarks...
+> a_Cache_open_url: file:/root/.dillo/splash024.html
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Are you using version 0.2.4??? There was once a problem with other
+charsets than iso8859-1, but AFAIK, this has been solved halfway some
+time ago. (Sorry, I'm always using iso8859-1, so I don't have any
+experiences.) Try to use a more recent version of dillo.
+
+Sebastian 
+
+
+
+[Dillo-dev]CSS
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-30 17:06
+
+Hi!
+
+Below are some notes on how CSS may be implemented in dillo. It mainly
+focusses on how the different parts "play together", many details for
+the single modules are left out, there should be enough room for
+different implementations. There are also some simplifications,
+e.g. the user-agent defined style sheet may be implemented in a
+different way. I've left out XML/CSS parsing, which should be possible
+by this design, but makes many changes of the HTML parser necessary.
+
+Please post comments, bugs, anticipated problems, ambiguities etc.
+
+Sebastian
+
+======================================================================
+
+-------------------------------------------
+A Possible Implementation of CSS in Dillo
+-------------------------------------------
+
+The User's View
+===============
+
+An important goal is asynchronous HTML/CSS parsing: when the HTML
+parser reads a <LINK> tag referring to an external style sheet, it
+continues to render the document _without_ the style sheet, while the
+style sheet (if it is not already in the cache) is retrieved and
+parsed parallel to this, and then applied on the current rendered part
+of the document. If the time difference is large enough, the user will
+notice a sudden change of colors, fonts, etc., but will be able to
+read the content with less delay time (which may be several seconds).
+
+
+Overview
+========
+
+The following diagram shows the associations between the data
+structures, and there multiplicities. Worth to notice is that for
+every document (represented currently by DilloHtmlLB), there is one
+document tree (Document) and one CSS cascade. The details are
+described below.
+
++-----------+
+| DilloHTML |
++-----------+
+0..1 | | 1
+,-------' `------.
+| |
+1 V V *
++-------------+ +----------------+ 0..1 +---------+
+| DilloHtmlLB | | DilloHtmlState |------>| Element |
++-------------+ +----------------+ 1 +---------+
+1 | | 1 |
+| | |
+| | 1 +----------+
+| `------------------------------->| Document |
+| +----------+
+| ^ 1
+| +-------------+ |
+`----------------->| CSS cascade |------'
+1 +-------------+ 1
+
+
+
+The Role of DwStyle
+===================
+
+The DwStyle structure will represent style attributes in one of the
+following ways (for the exact terminology, see [CSS2] chapter 6.1):
+
+1. Absolute values are represented directly. Examples are absolute
+lengths. The value "auto" is handled the same way.
+
+2. Some relative values are immediately computed, this may depend
+on attributes of the parent element. Examples are relative line
+heights, i.e. "line-height: 150%" will be computed into an
+absolute (pixel) value.
+
+3. Other relative sizes are represented this way in DwStyle,
+examples are relative widths and heights.
+
+Whether 2 or 3 applies to a specific attribute is determined by two
+factors:
+
+1. If the attribute value is independent of certain values, which
+changes affect only the level of Dw (important: window size),
+they can, for simplicity, put into category 2. Otherwise, they
+must belong to 3. The latter may not be inherited, for the
+reason, see next point.
+
+2. Since only *computed* values may be inherited, attributes,
+which values are inherited, may not be part of category 2,
+since Dw will not be able to handle them correctly.
+
+
+The Document Tree
+=================
+
+The document tree has two purposes:
+
+1. representation of the document structure, needed for the
+evaluation of CSS selectors, and
+2. near-complete encapsulation of the dillo widget.
+
+The HTML parser accesses for most elements only the document tree, and
+not anymore Dw. The interface is similar to a small subset of the
+Document Object Model (see [DOM2]), and provides methods for the
+following purposes:
+
+1. construction of nodes (mainly elements and text), adding them to
+other nodes,
+2. examining the structure (e.g. for evaluating CSS selectors),
+3. assigning style attributes,
+4. drawing, and
+5. changing the state.
+
+Some notes about the latter three points: The document tree is in most
+cases able to construct and access the Dw structures simply by style
+attributes. E.g., if the attribute "display" has the value "table", it
+"knows" that it must create a DwTable and add it to the DwPage
+associated with the parent node. This way, the HTML parser may be
+simplified, much functionality can be replaced by a user-agent-defined
+style sheet, as in [CSS2] appendix A.
+
+Since this is not in all cases possible, two back-doors are kept open:
+
+1. It is possible to add a special type of element to the tree,
+with a specified DwWidget. The <img> tag will processed this
+way.
+
+2. DwStyle will be extended by non-standard attributes, when
+necessary. For better distinction, they will be preceded by
+"x_". Examples are "x_link" and "x_colspan".
+
+An element may have a state, which is used as pseudo-element in the
+style evaluation (see below). This is how the dynamic pseudo-classes
+([CSS2] chapter 5.11.3) are handled. Changing this is e.g. done when
+the user clicks on a not yet visited link, the state then switches
+from "link" to "visited".
+
+
+The CSS Cascade
+===============
+
+"CSS cascade" is a module, which is responsible for evaluating CSS
+selectors ([CSS2] chapter 5). The evaluation function gets the element
+node, the default attributes (DwStyle), and a "pseudo-element" as
+argument, and returns a DwStyle with the values described in the
+section "DwStyle". The caller is responsible to determine the default
+attributes (those which are not changed, if no rule is found), either
+by setting them to default values, or copying them from the parent
+element.
+
+About the "pseudo-element": An evaluation with this argument set to
+non-NULL must only evaluate the rules containing this
+"pseudo-element".
+
+Of course, there is the need of a CSS parser. A "cascade" may combine
+several style documents, from different origins (see [CSS2] chapter
+6.4), so that the parser always adds rules to a cascade. There is no
+need for an incremental parser, instead, a document is always parsed
+as a whole (see below).
+
+In some cases, it is necessary to add element-specific rules to the
+cascade, either for evaluating the "style" attribute, or to process
+(mostly deprecated) HTML elements and attributes.
+
+
+Pseudo Elements and Generated Content
+=====================================
+
+Content is generated in two cases:
+
+1. if the ":before" and ":after" pseudo elements are used ([CSS2]
+chapter 5.12.3), and
+2. for list items.
+
+Content generation is the task of the document tree. For dealing with
+":before" and ":after", one document element refers to three DwStyle:
+
+(i) two from the evaluation of ":before" and ":after", and
+(ii) one actual style.
+
+The actual style may be affected by the state of the element.
+
+(There are many things missing for pseudo elements, they have to be
+specified, and some may not be implemented in dillo).
+
+
+What Actually Happens in Different Situations
+=============================================
+
+Adding Elements to the Tree
+---------------------------
+This happens after the parser has read an opening tag:
+
+1. The HTML parser evaluates the element attributes to create one
+or two new, element-specific rules, and inserts them into the
+CSS cascade.
+
+2. The HTML parser adds a new element to the current document
+element.
+
+3. The CSS cascade determines the style, based on the style of the
+parent, where some attributes are set to default values.
+
+4. This style is attached to the new element, and the element is
+drawn (e.g. the appropiate DwWidget methods are called).
+
+Handling the <STYLE> Element
+----------------------------
+The content of <STYLE> is written into the stash. When </STYLE> is
+written, following is done:
+
+1. The HTML parser passes the stash content to the CSS parser,
+which inserts the new rules into the CSS cascade.
+
+2. The styles for the whole document are recalculated, and the
+document is redrawn.
+
+Handling the <LINK> Element
+---------------------------
+An external style sheet is read by a special cache client, which
+writes the content into the buffer, and is associated with the
+document tree and the CSS cascade. If the data has been fully
+retrieved, the process is similar to <STYLE>, described above.
+
+What is important is to preserve the order the documents have been
+specified in the document, e.g. for
+
+<link href="style1.css" rel="stylesheet" type="text/css">
+<style>
+/* style sheet 2 */
+</style>
+
+it is likely that the content of <style> will be processed earlier,
+although it has been specified later in the HTML document. This may be
+done by assigning numbers to the style sheet documents, which are
+increased each time <link> or <style> is processed.
+
+
+References
+==========
+
+[CSS2] Cascading Style Sheets, level 2, CSS2 Specification
+http://www.w3.org/TR/1998/REC-CSS2-19980512
+
+[DOM2] Document Object Model (DOM) Level 2 Core Specification
+http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113 
+
+
+
+[Dillo-dev]parsing of "file:" URLS
+
+From: Arvind Narayanan <arvindn@my...> - 2002-04-30 17:06
+
+Hi,
+
+Typing file://foo/bar/ into the location bar takes you to /bar .
+The function doing this (Url_object_new in url.c) says it's according
+to rfc 2396. But the behavior is confusing, taken in conjunction
+with the fact that file://foo takes you to the home directory (or
+is it the current directory?). All this doesn't happen when there's
+1 or 3 slashes after "file:" (the token following // is parsed
+as "authority" and the path starts with the word after that).
+
+Here's a browser-wise description
+
+Dillo
+file: , file:// , file://foo ==> current dir
+file://foo/ ==> /
+file://foo/bar ==> /bar
+
+Moz
+file: , file:// , file://foo ==> /
+file://foo/bar ==> /bar
+
+Konq
+file: ==> home dir
+file:// ==> /
+file://foo ==> /foo
+
+NS 4.7
+file:// ==> /
+file: , file://foo , file://foo/bar ==> "can't find host"
+
+Opera
+file: ==> /
+file:// ==> "can't open"
+file://foo ==> /foo
+
+Nautilus
+file: , file:// ==> "error"
+file://foo ==> /foo
+
+No two are identical :-)
+(Can't get galeon to compile on my machine)
+
+Of the lot I think Konq is the most intuitive from the average Joe's
+POV. At least file://foo/bar ==> /bar should be avoided. Any thoughts?
+
+Arvind
+-- 
+Its all GNU to me 
+
+
+
+Re: [Dillo-dev]PgUp (was: 0.6.5 release)
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-30 15:16
+
+On Tue, Apr 30, 2002 at 12:04:16PM -0300, Livio Baldini Soares wrote:
+> [...]
+> See a post I've sent a few weeks ago about this issue:
+> http://www.geocrawler.com/lists/3/SourceForge/702/50/8334149/
+
+Sorry. There was much traffic on the list in the last time.
+
+> In my case what triggers it is NumLock (but read the post for full
+> explanation).
+[...]
+> > But META-B (Bookmark menu) should not work anymore (that's what is is
+> > supposed :-). Anyway, I've just comitted a small change, please test
+> > it and report the result.
+> 
+> I haven't seen your change yet, but the mail I've posted contained a
+> small patch which solved my issue (and should be a clean fix). I'll
+> check your changes to see if their something like mine (or better ;-)
+
+They're nearly the same :-) (I've no opinion whether or not to leave
+GDK_MOD2_MASK.)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]PgUp (was: 0.6.5 release)
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-30 15:04
+
+Hello!
+
+Sebastian Geerken writes:
+> Hi,
+> 
+> On Sat, Apr 27, 2002 at 02:39:31AM +0200, Ivo van Poorten wrote:
+> > I tried out dillo 0.6.5 today and I noticed that the page-up key didn't 
+> > work (anymore?).
+> 
+> I cannot reproduce it, but see below. 
+
+See a post I've sent a few weeks ago about this issue:
+http://www.geocrawler.com/lists/3/SourceForge/702/50/8334149/
+
+In my case what triggers it is NumLock (but read the post for full
+explanation). 
+
+> > I localized the problem. In dw_gtk_scrolled_frame.c at 
+> > line 480 it says:
+> > 
+> > if (event->state & (GDK_MOD1_MASK | GDK_MOD2_MASK))
+> > return FALSE;
+> > 
+> > I don't know what this is supposed to do (it's not in the pagedown 
+> > section), but when I comment it out, pageup is working again.
+> 
+> But META-B (Bookmark menu) should not work anymore (that's what is is
+> supposed :-). Anyway, I've just comitted a small change, please test
+> it and report the result.
+
+I haven't seen your change yet, but the mail I've posted contained a
+small patch which solved my issue (and should be a clean fix). I'll
+check your changes to see if their something like mine (or better ;-)
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]PgUp (was: 0.6.5 release)
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-30 14:00
+
+Hi,
+
+On Sat, Apr 27, 2002 at 02:39:31AM +0200, Ivo van Poorten wrote:
+> I tried out dillo 0.6.5 today and I noticed that the page-up key didn't 
+> work (anymore?).
+
+I cannot reproduce it, but see below.
+
+> I localized the problem. In dw_gtk_scrolled_frame.c at 
+> line 480 it says:
+> 
+> if (event->state & (GDK_MOD1_MASK | GDK_MOD2_MASK))
+> return FALSE;
+> 
+> I don't know what this is supposed to do (it's not in the pagedown 
+> section), but when I comment it out, pageup is working again.
+
+But META-B (Bookmark menu) should not work anymore (that's what is is
+supposed :-). Anyway, I've just comitted a small change, please test
+it and report the result.
+
+Sebastian 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-30 13:16
+
+Hi there,
+
+On Thu, 11 Apr 2002, Eric GAUDET wrote:
+
+Hmmmm, some time ago, but after the site move, presentation,
+release and regular duties, here's a time slice to answer. :)
+
+
+> Hi Jorge,
+
+Hi.
+
+> I think we can agree that according to the dpi1 proposal, the initial pat=
+ch
+> will include the following parts:
+> - init code
+> - plugin forking and pipe registration
+> - url indirection to plugin pipes and rendering.
+
+Could and couldn't!
+
+The current draft really needs more abstract work, specially on
+design and particularly in design validation...
+
+After that phase, the first prototype may be different (not
+forked for intance, but more on this in the next post).
+
+And yes, it may end having what you listed.
+
+
+> There will also be a minimal reference implementation plugin, that will
+> probably be a script or a small C program.
+
+Sure.
+
+> I=B4d like to know what code you already have, what code you have needs r=
+ework,
+> and if you plan to integrate any code soon or you prefer to discuss about=
+it a
+> little bit.
+
+I only have an ancient prototype we worked with Holger. Most
+probably the new dpi1 design will require something different,
+and as I wrote above, and as you suggest, it certainly needs more
+work.
+
+It's a matter of deeply understanding the draft, considering
+dillo internals and other implementation possibilities, then
+probing the design (validating what's OK and fixing/modifying
+what's wrong), then making a few pre-prototypes to test the
+implemetation choices, and finally building a prototype.
+
+
+Cheers
+Jorge.-
+
+
+> PS: Jorge, I wanted to ask you this for a long time: what text editor do =
+you
+> use, with that justify in plain text?
+
+It's and old companion of mine that I coded a long-long time
+ago; I've shown it to a few fellows, that use it regularly and
+that say to really miss when working without!
+
+As dillo, it's very simple, small, fast and stays out of the
+way. I never dared to make it public, because although very
+stable, I never had the time to clean its code! (and there're
+hundred of other editors out there). 
+
+
+
+[Dillo-dev]Simple plugins (dpi1)
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-30 13:15
+
+Hi there!
+
+... the good news are:
+
+
+Geoff Lane will be leading the work on dpi1 extensions!
+
+
+My advice: please cooperate with him with well tought/reasoned
+ideas only. That is, proposals that at least answer what, why and
+how.
+
+
+Sincerely
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-30 13:15
+
+Hi again!
+
+On Fri, 12 Apr 2002, Eric GAUDET wrote:
+
+> Hi,
+>
+> Tow things I=B4d like to see changed in the dpi1 proposal:
+>
+> - D1 and D2 fields being 2 bytes long, the endianness can be an issu=
+e. I
+> think it will be better to have 1 byte fields D1, D2, D3, D4 instead.
+
+Is not an issue. It's sent as text (guchar *), just as with
+files and http.
+
+>
+> - Along with the client ID, I think a request ID is needed too, to ensure
+> multiple windows calling the same PI concurently don=B4t get confused in =
+their
+> connections.
+
+You seem to have misunderstood the draft...
+
+The client ID is generated by the cache (inside dillo), so the
+client ID serves as what you call "request ID"!
+
+Later on, the same client ID is sent back by the PI (in the
+respective datagrams), so it serves as a kind of request-key.
+
+> [...]
+
+> I=B4d also want to make sure multiple connection are not made simultaneou=
+sly in
+> stdin/stdout. For that, dillo will need to have a pipe lock mecanism to b=
+e set
+> every time a datagram is transmited, until the transmission of this parti=
+cular
+> datagram is completed.
+
+Yes, this is an issue. I'll quote here what I answered to Geoff
+about a very similar question:
+
+>>
+> [Geoff wrote:]
+> ...
+> However, if there is a persistent plugin process running it may be used t=
+o
+> allow dillo to re-connect with the plugin - I don't know, I don't know
+> sufficient about dillo internals yet.
+
+Good point.
+
+But it's not of current dillo internals, but of of a choice of
+which communication channel we'll use to communicate (and launch)
+the plugin.
+
+I mean, maybe the PI can be started with a fork, or from a
+pthread, or from another fancy mechanism (as an ad-hoc launcher
+for instance; a helper program that forks itself and launches the
+PI, and acts as intermediary between PIs and dillo). Those
+are possibilities.
+
+And as for how they will communicate, it could be stdin/stdout
+(with fork for instance), in which case I can't see clearly how
+resident PIs could be implemented :) (as its stdin/stdout would
+be already in use).
+
+But, on a fine grained basis, it can be argued that such a
+resident PI could work if it were to remain resident but not
+accept any new connection until finished with the one in
+course...
+
+...but the point is that if they were to communicate trough a
+socket, or named pipe, or who knows, it could be possible to
+handle them in the more general case.
+
+
+Those are pending design issues...
+>>
+
+
+And that's the main point. Dpi1 needs some heavy work on design
+and validation. Some other techniques need to be evaluated (as
+the above mentioned), and tested.
+
+
+The good news are:
+
+<see next post> :)
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo (in the) News!
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-04-29 18:12
+
+its not just the news value the kiosk article looks like it could be an 
+excellent educational resource.
+
+I've yet to start compiling stuff for the ipaq, and would like a few 
+projects to run through as trials.
+
+I ran a small thread at w3c/wai about how fast dillo is.
+
+A few bods agreed, but could not get a thread running as to why the 
+others are so slow.
+
+jonathan 
+
+
+
+RE: [Dillo-dev]Dillo (in the) News!
+
+From: Eric Gaudet <ericg@ta...> - 2002-04-29 17:21
+
+> I'm resending my earlier posts about Dillo in articles for those who
+> have missed any. And I am considering opening a new page at our home
+> with links to these... something like "Press". Is such a page
+> interesting at all?
+> 
+
+Definitely needed! (especially with the 'funding' initiative). Should be
+called "Articles"
+
+Eric 
+
+
+
+Re: [Dillo-dev]Dillo (in the) News!
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-29 17:14
+
+Hello folks!
+
+I've found a "new" (25-Apr-2002) article which mentions Dillo, at
+http://www.linuxdevices.com, written by Patrick Glennon:
+
+http://www.linuxdevices.com/articles/AT2869412121.html
+
+It's about building a kiosk with embedded Linux, and they seem to
+use Dillo as their main GUI. Looks pretty cool, huh?
+
+(BTW: I'm still making efforts to make the cache_size_limit patch work
+100%. Pekka and I have both made different patches, but both are
+wrong, and the few small issues that are left are really hard to get
+around. I think that I'll probably have the patch ready for the next
+release).
+
+I'm resending my earlier posts about Dillo in articles for those who
+have missed any. And I am considering opening a new page at our home
+with links to these... something like "Press". Is such a page
+interesting at all?
+
+Has anyone seen any other articles which review/use/mention Dillo? I
+would like to know to get the material ready.
+
+best regards!
+
+Livio Baldini Soares writes:
+> Hello everyone,
+> 
+> I guess Dillo is more famous then I had imagined! We are making
+> headlines! ;-)
+> 
+> There is an article published yesterday on the Linux Journal about
+> Dillo! It's a review by a Ralph Krause, made yesterday (26/02/2002):
+> http://www.linuxjournal.com/article.php?sid=5847
+> 
+> I caught this link from the front page of NewsForge (newsforge.net):
+> http://www.newsforge.com/article.pl?sid=02/02/26/2358247&mode=thread
+> 
+> And another article mentions Dillo, made by Kevin Reichard at
+> BrowserWatch:
+> http://browserwatch.internet.com/news/stories2002/news-20020122-4.html
+> 
+> I don't know if Dillo is still too "ripe" for this kind of
+> attention, but, as the saying goes: "Bad press is better then no
+> press"! ;-)
+> 
+> Congratulations to all Dillo developers! Hope we grow a lot more
+> this year and make more users (and headlines ;).
+> 
+> -- 
+> Livio <livio@im...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Useful patches from the OpenBSD folks
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-29 16:35
+
+Hi,
+
+On Sun, 28 Apr 2002, Andreas Schweitzer wrote:
+
+> Hi everybody
+> While notifying the OpenBSD folks that they can upgrade
+> their dillo entry I noticed the patches they apply to
+> it before allowing a compile :
+> http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/
+> The 64bit issues certainly seem reasonable. As of this
+> writing the patches are against 0.6.4 and patches/patch-src_dns_c
+> and parts of patches/patch-src_IO_http_c are no longer necessary.
+> But the rest of the 64bit issues deserve consideration.
+
+Done!
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-29 14:17
+
+Hi there!
+
+On Mon, 29 Apr 2002, Livio Baldini Soares wrote:
+
+> > > This page http://dillo.cipsga.org.br/funding/ is not rendering properly
+> > > in anything except dillo :-)
+> >
+> > Hmmm, strange thing.
+> >
+> > I reviewed the code several times but havent't found anything
+> > non-standard there. Netscape simply "eats" a big part of the
+> > page, and tweaking the page by hand, I was able to isolate a case
+> > where adding the simplest of the subtables in a row triggered the
+> > problem (on Netscape). Mozilla, OTOH, renders the main part at
+> > the bottom.
+>
+> In the objective to temporarily aliviate this issue, I've done a few
+> modifications to the referred page. Now the page renders "correctly"
+> in Dillo, w3m, lynx, Mozilla (0.9.9), and Konqueror (2.2). It is
+> totally ignored by Netscape (4.77).
+>
+> I haven't tried any others (I have no Windows to try IE), but for
+> now I guess it's better than it was before.
+
+Ok, I gave some time to it, and as someone pointed out, there
+were some missing <td> tags (but this wasn't the main problem).
+It was fixed though.
+
+As the funding page is generated by a script, and its results
+are rendered perfectly by Netscape, Mozilla, Dillo, etc,
+wrapping it within our main site-frame shouldn't be a problem
+(it's done with another script, and there're plenty of working
+pages already).
+
+The point was: (ta ta ta taaaaaaaaaaannnn!.....)
+
+That when adapting the script, the last </table> was commented
+out!!!
+
+So netscape thought there was a lot yet to come and as it needs
+the whole table to start rendering, it did what you saw!
+
+Ah, and as there were some lacking tags, you can imagine the
+algorithmic hell in there.
+
+---
+
+Ahhhh, lots of times I've been thinking whether it would be a
+good idea to construct some malformed pages with a view to
+illustrate some people, that it is _very easy_ to pollute the web
+in an effort to try to push one browser over another.
+
+The ignorant thinks:
+
+"Ah this browser is more powerful (or advanced) because it can
+render this page."
+
+or
+
+"This browser is bad because I can't see this page, and it
+renders Ok with *"
+
+
+The right path though, is to try to keep it to the standards,
+and not to pullute the informative space where we all benefit
+form having access to.
+
+My apologies for the mistake, it wasn't intended, we even tested
+with several other browsers while developing it.
+
+
+Please test the new HTML code, and report back how it went.
+
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Can you help me?
+
+From: Armish <armish@li...> - 2002-04-29 13:35
+
+when i write the command "dillo" to the command line,the dillo opens and 
+closes in a minute and gives this error messages to the terminal ;
+(I use dillo-0.6.5)
+
+--------------------------------------------------------------------------------
+dillo_dns_init: Here we go!
+Loading bookmarks...
+a_Cache_open_url: file:/root/.dillo/splash024.html
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+
+Gdk-CRITICAL **: file gdkfont.c: line 318 (gdk_string_width): assertion `font 
+!= NULL' failed.
+Segmentation fault
+------------------------------------------------------------------------------------------
+
+what can i do?(I use the iso8859-9 fonts [Turkish]) 
+
+
+
+Re: [Dillo-dev]web page crash
+
+From: higuita <higuita@GM...> - 2002-04-29 09:35
+
+Attachments: Message as HTML      
+
+Ola' Livio
+
+On Fri, 26 Apr 2002 08:46:30 -0300, Livio Baldini Soares <livio@im...> wrote:
+> > i was using dillo 0.6.4 and found that it crash every time in
+> > this web page
+> > http://www.landoverbaptist.com
+> Humm, that's strange. I can't seem to reproduce the crash. I've
+
+me too 8)
+i have reboot the system since then and now works fine
+i dont know what happend, but at the time is crashed all the
+time (i deleted all the core dumps in my system this weekend, so
+we cant even check that )8
+
+> Oh, and instead of using 0.6.4, try reproducing the crash with 0.6.5
+
+already update and still dont crash... so maybe was a problem
+with my system
+
+Thanks for dillo
+abraços
+
+higuita
+-- 
+One Unix to rule them all, One Resolver to find them,
+One IP to bring them all and in the zone bind them. 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-04-29 06:14
+
+seems about right in ie6 now
+
+jonathan 
+
+
+
+[Dillo-dev]Useful patches from the OpenBSD folks
+
+From: Andreas Schweitzer <andy@ph...> - 2002-04-29 03:42
+
+Hi everybody
+While notifying the OpenBSD folks that they can upgrade
+their dillo entry I noticed the patches they apply to
+it before allowing a compile :
+http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/
+The 64bit issues certainly seem reasonable. As of this
+writing the patches are against 0.6.4 and patches/patch-src_dns_c
+and parts of patches/patch-src_IO_http_c are no longer necessary.
+But the rest of the 64bit issues deserve consideration.
+
+I also told them about our efforts to make it compile out of the
+box on OpenBSD, therefore some other stuff will simplyfy as well.
+
+The other BSD's have currently no relevant patches.
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-29 03:07
+
+Hello,
+
+Jorge Arellano Cid writes:
+> 
+> Doug,
+> 
+> > On Fri, Apr 26, 2002 at 10:13:26AM -0400, Jorge Arellano Cid wrote:
+> >
+> > <snip>
+> >
+> > > Ah, there's also some very interesting new material in the
+> > > site, so take your time and read it...
+> >
+> > This page http://dillo.cipsga.org.br/funding/ is not rendering properly
+> > in anything except dillo :-)
+> 
+> Hmmm, strange thing.
+> 
+> I reviewed the code several times but havent't found anything
+> non-standard there. Netscape simply "eats" a big part of the
+> page, and tweaking the page by hand, I was able to isolate a case
+> where adding the simplest of the subtables in a row triggered the
+> problem (on Netscape). Mozilla, OTOH, renders the main part at
+> the bottom.
+
+In the objective to temporarily aliviate this issue, I've done a few
+modifications to the referred page. Now the page renders "correctly"
+in Dillo, w3m, lynx, Mozilla (0.9.9), and Konqueror (2.2). It is
+totally ignored by Netscape (4.77).
+
+I haven't tried any others (I have no Windows to try IE), but for
+now I guess it's better than it was before.
+
+Jorge, sorry for the sudden intrusion. You can revert my changes if
+you like.
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]image rendering
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-04-28 21:03
+
+following on from the funding thread..
+
+I have reported a possible bug.
+
+pages I maintain http://www.peepo.com/alfi/c.html
+
+images 2 and 3 are not rendered by dillo but are by practically any 
+other browser...
+
+any ideas welcome.
+
+there are numerous other jpegs, and links using the same scripts around 
+the site, but these two images are the only ones I've found that won't 
+render in dillo.
+
+thanks
+
+jonathan chetwynd 
+
+
+
+Re: Re: [Dillo-dev]0.6.5 release
+
+From: Daniel Fairhead <ralphtheraccoon@uk...> - 2002-04-28 21:00
+
+Hi,
+
+> I reviewed the code several times but havent't found anything
+> non-standard there. Netscape simply "eats" a big part of the
+> page, and tweaking the page by hand, I was able to isolate a case
+> where adding the simplest of the subtables in a row triggered the
+> problem (on Netscape). Mozilla, OTOH, renders the main part at
+> the bottom.
+
+I looked at the code just now (even though I'm not Sebastian), and I
+think the problem is that within a lot of <tr> tags there aren't <td>s.
+Line 126 is one instance. This would explain why Netscape and
+moz both have problems with it, netscape would just say "argh! problem!
+ignore this bit!" and moz would say "argh! problem! render this somewhere 
+else!" like with the geocities addbox.
+
+http://validator.w3.org/check?uri=http://dillo.cipsga.org.br/funding/
+
+shows a lot of other stuff too.
+
+Hope this is useful,
+
+Dan 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-04-28 20:59
+
+I think the problem may relate to using tables within tables.
+This is not to be encouraged, I've heard.
+
+try http://validator.w3.org, there are numerous 'errors' most relate to 
+the use of tables.
+I had spotted this potential problem before validating.
+
+i can also say that mozilla and ie6 fail to show the content which dillo 
+does for the funding page.
+
+thanks
+
+jonathan chetwynd 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-28 19:41
+
+Doug,
+
+> On Fri, Apr 26, 2002 at 10:13:26AM -0400, Jorge Arellano Cid wrote:
+>
+> <snip>
+>
+> > Ah, there's also some very interesting new material in the
+> > site, so take your time and read it...
+>
+> This page http://dillo.cipsga.org.br/funding/ is not rendering properly
+> in anything except dillo :-)
+
+Hmmm, strange thing.
+
+I reviewed the code several times but havent't found anything
+non-standard there. Netscape simply "eats" a big part of the
+page, and tweaking the page by hand, I was able to isolate a case
+where adding the simplest of the subtables in a row triggered the
+problem (on Netscape). Mozilla, OTOH, renders the main part at
+the bottom.
+
+Well AFAIK, there's no problem with the HTML (that's generated
+by a couple of scripts BTW). I may be wrong, or my knowledge of
+the HTML table SPEC may not be perfect, so, the best that I can
+do is to ask "our" tables expert: Sebastian.
+
+Sebastian: Do you see anything wrong with the HTML of the
+presentation, or is just a simultaneous fault on a couple of big
+browsers? (certainly a rare case, although plausible).
+
+
+Greetings
+Jorge.- 
+
+
+
+[Dillo-dev]Error
+
+From: Armish <armish@li...> - 2002-04-27 17:33
+
+when i write the command "dillo" to the command,the dillo opens and closes in 
+a minute and gives this error messages to the terminal ;
+dillo_dns_init: Here we go!
+Loading bookmarks...
+a_Cache_open_url: file:/root/.dillo/splash024.html
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+Can't load any fonts!
+
+Gdk-CRITICAL **: file gdkfont.c: line 452 (gdk_char_width): assertion `font 
+!= NULL' failed.
+
+Gdk-CRITICAL **: file gdkfont.c: line 318 (gdk_string_width): assertion `font 
+!= NULL' failed.
+Segmentation fault
+
+
+what can i do?(I use the iso8859-9 fonts [Turkish]) 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: Doug Kearns <djkea2@mu...> - 2002-04-27 08:24
+
+On Sat, Apr 27, 2002 at 11:16:13AM +0300, madis wrote:
+> On Sat, 27 Apr 2002, Ivo van Poorten wrote:
+> 
+> > Furthermore, I added two lines to menu.c at line 172:
+> > 
+> > Menu_add(menu, "Back", NULL, bw, a_Commands_back_callback, bw);
+> > Menu_add(menu, "Forward", NULL, bw, a_Commands_forw_callback, bw);
+
+<snip>
+
+> you have been at least 3th person reinventing exactly this patch :)
+> imho it should go into main dillo tree.
+
+Yes, and I'm sure there are countless others running there own variants.
+
+Regards,
+Doug 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: madis <madis.janson@ma...> - 2002-04-27 08:11
+
+On Sat, 27 Apr 2002, Ivo van Poorten wrote:
+
+> Furthermore, I added two lines to menu.c at line 172:
+> 
+> Menu_add(menu, "Back", NULL, bw, a_Commands_back_callback, bw);
+> Menu_add(menu, "Forward", NULL, bw, a_Commands_forw_callback, bw);
+> 
+> It makes browsing more convenient this way, IMHO.
+> I have not thoroughly examined all the sourcecode and I have no serious 
+> plans to start coding on dillo, so maybe somebody could look into this and 
+> maybe make a patch to the CVS code. One question though, is there a reason 
+> why the icons in pixmap.h use so little colours?
+
+you have been at least 3th person reinventing exactly this patch :)
+imho it should go into main dillo tree.
+
+--
+mzz 
+
+
+
+RE: [Dillo-dev]quick question
+
+From: Patrick Glennon <pglennon@me...> - 2002-04-27 04:55
+
+Attachments: Message as HTML      
+
+Thanks for the reply, although I think you misunderstood. The
+meta-refresh patch and cache size limit patch were not mine, they were
+written by others, and they were good code patches, just created against
+earlier versions of dillo then we were using. My attempts to merge them
+in with 0.6.4 are what caused the problems, although they are working...
+
+I'm hoping that the solutions they created will get merged, not my
+hacked up attempts to mix them with 0.6.4... things are working now,
+there are just some weird complaints undoubtedly due to my bad merge...
+
+Hope that's more clear ;)
+
+-P
+
+On Fri, 2002-04-26 at 15:21, Eric Gaudet wrote:
+
+Hi,
+
+> Couple of quick things: 
+> 
+> 1) what is the priority of getting the meta-refresh
+> tag and the cache management patches in? I'm working
+> on an ongoing project with hotel survey kiosks using 
+> dillo in an embedded system ( intrinsyc cerfpod ). 
+> i've managed to staple and hot-glue a patch against 
+> an earlier version into 6.4 ( I think it was Pekka's 
+> patch, but I don't remember... ), but it is still 
+> pretty messy and complaining about things ( it's 
+> working though ;) It would be nice to have those 
+> in the stable or at least in the CVS tree to work 
+> against? My client is about to start pushing this 
+> in the sales channel, but when it is sold, we will 
+> need to be a bit more stable.. 
+
+There is several things you can do.
+- First, you can work against the cvs instead of a tarball. That way you can
+keep you own version up to date (by doing 'cvs update -dP' regularly) and
+still work on it.
+- I understand there is two different features here. The best thing is
+probably to use one cvs checkout for each of them, produce two patches when
+you're happy, and apply the patches on your own "release" version.
+- Make you patches available: post the url on the list. This way, people can
+try them and fix them (while keeping you informed, of course). This will
+speed-up *a*lot* the inclusion in the release, 'cause you can be sure Jorge
+will never even look at a patch that's "pretty messy and complaining about
+things" ;-) Let people help, open source rules.
+
+> 2) wrote a quick article for linuxdevices.com on how we got rapidly to
+phase 1 with almost no coding using dillo and > familiar:
+http://www.linuxdevices.com/articles/AT2869412121.html 
+
+Nice.
+
+> Thanks! 
+> -Patrick 
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: Ivo van Poorten <ivop@eu...> - 2002-04-27 00:37
+
+Hello all,
+
+I tried out dillo 0.6.5 today and I noticed that the page-up key didn't 
+work (anymore?). I localized the problem. In dw_gtk_scrolled_frame.c at 
+line 480 it says:
+
+if (event->state & (GDK_MOD1_MASK | GDK_MOD2_MASK))
+return FALSE;
+
+I don't know what this is supposed to do (it's not in the pagedown 
+section), but when I comment it out, pageup is working again.
+
+Furthermore, I added two lines to menu.c at line 172:
+
+Menu_add(menu, "Back", NULL, bw, a_Commands_back_callback, bw);
+Menu_add(menu, "Forward", NULL, bw, a_Commands_forw_callback, bw);
+
+It makes browsing more convenient this way, IMHO.
+I have not thoroughly examined all the sourcecode and I have no serious 
+plans to start coding on dillo, so maybe somebody could look into this and 
+maybe make a patch to the CVS code. One question though, is there a reason 
+why the icons in pixmap.h use so little colours?
+
+Greetings,
+--Ivo 
+
+
+
+RE: [Dillo-dev]quick question
+
+From: Eric Gaudet <ericg@ta...> - 2002-04-26 20:19
+
+Hi,
+
+> Couple of quick things: 
+> 
+> 1) what is the priority of getting the meta-refresh
+> tag and the cache management patches in? I'm working
+> on an ongoing project with hotel survey kiosks using 
+> dillo in an embedded system ( intrinsyc cerfpod ). 
+> i've managed to staple and hot-glue a patch against 
+> an earlier version into 6.4 ( I think it was Pekka's 
+> patch, but I don't remember... ), but it is still 
+> pretty messy and complaining about things ( it's 
+> working though ;) It would be nice to have those 
+> in the stable or at least in the CVS tree to work 
+> against? My client is about to start pushing this 
+> in the sales channel, but when it is sold, we will 
+> need to be a bit more stable.. 
+
+There is several things you can do.
+- First, you can work against the cvs instead of a tarball. That way you can
+keep you own version up to date (by doing 'cvs update -dP' regularly) and
+still work on it.
+- I understand there is two different features here. The best thing is
+probably to use one cvs checkout for each of them, produce two patches when
+you're happy, and apply the patches on your own "release" version.
+- Make you patches available: post the url on the list. This way, people can
+try them and fix them (while keeping you informed, of course). This will
+speed-up *a*lot* the inclusion in the release, 'cause you can be sure Jorge
+will never even look at a patch that's "pretty messy and complaining about
+things" ;-) Let people help, open source rules.
+
+> 2) wrote a quick article for linuxdevices.com on how we got rapidly to
+phase 1 with almost no coding using dillo and > familiar:
+http://www.linuxdevices.com/articles/AT2869412121.html 
+
+Nice.
+
+> Thanks! 
+> -Patrick 
+
+
+
+[Dillo-dev]quick question
+
+From: Patrick Glennon <pglennon@me...> - 2002-04-26 19:48
+
+Attachments: Message as HTML      
+
+Couple of quick things: 
+
+1) what is the priority of getting the meta-refresh tag and the cache
+management patches in? I'm working on an ongoing project with hotel
+survey kiosks using dillo in an embedded system ( intrinsyc cerfpod ). 
+i've managed to staple and hot-glue a patch against an earlier version
+into 6.4 ( I think it was Pekka's patch, but I don't remember... ), but
+it is still pretty messy and complaining about things ( it's working
+though ;) It would be nice to have those in the stable or at least in
+the CVS tree to work against? My client is about to start pushing this
+in the sales channel, but when it is sold, we will need to be a bit more
+stable.. 
+
+2) wrote a quick article for linuxdevices.com on how we got rapidly to
+phase 1 with almost no coding using dillo and familiar: 
+http://www.linuxdevices.com/articles/AT2869412121.html
+
+Thanks! 
+
+-Patrick 
+
+
+
+RE: [Dillo-dev]Oops, cancel that bug...
+
+From: Eric Gaudet <ericg@ta...> - 2002-04-26 19:44
+
+Actually there is a trick to add a comment: go head and volunteer for this
+bug, and add a comment in place of the email address. Keep it short, though.
+
+Eric
+
+> -----Original Message-----
+> From: dillo-dev-admin@li...
+> [mailto:dillo-dev-admin@li...]On Behalf Of Paul
+> Chamberlain
+> Sent: Friday, April 26, 2002 12:17 PM
+> To: Dillo mailing list
+> Subject: [Dillo-dev]Oops, cancel that bug...
+> 
+> 
+> I guess there's no way to cancel your own bug submission.
+> In fact, there's no way to even add a comment.
+> 
+> I just submitted a bug about cookies not working on
+> slashdot.org. I guess you have to set up cookiesrc
+> to accept the cookies. It works now despite dumping
+> slashdot's headers onto the screen (They use 302
+> rather than 301).
+> 
+> Perhaps the bug should read "why do I have to enable
+> cookies"?
+> --
+> Paul Chamberlain, tif@ti...
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]Oops, cancel that bug...
+
+From: Paul Chamberlain <tif@ti...> - 2002-04-26 19:17
+
+I guess there's no way to cancel your own bug submission.
+In fact, there's no way to even add a comment.
+
+I just submitted a bug about cookies not working on
+slashdot.org. I guess you have to set up cookiesrc
+to accept the cookies. It works now despite dumping
+slashdot's headers onto the screen (They use 302
+rather than 301).
+
+Perhaps the bug should read "why do I have to enable
+cookies"?
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+RE: [Dillo-dev]Content Access (was: Simple plugins)
+
+From: Eric Gaudet <ericg@ta...> - 2002-04-26 16:57
+
+> On Wed, Apr 24, 2002 at 06:00:42PM -0700, Eric Gaudet wrote:
+> [...]
+> > The tough point is when selected text goes accross 
+> containers (which happen
+> > very often since almost every non-text, non-image dw is 
+> likely to be an
+> > invisible containter containing another dw).
+> > Here's what I think the set of features that would give a 
+> nice DOM-like
+> > feeling:
+> > - a struct that would be used as a return value for all the 
+> functions,
+> > containing only a pointer to the widget (castable to 
+> dw_widget) and its type
+> > (one of WORD, IMAGE, TABLE_CELL, and some others like line 
+> breaks, bullets
+> > or list, form widgets, etc.)
+> > - a get_next function (whatever you want to name it), that 
+> would accept as
+> > parameters a pointer on the current widget, a mask for the 
+> type, and a
+> > direction (next, next_sibling, previous, previous sibling, 
+> first_child).
+> > - get_parent(pointer).
+> > 
+> > I am open to any suggestion for the implementation.
+> > This could be done by having the functions walk the 
+> structure at run-time,
+> > or add the relevant fields (type, next, previous, first 
+> child, parent) to
+> > the dw struct at (page) build time (no need for get_* 
+> functions here, only
+> > access the dw struct).
+> 
+> A solution would be to have abstract iterators, like in STL or
+> java.util.Iterator. Having static methods (with a state within the
+> widget) has the disadvantage of restricting the number of "running"
+> iterations at the same time to one.
+> 
+
+Sounds like an overkill. But if you think it's doable, why not.
+I like it better if the dw_widget class provides the information.
+
+> BTW, do you need to represent the positions of the words (where the
+> selection starts and where it ends)? How do you plan to solve this
+> problem? This must be considered, too.
+> 
+
+I am currently keeping a pointer to the first and last selected child
+widget, and descending the tree if the child widget has childs. (because the
+de/selection calls happen more often than copy/paste, so de/linking is the
+part to be optimized)
+
+[...]
+> > I am affraid Dw insertion and deletion is mandatory for 
+> > that long-term "vision".
+> 
+> Focus on construction, only because this is what is needed for
+> CSS. Full DOM (or something equivalent) could be an extension for the
+> future.
+> 
+
+Depending on how you build the <div> elements in the page, you can
+link/unlink a set of widgets to the link's container afterwards and that
+would nicely replace insertion/deletion.
+
+> 
+> Sebastian
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Using Dillo on a 4bits per pixel device
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-26 16:45
+
+Attachments: testrgb.c      
+
+Hi,
+
+On Mon, Apr 22, 2002 at 03:08:31PM +0530, Samyeer Metrani wrote:
+> I am trying to get Dillo running on the Simputer, a monochrome
+> strongarm Sa1110 based device.
+> 
+> Dillo works fine when viewing text pages, when trying to view a gif
+> or jpeg it crashes. Is this something that somebody else has faced
+> before. I believe the problem is linked to the 16color display. If I
+> run Dillo (the same executable file) on an iPAQ it runs fine with
+> the same libraries (jpeg etc.).
+> 
+> Any suggestions, pointers...
+
+Dillo depends on GdkRGB, which may not work with all displays. I've
+attached a simple test, taken from the Gtk+ distribution. Please
+compile (cc `gtk-config --cflags --libs` testrgb.c) and test it, and
+report the results.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]pango
+
+From: Tobin Fricke <tobin@sp...> - 2002-04-26 16:40
+
+On Fri, 26 Apr 2002, Sebastian Geerken wrote:
+
+> Pango will be used, but no one has yet started with it, this is an
+> open task.
+
+Since it sounds like using Pango is a slightly complicated task (since
+apparently it is wrapped up into the GTK 2.0 conversion?), I was thinking
+recently that perhaps a convenient temporary measure would be to just use
+a library like iconv to convert whatever character set a webpage uses into
+ISO-8859-1 (since "stock" Dillo currently supports only that character
+set). That way, pages encoded in UTF-8 but using only characters
+appearing in Latin1 could still be displayed correctly.
+
+Any comments on this idea before I put any time into it? It's kind of a
+hack, but the lack of support for unicode is pretty annoying, and in fact
+prevents me from using Dillo to view my own web pages, so I might be
+willing to put in some effort on this.
+
+http://www.gnu.org/software/libiconv/
+
+--tobin 
+
+
+
+Re: [Dillo-dev]pango
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-26 16:30
+
+On Thu, Apr 25, 2002 at 10:26:08PM -0700, L Parthipan wrote:
+> Is there an effort to use pango in dillo?
+
+Read the web site:
+
+http://dillo.cipsga.org.br/Notes.html
+
+Pango will be used, but no one has yet started with it, this is an
+open task.
+
+Sebastian 
+
+
+
+[Dillo-dev]Content Access (was: Simple plugins)
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-26 16:26
+
+On Wed, Apr 24, 2002 at 06:00:42PM -0700, Eric Gaudet wrote:
+[...]
+> The tough point is when selected text goes accross containers (which happen
+> very often since almost every non-text, non-image dw is likely to be an
+> invisible containter containing another dw).
+> Here's what I think the set of features that would give a nice DOM-like
+> feeling:
+> - a struct that would be used as a return value for all the functions,
+> containing only a pointer to the widget (castable to dw_widget) and its type
+> (one of WORD, IMAGE, TABLE_CELL, and some others like line breaks, bullets
+> or list, form widgets, etc.)
+> - a get_next function (whatever you want to name it), that would accept as
+> parameters a pointer on the current widget, a mask for the type, and a
+> direction (next, next_sibling, previous, previous sibling, first_child).
+> - get_parent(pointer).
+> 
+> I am open to any suggestion for the implementation.
+> This could be done by having the functions walk the structure at run-time,
+> or add the relevant fields (type, next, previous, first child, parent) to
+> the dw struct at (page) build time (no need for get_* functions here, only
+> access the dw struct).
+
+A solution would be to have abstract iterators, like in STL or
+java.util.Iterator. Having static methods (with a state within the
+widget) has the disadvantage of restricting the number of "running"
+iterations at the same time to one.
+
+BTW, do you need to represent the positions of the words (where the
+selection starts and where it ends)? How do you plan to solve this
+problem? This must be considered, too.
+
+[...]
+> > There will be a subset of DOM for CSS, with a focus on simple
+> > construction (appending nodes, no insertion), and especially changing
+> > style attributes (asynchronous HTML/CSS processing). Especially for
+> > the latter, an extended Dw interface is needed, but I haven't yet done
+> > any work on this area.
+> > 
+> 
+> You might want to merge the concept of css "class" with the current
+> dw_style, then.
+
+Yes, the DOM should hide Dw as far as possible, DwStyle will play an
+important role.
+
+[...]
+> > (Of course, text selection could copy HTML code into the cut buffer 
+> > -- why not, at least as an option?)
+> 
+> Nice idea. Can we find where in the html is located a word/widget from a
+> dw_page?
+
+Has to be thought of. This whole DOM thing will probably evolve over
+the time.
+
+[...]
+> > What is a "generic-application client"? ;-)
+> > 
+> 
+> That would be an application using the dillo's BrowserWindows for rendering
+> purpose (dillo's IO/http/web engine being one of the possible
+> applications).
+
+Well, personally, I hate web based applications (read: their user
+interface), or (even worse) classic applications trying to immitate
+web pages. I'd rather see dillo to be able to integrate classical
+(widget based) GUI's, to assist the user on document-centric
+applications (e.g. a help browser, based on dillo and a plugin, which
+shows a tree on the left side).
+
+Just MHO, I don't want any replies on this :-)
+
+> This makes sens when you understand that most javascript "applications"
+> mainly try to mimic the behavior of more powerfull GUI toolkits (gtk/qt). Tk
+> almost had it right with Wish, but too much script-oriented.
+> I am affraid Dw insertion and deletion is mandatory for that long-term
+> "vision".
+
+Focus on construction, only because this is what is needed for
+CSS. Full DOM (or something equivalent) could be an extension for the
+future.
+
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]0.6.5 release
+
+From: Doug Kearns <djkea2@mu...> - 2002-04-26 15:31
+
+On Fri, Apr 26, 2002 at 10:13:26AM -0400, Jorge Arellano Cid wrote:
+
+<snip>
+
+> Ah, there's also some very interesting new material in the
+> site, so take your time and read it...
+
+This page http://dillo.cipsga.org.br/funding/ is not rendering properly
+in anything except dillo :-)
+
+Sorry, I haven't the time to look at it at the moment.
+
+<snip>
+
+Regards,
+Doug 
+
+
+
+Re: [Dillo-dev]Using Dillo on a 4bits per pixel device
+
+From: Andreas Schweitzer <andy@ph...> - 2002-04-26 15:03
+
+Hi,
+
+(I'm back online ...)
+
+Here is an issue that is somehow related :
+
+> > I am trying to get Dillo running on the Simputer, a monochrome strong=
+arm Sa1110
+> > based device.
+> > =A0
+> > Dillo works fine when viewing text pages, when trying to view a gif o=
+r jpeg it
+> > crashes. Is this something that somebody else has faced before.=20
+>=20
+> Yes, I believe someone has already complained about Dillo crashing
+> on low depth displays (or was it black&white too?) I don't remember
+> exactly.
+
+When displaying dillo on the 24bit display of my AIX box (which can handl=
+e
+8bit, 16bit and 24bit) it dies with
+
+Gdk-ERROR **: BadMatch (invalid parameter attributes)
+serial 3120 error_code 8 request_code 130 minor_code 3
+
+As soon as any image is displayed - text works fine.
+
+I dug through archives and found this post :
+
+http://mail.gnome.org/archives/gnome-list/2000-June/msg00702.html
+
+However, I could not use that info to fix the problem due
+to my limited understanding of dillo's image handling :-)
+
+Oh - and I inserted this into the bug-tracking engine.
+
+Cheers,
+Andreas
+
+--=20
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]0.6.5 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-26 14:16
+
+Hi there,
+
+
+Ok guys, the wait is over! dillo-0.6.5 is there ready for
+download (finally we decided to revert to the old EAGAIN handler
+in order to make the release, so don't hesitate).
+
+I also made the freshmeat announcement (with dillo this time
+--haaaaaa, what a pleasure! --just hope it works ;).
+
+Ah, there's also some very interesting new material in the
+site, so take your time and read it...
+
+Clebration time!
+
+Best regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]web page crash
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-26 11:46
+
+Hello Higuita!
+
+higuita writes:
+> hi
+> 
+> i was using dillo 0.6.4 and found that it crash every time in
+> this web page
+> 
+> http://www.landoverbaptist.com
+
+
+Humm, that's strange. I can't seem to reproduce the crash. I've
+tried Dillo 0.6.4 and the lastest CVS. Both worked out ok.
+Could you try to get a stack trace from the crash? Maybe we'll have a
+better idea of why Dillo is crashing.
+
+Oh, and instead of using 0.6.4, try reproducing the crash with 0.6.5
+(which should be out some time today or tomorrow), or CVS (which will
+be almost the same as 0.6.5, anyway).
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]pango
+
+From: L Parthipan <lparth@ya...> - 2002-04-26 05:26
+
+Hi,
+
+Is there an effort to use pango in dillo?
+
+cheers
+
+~logan
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Games - play chess, backgammon, pool and more
+http://games.yahoo.com/ 
+
+
+
+[Dillo-dev]web page crash
+
+From: higuita <higuita@GM...> - 2002-04-25 17:38
+
+Attachments: Message as HTML      
+
+hi
+
+i was using dillo 0.6.4 and found that it crash every time in
+this web page
+
+http://www.landoverbaptist.com
+
+higuita
+-- 
+Try not to have a good time ... This is supposed to be educational.
+-- Charles Schulz
+Caravela.homelinux.net:
+6:37pm up 3 days, 23:32, 10 users, load average: 0.68, 0.46, 0.52 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Eric Gaudet <ericg@ta...> - 2002-04-25 00:58
+
+Hi Sebastian,
+
+> Hi Eric,
+> 
+> On Tue, Apr 02, 2002 at 06:34:08PM -0800, Eric GAUDET wrote:
+> [...]
+> > If we choose to go to a full dpi2 right away, (which can take some time,
+> > this is why I propose to keep the early dpi1 for now), we will need more
+> > interaction with the rendering engine, which calls for the two following
+> > features:
+> > - the ability to walk the internal representation of the page: for now,
+it?s a
+> > pain in the ass to find which dw ?children? are actually rendered, which
+are
+> > words, which are containers, etc. The find_text code talks by itself,
+and I am
+> > postponing the text copy-paste until I find a good solution.
+> 
+> Yes, find-text is ugly, and I'll try to find a cleaner, abstract
+> solution; please send me also what kind of interface you need (more or
+> less) exactly for text selection. I do not plan to make this too
+> complicated, just a simple way to access the text content of widgets
+> (see below).
+> 
+
+The tough point is when selected text goes accross containers (which happen
+very often since almost every non-text, non-image dw is likely to be an
+invisible containter containing another dw).
+Here's what I think the set of features that would give a nice DOM-like
+feeling:
+- a struct that would be used as a return value for all the functions,
+containing only a pointer to the widget (castable to dw_widget) and its type
+(one of WORD, IMAGE, TABLE_CELL, and some others like line breaks, bullets
+or list, form widgets, etc.)
+- a get_next function (whatever you want to name it), that would accept as
+parameters a pointer on the current widget, a mask for the type, and a
+direction (next, next_sibling, previous, previous sibling, first_child).
+- get_parent(pointer).
+
+I am open to any suggestion for the implementation.
+This could be done by having the functions walk the structure at run-time,
+or add the relevant fields (type, next, previous, first child, parent) to
+the dw struct at (page) build time (no need for get_* functions here, only
+access the dw struct).
+
+> > - the ability to dynamically change the tree structure, not only be
+altering
+> > the content of it, but by inserting and removing words and widgets.
+Right now,
+> > the result when trying that is guaranteed to be ?unknown?.
+> >
+> > This means we have to come with some sort of DOM interface on top of the
+> > internal dw representation.
+> 
+> There will be a subset of DOM for CSS, with a focus on simple
+> construction (appending nodes, no insertion), and especially changing
+> style attributes (asynchronous HTML/CSS processing). Especially for
+> the latter, an extended Dw interface is needed, but I haven't yet done
+> any work on this area.
+> 
+
+You might want to merge the concept of css "class" with the current
+dw_style, then.
+
+> If plugins will be able to access the document tree, they should IMO
+> do this by the DOM interface (except graphical plugins as described in
+> my post before).
+> 
+> I'm not sure if *this* DOM makes sense for text search and selection,
+> this could probably better handled by an extended Dw. DOM is more for
+> handling the *document* structure (as opposed to the widget
+> structure), which is crucial for CSS. 
+
+No matter how you do it, the ability to easily go to the next WORD will make
+my life better.
+
+> (Of course, text selection could copy HTML code into the cut buffer 
+> -- why not, at least as an option?)
+
+Nice idea. Can we find where in the html is located a word/widget from a
+dw_page?
+
+> 
+> > A lot of good could come from it, including the
+> > ability for dillo to become a generic-application client as well as a
+better
+> > browser, at almost no cost in development and no ?bloat?.
+> 
+> What is a "generic-application client"? ;-)
+> 
+
+That would be an application using the dillo's BrowserWindows for rendering
+purpose (dillo's IO/http/web engine being one of the possible
+applications).
+This makes sens when you understand that most javascript "applications"
+mainly try to mimic the behavior of more powerfull GUI toolkits (gtk/qt). Tk
+almost had it right with Wish, but too much script-oriented.
+I am affraid Dw insertion and deletion is mandatory for that long-term
+"vision".
+
+> Sebastian
+> 
+
+Eric 
+
+
+
+Re: [Dillo-dev]Re: Dillo: Bug in new EGAIN code
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-24 14:03
+
+Hi there!
+
+On Mon, 22 Apr 2002, Pekka Lampila wrote:
+
+> On Sun, 21 Apr 2002 17:51:22 -0400 (CLT)
+> Jorge Arellano Cid <jcid@em...> wrote:
+>
+> > After reviewing the patch and giving some thought on it,
+> > there's a new patch that solves the problem without the need of
+> > the extra parameter to IO_write().
+> >
+> > Pekka, please chack what efence has to say about it! :)
+>
+> No problems as far as I can see.
+
+I'm a bit hesitant with this subject. This is the story: I've
+been working on presentation material for the site, and testing
+its rendering with dillo; that is, small html files that are
+re-created by a script very often, and then reloaded into dillo.
+The sad new is that I've caught this problem twice:
+
+>>
+Nav_open_url: Url=>file:/tmp/funding/advantages.html#eff<
+[New Thread 31776 (LWP 413)]
+Delayed SIGSTOP caught for LWP 413.
+LWP 413 exited.
+Nav_open_url: Url=>file:/tmp/funding/advantages.html#eff<
+Cannot find thread 33: invalid thread handle
+(gdb) bt
+#0 0x40083881 in __linuxthreads_create_event () at events.c:26
+#1 0x4007d4da in pthread_handle_create (thread=0x40088e90, attr=0x0,
+start_routine=0x8075a38 <File_transfer_file>, arg=0x80eda08,
+mask=0x80f9dfc, father_pid=276, report_events=1, event_maskp=0x40088fec)
+at manager.c:615
+#2 0x4007ce78 in __pthread_manager (arg=0xd) at manager.c:157
+#3 0x4007cf80 in pthread_start_thread (arg=0xd) at manager.c:221
+>>
+
+When it continues, a SEGFAULT pops...
+
+I haven't given it much thought (that's the purpose of this
+email :), so please give some work to it.
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]a way to have the toolbar disabled
+
+From: CLOTILDE Guy Daniel <guy.clotilde@wa...> - 2002-04-24 10:15
+
+Hi all
+Maybe I lost my last post, so I post it once again.
+Is there a way to disable the toolbars in dillo in dillorc?
+If not is it in the list of things to be implemented?
+For now, double-cliking in the page makes the toolbars appear/disappear .
+
+Thanks for answers.
+
+BTW, it seems quite quiet here since last weeks. 
+
+
+
+Re: [Dillo-dev]Using Dillo on a 4bits per pixel device
+
+From: Samyeer Metrani <sam@nc...> - 2002-04-23 03:39
+
+Hello Livio,
+
+Thank you for your email.
+
+I tried out the patch but it does not solve my problem. I dont have a debugger on
+the arm device that I am trying to run it on so I need to dig some more to find out
+where the problem is coming from.
+
+I will also try it out on a pc with a 16 color display and see what happens.
+
+I know that bitmap(gif/jpeg) display is working fine because I have a program that
+uses libjpeg and displays them fine. I have another browser (chimera) that is able
+to display the gifs/jpeg's fine.
+
+Is there anybody who has tried dillo on the mono compaq iPaq? I know that the color
+compaq has a 12bit display I assume that the mono one would use a 4bit.
+
+Warm Regards,
+
+Samyeer
+
+Livio Baldini Soares wrote:
+
+> Hello Samyeer!
+>
+> Samyeer Metrani writes:
+> > Hello,
+> >
+> > I am trying to get Dillo running on the Simputer, a monochrome strongarm Sa1110
+> > based device.
+> >
+> > Dillo works fine when viewing text pages, when trying to view a gif or jpeg it
+> > crashes. Is this something that somebody else has faced before.
+>
+> Yes, I believe someone has already complained about Dillo crashing
+> on low depth displays (or was it black&white too?) I don't remember
+> exactly.
+>
+> > I believe the
+> > problem is linked to the 16color display. If I run Dillo (the same executable
+> > file) on an iPAQ it runs fine with the same libraries (jpeg etc.).
+> >
+> > Any suggestions, pointers...
+>
+> I don't know exactly _what_ is making your Dillo crash. Maybe you
+> could try compiling it yourself and run under gdb... :
+>
+> gdb ./dillo
+>
+> (gdb) r
+>:
+>: Here Dillo will run and you can do your stuff to make it crash
+>:
+> CRASH!
+> (gdb) bt
+>
+> Then you get a backtrace from Dillo's calls. You can either
+> interpret them yourself or post them here for help.
+>
+> I've also made a patch so that Dillo uses a private colormap, maybe
+> it'll do something for you (I'm not promising anything ;-):
+>
+> (against current CVS):
+> http://www.ime.usp.br/~livio/dillo/patches/private_colormap.diff
+>
+> hopes this help,
+>
+> --
+> Livio <livio@im...> 
+
+
+
+RE: [Dillo-dev]Dillo on Solaris 8..y
+
+From: Yu-Fong Cho <yfcho@ms...> - 2002-04-22 14:19
+
+Sadly, there is no Solaris x86 on the list, but only Solaris SPARC.
+
+I was just wondering how much difference between Solaris x86 and Solaris
+SPARC?
+According to Sun, they are code compatible...
+If a program is ok in Solaris SPARC, it should be no problem in Solaris x86
+after recompiling it.
+
+
+Yu-Fong
+
+-----Original Message-----
+From: Jorge Arellano Cid [mailto:jcid@em...]
+Sent: Wednesday, March 20, 2002 5:50 PM
+To: Yu-Fong Cho
+Subject: RE: [Dillo-dev]Dillo on Solaris 8..y
+
+
+
+Yu-Fong,
+
+> Please give me some information about this.
+>
+> I know this is not a development problem, but I am trying install Dillo on
+> different platforms for interest. I have done on FreeBSD 4.5 and now are
+> trying on Solaris 8 x86. Just give me some information about this and I'll
+> appreciate it.
+>
+> Thank you.
+
+Please go to the [Links] page, Compatibility section. There's a
+big list there. If it doesn't work for you on one of the listed
+machines/OS it's probably a local configuration error.
+
+Cheers
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Dillo on Solaris 8..
+
+From: Yu-Fong Cho <yfcho@ms...> - 2002-04-22 14:19
+
+SunOS 5.8 is Solaris 8.
+Solaris 8 is the package name and SunOS 5.8 is the kernel name.
+
+I guess you have to use GNU make, Sun make seems don't understand dillo
+Makefile.
+
+
+-----Original Message-----
+From: Mark Schreiber [mailto:mark7@an...]
+Sent: Saturday, March 23, 2002 1:28 PM
+To: Yu-Fong Cho
+Subject: Re: [Dillo-dev]Dillo on Solaris 8..
+
+
+I don't know whether the problem is that people aren't responding. It
+may just be that not many people have Solaris.
+
+I tried, but the lastest Sun thing I have access to is SunOS 5.8, and
+the dillo Makefile won't even run on that thing. <shrug>
+
+On Wed, Mar 20, 2002 at 05:10:52PM -0500, Yu-Fong Cho wrote:
+> Please give me some information about this.
+>
+> I know this is not a development problem, but I am trying install Dillo on
+> different platforms for interest. I have done on FreeBSD 4.5 and now are
+> trying on Solaris 8 x86. Just give me some information about this and I'll
+> appreciate it.
+>
+> Thank you.
+>
+>
+> -----Original Message-----
+> From: dillo-dev-admin@li...
+> [mailto:dillo-dev-admin@li...]On Behalf Of Yu-Fong Cho
+> Sent: Tuesday, March 19, 2002 12:46 PM
+> To: Dillo Dev
+> Subject: [Dillo-dev]Dillo on Solaris 8..
+>
+>
+> Hi,
+>
+> Has anyone tried run Dillo 0.6.4 on Solaris 8 before?
+>
+> I compiled and installed it. It seems be ok except the way it handle jpeg
+> image.
+> The jpeg image shows only black and while mode and has some vertical line
+on
+> it. It isn't right.
+>
+> I have GNU jpeg and zlib installed. Does anyone know what is going on?
+> I tried Dillo on FreeBSD 4.5 before and it was ok.
+>
+> Appreciate any information. Thank you.
+>
+>
+> Yu-Fong Cho
+>
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+>
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+--
+Best of luck,
+Mark Schreiber 
+
+
+
+[Dillo-dev]When will dillo 0.6.5 be released?
+
+From: robbie chen <sandy_21@si...> - 2002-04-22 14:00
+
+V2hhdCBmZWF0dXJlIGltcHJvdmVkP0knbSB3YWl0aW5nIGZvciBpdA0KLS0tLS0gT3JpZ2luYWwg
+TWVzc2FnZSAtLS0tLSANCkZyb206ICJKb3JnZSBBcmVsbGFubyBDaWQiIDxqY2lkQGVtYXRpYy5j
+b20+DQpUbzogIkRpbGxvIG1haWxpbmcgbGlzdCIgPGRpbGxvLWRldkBsaXN0cy5zb3VyY2Vmb3Jn
+ZS5uZXQ+DQpTZW50OiBNb25kYXksIEFwcmlsIDIyLCAyMDAyIDU6NTEgQU0NClN1YmplY3Q6IFtE
+aWxsby1kZXZdUmU6IERpbGxvOiBCdWcgaW4gbmV3IEVHQUlOIGNvZGUNCg0KDQo+IA0KPiBIaSB0
+aGVyZSENCj4gDQo+IA0KPiBPbiBTdW4sIDE0IEFwciAyMDAyLCBMaXZpbyBCYWxkaW5pIFNvYXJl
+cyB3cm90ZToNCj4gDQo+ID4gSGVsbG8gUGVra2EhDQo+ID4NCj4gPiBQZWtrYSBMYW1waWxhIHdy
+aXRlczoNCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IFdoZW4gcnVubmluZyB3aXRoIGVmZW5jZSBl
+bmFibGVkIERpbGxvIGNyYXNoZXMgYmVmb3JlIGRpc3BsYXlpbmcgYW55DQo+ID4gPiBwYWdlLg0K
+PiA+ID4NCj4gPiA+IElPX2NhbGxiYWNrIChzcmM9MHg0MzVhYWZmMCwgY29uZD1HX0lPX09VVCwg
+ZGF0YT0weDEpIGF0IElPLmM6MjQwDQo+ID4gPiAyNDAgICAgICAgICAgIGlmIChpby0+U3RhdHVz
+ID09IC1FQUdBSU4pDQo+ID4NCj4gPiAgIEFoISBHb29kIGV5ZSEgSSBmb3VuZCB0aGUgcHJvYmxl
+bS4uLg0KPiA+DQo+ID4gPiBJIHRoaW5rIGlvLT5TdGF0dXMgaXMgbm90IGRlZmluZWQuDQo+ID4g
+Pg0KPiA+ID4gRG9uJ3Qga25vdyBlbm91Z2ggYWJvdXQgSU8tc3lzdGVtIHRvIGNvbWUgdXAgd2l0
+aCBwcm9wZXIgZml4LiBCdXQgSSdsbA0KPiA+ID4gaW1hZ2luZSBpdCB3b24ndCBiZSB0b28gZGlm
+ZnVjdWx0IHByb2JsZW0uIDopDQo+ID4NCj4gPiAgIFdlbGwsIGl0J3Mgbm90IGlvLT5TdGF0dXMg
+d2hpY2ggaXMgbm90IGRlZmluZWQgYnV0IHRoZSBgaW9gDQo+ID4gaXRzZWxmLi4gRXZlcnl0aW1l
+IHRoZSBJTyBmaW5pc2hlcywgSU9fd3JpdGUoKSBjYWxscw0KPiA+IGFfSU9fY2NjKE9wRW5kLC4u
+LiksIHdoaWNoIGNvbnNlcXVlbnRseSBmcmVlcyB0aGUgYGlvYC4gIDotKA0KPiA+DQo+ID4gICBB
+bmQgZWxlZ2FudCBmaXggZm9yIHRoaXMgaXMga2luZCBvZiBoYXJkLiBGaXJzdCBJIHRob3VnaHQg
+b2YNCj4gPiBkZWxheWluZyB0aGUgYV9JT19jY2MoKSBjYWxsLCBhbmQgZG9pbmcgaXQgaW5zaWRl
+IElPX2NhbGxiYWNrKCkuLiBidXQNCj4gPiB0aGF0IGxvb2tlZCBraW5kIG9mIGRpcnR5LiBUaGVu
+IEkgdGhvdWdodCBvZiB0cnlpbmcgdG8gc2V0IGBpb2AgdG8NCj4gPiBOVUxMIGFmdGVyIGl0IGhh
+ZCBiZWVuIGZyZWVkIHNvIHRoYXQgd2UgY291bGQgY2hlY2sgZm9yIE5VTEwNCj4gPiB2YWx1ZS4u
+LiBidXQgdGhhdCB3b3VsZCByZXF1aXJlIGNoYW5nZXMgdG8gdGhlIENDQyBBUEkgKHdlIHdvdWxk
+IGhhdmUNCj4gPiB0byBwYXNzIHZvaWQgKipEYXRhLCBpbnN0ZWFkIG9mIHZvaWQgKkRhdGEpLg0K
+PiA+DQo+ID4gICBJJ3ZlIG1hZGUgYSBzb2x1dGlvbiB3aGljaCBtaWdodCBub3QgYmUgZ29vZCBl
+aXRoZXIsIGJ1dCBhdCBsZWFzdA0KPiA+IHRoZSBjaGFuZ2VzIGFyZSBzbWFsbCwgYW5kIHRoZSBw
+cm9ibGVtIGdldHMgZml4ZWQuLi4gbWF5YmUgeW91IGd1eXMNCj4gPiBjYW4gdGhpbmsgb2Ygc29t
+ZXRoaW5nIGJldHRlci4gVGhlIHBhdGNoIGZvbGxvd3M6DQo+IA0KPiAgIEFmdGVyICByZXZpZXdp
+bmcgIHRoZSAgcGF0Y2ggIGFuZCAgZ2l2aW5nICBzb21lICB0aG91Z2h0IG9uIGl0LA0KPiB0aGVy
+ZSdzICBhICBuZXcgcGF0Y2ggdGhhdCBzb2x2ZXMgdGhlIHByb2JsZW0gd2l0aG91dCB0aGUgbmVl
+ZCBvZg0KPiB0aGUgZXh0cmEgcGFyYW1ldGVyIHRvIElPX3dyaXRlKCkuDQo+IA0KPiAgIFBla2th
+LCBwbGVhc2UgY2hhY2sgd2hhdCBlZmVuY2UgaGFzIHRvIHNheSBhYm91dCBpdCEgOikNCj4gDQo+
+ICAgQ2hlZXJzDQo+ICAgSm9yZ2UuLQ0KPiANCj4gDQo+IFBTOiAgMC42LjUgIGlzIGEgYml0IGRl
+bGF5ZWQsIGJ1dCBpdCdzIGp1c3QgYSBmZXcgZGF5cyBhaGVhZCwgYW5kDQo+IG1vc3QgIHByb2Jh
+Ymx5IHdpbGwgYmUgY3VycmVudCBDVlMuIEl0IG5lZWRzIHNvbWUgdGVzdGluZyBvZiB0aGlzDQo+
+IHBhdGNoLg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
+X19fX19fX19fX19fXw0KPiBEaWxsby1kZXYgbWFpbGluZyBsaXN0DQo+IERpbGxvLWRldkBsaXN0
+cy5zb3VyY2Vmb3JnZS5uZXQNCj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMv
+bGlzdGluZm8vZGlsbG8tZGV2DQo+IA0KPiANCg== 
+
+
+
+Re: [Dillo-dev]Using Dillo on a 4bits per pixel device
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-22 11:38
+
+Hello Samyeer!
+
+Samyeer Metrani writes:
+> Hello,
+>  
+> I am trying to get Dillo running on the Simputer, a monochrome strongarm Sa1110
+> based device.
+>  
+> Dillo works fine when viewing text pages, when trying to view a gif or jpeg it
+> crashes. Is this something that somebody else has faced before. 
+
+Yes, I believe someone has already complained about Dillo crashing
+on low depth displays (or was it black&white too?) I don't remember
+exactly.
+
+> I believe the
+> problem is linked to the 16color display. If I run Dillo (the same executable
+> file) on an iPAQ it runs fine with the same libraries (jpeg etc.).
+>  
+> Any suggestions, pointers...
+
+I don't know exactly _what_ is making your Dillo crash. Maybe you
+could try compiling it yourself and run under gdb... :
+
+gdb ./dillo
+
+(gdb) r
+:
+: Here Dillo will run and you can do your stuff to make it crash
+:
+CRASH!
+(gdb) bt
+
+Then you get a backtrace from Dillo's calls. You can either
+interpret them yourself or post them here for help.
+
+I've also made a patch so that Dillo uses a private colormap, maybe
+it'll do something for you (I'm not promising anything ;-):
+
+(against current CVS):
+http://www.ime.usp.br/~livio/dillo/patches/private_colormap.diff
+
+
+hopes this help,
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Re: Dillo: Bug in new EGAIN code
+
+From: Pekka Lampila <medar@ka...> - 2002-04-22 11:23
+
+On Sun, 21 Apr 2002 17:51:22 -0400 (CLT)
+Jorge Arellano Cid <jcid@em...> wrote:
+
+> After reviewing the patch and giving some thought on it,
+> there's a new patch that solves the problem without the need of
+> the extra parameter to IO_write().
+> 
+> Pekka, please chack what efence has to say about it! :)
+
+No problems as far as I can see.
+
+> PS: 0.6.5 is a bit delayed, but it's just a few days ahead, and
+> most probably will be current CVS. It needs some testing of this
+> patch.
+
+And it has 34 ChangeLog items. Big thanks everyone :)
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+[Dillo-dev]Using Dillo on a 4bits per pixel device
+
+From: Samyeer Metrani <sam@nc...> - 2002-04-22 09:36
+
+Attachments: Message as HTML      
+
+Hello,
+
+I am trying to get Dillo running on the Simputer, a monochrome strongarm =
+Sa1110 based device.
+
+Dillo works fine when viewing text pages, when trying to view a gif or =
+jpeg it crashes. Is this something that somebody else has faced before. =
+I believe the problem is linked to the 16color display. If I run Dillo =
+(the same executable file) on an iPAQ it runs fine with the same =
+libraries (jpeg etc.).
+
+Any suggestions, pointers...
+
+Warm Regards,
+
+Samyeer 
+
+
+
+[Dillo-dev]Re: Dillo: Bug in new EGAIN code
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-21 22:04
+
+Hi there!
+
+
+On Sun, 14 Apr 2002, Livio Baldini Soares wrote:
+
+> Hello Pekka!
+>
+> Pekka Lampila writes:
+> > Hi,
+> >
+> > When running with efence enabled Dillo crashes before displaying any
+> > page.
+> >
+> > IO_callback (src=0x435aaff0, cond=G_IO_OUT, data=0x1) at IO.c:240
+> > 240 if (io->Status == -EAGAIN)
+>
+> Ah! Good eye! I found the problem...
+>
+> > I think io->Status is not defined.
+> >
+> > Don't know enough about IO-system to come up with proper fix. But I'll
+> > imagine it won't be too diffucult problem. :)
+>
+> Well, it's not io->Status which is not defined but the `io`
+> itself.. Everytime the IO finishes, IO_write() calls
+> a_IO_ccc(OpEnd,...), which consequently frees the `io`. :-(
+>
+> And elegant fix for this is kind of hard. First I thought of
+> delaying the a_IO_ccc() call, and doing it inside IO_callback().. but
+> that looked kind of dirty. Then I thought of trying to set `io` to
+> NULL after it had been freed so that we could check for NULL
+> value... but that would require changes to the CCC API (we would have
+> to pass void **Data, instead of void *Data).
+>
+> I've made a solution which might not be good either, but at least
+> the changes are small, and the problem gets fixed... maybe you guys
+> can think of something better. The patch follows:
+
+After reviewing the patch and giving some thought on it,
+there's a new patch that solves the problem without the need of
+the extra parameter to IO_write().
+
+Pekka, please chack what efence has to say about it! :)
+
+Cheers
+Jorge.-
+
+
+PS: 0.6.5 is a bit delayed, but it's just a few days ahead, and
+most probably will be current CVS. It needs some testing of this
+patch. 
+
+
+
+[Dillo-dev]Great Little Browser!!!!
+
+From: Chris Hawks <chrish@sy...> - 2002-04-19 20:31
+
+My company is looking for a browser to use as a UI for some of our
+products, so, I've looked at several recently.
+
+Until I found dillo, they were all big/slow/bloated/leaky of some
+combination there-of.
+
+Dillo is fast, clean, and robust. Really great!!
+
+The first thing I missed was setting the font sizes thru HTML. I
+uncommented the code in html.c to set the "face" and added code to set the
+"size" and it works great!!!
+
+I also added code to set the font and size for the gtk widgets. I can
+send a diff if there is interest.
+
+
+Thanks again!!!
+
+Chris
+
+Christopher R. Hawks Software Engineer
+Syscon Plantstar a Division of Syscon International
+-------------------------------------------------------------------------
+Ignorance is no excuse for not thinking! 
+
+
+
+Re: [Dillo-dev]Simple plugins
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-17 17:23
+
+Hi Eric,
+
+On Tue, Apr 02, 2002 at 06:34:08PM -0800, Eric GAUDET wrote:
+[...]
+> If we choose to go to a full dpi2 right away, (which can take some time,
+> this is why I propose to keep the early dpi1 for now), we will need more
+> interaction with the rendering engine, which calls for the two following
+> features:
+> 
+> - the ability to walk the internal representation of the page: for now, it?s a
+> pain in the ass to find which dw ?children? are actually rendered, which are
+> words, which are containers, etc. The find_text code talks by itself, and I am
+> postponing the text copy-paste until I find a good solution.
+
+Yes, find-text is ugly, and I'll try to find a cleaner, abstract
+solution; please send me also what kind of interface you need (more or
+less) exactly for text selection. I do not plan to make this too
+complicated, just a simple way to access the text content of widgets
+(see below).
+
+> - the ability to dynamically change the tree structure, not only be altering
+> the content of it, but by inserting and removing words and widgets. Right now,
+> the result when trying that is guaranteed to be ?unknown?.
+>
+> This means we have to come with some sort of DOM interface on top of the
+> internal dw representation.
+
+There will be a subset of DOM for CSS, with a focus on simple
+construction (appending nodes, no insertion), and especially changing
+style attributes (asynchronous HTML/CSS processing). Especially for
+the latter, an extended Dw interface is needed, but I haven't yet done
+any work on this area.
+
+If plugins will be able to access the document tree, they should IMO
+do this by the DOM interface (except graphical plugins as described in
+my post before).
+
+I'm not sure if *this* DOM makes sense for text search and selection,
+this could probably better handled by an extended Dw. DOM is more for
+handling the *document* structure (as opposed to the widget
+structure), which is crucial for CSS. (Of course, text selection could
+copy HTML code into the cut buffer -- why not, at least as an option?)
+
+> A lot of good could come from it, including the
+> ability for dillo to become a generic-application client as well as a better
+> browser, at almost no cost in development and no ?bloat?.
+
+What is a "generic-application client"? ;-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Simple plugins
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-17 16:37
+
+Hi!
+
+Just some notes on graphical plugins. An idea I plan to test, is to
+base this on GtkPlug and GtkSocket, which will be extended to support
+the additional features in the size model of Dw. Extensions will be
+implemented by using ICC (inter client communication) methods (like
+window properties) instead of IPC. The only data which has to be
+passed is the id of the socket window, this should be done via DPI1.
+
+This is (aside from a new command) fully compatible with the current
+DPI1 specification, so that the focus should now remain on
+non-graphical aspects.
+
+The way how dillo deals e.g. with <OBJECT>s, could be:
+
+1. From the TYPE attribute (and the "imaginary" plugin registration
+file), dillo knows what plugin to start (when necessary). If
+this type is not supported, the alternative content is displayed.
+
+2. The HTML parser creates a DwSocket (Dw's analogum to GtkSocket),
+adds it to the current DwPage, and then sends the command
+DpiCreateDwPlug, with a window id as data. Dillo does *not* have
+to wait, until the plugin creates the plug window.
+
+3. The plugin then receives and processes the data in a way already
+specified.
+
+Some points are missing:
+
+1. For toplevel plugins, the "Content-Type" field of the HTTP
+response (or perhaps only the "URL suffix") has to be evaluated.
+
+2. In case of an error, after the DpiCreatePlugWindow has been
+sent, dillo should somehow render the alternative content. This
+is a pure rendering issue, Dw (or perhaps an other level above)
+has to be extended for this.
+
+The code for the plugin will be similar to plugins using the Gtk+
+plug/socket mechanism, perhaps it will even be backward-compatible, so
+that simple graphical plugins may be implemented by creating a
+GtkPlug.
+
+Aside from that, perhaps GtkPlug and GtkSocket could also used for
+some more complex GUI extensions, for which dillo could reserve some
+space for. I thought of something like the sidebar steps in Mozilla.
+
+
+Sebastian 
+
+
+
+[Dillo-dev]Re: Dillo feedback
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-04-17 15:50
+
+On Sun, Apr 14, 2002 at 10:15:54AM +0200, Tels wrote:
+> Moin,
+
+Tach Tels,
+
+> I just tried dillo on my iPAQ and it is great! Cool! ;)
+> 
+> Three things as suggestions:
+> 
+> I emits things on the console, I guess that is debug stuff you forgot to
+> remove:
+> 
+> bash-2.03# Html_submit_form form->action=http://www.google.de/search
+> Nav_open_url:
+> Url=>http://www.google.de/search?q=&hl=de&btnI=Auf+gut+Gl%FCck!&meta=<
+> border width: 0
+> border width: 0
+
+$ grep -n -e "^#define DEBUG_LEVEL" *.c
+cache.c:37:#define DEBUG_LEVEL 5
+colors.c:7:#define DEBUG_LEVEL 5
+cookies.c:33:#define DEBUG_LEVEL 8
+dns.c:33:#define DEBUG_LEVEL 5
+interface.c:45:#define DEBUG_LEVEL 0
+web.c:28:#define DEBUG_LEVEL 5
+
+These are sources Jorge is responsible for ...
+
+> I tried google, and it is just cool ;) Dillo even respected my local proxy
+> environment variable. Unfortunately, the logo is too big and and the entry
+> box too long.
+> 
+> Suggestion: How about an automatic down-scaling of images (anything that is
+> larger than lets say 20x30 pixel) by a predefined factor? This way googles
+> logo would automatically fit. Entry box drawing-lengths could be restricted
+> to something sensible automatically.
+
+A global image scaling factor is planned. Scaling only images above a
+certain size may be an option. (Or non-linear scaling?)
+
+> I am also contacting Google in the hope that they make a special handhelds
+> interface ;)
+> 
+> Suggestion three: How about a local (fake) page that shows you your actuall
+> settings? I can write a Perl script which generates it on the fly from the
+> setttings file, but then Dillo would need to know to call this script.
+> Alternatively, it could construct this page on the fly.
+
+This will in future be possible with plugins. See
+
+http://so....net/mailarchive/forum.php?thread_id=605248&forum_id=6557
+
+for more.
+
+> Thank you for all your work,
+> 
+> Tels
+> 
+> 
+> - --
+> "Why do you go so slowly? Do you think this is some kind of game?"
+> PGP key available on http://bloodgate.com/tels.asc or via email.
+> perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
+> evangelistically build clicks-and-mortar functionalities
+
+Sebastian 
+
+
+
+[Dillo-dev]toolbar pixmaps
+
+From: CLOTILDE Guy Daniel <guy.clotilde@wa...> - 2002-04-14 11:33
+
+Attachments: pixmaps.h      
+
+Hi
+I'm very happy to send you this pixmap.h file with gnome icons ( from tigert homepage, these icons are GPL ) .
+A screenshot is available here 
+perso.wanadoo.fr/guy.clotilde/GPL/dillo_toolbar_screenshot.png
+
+Hope you like it. 
+
+
+
+[Dillo-dev]plugins
+
+From: Madis Janson <madis@cy...> - 2002-04-12 11:32
+
+maybe it should be possible to use plugins for implementating scripting
+languages (like javascript) in future? its just an idea... 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Eric GAUDET <eric.gaudet@vn...> - 2002-04-12 07:04
+
+Hi,
+
+Tow things I=B4d like to see changed in the dpi1 proposal:
+
+- D1 and D2 fields being 2 bytes long, the endianness can be an issue. I =
+think
+it will be better to have 1 byte fields D1, D2, D3, D4 instead.
+
+- Along with the client ID, I think a request ID is needed too, to ensure
+multiple windows calling the same PI concurently don=B4t get confused in =
+their
+connections.
+There is several ways to do that, depending on if we want dillo or the PI=
+to
+generate those IDs. IMHO it would be easier for everyone if the PI took c=
+are
+of the communications its involved in.
+What I propose is to add the dillo->dpi command DpiNewRequest generating =
+a
+unique request ID in an atomic fashion (by incrementing an index for a st=
+ruct
+table, for instance), and returning the request ID to the client. This me=
+ans
+that dillo must use this command every time it wants to do a DpiUri. We=B4=
+ll also
+need a DpiFreeRequest for dillo to tell the PI its closing the communicat=
+ion,
+so the PI can reuse the slot for futher requests.
+For dpi-initiated communication, the dpi generates a request ID by itself=
+, and
+dillo must reuse the request ID to answer.=20
+
+The way I see the implementation from a plugin standpoint, is to have a
+MyParamStruct containing all variables needed for one single request.
+
+int myParamMax =3D 4;
+int myParamNumber =3D 0;
+
+MyParamStruct *myParam;
+
+and malloc it with an a_List_ like macro, then for each request find the =
+first
+available slot in *myParam and using the index as the request ID.
+Every time a command is received or issued, all the data needed are in
+myParam[requestID].
+
+I=B4d also want to make sure multiple connection are not made simultaneou=
+sly in
+stdin/stdout. For that, dillo will need to have a pipe lock mecanism to b=
+e set
+every time a datagram is transmited, until the transmission of this parti=
+cular
+datagram is completed.
+
+Best,
+Eric
+
+-- En reponse de "RE: [Dillo-dev]Simple plugins" de Jorge Arellano Cid, l=
+e
+11-Apr-2002 :
+>=20
+> Hi there!
+>=20
+> I just reviewed the dpi1 draft once more, and updated it with
+> some information found in some old emails, and some new ideas. In
+> brief, is just a few changes:
+>=20
+> * ClientIDs
+> * Initialization proposal
+> * PI options note
+>=20
+>=20
+> Cheers
+> Jorge.-
+>=20
+>=20
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------------------------------------------
+Eric GAUDET <eric.gaudet@vn...>
+Le 11-Apr-2002 a 23:25:08
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Eric GAUDET <eric.gaudet@vn...> - 2002-04-12 02:02
+
+Hi Jorge,
+
+I think we can agree that according to the dpi1 proposal, the initial pat=
+ch
+will include the following parts:
+- init code
+- plugin forking and pipe registration
+- url indirection to plugin pipes and rendering.
+
+There will also be a minimal reference implementation plugin, that will
+probably be a script or a small C program.
+
+I=B4d like to know what code you already have, what code you have needs r=
+ework,
+and if you plan to integrate any code soon or you prefer to discuss about=
+it a
+little bit.
+
+Best,
+Eric
+
+
+-- En reponse de "RE: [Dillo-dev]Simple plugins" de Jorge Arellano Cid, l=
+e
+11-Apr-2002 :
+>=20
+> Hi there!
+>=20
+> I just reviewed the dpi1 draft once more, and updated it with
+> some information found in some old emails, and some new ideas. In
+> brief, is just a few changes:
+>=20
+> * ClientIDs
+> * Initialization proposal
+> * PI options note
+>=20
+>=20
+> Cheers
+> Jorge.-
+>=20
+>=20
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------------------------------------------
+Eric GAUDET <eric.gaudet@vn...>
+Le 11-Apr-2002 a 18:54:34
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+Re: [Dillo-dev]netscape4 icons
+
+From: Adam Sampson <azz@gn...> - 2002-04-11 21:33
+
+Jorge Arellano Cid <jcid@em...> writes:
+
+> Hmmmm, those are netscape's icons.
+> What about the copyrights?
+
+The Netscape 4 icons are included in one of Mozilla's default themes,
+so I'd guess they can be used under the terms of the GPL with the
+proper copyright attribution.
+
+-- 
+Adam Sampson <azz@gn...> <URL:http://azz.us-lot.org/> 
+
+
+
+Re: [Dillo-dev]Page saving and POST-generated pages
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-11 20:58
+
+Nikita,
+
+> Hi, All !
+
+Hi!
+
+> There is one problem with saving a page:
+> if curent page is generated as result of POST then saving it
+> gives you the page (cahed or reloaded) with that url and no POST-data.
+>
+> This patch makes dillo to save exactly the page currently shown:
+>
+> [...]
+>
+
+Done! (I also removed the now unused 'url_str' code).
+
+
+Cheers
+Jorge.- 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-11 19:26
+
+Hi there!
+
+I just reviewed the dpi1 draft once more, and updated it with
+some information found in some old emails, and some new ideas. In
+brief, is just a few changes:
+
+* ClientIDs
+* Initialization proposal
+* PI options note
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]BugTrack
+
+From: Lars Clausen <lrclause@cs...> - 2002-04-10 17:45
+
+On Wed, 10 Apr 2002, Jorge Arellano Cid wrote:
+>=20
+> Hi there,
+>=20
+> Please review the entries before making new ones!
+>=20
+> I just remove #320 (valign) repeated with #297 --second time :(.
+> and also #323 (no way out of find text with keyboard). C'mon, just
+> press TAB or down arrow.
+
+I for one would like all dialogs to at least have Esc be Cancel. I find
+using TAB or down arrow to be quite cumbersome.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]BugTrack
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-10 17:10
+
+Hi there,
+
+Please review the entries before making new ones!
+
+I just remove #320 (valign) repeated with #297 --second time :(.
+and also #323 (no way out of find text with keyboard). C'mon, just
+press TAB or down arrow.
+
+That's all
+Jorge.- 
+
+
+
+[Dillo-dev]Looking for Patches...
+
+From: Patrick Glennon <pglennon@me...> - 2002-04-10 12:32
+
+Attachments: Message as HTML      
+
+Howdy, 
+
+I'm testing Dillo for an embedded systems project, and am desperately
+looking for patches against 0.6.4 or the cvs version for meta-refresh
+support as well as for the 0 cache-size support.
+
+We have seen some weirdness on the dillo-cache regarding posting form
+results. It seems to cache result sets even when we add cache-busting
+random ids in the POST URL. If anyone knows a simple way to disable the
+cache, that would be delightful as well!
+
+Thanks,
+Patrick 
+
+
+
+Re: [Dillo-dev][PATCH] Private colormap
+
+From: Imad <magius@pu...> - 2002-04-10 04:19
+
+On Tue, 9 Apr 2002, Livio Baldini Soares wrote:
+
+>(Am I the only one with measly
+> 8 bit per pixel ? :(
+
+No, my main box is a Sparc 5 with a 256 color adaptor, so I'm in a
+similiar situation. However, as long as I start Dillo up early and use a
+window manager that handles colors well (e.g., Icewm), I don't have any
+problems with the colormap.
+
+On Blackbox, if I started Dillo 6.3 after other programs, Dillo would
+absolutely ruin images -- even the old Dillo title (on the old site's
+main page) would be all brown and gray. Switching to Icewm, GTK-only
+apps, and starting Dillo early in a session fixed all that.
+
+I'll try out the patch when I get back home, but I'm not expecting a
+huge change. I will point out that QT seems to deal with 8bpp displays
+quite a bit better than GTK does -- poor colormap support is a known
+defect. Not that I'd want Dillo to be QT-based -- speed is of the
+essence. =)
+
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+Re: [Dillo-dev]netscape4 icons
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-10 02:56
+
+On Thu, 4 Apr 2002, HORVATH Szabolcs wrote:
+
+> http://fi.inf.elte.hu/~horvaths/pixmaps.h
+>
+> enjoy :-)
+
+Hmmmm, those are netscape's icons.
+What about the copyrights?
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev][PATCH] Private colormap
+
+From: Lars Clausen <lrclause@cs...> - 2002-04-10 02:22
+
+On Tue, 9 Apr 2002, Livio Baldini Soares wrote:
+> Hello,
+>=20
+[...]
+> Does anyone need this? Any comments? (Am I the only one with measly
+> 8 bit per pixel ? :(
+
+Yes. Upgrade. :)
+
+Seriously, I wish X had done a virtual full-colour screen and a conversion
+in the server like Mac does. Would have way reduced these problems. Would
+also have made multi-screen displays much easier. We will need to support
+8bpp, though.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev][PATCH] Private colormap
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-10 01:06
+
+Hello,
+
+recently I've been using Dillo on a system with only 8bpp. X runs
+out of colors pretty quickly, and specially when Dillo is showing
+images, the colormap gets pretty ugly.
+
+To solve this we have to, basically, add this to the initialization
+(in dillo.c):
+
++ gtk_widget_set_default_colormap (gdk_rgb_get_cmap());
+
+With this, Dillo grabs a "private" colormap. This makes the X
+colormap "flip" when focusing on-to/out-of Dillo. (Similar to
+Netscape's `-install` option).
+
+My patch not only adds this, but also adds a preference in dillorc
+called `use_private_colormap`. The patch is at:
+
+http://www.ime.usp.br/~livio/dillo/patches/private_colormap.diff
+
+Does anyone need this? Any comments? (Am I the only one with measly
+8 bit per pixel ? :(
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Page saving and POST-generated pages
+
+From: Nikita V. Borodikhin <eliterr@tk...> - 2002-04-09 19:49
+
+Hi, All !
+
+There is one problem with saving a page:
+if curent page is generated as result of POST then saving it
+gives you the page (cahed or reloaded) with that url and no POST-data.
+
+This patch makes dillo to save exactly the page currently shown:
+
+
+diff -urN dillo.old/src/interface.c dillo/src/interface.c
+--- dillo.old/src/interface.c Mon Mar 4 19:42:24 2002
++++ dillo/src/interface.c Tue Apr 9 17:37:29 2002
+@@ -1163,7 +1163,7 @@
+entry_url = GTK_ENTRY(bw->location);
+name = gtk_file_selection_get_filename(choosefile);
+url_str = gtk_entry_get_text(entry_url);
+- url = a_Url_new(url_str, NULL, 0, 0);
++ url = a_Url_dup(a_History_get_url(NAV_TOP(bw)));
+
+if ( strlen(name) && (out = fopen(name, "w")) != NULL ) {
+DilloWeb *Web = a_Web_new(url); 
+
+
+
+Re: [Dillo-dev]Abstraction to user interface
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-04-09 17:35
+
+Hi,
+
+on Tue, 9 Apr 2002 18:17:53 +0100
+mallum <breakfast@10.am> wrote:
+
+> on Mon, Apr 08, 2002 at 12:34:46AM +0200, Melvin Hadasht wrote:
+> > (With other (available) patches to allow
+> > full-window mode and offline browsing at startup, this is an
+> > excellent choice for rendering html in mail user agents, or manual
+> > browsers)
+> > 
+> ooo, where are these patches ?
+
+http://melvin.hadasht.free.fr/dillo/
+or 
+http://freefluid.dyndns.org/dillo/ (not 24/24)
+
+dillo-embed-cvs-27-03-2002.patch:
+
+a gtkplug must be created by another application, then it runs 'dillo
+-xid XXXX' where XXXX is the XID of the window created by gtkplug (more
+info by request)
+
+dillo-local-cvs-30-03-2002.patch:
+
+start dillo with '-l' option, and all non 127.*.*.* http requests are
+reported as 'can't solve ...'
+
+The full window (not full screen) patch is not there, but I can put it
+if requested.
+
+I don't think both patches are compatibles. If you want, I'll put a
+patch having all 3 features (xid, local browsing, and full window
+startup)
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]Abstraction to user interface
+
+From: mallum <breakfast@10...> - 2002-04-09 17:17
+
+on Mon, Apr 08, 2002 at 12:34:46AM +0200, Melvin Hadasht wrote:
+> (With other (available) patches to allow
+> full-window mode and offline browsing at startup, this is an excellent
+> choice for rendering html in mail user agents, or manual browsers)
+> 
+ooo, where are these patches ?
+
+-- mallum 
+
+
+
+Re: [Dillo-dev]Mouse-Wheel not working anymore
+
+From: Ralph Slooten <ralph@de...> - 2002-04-09 05:32
+
+I just tried the CVS from yesterday, and it's working again :-) Since the
+20020327 version I had tried for several days (almost each day) to get it
+working with new CVS versions , but each day it didn't. Newer versions just
+scrolled down, but as I said, not up.
+
+But that seems to be fixed now. No idea how or what though :-) I didn't use 
+your patch (thanks for the effort though).
+
+Many thanks,
+
+Greetings
+Ralph
+
+
+On Mon, 8 Apr 2002, Livio Baldini Soares wrote:
+
+> Hello Ralph!
+> 
+> Ralph Slooten writes:
+> > Hi there guys,
+> > 
+> > I'm not sure if I am the only one to get this problem, however as from the
+> > CVS version on 27/03 my mouse-wheel only pages down, and not up. I have
+> > tried several versions since then, and they all do not work here.
+> 
+> Hum.. now that you mention it, I _do_ have a similar problem. Except
+> it happens not only with the mouse wheel, but with PageUp as well.
+> 
+> > Any ideas?
+> 
+> Yup... I think Jorge made some additions to the interface to allow
+> SPACE to PageDown and 'b' or 'B' to PageUp. But he also added a
+> additional check to see if those 'b's had an additional modifier (like
+> Alt-B, which should actually access the Bookmarks menu).
+> 
+> In my case GDK_MOD2_MASK is the Num Lock... so it kind of took a
+> while to understand why sometimes it worked, and why sometimes it
+> didn't... 
+> 
+> Ralph, does the mouse-wheel going up issue disappear with your
+> NumLock off? Is your keyboard a 101-US? (Does the following patch help
+> at all?)
+> 
+> I have a patch here... I does only two things:
+> 
+> [1] Doesn't check modifier upon normal PageUp button.
+> 
+> [2] When 'b' or 'B' are pressed only check for GDK_MOD1_MASK
+> 
+> Item 2 is "optional" (in the sense that item 1 should solve your
+> mouse problem, and my PageUp problem, but would still have a problem
+> with 'b' and NumLock on).
+> 
+> Getting the modifiers right is kind of tricky, because it depends on
+> the X keyboard mappings... check here for more info:
+> 
+> http://developer.gnome.org/doc/API/2.0/gdk/gdk-windows.html#GDKMODIFIERTYPE
+> 
+> Here is the 3 liner (against CVS from 08-Apr-2002):
+> 
+> *****************************************************************************
+> diff -pru dillo/src/dw_gtk_scrolled_frame.c
+> dillo.my/src/dw_gtk_scrolled_frame.c
+> --- dillo/src/dw_gtk_scrolled_frame.c Fri Mar 29 01:37:25 2002
+> +++ dillo.my/src/dw_gtk_scrolled_frame.c Mon Apr 8 22:22:25 2002
+> @@ -475,10 +475,10 @@ static gint Dw_gtk_scrolled_frame_key_pr
+> else
+> return gtk_container_focus (container, GTK_DIR_TAB_FORWARD);
+> 
+> - case GDK_Page_Up:
+> case GDK_b: case GDK_B:
+> - if (event->state & (GDK_MOD1_MASK | GDK_MOD2_MASK))
+> - return FALSE;
+> + if (event->state & GDK_MOD1_MASK)
+> + return FALSE;
+> + case GDK_Page_Up:
+> if (event->state & GDK_CONTROL_MASK)
+> Dw_gtk_scrolled_frame_move_by(frame,
+> - frame->hadjustment->page_increment, 0);
+> *******************************************************************************
+> 
+> best regards to all!
+> 
+> -- 
+> Livio <livio@im...>
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+Re: [Dillo-dev]sourceforge: why the move?
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-09 02:37
+
+Hello Jonathan!
+
+jonathan chetwynd writes:
+> sorceforge has so many great projects, why the move?
+
+Well, this has been discussed here at the end of the last year (2001):
+http://so....net/mailarchive/message.php?msg_id=878753
+
+That was my first message about the subject, but at the bottom,
+you'll see links to some more thoughts from others (specially Jorge,
+the maintainer). My first post was rather "euforic" (with lots of
+English mistakes ;), but if you read my second post and some of the
+others, you'll see that we have reached a "consensus" about leaving
+sourceforge.
+
+> will the mailing list stay at sourceforge?
+
+Probably not. The goal is to take everything away from
+SourceForge. We are still trying to get the mailing lists up at
+CIPSGA, CVS should follow.
+
+But please, don't worry. The move should ease developers to keep
+contributing to the project. Plus, _everything_ will be announced
+ahead of time! We will (probably) leave notices at the out SF site,
+redirecting the home page, CVS and mailing lists.
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Mouse-Wheel not working anymore
+
+From: Livio Baldini Soares <livio@im...> - 2002-04-09 02:14
+
+Hello Ralph!
+
+Ralph Slooten writes:
+> Hi there guys,
+> 
+> I'm not sure if I am the only one to get this problem, however as from the
+> CVS version on 27/03 my mouse-wheel only pages down, and not up. I have
+> tried several versions since then, and they all do not work here.
+
+Hum.. now that you mention it, I _do_ have a similar problem. Except
+it happens not only with the mouse wheel, but with PageUp as well.
+
+> Any ideas?
+
+Yup... I think Jorge made some additions to the interface to allow
+SPACE to PageDown and 'b' or 'B' to PageUp. But he also added a
+additional check to see if those 'b's had an additional modifier (like
+Alt-B, which should actually access the Bookmarks menu).
+
+In my case GDK_MOD2_MASK is the Num Lock... so it kind of took a
+while to understand why sometimes it worked, and why sometimes it
+didn't... 
+
+Ralph, does the mouse-wheel going up issue disappear with your
+NumLock off? Is your keyboard a 101-US? (Does the following patch help
+at all?)
+
+I have a patch here... I does only two things:
+
+[1] Doesn't check modifier upon normal PageUp button.
+
+[2] When 'b' or 'B' are pressed only check for GDK_MOD1_MASK
+
+Item 2 is "optional" (in the sense that item 1 should solve your
+mouse problem, and my PageUp problem, but would still have a problem
+with 'b' and NumLock on).
+
+Getting the modifiers right is kind of tricky, because it depends on
+the X keyboard mappings... check here for more info:
+
+http://developer.gnome.org/doc/API/2.0/gdk/gdk-windows.html#GDKMODIFIERTYPE
+
+Here is the 3 liner (against CVS from 08-Apr-2002):
+
+*****************************************************************************
+diff -pru dillo/src/dw_gtk_scrolled_frame.c
+dillo.my/src/dw_gtk_scrolled_frame.c
+--- dillo/src/dw_gtk_scrolled_frame.c Fri Mar 29 01:37:25 2002
++++ dillo.my/src/dw_gtk_scrolled_frame.c Mon Apr 8 22:22:25 2002
+@@ -475,10 +475,10 @@ static gint Dw_gtk_scrolled_frame_key_pr
+else
+return gtk_container_focus (container, GTK_DIR_TAB_FORWARD);
+
+- case GDK_Page_Up:
+case GDK_b: case GDK_B:
+- if (event->state & (GDK_MOD1_MASK | GDK_MOD2_MASK))
+- return FALSE;
++ if (event->state & GDK_MOD1_MASK)
++ return FALSE;
++ case GDK_Page_Up:
+if (event->state & GDK_CONTROL_MASK)
+Dw_gtk_scrolled_frame_move_by(frame,
+- frame->hadjustment->page_increment, 0);
+*******************************************************************************
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Abstraction to user interface
+
+From: Bo Lorentsen <bl@ne...> - 2002-04-08 08:36
+
+On Mon, 2002-04-08 at 09:18, Melvin Hadasht wrote:
+
+> I think this is not possible via gtksocket/gtkplug. 
+Ups --- sorry, you are right :-)
+
+/BL 
+
+
+
+Re: [Dillo-dev]Abstraction to user interface
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-04-08 07:24
+
+Hi,
+
+on 08 Apr 2002 08:57:29 +0200
+Bo Lorentsen <bl@ne...> wrote:
+> > Then, how
+> > about accessing the gui elements inside the HTML dokument via, the
+> > gtk C interface ? That way this could be a new way of making custom
+> > user interface.
+
+I think this is not possible via gtksocket/gtkplug. 
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]Abstraction to user interface
+
+From: Bo Lorentsen <bl@ne...> - 2002-04-08 06:57
+
+On Mon, 2002-04-08 at 00:34, Melvin Hadasht wrote:
+> I made a patch to embed the X window of dillo using gtk_plug/gtk_socket.
+> Works like a charm. See dillo mail archive, subject '[Dillo-dev]patch:
+> embedding dillo'. That means, dillo is run as an external program, only
+> its window is embedded in an application. Although, I don't think this
+> is sufficient for you. (With other (available) patches to allow
+> full-window mode and offline browsing at startup, this is an excellent
+> choice for rendering html in mail user agents, or manual browsers)
+Then, how about accessing the gui elements inside the HTML dokument via,
+the gtk C interface ? That way this could be a new way of making custom
+user interface.
+
+/BL 
+
+
+
+Re: [Dillo-dev]Abstraction to user interface
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-04-07 22:40
+
+Hi,
+
+on Mon, 8 Apr 2002 00:00:49 +0200
+Erich Schubert <erich@de...> wrote:
+
+> I'd like to see dillo as html renderer for upcomding galeon2.
+> Galeon2 tries to become mozilla-independant, so it possibly could use
+> gtkhtml2 or dillo as alternative renderers...
+> 
+> Does dillo support this? Is there some dillo-embed wiget i could use
+> in own programs? I just looked at the source and it did not seem to
+> me as if this is possible right now :-(
+> 
+> mozilla is so slow and needs so much memory, but i just love the
+> galeon user interface...
+
+I made a patch to embed the X window of dillo using gtk_plug/gtk_socket.
+Works like a charm. See dillo mail archive, subject '[Dillo-dev]patch:
+embedding dillo'. That means, dillo is run as an external program, only
+its window is embedded in an application. Although, I don't think this
+is sufficient for you. (With other (available) patches to allow
+full-window mode and offline browsing at startup, this is an excellent
+choice for rendering html in mail user agents, or manual browsers)
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]Abstraction to user interface
+
+From: Erich Schubert <erich@de...> - 2002-04-07 22:07
+
+I'd like to see dillo as html renderer for upcomding galeon2.
+Galeon2 tries to become mozilla-independant, so it possibly could use
+gtkhtml2 or dillo as alternative renderers...
+
+Does dillo support this? Is there some dillo-embed wiget i could use in
+own programs? I just looked at the source and it did not seem to me as
+if this is possible right now :-(
+
+mozilla is so slow and needs so much memory, but i just love the galeon
+user interface...
+
+Greetings,
+Erich 
+
+
+
+[Dillo-dev]Speed: and the wheely mouse
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-04-06 15:26
+
+I'm just beginning to use dillo on my laptop, having been stunned by how 
+fast it is on the ipaq.
+I'm certain there is a need for a visual lynx, though the 'dillo' name 
+is somewhat wanting...
+
+How will animated gifs, css, javascript bookmarklets, impact on speed.
+You may not have answers, but please don't sacrifice speed, its a niche 
+you fit very well
+
+Is it possible that a wheely mouse could be used to scroll thru the 
+history file?
+
+thanks
+
+jonathan 
+
+
+
+[Dillo-dev]Thank you Dillo developers
+
+From: grump old <grumpyold_man@ya...> - 2002-04-05 20:55
+
+You guys are making a fantastic browser! 
+John Andrews
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Tax Center - online filing with TurboTax
+http://taxes.yahoo.com/ 
+
+
+
+[Dillo-dev]sourceforge: why the move?
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-04-05 20:07
+
+sorceforge has so many great projects, why the move?
+
+will the mailing list stay at sourceforge?
+
+thanks 
+
+
+
+[Dillo-dev]Mouse-Wheel not working anymore
+
+From: Ralph Slooten <ralph@de...> - 2002-04-05 16:43
+
+Hi there guys,
+
+I'm not sure if I am the only one to get this problem, however as from the
+CVS version on 27/03 my mouse-wheel only pages down, and not up. I have
+tried several versions since then, and they all do not work here.
+
+Any ideas?
+
+Greetings
+Ralph
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Gustavo Noronha Silva <kov@de...> - 2002-04-05 16:21
+
+Em Fri, 5 Apr 2002 08:43:14 -0300, Eduardo Marcel Maçan <macan@de...>
+escreveu:
+
+> On Thu, 4 Apr 2002 11:01:12 -0400 (CLT) Jorge Arellano Cid <jcid@em...>
+> wrote:
+> > OK, I just received the extra couple success-notes, so now it's
+> > official, we've moved to http://dillo.cipsga.org.br/ !!!
+> 
+> Wow, Congratulations to both Jorge, Livio (which by the way
+> we had the pleasure to have in our IRC channel :) ) the dillo contributors,
+> and the folks in the Debian-br team who do the admin at cipsga, and of 
+> course cipsga itself for the great job in promoting the use and development
+> of free software in Brazil and abroad.
+congrats =D, I just called Djalma about the lists, I'm sorry for the delay
+
+
+> I am very happy this could happen, it would only be better if the
+> former dillo maintainer in debian remembered that I e-mailed him saying
+> that if he was ever to abandon dillo, he should handle it to me... he
+> orphaned it during my "forced vacations" and I lost it :( Well... that's life
+> :)
+well, I tried, but you can still discuss with the one who took it =D
+
+[]s!
+
+-- 
+kov@de...: Gustavo Noronha <http://people.debian.org/~kov>
+Debian: <http://www.debian.org> * <http://debian-br.cipsga.org.br> 
+
+
+
+Re: [Dillo-dev]Re: CSS
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-05 15:21
+
+Jonathan,
+
+> connected fine, comments please on CSS1 and CSS2 which do not seem to be
+> supported at present...
+>
+> will they be?
+
+Probably.
+
+> and if so when-ish?
+
+That depends on how much knowledgeable people is willing to
+help with that!
+
+> really its a fabulous browser - good stuff
+>
+> thanks again
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Eduardo Marcel <macan@co...> - 2002-04-05 11:53
+
+On Fri, 5 Apr 2002 08:43:14 -0300 Eduardo Marcel Ma=E7an <macan@de...=
+g> wrote:
+> Wow, Congratulations to both Jorge, Livio (which by the way
+> we had the pleasure to have in our IRC channel :) ) the dillo contribut=
+ors,
+> and the folks in the Debian-br team who do the admin at cipsga, and of
+> course cipsga itself for the great job in promoting the use and develop=
+ment
+> of free software in Brazil and abroad.
+
+Hah, "both" overflow :)
+It just happened I remembered "on the fly" that I had to thank more than
+two groups of people :)
+
+--=20
+Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager
+macan@co... Col=E9gio Bandeirantes 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Eduardo Marcel <macan@de...> - 2002-04-05 11:43
+
+On Thu, 4 Apr 2002 11:01:12 -0400 (CLT) Jorge Arellano Cid <jcid@em...=
+om> wrote:
+> OK, I just received the extra couple success-notes, so now it's
+> official, we've moved to http://dillo.cipsga.org.br/ !!!
+
+Wow, Congratulations to both Jorge, Livio (which by the way
+we had the pleasure to have in our IRC channel :) ) the dillo contributor=
+s,
+and the folks in the Debian-br team who do the admin at cipsga, and of=20
+course cipsga itself for the great job in promoting the use and developme=
+nt
+of free software in Brazil and abroad.
+
+I am very happy this could happen, it would only be better if the
+former dillo maintainer in debian remembered that I e-mailed him saying
+that if he was ever to abandon dillo, he should handle it to me... he
+orphaned it during my "forced vacations" and I lost it :( Well... that's =
+life :)
+
+At least I am still the "dillo for ipaq" maintainer in the familiar=20
+distribution :)
+
+> Note that the CVS still remains at SF, but hopefully that'll
+> change soon.
+>=20
+> Ah, I also adviced you to keep the BugTrack at SF, until we
+> moved. Well, not IS time to switch to using the one at CIPSGA!
+> (Yes, it's updated).
+
+--=20
+Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager
+macan@co... Col=E9gio Bandeirantes 
+
+
+
+[Dillo-dev]netscape4 icons
+
+From: HORVATH Szabolcs <horvaths@fi...> - 2002-04-04 21:21
+
+http://fi.inf.elte.hu/~horvaths/pixmaps.h
+
+enjoy :-)
+
+
+-- 
+Horváth Szabolcs, <horvaths@fi.inf.elte.hu> 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-04 17:03
+
+Hi there!
+
+
+On Wed, 3 Apr 2002, Bjoern Weber wrote:
+
+> Jorge Arellano Cid <jcid@em...> schrieb am 02.04.02:
+> > Hi there!
+> > > > The new site's at: http://dillo.cipsga.org.br/
+> > > > It hasn't yet been blessed as our official site, but please go
+> > > > there and test it, specially those of you from Europe, so we can
+> > > > get a feel of how the connection behaves.
+> > > i've tried it now multiple times, and it has always worked fine and fast
+> > > (i'm in estonia, which is in europa).
+> > Thanks a lot Madis. A couple more successful reports and I'll
+> > turn it our official site. It's much better!
+>
+> Then add my voice to the list of successful reports. I prefer the
+> new site as well. Design is nice and usable, bugtracking works fine
+> too - at least the few things I tested =)
+
+OK, I just received the extra couple success-notes, so now it's
+official, we've moved to http://dillo.cipsga.org.br/ !!!
+
+Note that the CVS still remains at SF, but hopefully that'll
+change soon.
+
+Ah, I also adviced you to keep the BugTrack at SF, until we
+moved. Well, not IS time to switch to using the one at CIPSGA!
+(Yes, it's updated).
+
+
+> Yet the compatibility page seems incomplete, if you don't mind
+> occasional memory faults out of the gtk you may as well use dillo
+> on QNX RTP 6.1/x86 as well =)
+
+I'll add that one.
+
+
+Cheers+ :)
+Jorge.- 
+
+
+
+[Dillo-dev]question about html parser
+
+From: Madis Janson <madis@cy...> - 2002-04-03 17:02
+
+does nested tags use parent tag data structures? i mean, whether it is
+safe to delete parent tag from tag stack and move its children down to its
+place, when closing a tag. for example html like this:
+
+<form>
+...
+<table>
+
+</form>
+
+...
+</table>
+
+currently dillo just kills the table, when it founds </form> tag.
+i've thought about modifing parser to search matching tag and close only
+the matching tag in Html_pop_tag function. 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Bjoern Weber <foxbow@we...> - 2002-04-03 07:20
+
+Jorge Arellano Cid <jcid@em...> schrieb am 02.04.02:
+> Hi there!
+> > > The new site's at: http://dillo.cipsga.org.br/
+> > > It hasn't yet been blessed as our official site, but please go
+> > > there and test it, specially those of you from Europe, so we can
+> > > get a feel of how the connection behaves.
+> > i've tried it now multiple times, and it has always worked fine and fast
+> > (i'm in estonia, which is in europa).
+> Thanks a lot Madis. A couple more successful reports and I'll
+> turn it our official site. It's much better!
+
+Then add my voice to the list of successful reports. I prefer the
+new site as well. Design is nice and usable, bugtracking works fine
+too - at least the few things I tested =)
+
+Yet the compatibility page seems incomplete, if you don't mind 
+occasional memory faults out of the gtk you may as well use dillo
+on QNX RTP 6.1/x86 as well =)
+
+Greetings,
+Bjoern
+-- 
+A nuclear bomb is really funny but when it comes your way
+Falling on your breakfast table can disturb your day!
+(Off - Bad News) 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: <SirVer@gm...> - 2002-04-03 13:16
+
+On Tue, Apr 02, 2002 at 12:00:51PM -0600, Jamin W. Collins wrote:
+> On Tue, 2 Apr 2002 11:46:35 -0400 (CLT)
+> "Jorge Arellano Cid" <jcid@em...> wrote:
+> 
+> > Thanks a lot Madis. A couple more successful reports and I'll
+> > turn it our official site. It's much better!
+> 
+> Worked fine when I tested it. Like the layout too.
+yep, works fine and fast from here in germany
+
+Holger 
+
+
+
+Re: [Dillo-dev]Simple plugins
+
+From: Lars Clausen <lrclause@cs...> - 2002-04-03 03:14
+
+On Tue, 2 Apr 2002, Jorge Arellano Cid wrote:
+>=20
+> Hi there!
+>=20
+[...]
+> This is the opportunity to discuss, design, improve, correct,
+> etc. (is far better to correct the design than trying to mend an
+> unsuitable piece of code.)
+
+I have to wonder, why the two data fields and then 'length' amount of data?
+Why not have any data fields be a part of the data?
+
+I'd like to see things like page info (date, size, server, cache-info etc)
+being passed to plugins.
+
+I'm not sure how actual data download works with this. How would, say, an
+external viewer plugin get the data to feed to the external program (not
+all external programs understand URI's)? Dillo already handles download,
+so it seems we should take advantage of that. Perhaps the plugin can tell
+Dillo to save the data to a file, or pass it into a socket, or something?
+
+I like the idea of prefs being a plugin, but there's some work to be done
+to make Dillo actually use new prefs internally. Not too hard, probably.
+
+I've been thinking about a better version of the external viewer program,
+and of course I'd like to do it with plugins, when they are available.
+Here's my idea:
+
+At startup, parse either ~/.mailcap or ~/.dillo/viewers to set up known
+viewers. Also parse /etc/mailcap, but store the associations separately.
+
+The default viewer for unknown mime types should be a handler that asks
+the users what to do: Either save to disk, specify a program directly,
+or pick one of the associated programs found in /etc/mailcap. Optionally
+store this in either ~/.mailcap or ~/.dillo/viewers, if it is to be
+permanent.=20
+
+This makes for a nice intermediate between 'one fixed viewer' and 'select
+any program', and fits well into the current mime system. As for
+~/.mailcap vs. ~/.dillo/viewers, using ~/.mailcap may interfere with other
+programs, but it may also be seen as the users preferred general settings.
+
+> Finally, dillo-0.6.5 release is planned for mid April, from the
+> new site!!!
+
+Could you put a link to the new site up on the old site, perhaps?
+
+-Lars
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+RE: [Dillo-dev]Simple plugins
+
+From: Eric GAUDET <eric.gaudet@vn...> - 2002-04-03 02:36
+
+Hi Jorge,
+
+I am so glad you finally gave the dpi some priority! I can=B4t help notic=
+ing that
+you came back to most of my initial design, even if you gave me a hard ti=
+me
+back then because you found it too complicated :-)
+
+I still have to review it in detail, though. I=B4d also want to know how =
+much
+code you have have for it and for what feature, since a lot of people see=
+m to
+have sent you a contribution.
+
+Now I had almost a year of reflection about it, I think that there is a m=
+ajor
+flaw to this dpi1-plus plugin: re-entrance will be very difficult to main=
+tain
+with the proposed design, basically leaving it up to the plugin=B4s devel=
+oper.
+That=B4s because most plugins will be kept alive. This half-baked dpi1-al=
+most2
+propostion does not satisfy me.
+
+Since it seems to be a good time for discussing about it, here=B4s what I=
+think.
+
+1) revert to dpi1 with one simple request-answer scheme without keeping i=
+t alive
+(perhaps by using the implementation I did before), or simply abandon it.
+
+2) push the current proposition up to a full dpi2, where each plugin will=
+be
+loaded and kept alive a staring time. A lot of simplification can be done=
+here:
+no more stdin-stdout, but use dlopen with a clean interface of calling
+functions to implement; all relevant data for each request would be maint=
+ained
+by a session struct passed as a pointer to each of these functions.
+
+If we choose to go to a full dpi2 right away, (which can take some time,
+this is why I propose to keep the early dpi1 for now), we will need more
+interaction with the rendering engine, which calls for the two following
+features:
+
+- the ability to walk the internal representation of the page: for now, i=
+t=B4s a
+pain in the ass to find which dw =A8children=A8 are actually rendered, wh=
+ich are
+words, which are containers, etc. The find_text code talks by itself, and=
+I am
+postponing the text copy-paste until I find a good solution.
+
+- the ability to dynamically change the tree structure, not only be alter=
+ing
+the content of it, but by inserting and removing words and widgets. Right=
+now,
+the result when trying that is guaranteed to be =A8unknown=A8.
+
+This means we have to come with some sort of DOM interface on top of the
+internal dw representation. A lot of good could come from it, including t=
+he
+ability for dillo to become a generic-application client as well as a bet=
+ter
+browser, at almost no cost in development and no =A8bloat=A8.
+
+Mozilla=B4s gecko rendering engine is successful amongst developers becau=
+se it=B4s
+mimic-ing the MSIE=B4s poor internal representation they know, let=B4s de=
+sign
+something better.
+
+Best,
+Eric
+
+PS: Jorge, I wanted to ask you this for a long time: what text editor do =
+you
+use, with that =A8justify=A8 in plain text?
+
+-- En reponse de "[Dillo-dev]Simple plugins" de Jorge Arellano Cid, le
+02-Apr-2002 :
+>=20
+> Hi there!
+>=20
+> Those of you that read my "Dillo plans for 2002" post should
+> have a good overview of what's currently going on:
+>=20
+> http://www.geocrawler.com/archives/3/702/2002/1/0/7681591/
+>=20
+> As you may see there, my first priority now is getting some
+> funds to keep rolling dillo project; it's a tough situation, so
+> I'm currently making some presentation material to show to
+> potential contributors... (Please re-read the post for details).
+>=20
+>=20
+>=20
+> I've noticed special interest for what we agred to call "simple
+> plugins". At least, Russell, Paul, Johnatan, Bruce, Ralph, Geoff,
+> Tomas, Imad, Mark, Stephen and Eric have wrote something directly
+> or closely related to them. Considering the situation, I decided
+> to give some time to it, and prepared a new draft of the dpi1
+> spec. The document is several pages long, so I put it under the
+> "Developers" section of the new site.
+>=20
+> Please read it as it's the generic answer to all of those
+> posts that seemed forgoten, but that were not!
+>=20
+> The doc is somewhat dense and will surely require some time to
+> study, digest and comprehend. Well, with that interest showing, I
+> think it's a good time to give it some thought.
+>=20
+> This is the opportunity to discuss, design, improve, correct,
+> etc. (is far better to correct the design than trying to mend an
+> unsuitable piece of code.)
+>=20
+> Best of luck with it!
+>=20
+>=20
+> Ah, passing to another subject, I have a couple of SSL
+> implementations to review here, but I'll get into them later
+> (maybe in a month or more). I'd love to have some more feedback
+> from the authors, just to know how they behave and why they
+> decided to implement it that way.
+>=20
+> Finally, dillo-0.6.5 release is planned for mid April, from the
+> new site!!!
+>=20
+>=20
+> Stay tuned!
+> Jorge.-
+>=20
+>=20
+>=20
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------------------------------------------
+Eric GAUDET <eric.gaudet@vn...>
+Le 02-Apr-2002 a 17:48:39
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+[Dillo-dev]Simple plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-02 23:19
+
+Hi there!
+
+Those of you that read my "Dillo plans for 2002" post should
+have a good overview of what's currently going on:
+
+http://www.geocrawler.com/archives/3/702/2002/1/0/7681591/
+
+As you may see there, my first priority now is getting some
+funds to keep rolling dillo project; it's a tough situation, so
+I'm currently making some presentation material to show to
+potential contributors... (Please re-read the post for details).
+
+
+
+I've noticed special interest for what we agred to call "simple
+plugins". At least, Russell, Paul, Johnatan, Bruce, Ralph, Geoff,
+Tomas, Imad, Mark, Stephen and Eric have wrote something directly
+or closely related to them. Considering the situation, I decided
+to give some time to it, and prepared a new draft of the dpi1
+spec. The document is several pages long, so I put it under the
+"Developers" section of the new site.
+
+Please read it as it's the generic answer to all of those
+posts that seemed forgoten, but that were not!
+
+The doc is somewhat dense and will surely require some time to
+study, digest and comprehend. Well, with that interest showing, I
+think it's a good time to give it some thought.
+
+This is the opportunity to discuss, design, improve, correct,
+etc. (is far better to correct the design than trying to mend an
+unsuitable piece of code.)
+
+Best of luck with it!
+
+
+Ah, passing to another subject, I have a couple of SSL
+implementations to review here, but I'll get into them later
+(maybe in a month or more). I'd love to have some more feedback
+from the authors, just to know how they behave and why they
+decided to implement it that way.
+
+Finally, dillo-0.6.5 release is planned for mid April, from the
+new site!!!
+
+
+Stay tuned!
+Jorge.- 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Jamin W. Collins <jcollins@as...> - 2002-04-02 18:02
+
+On Tue, 2 Apr 2002 11:46:35 -0400 (CLT)
+"Jorge Arellano Cid" <jcid@em...> wrote:
+
+> Thanks a lot Madis. A couple more successful reports and I'll
+> turn it our official site. It's much better!
+
+Worked fine when I tested it. Like the layout too.
+
+-- 
+Jamin W. Collins 
+
+
+
+Re: [Dillo-dev]CIPSGA
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-04-02 17:49
+
+Hi there!
+
+On Mon, 1 Apr 2002, Madis Janson wrote:
+
+> On Wed, 20 Mar 2002, Jorge Arellano Cid wrote:
+>
+> >
+> > The new site's at: http://dillo.cipsga.org.br/
+> >
+> > It hasn't yet been blessed as our official site, but please go
+> > there and test it, specially those of you from Europe, so we can
+> > get a feel of how the connection behaves.
+>
+> i've tried it now multiple times, and it has always worked fine and fast
+> (i'm in estonia, which is in europa).
+
+
+Thanks a lot Madis. A couple more successful reports and I'll
+turn it our official site. It's much better!
+
+
+Cheers
+Jorge.- 
+
diff --git a/old/oldmail/200205.txt b/old/oldmail/200205.txt
new file mode 100644
index 0000000..0a5e4c1
--- /dev/null
+++ b/old/oldmail/200205.txt
@@ -0,0 +1,4676 @@
+[Dillo-dev]dillo-0.6.6 success
+
+From: Bjoern Weber <foxbow@we...> - 2002-05-31 07:39
+
+Heyas,
+
+and again an information that nobody really needs =)
+dillo-0.6.6 compiled instantly on my QNX6.1 host. I'm
+looking to see if I can create a PPC version as well and
+wonder if anyone would be interested in a .qpk that 
+installs dillo together with all needed libs...
+
+Ah, one issue remains, configure thinks that QNX
+needs the -pthread flag, that's not the case. The compiler
+complains about an unknown option but everything runs
+fine.
+
+Wish me luck on my NetBSD/Sparc =)
+
+Bjoern 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-05-31 01:31
+
+On Thu, May 30, 2002 at 09:27:48PM +0100, Freya wrote:
+> gtk 2.0 for a much more practical reason tho. It seems like there is a
+> lot of great code and patches around based on the current code base and
+> it would seem like it would be more sensible to apply all this code to
+> the current codebase and get a new version out fairly quickly than to
+> delay things for gtk2. This would also give a lot longer for gtk 2 to
+> find it's way out there and for people to be able to see how it goes and
+> learn from that. I assume that nobody is suggesting gtk2 for the next
+> version anyway tho.
+
+
+There's a standard answer to this sort of problem: branch the code. I
+agree that gtk2.0 is probably the ay to go in the future (all the linux
+ipaq developers have started having this conversation, as well) but it
+will be some time. If someone wantsto start that work, I think it should
+probably be in a fork or branch.
+
+Ross 
+
+
+
+[Dillo-dev][PATCH] Font Faces
+
+From: Livio Baldini Soares <livio@im...> - 2002-05-31 00:34
+
+Hello Sebastian!
+
+Sebastian Geerken writes:
+> On Tue, Apr 30, 2002 at 05:49:26PM -0500, Chris Hawks wrote:
+> > Just a question for a new (and very impressed) user...
+> > 
+> > 
+> > Why is the font face code commented out in html.c (about line 1720). I
+> > un-commented it and it seems to work correctly...
+> 
+> I fear that was me who did this. I planned to add an "force_my_faces"
+> option immediately to overide this, that should be done before
+> uncommenting the code.
+
+Ahhh, I think this is a very interesting option.
+
+Sorry if I'm stepping on your toes Sebastian ;-), but here is a
+patch which adds force_my_fonts option to dillorc:
+
+http://www.ime.usp.br/~livio/dillo/patches/force_my_font_pref.diff
+
+Personally I leave force_my_fonts=NO, to visualiaze the original's
+HTML font intention, but to Dillo consistent with what it is today,
+the default option is YES. (This means you'll no difference unless you
+explicitly change your "dillorc").
+
+Any comments? 
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Greyscale .jpg's
+
+From: Freya <Freya@he...> - 2002-05-30 20:55
+
+Something I've been wondering for some time is whether it would be
+possible to render .jpg's with a greyscale palette? I was originally
+wondering this because I thought my nasty old laptop was only capable of
+16 colours, turns out it can do 256! This is very nice as I can really
+see what photos look like! :) However, if you render a photo in 16
+greyscales then you can still very much see the photo, really quite well
+in fact, and if I could use 256 greyscales (which my laptop does yay!)
+then photos would just look like black and white photos with no
+artifacts as such at all! (If you've seen a jpg in 256 colours, you can
+see that there is only 256 colours it still looks wrong. It looks good,
+but just that little bit not there!)
+
+My display is only mono anyway I should explain, or you might wonder! ;)
+
+Anyway, just how impossible would this be?
+
+love
+
+Freya 
+
+
+
+[Dillo-dev]dillo-0.6.6 release
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-30 20:50
+
+Surprise!
+
+
+I just packed out dillo-0.6.6, it's there ready for download.
+Tomorrow I'll make the announcements urbi et orbi.
+
+Go get it!
+
+
+Cheers
+Jorge.-
+
+
+PS: Ah, for those new to this list, please read the mailing list
+etiquette before posting (unfortunately it's obvious some
+haven't). 
+
+
+
+[Dillo-dev]GTK+2.0
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-30 20:50
+
+Hi there,
+
+Brief explanation before this becomes a debate:
+
+GTK+2.0 is very important to dillo because of the reasons
+explained in the "Project Notes". The hard part of the porting
+task is the core, not on the UI. I fully agree with Andreas on
+waiting until it is available in the big distros, and with
+Sebastian on making it at once.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Daniel Fairhead <ralphtheraccoon@uk...> - 2002-05-30 20:47
+
+> But why would you want to port it to gtk2?
+> What advantage does that bring?
+
+a) AntiAliased text. I know a lot of people will object, raise all the "argh blurry text" arguments
+but I dont care. Besides, you can turn it off. I also know about gtkxft, but it was buggy when I tried
+it, and many other people have said the same.
+
+b) Characterset GTK fixes.
+
+c) A working fast browser in GTK2 (and so GNOME2) which might possibly bring it to a larger viewage.
+
+d) I dont know, but I think GTK2 is easy to port (if not crossplatform directly) to other display systems
+(such as Wind*ws, OSX) and also to the framebuffer system, which could be useful for an embedded
+enviroment which may not have an X server. I dont know if dillo already does this though.
+
+e) Finding bugs in (non GTK) code which didn't get noticed due to GTK being friendlier than it perhaps
+should
+
+f) The developpers who port it get some experience at porting GTK apps, and writing GTK2 code.
+
+g) For those who have this itch, it is scratched.
+
+h) To prove it can be done.
+
+i) Fun (for those who enjoy such things).
+
+Theres a few reasons. 
+
+MadProf 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Freya <Freya@ga...> - 2002-05-30 20:41
+
+On Thu, 30 May 2002 18:22:13 +0200 (MET DST)
+Lawrence Mayer dsg <Lawrence.Mayer@ds...> wrote:
+
+> On Thu, 30 May 2002, Freya wrote:
+> 
+> > But why would you want to port it to gtk2?
+> > What advantage does that bring?
+> 
+> According to http://developer.gnome.org/dotplan/schedule/
+> Gnome 2.0 Desktop Final (which uses GTK+-2.0) is scheduled for release
+> on June 21.
+> 
+> How many Linux distros released after June 21 will keep obsolete,
+> unsupported GTK+-1.2 around? And for how long?
+
+No idea, but it must be said that my debian testing doesn't even have
+the new dillo yet and that's been out ages now! My guess is gtk 1.2 will
+be around for ages too, I think my distro still includes libc5?
+
+> So if Dillo doesn't port over to GTK+-2.0, how will it survive?
+
+Well that answers the first of my two questions, but to be honest I was
+more wondering about the second question, I kind of added the first
+question without thinking about it because I thought there was something
+that people really wanted that was in gtk 2, and they were excited about
+it! :) Maybe a silly assumption on my part. Anyway there surely is an
+advantage to gtk2, I mean this isn't microsoft world where the advantage
+is all for microsoft IYSWIM ;)
+
+love
+
+Freya 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Freya <Freya@he...> - 2002-05-30 20:40
+
+> > > 
+> > > Lawrence.Mayer@ds... writes:
+> > > > If Dillo needs GTK+-1.2, are there any plans to make a GTK+-2.0
+> > > > version? If so, any idea when it might become available?
+> 
+> 
+> > Availibility on distributions is indeed a problem, since this
+> > affects how easily dillo can be installed.
+> 
+> 
+> Just one thought on that one : dillo is popular on low end machines.
+> If I would have to go through a major pain to upgrade gtk just
+> to get dillo running I would think twice. Now, I don't know how
+> much more resource hungry gtk2 compared to gtk1.2 is. But either
+> way, an upgrade on a low end machine may be painful.
+
+This would affect me of course running in 8mb! lol! 
+I think I could upgrade fairly easily to gtk 2 as soon as it made it's
+way to debian testing, although I suspect that will be a long time from
+now going on past things. The resource hungryness is obviously a big
+issue tho, although I heard some rumblings that people found gtk2 wasn't
+that bad but none of these people were working with low end machines. 
+I think it would be kind of crazy for the next release of dillo to be
+gtk 2.0 for a much more practical reason tho. It seems like there is a
+lot of great code and patches around based on the current code base and
+it would seem like it would be more sensible to apply all this code to
+the current codebase and get a new version out fairly quickly than to
+delay things for gtk2. This would also give a lot longer for gtk 2 to
+find it's way out there and for people to be able to see how it goes and
+learn from that. I assume that nobody is suggesting gtk2 for the next
+version anyway tho.
+
+Quite curious about it and still kind of mystified as to what the whole
+gtk 2 thing is all about! :)
+
+love
+
+Freya 
+
+
+
+[Dillo-dev]Having trouble compiling dillo...
+
+From: Freya <Freya@he...> - 2002-05-30 20:20
+
+Attachments: config.log      
+
+...I should point out that I'm sure this is because I don't have a clue
+what I'm doing! But Perhaps someone with some more experience can help
+me here!
+
+I think the problem I am having is that either I need to download the
+source or header files or something for working with gtk (anyone suggest
+the debian packages I need) or that some pointers or symbolic links or
+something need to be set up so that configure and make know where to
+find everything. I have attached my config.log to give and idea of what
+is going on. It seems to think that I won't be needing .jpg support!
+lol!
+
+I've tried doing a make as well but that just fails completely.
+Also if I do a make install, will this overwrite my existing dillo?
+I'd rather just install a debian package yet but as far as I know it's
+still the old version in testing and I want to know if I can compile
+things as I need to compile something else and that isn't playing at
+all!
+
+Can you run an old and new dillo side by side?
+
+Lots of questions! :)
+
+love
+
+Freya 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Pekka Lampila <medar@ka...> - 2002-05-30 16:41
+
+Hi.
+
+On Thu, 30 May 2002 10:42:44 -0400
+Andreas Schweitzer <andy@ph...> wrote:
+> Just one thought on that one : dillo is popular on low end machines.
+> If I would have to go through a major pain to upgrade gtk just
+> to get dillo running I would think twice. Now, I don't know how
+> much more resource hungry gtk2 compared to gtk1.2 is. But either
+> way, an upgrade on a low end machine may be painful.
+
+I don't know how much gtk based software there is for low end machines,
+but most of gtk software has been or are currently being ported to 2.0.
+So we may soon come to point where the question is whether to keep
+gtk1.2 around just for Dillo...
+
+Don't have any facts about gtk2.0's resource hungryness, but just
+because it has bigger version number doesn't mean it's worse in that
+respect. I quess it can be even faster than gtk1.2 in many ways. 
+
+> Also, I think it hurts a project to always use the latest
+> cool, on-the-edge libraries out there because hardly any
+> distro has the latest, on-the-edge versions included. When
+> I see a project, think it's cool, and start reading in the
+> requirements that I need lib-o-so-cool lib-o-so-new I start
+> thinking if it is really worth it.
+
+gtk1.3 (the development branch) was cool, new, on-the-edge library, but
+2.0 is stable successor for 1.2, fixing many bugs and adding some needed
+features. (Characterset handling being perhaps the most important for
+Dillo.)
+
+> Of course, dillo is the coolest thing ever ;-) and theoretically
+> only for developers (although there are probably far more end users
+> than anticipated at this point), therefore, you can expect more flexibility
+> from its audience.
+
+Agreed :)
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Lawrence Mayer dsg <Lawrence.Mayer@ds...> - 2002-05-30 16:26
+
+On Thu, 30 May 2002, Freya wrote:
+
+> But why would you want to port it to gtk2?
+> What advantage does that bring?
+
+According to http://developer.gnome.org/dotplan/schedule/
+Gnome 2.0 Desktop Final (which uses GTK+-2.0) is scheduled for release on
+June 21.
+
+How many Linux distros released after June 21 will keep obsolete,
+unsupported GTK+-1.2 around? And for how long?
+
+So if Dillo doesn't port over to GTK+-2.0, how will it survive?
+
+Friendly Greetings,
+Lawrence 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Andreas Schweitzer <andy@ph...> - 2002-05-30 14:42
+
+Hi
+
+On Wed, May 29, 2002 at 04:50:56PM +0200, Sebastian Geerken wrote:
+> On Thu, May 23, 2002 at 08:27:59AM -0300, Livio Baldini Soares wrote:
+> > Hello Lawrence!
+> > 
+> > Lawrence.Mayer@ds... writes:
+> > > If Dillo needs GTK+-1.2, are there any plans to make a GTK+-2.0 version? If
+> > > so, any idea when it might become available?
+
+
+> Availibility on distributions is indeed a problem, since this affects
+> how easily dillo can be installed.
+
+
+Just one thought on that one : dillo is popular on low end machines.
+If I would have to go through a major pain to upgrade gtk just
+to get dillo running I would think twice. Now, I don't know how
+much more resource hungry gtk2 compared to gtk1.2 is. But either
+way, an upgrade on a low end machine may be painful.
+
+Also, I think it hurts a project to always use the latest
+cool, on-the-edge libraries out there because hardly any
+distro has the latest, on-the-edge versions included. When
+I see a project, think it's cool, and start reading in the
+requirements that I need lib-o-so-cool lib-o-so-new I start
+thinking if it is really worth it.
+
+Of course, dillo is the coolest thing ever ;-) and theoretically
+only for developers (although there are probably far more end users
+than anticipated at this point), therefore, you can expect more flexibility
+from its audience.
+
+Just my 2 cents.
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Freya <Freya@he...> - 2002-05-30 12:44
+
+But why would you want to port it to gtk2?
+What advantage does that bring?
+
+love
+
+Freya
+
+On Wed, 29 May 2002 23:49:16 +0200 (MET DST)
+Lawrence Mayer dsg <Lawrence.Mayer@ds...> wrote:
+
+> Hi Sebastian!
+> 
+> On Wed, 29 May 2002, Sebastian Geerken wrote:
+> 
+> > I read the porting guidelines (somewhere at gtk.org)
+> 
+> The GNOME 2.0 porting guide
+> http://developer.gnome.org/dotplan/porting/
+> "has some more detailed discussion of porting from GTK+-1.2 to -2.0.
+> See the sections on GLib and GTK+."
+> 
+> Here are some additional resources:
+> 
+> The GTK+-2 Reference Manual is at
+> http://developer.gnome.org/doc/API/2.0/gtk/index.html
+> 
+> Of particular note is the section "Changes from 1.2 to 2.0"
+> http://developer.gnome.org/doc/API/2.0/gtk/gtk-changes-2-0.html
+> 
+> The mailing list
+> http://mail.gnome.org/archives/gtk-app-devel-list
+> "is oriented toward developing applications with GTK+. This has been a
+> lower traffic list which is good for asking simple GTK+ questions."
+> 
+> The original release annoncement for GTK+-2.0.0 is at
+> http://mail.gnome.org/archives/gtk-app-devel-list/2002-March/msg00091.html
+> 
+> The release annoncement for GTK+-2.0.3 (current stable version) is at
+> http://mail.gnome.org/archives/gtk-app-devel-list/2002-May/msg00276.html
+> 
+> Also worthy of note: http://www.gtk.org/download/
+> "Many applications still require GTK+-1.2, the last stable version of
+> GTK+. You can have the runtime and development environments for both
+> GTK+-2.0 and GTK+-1.2 installed simultaneously on your computer."
+> 
+> 
+> > Availibility on distributions is indeed a problem, since this
+> > affects how easily dillo can be installed. Perhaps others may give
+> > information on when Gtk+ 2 may be available.
+> 
+> GTK+-2.0 and its libraries GLib-2.0, Pango, and ATK are all available
+> as:
+> 
+> Source from ftp://ftp.gtk.org/pub/gtk/v2.0/
+> 
+> RedHat-7.2 binaries from
+> ftp://ftp.gtk.org/pub/gtk/v2.0/binary/RedHat-7.2/
+> 
+> FreeBSD binaries from
+> ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/x11-toolkits/
+> or from many mirror sites.
+> 
+> 
+> I think it's exciting that we have serious discussion regarding
+> porting Dillo to GTK+-2.0. I hope the above resources prove useful.
+> 
+> Friendly Greetings,
+> Lawrence
+> 
+> 
+> 
+> _______________________________________________________________
+> 
+> Don't miss the 2002 Sprint PCS Application Developer's Conference
+> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Gombok Arthur <gombok@so...> - 2002-05-30 10:18
+
+"Justin (Gus) Hurwitz" wrote:
+
+> OK- I fixed my problems, mainly by (unfortunately) doing
+> Bad Things(TM). I got the ord this afternoon that it's very 
+> unlikely that we can get the server fixed. so I went ahead 
+> and got things working by breaking dillo.
+
+What a big bullshit (sorry, really). Convince the server-admin to validate the generated html contect (either w3c or wdg).
+
+(Spending so much time implementing buhgs)
+
+> And again, great job with the browser!
+
+I agree
+
+--Gombok 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Justin (Gus) Hurwitz <ghurwitz@dy...> - 2002-05-29 22:15
+
+OK- I fixed my problems, mainly by (unfortunately) doing Bad Things(TM). I
+got the ord this afternoon that it's very unlikely that we can get the
+server fixed. so I went ahead and got things working by breaking dillo.
+Description follows for edification, not incorporation. I'm working on an
+embedded app here, so I only need the browser to work for this web-based
+application- breaking other stuff is unfortunately the way I must go.
+
+1. I modified Html_parse_entity() to kludge around missing semi-colons:
+
+eoe = (toksize) ? memchr(token, ';', toksize) : strchr(token, ';');
+if (eoe) {
+if (token[1] == '#') {
+/* Numeric token */
+base = (token[2] == 'x' || token[2] == 'X') ? 16 : 10;
+isocode = strtol(token + 2 + (base==16), NULL, base);
+return (isocode > 0 && isocode <= 255) ? isocode : -1;
+} else {
+/* Search for named entity */
+name = g_strndup(token + 1, eoe - token - 1);
+i = Html_entity_search(name);
+g_free(name);
+return (i != -1) ? Entities[i].isocode : -1;
+}
++ } else {
++ /* This shouldn't be here- we're dealing with non-compliant HTML */
++ /* But, we'll search anyhow */
++ int len=1;
++ gchar *tokpos=token+2;
++
++ while(isalnum(tokpos[0])) {
++ tokpos++; len++;
++ }
++ name = g_strndup(token + 1, len);
++ i = Html_entity_search(name);
++ g_free(name);
++ return (i != -1) ? Entities[i].isocode : -1;
+}
+return -1;
+}
+
+This gets &nbsp working.
+
+2. Getting that odd image to load (the one that lies about its content
+type and is generated by php) was another matter entirely- I started by
+modifying Cache_parse_header() to always detect the content type from the
+data:
+
+io->IOVec.iov_base = (char *)entry->Data + entry->ValidSize;
+io->IOVec.iov_len = entry->BuffSize;
+io->Flags &= ~IOFlag_FreeIOVec;
+}
+
+/* Get Content-Type */
+- if ( (Type = Cache_parse_field(header, "Content-Type")) == NULL ) {
+- DEBUG_HTTP_MSG("Server didn't send Content-Type in header.\n");
+- Type = Cache_get_type_from_data(entry->Data, entry->ValidSize);
+- }
+- entry->Type = Type;
+-
++ Type = Cache_get_type_from_data(entry->Data, entry->ValidSize);
++ entry->Type = Type;
++ if(strstr(Type, "image")) entry->Flags &= ~(CA_Redirect);
+}
+
+/*
+* Consume bytes until the whole header is got (up to a "\r\n\r\n" sequence)
+* (Also strip '\r' chars from header)
+*/
+
+
+The astute reader will notice rather quickly that I'm also forcing the
+CA_Redirect bit low. It turns out that the php that generates the image
+and sends the wrong content type also sends the image as a 302, which is a
+redirect code (redirects to /logout.php). The entire site uses a lot of
+302's to load pages, but ignoring it for images seems to work. (Andreas-
+that's why just forcing the content-type autodetect didn't work).
+
+
+
+Those two sets of changes make everything work as I need it to. I report
+them mainly so others can see what need be done to support this broken
+code (in the event that others, too, must support similar broken code),
+and to let those who helped know.
+
+And again, great job with the browser!
+
+--Gus
+
+--
+Justin (Gus) Hurwitz
+ghurwitz@dy... 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Lawrence Mayer dsg <Lawrence.Mayer@ds...> - 2002-05-29 21:53
+
+Hi Sebastian!
+
+On Wed, 29 May 2002, Sebastian Geerken wrote:
+
+> I read the porting guidelines (somewhere at gtk.org)
+
+The GNOME 2.0 porting guide
+http://developer.gnome.org/dotplan/porting/
+"has some more detailed discussion of porting from GTK+-1.2 to -2.0. See
+the sections on GLib and GTK+."
+
+Here are some additional resources:
+
+The GTK+-2 Reference Manual is at
+http://developer.gnome.org/doc/API/2.0/gtk/index.html
+
+Of particular note is the section "Changes from 1.2 to 2.0"
+http://developer.gnome.org/doc/API/2.0/gtk/gtk-changes-2-0.html
+
+The mailing list
+http://mail.gnome.org/archives/gtk-app-devel-list
+"is oriented toward developing applications with GTK+. This has been a
+lower traffic list which is good for asking simple GTK+ questions."
+
+The original release annoncement for GTK+-2.0.0 is at
+http://mail.gnome.org/archives/gtk-app-devel-list/2002-March/msg00091.html
+
+The release annoncement for GTK+-2.0.3 (current stable version) is at
+http://mail.gnome.org/archives/gtk-app-devel-list/2002-May/msg00276.html
+
+Also worthy of note: http://www.gtk.org/download/
+"Many applications still require GTK+-1.2, the last stable version of
+GTK+. You can have the runtime and development environments for both
+GTK+-2.0 and GTK+-1.2 installed simultaneously on your computer."
+
+
+> Availibility on distributions is indeed a problem, since this affects
+> how easily dillo can be installed. Perhaps others may give information
+> on when Gtk+ 2 may be available.
+
+GTK+-2.0 and its libraries GLib-2.0, Pango, and ATK are all available as:
+
+Source from ftp://ftp.gtk.org/pub/gtk/v2.0/
+
+RedHat-7.2 binaries from
+ftp://ftp.gtk.org/pub/gtk/v2.0/binary/RedHat-7.2/
+
+FreeBSD binaries from
+ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/x11-toolkits/
+or from many mirror sites.
+
+
+I think it's exciting that we have serious discussion regarding porting
+Dillo to GTK+-2.0. I hope the above resources prove useful.
+
+Friendly Greetings,
+Lawrence 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Paul Chamberlain <tif@ti...> - 2002-05-29 21:11
+
+Justin (Gus) Hurwitz wrote:
+> Your responses to the list definitely help, esp. pointing out that the
+> server is sending a content type of text/html. I'm seeing if I can get
+> that fixed.
+
+There may be a way in the apache conf to say that this
+one URL is always image/png.
+
+> Or perhaps we should never believe the
+> content type and always try to autodetect from the data (it is a fairly
+> quick routine)?
+
+This sounds like a discussion that might have taken place
+right before outlook got the bug that allows many virii
+to infect Windows boxen. "It says it's a wav so let's
+go ahead and play it (wav's are safe)... Oh, look it's
+not a wav afterall, it's an exe, let's magically do the
+right thing and execute it."
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Pekka Lampila <medar@ka...> - 2002-05-29 20:17
+
+On Wed, 29 May 2002 11:08:35 -0500 (EST)
+"Justin (Gus) Hurwitz" <ghurwitz@dy...> wrote:
+> 
+> Of course, this won't help my situation, since the server is lying about
+> the content type. Perhaps it makes sense to also run the auto-detect
+> routine if loading the data fails? Or perhaps we should never believe the
+> content type and always try to autodetect from the data (it is a fairly
+> quick routine)?
+
+That violates HTTP standard[1]. And of course it can make perfect sense
+to have text document that starts with "<HTML>" or something similiar.
+
+Local files are of course different matter. But I can't think many
+situations where detection from file extension isn't enough. Why have
+jpg files without jpg extension?
+
+[1] RFC 2616 (HTTP 1.1):
+Any HTTP/1.1 message containing an entity-body SHOULD include a
+Content-Type header field defining the media type of that body. If
+and only if the media type is not given by a Content-Type field, the
+recipient MAY attempt to guess the media type via inspection of its
+content and/or the name extension(s) of the URI used to identify the
+resource. If the media type remains unknown, the recipient SHOULD
+treat it as type "application/octet-stream".
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Justin (Gus) Hurwitz <ghurwitz@dy...> - 2002-05-29 18:24
+
+Your responses to the list definitely help, esp. pointing out that the
+server is sending a content type of text/html. I'm seeing if I can get
+that fixed.
+
+But, I've come across another interesting aspect of this problem. I load
+the image in netscape and save it as chasis.png. I then load it in dillo
+and all is well. But, I then save it as chasis.php and try to load it. I
+get text. And then, if I save it as chasis.gif I get nothing. Apparently
+dillo gives priority to the filename extention in determining content
+type? And when in doubt it assumes text/html (IO/file.c:250)? Why not hook
+into the Cache_get_type_from_data() (or abstract it) and run that if/when
+File_content_type() falls through.
+
+Of course, this won't help my situation, since the server is lying about
+the content type. Perhaps it makes sense to also run the auto-detect
+routine if loading the data fails? Or perhaps we should never believe the
+content type and always try to autodetect from the data (it is a fairly
+quick routine)? I am philosophically against compensating for broken
+servers on the client side, and so don't like these ideas. But, if
+detecting the content type from the data can be made comparably as fast as
+from the file extention or even the server's content-type field, then it
+might make good sense.
+
+--Gus
+
+On Wed, 29 May 2002, Andreas Schweitzer wrote:
+
+> Hi
+>
+> On Tue, May 28, 2002 at 05:20:56PM -0500, Justin (Gus) Hurwitz wrote:
+> > On Wed, 29 May 2002, Nipo wrote:
+> >
+> > > Hurwitz Justin W. eut le bonnheur d'ecrire:
+> > >
+> > > The script which generates the image ( chassis.php ) does not issue any
+> > > Content/type header. So dillo can not be sure data is image and that is
+> > > only because Netscape is very tolerant that the image is displayed.
+> > > Try to make netscape open the image url directly and you'll get raw data!
+> >
+> > But dillo does have a parse routine that tries to identify unknown data
+> > types- and it looks like it should work just fine. But, when I try to load
+> > the page, that routine is never encountered. If the image type can be
+> > detected by dillo (and there already exists efficient support for the
+> > detection) why doesn't/can't dillo do the detection?
+>
+> (I only posted my answers to the list, not to you - if you are
+> subscribed this is not a problem :-) ... if not I briefly repeat )
+> Because the server says the image is text/html and dillo trusts that.
+> I plaid around with the routines.
+>
+> > I might be able to get minor (ie, very minor, like changing &nbsp to
+> > $nbsp;) changes made on the server side. But I cannot think of a way to
+> > simply fix this problem on the server side without trying to convince
+> > another company to completely re-engineer their product :) If getting
+>
+> Well, if the software sends an image and claims this image is text/html
+> then this is most certainly a bug. And a bug report should be filed with
+> the software maker :-) ....
+>
+> Cheers,
+> Andreas
+>
+> --
+> Department of Physics & Astronomy and Center for Simulational Physics
+> University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+> Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+> USA http://dilbert.physast.uga.edu/~andy/
+>
+
+--
+Justin (Gus) Hurwitz 
+
+
+
+Re: [Dillo-dev]Faces
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-05-29 15:02
+
+On Tue, Apr 30, 2002 at 05:49:26PM -0500, Chris Hawks wrote:
+> Just a question for a new (and very impressed) user...
+> 
+> 
+> Why is the font face code commented out in html.c (about line 1720). I
+> un-commented it and it seems to work correctly...
+
+I fear that was me who did this. I planned to add an "force_my_faces"
+option immediately to overide this, that should be done before
+uncommenting the code.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-05-29 14:51
+
+On Thu, May 23, 2002 at 08:27:59AM -0300, Livio Baldini Soares wrote:
+> Hello Lawrence!
+> 
+> Lawrence.Mayer@ds... writes:
+> > If Dillo needs GTK+-1.2, are there any plans to make a GTK+-2.0 version? If
+> > so, any idea when it might become available?
+> 
+> There have been a few individual tries to port Dillo do GTK+-2.0, as
+> as far as I know, none of which have succeed completely. I think the
+> main Dillo developers are not currently very motivated to do this
+> port, at least while GTK+-2.0 isn't available on most mainstream
+> stable distributions.
+
+I haven't taken any look on Gtk+ 2 until now, mostly due to the lack
+of time. I read the porting guidelines (somewhere at gtk.org), and
+what I remember is that porting should be simple, problems may only
+arise in the usage of GtkObject (which is now GObject, and a part of
+glib), and text rendering (which is now done by Pango). Well, That's
+both what the Dw module heavily depends on!
+
+Availibility on distributions is indeed a problem, since this affects
+how easily dillo can be installed. Perhaps others may give information
+on when Gtk+ 2 may be available. (There is also the possibility of
+keeping dillo for a while runnable with both versions, using ugly
+#ifdef's, double test runs, new options for the configure script
+etc. -- but I think the port should be done once, without transitional
+time.)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: madis <madis@cy...> - 2002-05-29 09:53
+
+On Tue, 28 May 2002, Justin (Gus) Hurwitz wrote:
+
+> But dillo does have a parse routine that tries to identify unknown data
+> types- and it looks like it should work just fine. But, when I try to load
+> the page, that routine is never encountered. If the image type can be
+> detected by dillo (and there already exists efficient support for the
+> detection) why doesn't/can't dillo do the detection?
+> 
+Dillo belives the content-type and does not know how to display text/html 
+images. The detection routine is invoked only when Content-Type header is 
+missing (Cache_get_type_from_data invoked from end of Cache_parse_header).
+It is not very reliable also, because it works only, if this last read 
+from TCP socket, which delivered HTTP header end also delivered enough 
+HTTP body data for content type autodetection (because TCP stack tries to
+concatenate short packets before sending, it is usually not a problem).
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Justin (Gus) Hurwitz <ghurwitz@dy...> - 2002-05-29 00:36
+
+On Wed, 29 May 2002, Nipo wrote:
+
+> Hurwitz Justin W. eut le bonnheur d'ecrire:
+>
+> >In Netscape there is a big PNG picture at the top-center of the page. It
+> >is generated by chasis.php. Dillo does not display it. This makes me very
+> >sad. More importantly, it prevents me from being able to "look inside"
+> >the chasis (if you click on the image in Netscape, you'll see what I
+> >mean- pretty cool, eh? ;)
+>
+> The script which generates the image ( chassis.php ) does not issue any
+> Content/type header. So dillo can not be sure data is image and that is
+> only because Netscape is very tolerant that the image is displayed.
+> Try to make netscape open the image url directly and you'll get raw data!
+
+But dillo does have a parse routine that tries to identify unknown data
+types- and it looks like it should work just fine. But, when I try to load
+the page, that routine is never encountered. If the image type can be
+detected by dillo (and there already exists efficient support for the
+detection) why doesn't/can't dillo do the detection?
+
+I might be able to get minor (ie, very minor, like changing &nbsp to
+$nbsp;) changes made on the server side. But I cannot think of a way to
+simply fix this problem on the server side without trying to convince
+another company to completely re-engineer their product :) If getting
+dillo to play nice with the bullies (which I understand and agree with
+being a not-the-right solution) is out of the question, can you think of
+any workable, simple server side solution?
+
+> >The second problem, which I'm sure is a common one, is that &nbsp tags
+> >are displayed- which makes pages look a bit wrong :) But that's of minor
+> >importance.
+>
+> That is also due to netscape (and many other browsers ) 's tolerance!
+> There must be a semicolon [;] after the tag.
+> Just like &amp; &lt; ... and all other &(...); tags
+
+Indeed, you are quite right! I'll see if I can get that fixed on the
+server side (fingers crossed on that, though I am doubtful).
+
+
+Thanks!
+--Gus
+
+> --
+>
+> Nipo
+> 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Andreas Schweitzer <andy@ph...> - 2002-05-28 23:52
+
+On Wed, May 29, 2002 at 01:11:19AM +0200, Nipo wrote:
+> Oops, I forgot the list..
+> 
+> Hurwitz Justin W. eut le bonnheur d'ecrire:
+> 
+> >In Netscape there is a big PNG picture at the top-center of the page. It 
+> >is generated by chasis.php. Dillo does not display it. This makes me very
+> >sad. More importantly, it prevents me from being able to "look inside"
+> >the chasis (if you click on the image in Netscape, you'll see what I
+> >mean- pretty cool, eh? ;)
+> 
+> The script which generates the image ( chassis.php ) does not issue any
+> Content/type header.
+
+Well, actually it does. But the wrong one ! (text/html)
+I tried to force dillo to detect the mime type by itself.
+Still nothing. However, I'd suggest to first fix the server/script
+to send the correct mime type.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Andreas Schweitzer <andy@ph...> - 2002-05-28 23:11
+
+On Tue, May 28, 2002 at 03:47:59PM -0700, Eric Gaudet wrote:
+> > -----Original Message-----
+> > From: dillo-dev-admin@li...
+> > [mailto:dillo-dev-admin@li...]On Behalf Of Hurwitz
+> > Justin W.
+> > Sent: Tuesday, May 28, 2002 3:30 PM
+> > To: dillo-dev@li...
+> > Subject: [Dillo-dev]The PNG that would not load
+> 
+> I think it's because dillo doesn't support Image Buttons in forms yet (same
+
+As far as I looked into it, it is not an image in a form. Making a tiny file
+like
+
+<html>
+<body>
+<img src=">
+</body>
+</html>
+
+does not display the image in dillo either. It does work in netscape.
+Saving the png in netscape and then displaying that very file in
+dillo does work, however.
+From this I'd conclude it must be in the communication between dillo
+and the server. Note also, that dillo never actually finishes the
+loading of the image (the image count is always missing one).
+It could be that the server does not send the mime type and dillo
+does still not recoginzie it (despite my fixes a few weeks back ;-) ...)
+Netscape does report it as unknown MIME type ! I may look into this.
+
+CHeers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]The PNG that would not load
+
+From: Nipo <nipo@ss...> - 2002-05-28 23:07
+
+Oops, I forgot the list..
+
+Hurwitz Justin W. eut le bonnheur d'ecrire:
+
+>In Netscape there is a big PNG picture at the top-center of the page. It 
+>is generated by chasis.php. Dillo does not display it. This makes me very
+>sad. More importantly, it prevents me from being able to "look inside"
+>the chasis (if you click on the image in Netscape, you'll see what I
+>mean- pretty cool, eh? ;)
+
+The script which generates the image ( chassis.php ) does not issue any
+Content/type header. So dillo can not be sure data is image and that is
+only because Netscape is very tolerant that the image is displayed.
+Try to make netscape open the image url directly and you'll get raw data!
+
+>The second problem, which I'm sure is a common one, is that &nbsp tags
+>are displayed- which makes pages look a bit wrong :) But that's of minor 
+>importance.
+
+That is also due to netscape (and many other browsers ) 's tolerance!
+There must be a semicolon [;] after the tag.
+Just like &amp; &lt; ... and all other &(...); tags
+
+-- 
+
+Nipo 
+
+
+
+RE: [Dillo-dev]The PNG that would not load
+
+From: Eric Gaudet <ericg@ta...> - 2002-05-28 22:46
+
+> -----Original Message-----
+> From: dillo-dev-admin@li...
+> [mailto:dillo-dev-admin@li...]On Behalf Of Hurwitz
+> Justin W.
+> Sent: Tuesday, May 28, 2002 3:30 PM
+> To: dillo-dev@li...
+> Subject: [Dillo-dev]The PNG that would not load
+> 
+> 
+> First off, to those who make dillo possible- great work with 
+> it! I've been 
+> wonderfully impressed. It's a bloody shame more programers aren't as 
+> intentional with how they program as you all are. Your work 
+> should help to remind us all that programming is an art.
+> 
+
+Don't forget Jorge's outstanding leadership qualities: I've been trying to
+participate to many open source projects and abandoned most of them because
+of the people being unreliable. It's really Jorge that makes Dillo that
+successfull.
+
+> Now, on to my problem. I'm working on an embedded tool to 
+> monitor our RLX 
+> based clusters (www.rlxtechnologies.com). RLX has a web based 
+> management/monitoring solution (Control Tower 2) that works 
+> great. I'm 
+> running dillo on an iPAQ as part of our monitoring tool. It 
+> works great. 
+> Bu there are two problems- one aesthetic, and one functional. The 
+> functional one it the more important:
+> 
+> Load the following URL in both Netscape and dillo:
+> http://rack1.rlxtechnologies.com/cm/chassview.php?ShowChassisI
+> D=1&p=0|1|2
+> 
+> In Netscape there is a big PNG picture at the top-center of 
+> the page. It 
+> is generated by chasis.php. Dillo does not display it. This 
+> makes me very 
+> sad. More importantly, it prevents me from being able to 
+> "look inside" the 
+> chasis (if you click on the image in Netscape, you'll see 
+> what I mean- 
+> pretty cool, eh? ;)
+> 
+> I've begun looking into why this image does not display in dillo, and
+> think I might be making some (very slow) progress. Due to 
+> time constraints
+> (and possible ailment- I fear I will be spending the next few 
+> days sick in
+> bed, sigh), I doubt I'll be able to properly fix this 
+> problem, if I can
+> fix it at all. If anyone has ideas where to start, or what's 
+> wrong, I'd
+> love to hear them- saving me a few dead-ends would be a great help. Of
+> course, if anyone has an immediate patch, I'll gladly let 
+> them take the
+> glory for fixing this problem, too :)
+> 
+
+I think it's because dillo doesn't support Image Buttons in forms yet (same
+problem in maps.yahoo.com). There is a bugtrack entry for that. If you don't
+feel like implemnting this feature, you could use an image map (server side)
+in your page instead.
+
+> The second problem, which I'm sure is a common one, is that 
+> &nbsp tags are 
+> displayed- which makes pages look a bit wrong :) But that's of minor 
+> importance.
+> 
+
+IMHO the correct syntax for entities is like this: &nbsp;
+Dillo is actually right when displaying &nbsp if the semicolon is missing.
+
+> Many thanks for any help offered.
+> 
+> --Gus
+> 
+> 
+> 
+> _______________________________________________________________
+> 
+> Don't miss the 2002 Sprint PCS Application Developer's Conference
+> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
+> 
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]The PNG that would not load
+
+From: Hurwitz Justin W. <hurwitz@la...> - 2002-05-28 22:29
+
+First off, to those who make dillo possible- great work with it! I've been 
+wonderfully impressed. It's a bloody shame more programers aren't as 
+intentional with how they program as you all are. Your work should help to 
+remind us all that programming is an art.
+
+Now, on to my problem. I'm working on an embedded tool to monitor our RLX 
+based clusters (www.rlxtechnologies.com). RLX has a web based 
+management/monitoring solution (Control Tower 2) that works great. I'm 
+running dillo on an iPAQ as part of our monitoring tool. It works great. 
+Bu there are two problems- one aesthetic, and one functional. The 
+functional one it the more important:
+
+Load the following URL in both Netscape and dillo:
+http://rack1.rlxtechnologies.com/cm/chassview.php?ShowChassisID=1&p=0|1|2
+
+In Netscape there is a big PNG picture at the top-center of the page. It 
+is generated by chasis.php. Dillo does not display it. This makes me very 
+sad. More importantly, it prevents me from being able to "look inside" the 
+chasis (if you click on the image in Netscape, you'll see what I mean- 
+pretty cool, eh? ;)
+
+I've begun looking into why this image does not display in dillo, and
+think I might be making some (very slow) progress. Due to time constraints
+(and possible ailment- I fear I will be spending the next few days sick in
+bed, sigh), I doubt I'll be able to properly fix this problem, if I can
+fix it at all. If anyone has ideas where to start, or what's wrong, I'd
+love to hear them- saving me a few dead-ends would be a great help. Of
+course, if anyone has an immediate patch, I'll gladly let them take the
+glory for fixing this problem, too :)
+
+The second problem, which I'm sure is a common one, is that &nbsp tags are 
+displayed- which makes pages look a bit wrong :) But that's of minor 
+importance.
+
+Many thanks for any help offered.
+
+--Gus 
+
+
+
+Re: [Dillo-dev]Fix for standard file locking in cookies.c
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2002-05-28 17:24
+
+On Mon, May 27, 2002 at 05:08:27PM -0400, Jorge Arellano Cid wrote:
+> Yes, it is already on CVS, so please test it (specially on non
+> Linux platforms).
+> 
+> - Build the latest CVS :)
+> - Close every open dillo.
+> - Start dillo (it should not disable cookies)
+> - Start another dillo (NOT a new window), it should
+> disable cookies.
+> - Report success!
+
+Success on FreeBSD 4.6-RC.
+
+Regards,
+Johannes 
+
+
+
+Re: Re: [Dillo-dev]new pref: auto-scaling images
+
+From: Paul Chamberlain <tif@ti...> - 2002-05-28 16:04
+
+Ross J. Reedstrom wrote:
+> On Tue, May 28, 2002 at 07:55:52AM -0500, Paul Chamberlain wrote:
+> > From: Jorge Arellano Cid <jcid@em...>
+> > > The idea of having an image_factor in dillorc (as [well as]
+> > > font_factor) seems also a good one.
+> > How difficult would it be to make these run-time options?
+> ... that's a small matter of user interface, not a design problem:
+> if you change the prefs.font_factor value on a running image (with gdb,
+> for example) and reload the page, everything 'just works'.
+
+Excellent, that's exacty what I was after.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: Re: [Dillo-dev]new pref: auto-scaling images
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-05-28 15:14
+
+On Tue, May 28, 2002 at 07:55:52AM -0500, Paul Chamberlain wrote:
+> From: Jorge Arellano Cid <jcid@em...>
+> > The idea of having an image_factor in dillorc (as [well as]
+> > font_factor) seems also a good one.
+> 
+> How difficult would it be to make these run-time options?
+> 
+> I'll admit that it seems out of balance to have this feature
+> when we lack other more basics, but I've come to like the
+> scaling features in other browsers and wondered if it would
+> be helpful to think about this now.
+
+Depends on what you mean by 'run-time': font_factor (and the
+image_factor I'm looking at implementing) are preferences, set in the
+dillorc. Currently, there is no mechanism to alter them in a running
+image, only by editting dillorc and restarting, but as far as I can
+tell, that's a small matter of user interface, not a design problem:
+if you change the prefs.font_factor value on a running image (with gdb,
+for example) and reload the page, everything 'just works'.
+
+Ross 
+
+
+
+Re: Re: [Dillo-dev]new pref: auto-scaling images
+
+From: Paul Chamberlain <tif@ti...> - 2002-05-28 12:56
+
+From: Jorge Arellano Cid <jcid@em...>
+> The idea of having an image_factor in dillorc (as [well as]
+> font_factor) seems also a good one.
+
+How difficult would it be to make these run-time options?
+
+I'll admit that it seems out of balance to have this feature
+when we lack other more basics, but I've come to like the
+scaling features in other browsers and wondered if it would
+be helpful to think about this now.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]Little bugfix
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-28 01:36
+
+Hi,
+
+On Mon, 27 May 2002, Andreas Schweitzer wrote:
+
+>
+> Speaking of bugfixes : the OpenBSD folks have more cleanups in
+>
+> http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/
+>
+> The files
+> patch-src_IO_http_c
+
+That was already fixed.
+
+> patch-src_dns_c
+
+I don't understand that patch...
+
+> patch-src_dw_style_c
+
+Was almost fully done.
+At least there was a (gpointer) cast to change to GINT_TO_POINTER().
+
+Done!
+
+
+Greets
+Jorge.- 
+
+
+
+Re: [Dillo-dev]new pref: auto-scaling images
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-05-28 00:50
+
+Attachments: percent-images.diff      
+
+On Thu, May 23, 2002 at 08:59:06AM -0300, Livio Baldini Soares wrote:
+> 
+> > BTW, I noticed that percentage sizes on images does not seem to be
+> > supported. HTML 4.01 certainly defines the width and height attributes
+> > generically, saying that percentages are supported for images.
+> > 
+> > http://www.w3.org/TR/html401/struct/objects.html#adef-width-IMG
+> 
+> Hum, this I haven't noticed... if you like, please add support for
+> this! :-)
+> 
+
+Fixed this, at least, while tracing what's happening with image
+sizing. Looks like a cut-n-paste-o: There was a stanza about width,
+then one about height, except it was still testing the type of width,
+rather than height. Patch attached. (What's the patch etiquette for
+dillo, BTW? Small patches to the list, big ones behind a URL, or what?)
+
+Ross 
+
+
+
+Re: [Dillo-dev]Little bugfix
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-27 21:57
+
+Hi,
+
+On Mon, 27 May 2002, Grigory Bakunov wrote:
+
+> When i make a rpm for dillo i see little bug in Makefile.am (in doc directory)
+> In short words - not all of docs refered in Makefile.am so
+> 'make dist' doesn't work.
+> Patch attached.
+
+Done!
+
+Cheers
+Jorge.-
+
+
+PS: Please test the latest CVS. 0.6.6 bug-fix release is very close! 
+
+
+
+Re: [Dillo-dev]Fix for standard file locking in cookies.c
+
+From: Livio Baldini Soares <livio@im...> - 2002-05-27 21:30
+
+Hi Jorge!
+
+Jorge Arellano Cid writes:
+> 
+> Hi there,
+> 
+
+[...]
+
+> Yes, it is already on CVS, so please test it (specially on non
+> Linux platforms).
+> 
+> How?
+> 
+> - Build the latest CVS :)
+> - Close every open dillo.
+> - Start dillo (it should not disable cookies)
+> - Start another dillo (NOT a new window), it should
+> disable cookies.
+> - Report success!
+
+Success on:
+
+- SunOS jaca 5.7 Generic_106541-04 sun4u sparc
+(the previous CVS code did not work here)
+
+- Linux pipoca 2.4.17-rmap12a #1 Mon Feb 4 11:01:06 BRST 2002 i686 unknown
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Re: have you considered upgrading your SSL patch to 0.6.5?
+
+From: Gombok Arthur <gombok@so...> - 2002-05-27 21:18
+
+Pekka Lampila <medar@ka...> wrote:
+
+> Gombok Arthur <gombok@so...> wrote:
+> > Does anyone except Jonathan got this running?
+> 
+> Works fine for me. Thanks Jonathan. :)
+
+Me too. Thanks a lot.
+
+> ~$ autoconf --version
+> Autoconf version 2.13
+> ~$ automake --version
+> automake (GNU automake) 1.4-p4
+
+Using autoconv 2.52 and automake 1.5
+but needed to update openssl
+
+> My system is i386, Debian unstable.
+
+mine is a whole mess (and unstable too)
+
+> Though I haven't heard from Jorge for a long time, and CVS has been
+> very quiet. Does anybody know what's up?
+
+Sorry no 
+
+> BTW. Has anyone consired making SSL patch using GNUTLS[1]. That would
+> avoid all the grief with OpenSSL's licensing.
+
+How about compiling openssl with no-rc5 and no-ideo?
+Does that still allow https:hombanking (etc...)
+BTW how can i check which ciphers are used?
+
+> It may not (yet) have as long feature list as OpenSSL has, but I think
+> it has all that Dillo needs. And of course, when more projects use
+> GNUTLS it will gain more support and develop faster.
+> [1] http://www.gnu.org/software/gnutls/
+
+Isn't that the point to enable a switchable modular protocol (plugin)
+interface (file: http: https: ftp: res: help: man: ...)
+
+Maybe its possible to render man pages (with links like tkman) or build a simple and fast html-based help-system (using namazu for fulltext-searches and other tools for keyword lookup and predefined topic-pages)
+
+The bad thing about patches is that they require a special base version
+to patch against. 
+
+Greetings
+Gombok 
+
+
+
+Re: [Dillo-dev]Fix for standard file locking in cookies.c
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-27 21:12
+
+Hi there,
+
+On Mon, 27 May 2002, Andreas Schweitzer wrote:
+
+> Hi everybody,
+> a tiny fix for cookies.c. The flock call is not POSIX compliant,
+> but lockf is XPG4.2 compliant. Hence the patch.
+> (My AIX box complaint when compiling the latest CVS version).
+
+Uh!, well, file locks hold a long record of incompatibilities
+and problems... After digging the man page, and Linux kernel docs
+I only hope this one does better! ;-)
+
+Yes, it is already on CVS, so please test it (specially on non
+Linux platforms).
+
+How?
+
+- Build the latest CVS :)
+- Close every open dillo.
+- Start dillo (it should not disable cookies)
+- Start another dillo (NOT a new window), it should
+disable cookies.
+- Report success!
+
+
+That's all folks
+Jorge.- 
+
+
+
+[Dillo-dev]Fix for standard file locking in cookies.c
+
+From: Andreas Schweitzer <andy@ph...> - 2002-05-27 18:20
+
+Attachments: cookies.diff      
+
+Hi everybody,
+a tiny fix for cookies.c. The flock call is not POSIX compliant,
+but lockf is XPG4.2 compliant. Hence the patch.
+(My AIX box complaint when compiling the latest CVS version).
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Little bugfix
+
+From: Grigory Bakunov <black@as...> - 2002-05-27 17:50
+
+Attachments: dillo-0.6.5-makefile.patch      
+
+When i make a rpm for dillo i see little bug in Makefile.am (in doc directory)
+In short words - not all of docs refered in Makefile.am so
+'make dist' doesn't work.
+Patch attached.
+
+........................................................................
+IRC: irc.openproject.net #asplinux Grigory Bakunov 
+EMAIL: black@as... ASPLinux Support Team
+ICQ: 51369901 http://www.asplinux.ru
+-----BEGIN GEEK CODE BLOCK-----
+GCS/MU d-(--) s:- a- C+++>++$ UBLAVSX+++$ P+ L++++$ E++$ W++ N+>- o? K?
+w-- O- M V-(--) PS+ PE+ !Y PGP+>++++ t+ 5++ X+++ R+++ tv+>-- b+++ ?DI D+
+G++ e>++$ h- r++ y+ z++(+++)
+------END GEEK CODE BLOCK------ 
+
+
+
+[Dillo-dev]Another dillo localization patches
+
+From: Grigory Bakunov <black@as...> - 2002-05-27 17:48
+
+Hello all!
+
+I only need to say what i make little page for my patch what
+help to some users with nonlatin1 codepages
+
+http://bobuk.ipost.ru/packages/dillo/index.html
+
+Any comments and ideas wellcome.
+And especialy about my terrible english. :)
+
+Thanks guys. i love this browser and with perseverance wait while
+Dillo can be compiled with GTK2.
+
+........................................................................
+IRC: irc.openproject.net #asplinux Grigory Bakunov 
+EMAIL: black@as... ASPLinux Support Team
+ICQ: 51369901 http://www.asplinux.ru
+-----BEGIN GEEK CODE BLOCK-----
+GCS/MU d-(--) s:- a- C+++>++$ UBLAVSX+++$ P+ L++++$ E++$ W++ N+>- o? K?
+w-- O- M V-(--) PS+ PE+ !Y PGP+>++++ t+ 5++ X+++ R+++ tv+>-- b+++ ?DI D+
+G++ e>++$ h- r++ y+ z++(+++)
+------END GEEK CODE BLOCK------ 
+
+
+
+Re: [Dillo-dev]Re: have you considered upgrading your SSL patch to
+
+From: Geoff Lane <zzassgl@tw...> - 2002-05-27 10:17
+
+> I thought, that it would be nice to make ssl a dpi1 plugin which 
+> handles https: urls. This way extra bloat could be avoided from dillo (SSL 
+> is not a very small thing).
+
+cURL does support SSL so it may be something worth investigating.
+
+People paranoid about security will worry about the unencrypted data path
+between the plugin and dillo. But there's nothing to stop that being
+encrypted using some single key scheme (which after all is what SSL uses
+once the initial key exchange is performed.)
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+Journeys begin with a single step, and a decision to take it. 
+
+
+
+Re: [Dillo-dev]Re: have you considered upgrading your SSL patch to 0.6.5?
+
+From: madis <madis.janson@ma...> - 2002-05-27 09:58
+
+On Sat, 25 May 2002, Pekka Lampila wrote:
+
+> BTW. Has anyone consired making SSL patch using GNUTLS[1]. That would
+> avoid all the grief with OpenSSL's licensing.
+> 
+> It may not (yet) have as long feature list as OpenSSL has, but I think
+> it has all that Dillo needs. And of course, when more projects use
+> GNUTLS it will gain more support and develop faster.
+> 
+> [1] http://www.gnu.org/software/gnutls/
+>
+
+I thought, that it would be nice to make ssl a dpi1 plugin which 
+handles https: urls. This way extra bloat could be avoided from dillo (SSL 
+is not a very small thing).
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]Query about DNS Search
+
+From: Ralph Slooten <ralph@de...> - 2002-05-26 20:13
+
+Sorry for the typo in the Subject ;-) 
+
+On Sun, 26 May 2002, Ralph Slooten wrote:
+
+> Hi there all
+> 
+> It just occured to me, but it looks like when one types in a wrong URL, 
+> and presses enter, followed directly by the correct URL (also followed by 
+> enter), Dillo will first try look to the wrong site, before progressing to 
+> the second site given. Sometimes I have to shut down Dillo and restart it 
+> as this goes quicker.
+> 
+> The first URL could be an existing site which does exist but is very slow 
+> to get a connection with, and the second something like freshmeat.net, 
+> which goes like lightning here.
+> 
+> Is there some way to get Dillo to "drop" what it's busy with and continue 
+> with the latest request? Maybe an idea for future development? ... that is 
+> unless I'm mistaken ;-)
+> 
+> Greetings
+> Ralph
+> 
+> 
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+[Dillo-dev]Query about DNS Serach
+
+From: Ralph Slooten <ralph@de...> - 2002-05-26 20:02
+
+Hi there all
+
+It just occured to me, but it looks like when one types in a wrong URL, 
+and presses enter, followed directly by the correct URL (also followed by 
+enter), Dillo will first try look to the wrong site, before progressing to 
+the second site given. Sometimes I have to shut down Dillo and restart it 
+as this goes quicker.
+
+The first URL could be an existing site which does exist but is very slow 
+to get a connection with, and the second something like freshmeat.net, 
+which goes like lightning here.
+
+Is there some way to get Dillo to "drop" what it's busy with and continue 
+with the latest request? Maybe an idea for future development? ... that is 
+unless I'm mistaken ;-)
+
+Greetings
+Ralph
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+[Dillo-dev] Segfault on image maps (bug 277)
+
+From: Imran Hasnain <iah21@he...> - 2002-05-26 00:33
+
+Anyone help me out? This bug appears to have surfaced again on my new CVS
+build. URLs typed in are fine - as are Favourites. On mouseover dillo
+displays
+
+'http://dillo.so....net/?36848,-1073746304' etc as before so I assume
+this is the same bug?
+
+Running on Darwin 6.0, Xfree 4.2.0. Dillo 0.6.4 is fine, but both 0.6.5 and
+the current CVS code don't work. :-(
+
+Thanks,
+
+Imran
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]gethostbyname
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-25 20:15
+
+Madis,
+
+
+> I read dns.c and found, that gethostbyname is used with pthreads.
+> Is it safe to do so (i thought that gethostbyname is not thread-safe due
+> to static buffers usage)?
+
+AFAIR (it was along time ago when I implemented it), the
+information I had was that libc5 was not reentrant and that
+glibc2 had no problems with MT; that's why the dns code has
+define statements that either enable the libc5 version or glibc2.
+Even more, it can be set to use a single server only.
+
+The final scheme didn't show a single fault when stress-tested
+with over a hundred of simultaneous requests on 4 channels.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]splint / lint
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-25 20:15
+
+Klaus,
+
+
+> Would it be useful to make dillo "lint clean" ? To detect memory leaks and
+> bogus pointers automatically.
+
+Sure!
+
+It's not a religious matter tough! ;)
+
+If lint can point to some weak portions of code, and those are
+fixed, great! If it points to some others that are OK, there's no
+need to "fix" them.
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]new pref: auto-scaling images
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-25 20:14
+
+Ross,
+
+> [...]
+> One feature I've seen in other small-screen browsers that is surprisingly
+> effective in making sites fit is auto-scaling of images by 1:2. "Well,"
+> he says to himself "here's my chance to contribute". So, I pulled
+> the CVS feed, and rebuilt it, and played with it a little (oh,
+> shiny! cookies!) and perused the code for where and how images are
+> built. Hmm, I seem to be lost in a series of nested structs, many with
+> members with names like 'width', 'height', 'ascent', and 'descent'. After
+> poking around a bit, it seems to me that these structures get built,
+> then filled in later via signals and callbacks.
+>
+> Any suggestions on where to dig, and any 'gotchas'? I'm thinking i'll
+> probably need a new boolean in the Dwimage struct, halfsize, or some
+> such, so I can scale all the various sizes properly.
+
+If I were you, I'd start tweaking Html_tag_open_img to send
+custom width and height values, and thus make the inner layers
+think it was a size specified in the HTML page.
+
+The idea of having an image_factor in dillorc (as font_factor)
+seems also a good one.
+
+The third step is to try to find the place where this "fix"
+should go, with a view to make it fit well in the overall design
+and make it a feature. At least, what I suggest here is easy to
+develop!
+
+> BTW, I noticed that percentage sizes on images does not seem to be
+> supported. HTML 4.01 certainly defines the width and height attributes
+> generically, saying that percentages are supported for images.
+>
+> http://www.w3.org/TR/html401/struct/objects.html#adef-width-IMG
+
+Thanks for the tip, worth a bug track entry.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Re: have you considered upgrading your SSL patch to 0.6.5?
+
+From: Pekka Lampila <medar@ka...> - 2002-05-25 14:41
+
+On Sat, 25 May 2002 13:47:58 +0000 (GMT)
+toor the halberdier <cndlizard@ha...> wrote:
+> On Sat, 25 May 2002, Pekka Lampila wrote:
+> > BTW. Has anyone consired making SSL patch using GNUTLS[1]. That would
+> > avoid all the grief with OpenSSL's licensing.
+> >
+> > It may not (yet) have as long feature list as OpenSSL has, but I think
+> > it has all that Dillo needs. And of course, when more projects use
+> > GNUTLS it will gain more support and develop faster.
+> >
+> > [1] http://www.gnu.org/software/gnutls/
+>
+> ok i am a bit slow but what greif is there whith a BSD type licence ...
+> forgive me for not being up on copyright law (it's just too dull) ;)
+> thax
+
+OpenSSL's license is BSD with an advertising clause. GPL doesn't allow
+additional restrictions and that's what advertising clause is.
+
+So if Dillo were to use OpenSSL it either needs to change license or add
+explicit permission to link against OpenSSL. Plus any other libraries
+Dillo links against must also be compatible with OpenSSL's license.
+
+And of course IANAL. You should search debian-legal archives and google
+for more information.
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+Re: [Dillo-dev]Progress halted?
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-05-25 13:26
+
+Hi,
+
+on Thu, 23 May 2002 07:33:02 +0200 (CEST)
+Ralph Slooten <ralph@de...> wrote:
+
+> [...] but it appeard that the CVS from Dillo 
+> had not been updated from May 4. Does this mean that progress has stopped 
+> for the time being?
+
+AFAIK, Jorge is working on the funding of Dillo. There's a link in Dillo's home
+page. So Dillo development is not halted, only delayed a bit. It will continue.
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]Re: have you considered upgrading your SSL patch to 0.6.5?
+
+From: Pekka Lampila <medar@ka...> - 2002-05-25 13:05
+
+On Sat, 25 May 2002 14:23:19 +0100 (Wild Europe Standard Time)
+Gombok Arthur <gombok@so...> wrote:
+
+> Does anyone except Jonathan got this running? automake needs depcomp
+> (which is missing), configure complains about missing (too old and missing
+> -run command), make breaks in IO on ar (no https.o missing)
+> manually compiling says warning: implizit declaration of function: SSL_get_*fd
+> ..
+> After updating missing und depcomp by automake versions all went fine until
+> linking (undefined reference to SSL_get_*fd in https.c)
+
+Works fine for me. Thanks Jonathan. :)
+
+~$ autoconf --version
+Autoconf version 2.13
+~$ automake --version
+automake (GNU automake) 1.4-p4
+
+My system is i386, Debian unstable.
+
+> Does all these patches (expires,fzip,plugin...) find a way into the regular
+> dillo versions?
+
+Very propably, when they have been proven to be good quality and tested
+enough.
+
+Though I haven't heard from Jorge for a long time, and CVS has been very
+quiet. Does anybody know what's up?
+
+
+BTW. Has anyone consired making SSL patch using GNUTLS[1]. That would
+avoid all the grief with OpenSSL's licensing.
+
+It may not (yet) have as long feature list as OpenSSL has, but I think
+it has all that Dillo needs. And of course, when more projects use
+GNUTLS it will gain more support and develop faster.
+
+[1] http://www.gnu.org/software/gnutls/
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+[Dillo-dev]Re: have you considered upgrading your SSL patch to 0.6.5?
+
+From: Gombok Arthur <gombok@so...> - 2002-05-25 12:27
+
+>> when i tried it with 0.6.4 to do my online banking, i wasnt successful 
+>> because i needed cookies.
+
+>I've posted the patch to
+>http://members.verizon.net/~vze2mqqv/dillo-ssl.0.6.5.diff .
+>$ patch -p1 <dillo-ssl.0.6.5.diff
+>$ autoconf
+>$ automake
+>$ configure --enable-ssl
+>$ make
+>$ sudo make install
+
+Does anyone except Jonathan got this running? automake needs depcomp
+(which is missing), configure complains about missing (too old and missing
+-run command), make breaks in IO on ar (no https.o missing)
+manually compiling says warning: implizit declaration of function: SSL_get_*fd
+..
+After updating missing und depcomp by automake versions all went fine until
+linking (undefined reference to SSL_get_*fd in https.c)
+
+Does all these patches (expires,fzip,plugin...) find a way into the regular
+dillo versions?
+
+Greetings
+-ga 
+
+
+
+Re: [Dillo-dev]experimental dillo patches
+
+From: Ralph Slooten <ralph@de...> - 2002-05-25 12:20
+
+Hi there Geoff,
+
+Firstly I would like to say that I tried your patch last night (Ad-Block) 
+and it works great ;-) It's so much faster than going through a 
+banner-blocking proxy. 
+
+On Fri, 24 May 2002, Geoff Lane wrote:
+
+> 
+> While working my way through the dillo sources trying to work out what is
+> going on I've written some experimental code to see if I understand what I
+> see. This has resulted in four patches: support for gzip'ed HTML, an advert
+> buster, expires and pragma header support and an external generic plugin.
+> 
+> This is ALL highly experimental code and you use it at your own risk.
+
+Yeah, got it.. it was sure worth the test, and I do hope the developers of 
+Dillo will consider using your code, or a similiar concept in their code.
+
+The other 2 patches I haven't gotten to yet, but just wanted to give a good 
+review on the one. It's not that straighforward though (yet) with the 
+"rules", but I managed to get it all working, and now I seem to have a much 
+cleaner page =)
+
+> (Anyone else noticed that dillo is getting a lot of good reviews in the
+> Linux news groups lately?)
+
+I have read indeed a few articles on it, and seems all very positive. I 
+just haven't noticed any updates with the CVS in the last month or so. I 
+don't know if development has halted or whatever, but it was making great 
+progress.
+
+Greetings
+Ralph 
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+[Dillo-dev]It works great on RH6.0!
+
+From: Leandro Gil <leagil@ho...> - 2002-05-24 13:03
+
+Attachments: Message as HTML      
+
+I wanted to thank you all for your help, and congratulate you on a =
+job well done.
+This browser is a little gem.
+RedHat 6.0 allowed me to compile Dillo, no update was necesary.
+I'll see if I can learn to use RPM well enough to make an .rpm =
+binary out of my compilation, because I couldn't find an up to date one =
+on the web.
+=20 
+
+
+
+[Dillo-dev]experimental dillo patches
+
+From: Geoff Lane <zzassgl@tw...> - 2002-05-24 12:58
+
+While working my way through the dillo sources trying to work out what is
+going on I've written some experimental code to see if I understand what I
+see. This has resulted in four patches: support for gzip'ed HTML, an advert
+buster, expires and pragma header support and an external generic plugin.
+
+This is ALL highly experimental code and you use it at your own risk.
+
+The external generic plugin does NOT implement dpi1.v4.txt and never will. 
+It's just an experiment. The sample plugin.sh script does nothing but report
+the request URL but can easily be extended to do some real functions.
+
+The patches were all developed seperately and have not been tested against
+each other. Large amounts of debugging information is issued from the
+patches.
+
+The patches can be downloaded from http://twirl.mcc.ac.uk/dillo/
+
+If anybody wants to grab the gzip'ed HTML and advert buster patches and
+develop them into reliable code for inclusion in Dillo please do. There are
+some suggestions for further work on the relevant web pages.
+
+As I said above, experimental code complete with bugs (some of which are
+documented in the source) so take care...
+
+(Anyone else noticed that dillo is getting a lot of good reviews in the
+Linux news groups lately?)
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+I'm an absolute, off-the-wall fanatical moderate. 
+
+
+
+Re: [Dillo-dev]Compiling dillo. What do I need?
+
+From: Freya <Freya@ga...> - 2002-05-23 12:21
+
+> > I intend switch
+> > to woody Debian
+> > when I can get my
+> > hands on it.
+> 
+> Smart move, good for you! ;-)
+
+I was thinking that debian would be great in this situation where you
+aren't sure of the dependencies, but of course it's really suited to
+people with fast internet connections who can just apt-get everything
+off the internet. I originally went round someone elses house who helped
+me set it all up and had a cable modem connection. If you don't have to
+pay for the connection time, by the minute I mean, then Debian is in a
+lot of ways the best and easiest distro to use and the one most sutied
+to installing on small machines as you don't have to shovel lots of
+stuff you don't need onto your hard disk.
+
+One tip if you do get hold of Debian, avoid the dselect program, debian
+tries to make you use it ( a really nasty disk shoveling program that is
+horribly difficult to use) but you don't have to, you can just exit and
+ignore it and apt-get everything. I found you can even do this with a
+cd-rom using the apt-cd command, but the apt-cd command is not in the
+base system :( so you have to either get it from the internet with
+apt-get, which throws things slightly askew, or what would be best,
+would be to find a way to get at the apt package of the cd-rom without
+using dselect. (I didn't work out how to do this and just used my modem
+to get the apt package)
+
+On the other hand running debian means I don't have the latest version
+of dillo as it isn't in testing yet. :( Even worse, being on this list
+is making me want the next unreleased version already! It sounds like
+there are lots of people here with all kinds of goodies hidden up their
+sleeves! ;)
+
+love
+
+Freya 
+
+
+
+Re: [Dillo-dev]new pref: auto-scaling images
+
+From: Livio Baldini Soares <livio@im...> - 2002-05-23 11:59
+
+Hello Ross!
+
+Ross J. Reedstrom writes:
+> Hey dillo developers - 
+> Love the browser - I use it on my lipaq (linux/ipaq) for both browsing w/
+> wireless at work, and as a general eBook reader w/ HTML format books. I
+> _really_ love the 'wrap to viewport' pref: it makes a lot of sites
+> readable that would otherwise require a lot of scrolling around.
+
+Thanks, man! We really like to hear how people like Dillo! ;-) I,
+myself, constantly use Dillo as my main desktop browser. I feel really
+amazed how my desktop browser is flexible enough to behave well on a
+handheld.
+
+> One feature I've seen in other small-screen browsers that is surprisingly
+> effective in making sites fit is auto-scaling of images by 1:2. "Well,"
+> he says to himself "here's my chance to contribute". So, I pulled
+> the CVS feed, and rebuilt it, and played with it a little (oh,
+> shiny! cookies!) and perused the code for where and how images are
+> built. Hmm, I seem to be lost in a series of nested structs, many with
+> members with names like 'width', 'height', 'ascent', and 'descent'. After
+> poking around a bit, it seems to me that these structures get built,
+> then filled in later via signals and callbacks.
+
+Yeah, at first Dillo is kind of tricky because of the asynchronous
+handling of events (which is one of the reasons it is fast). But after
+a while you start getting the hang of it!
+
+> Any suggestions on where to dig, and any 'gotchas'? I'm thinking i'll
+> probably need a new boolean in the Dwimage struct, halfsize, or some
+> such, so I can scale all the various sizes properly.
+
+Yeah, that seems about right to me. You should be mainly looking at
+dw_image.c (and possibly image.c). I haven't tried this, so this can
+be wrong, but try starting with a_Image_set_parms() and scale the
+width and height. This will "trick" the DwImage module into thinking
+that the HTML author is resizing the image, so it may be possible to
+avoid introduing changes to DwImage.
+
+In theory, this should work smoothly (in theory! ;-). I currently
+have _no_ time to contribute to Dillo do to real life commitments, but
+if you have any doubts and comments you can send them here to the list
+or to me. I'm not sure, but I think Sebastian has a plan to rework
+Dillo's image internals to make it easier to do correct background
+support (using RGBA, instead of normal RGB), and some other things,
+but I don't know how it is coming out.
+
+> BTW, I noticed that percentage sizes on images does not seem to be
+> supported. HTML 4.01 certainly defines the width and height attributes
+> generically, saying that percentages are supported for images.
+> 
+> http://www.w3.org/TR/html401/struct/objects.html#adef-width-IMG
+
+Hum, this I haven't noticed... if you like, please add support for
+this! :-)
+
+best regards and good luck.
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]Compiling dillo. What do I need?
+
+From: Livio Baldini Soares <livio@im...> - 2002-05-23 11:39
+
+Hi Leandro!
+
+Leandro Gil writes:
+>
+> I'm trying to turn a 486DX4 100MHz with 16MB RAM into a Linux box. I would
+> like to know what version of GCC, libraries and GTK+ do I need to compile and
+> use Dillo. If possible, I would like to use one of the distributions in my
+> possesion: Redhat 5.1, Redhat 6.0 and Redhat 7.2
+
+If I remember correctly, you'll need:
+
+libglib1.2 (runtime and development package)
+libgtk1.2 (runtime and development package)
+libjpeg62 (runtime and development package)
+libpng2 (runtime and development package)
+
+That's about all (I think). If you get a precompiled binary (there
+are some RPMs rolling around the internet), you'll only need the
+runtime stuff.
+
+> I'm sorry if this seems a bit off-topic, but downloading more than 20MB from
+> the net can be an expensive endeavor where I live, and recently I've become
+> aware of the customized GCC versions Redhat uses. 
+
+Well, I've tried Dillo with various GCCs and OSs, and I never got
+any problems there. My guess is that you'll only notice RedHat's
+customized GCC with a few programs which use some low-level compiler
+specific stuff (like the Linux kernel).
+
+> I intend switch to woody
+> Debian when I can get my hands on it.
+
+Smart move, good for you! ;-)
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Re: have you considered upgrading your SSL patch to 0.6.5?
+
+From: Jonathan P Springer <jonathan.springer@ve...> - 2002-05-23 11:30
+
+I've posted the patch to
+http://members.verizon.net/~vze2mqqv/dillo-ssl.0.6.5.diff .
+
+This is not a patch for the faint of heart!
+
+To apply, download to the root of your dillo 0.6.5 directory and
+
+$ patch -p1 <dillo-ssl.0.6.5.diff
+$ autoconf
+$ automake
+$ configure --enable-ssl
+$ make
+$ sudo make install
+
+Regards,
+-js
+
+On Fri, May 17, 2002 at 12:03:00PM -0500, John Utz wrote:
+> Can anybody point me at it? has anybody tried it with 0.6.5?
+> 
+> when i tried it with 0.6.4 to do my online banking, i wasnt successful 
+> because i needed cookies.
+> 
+> now, that i have cookies that work correctly after applying joergen's ? 
+> path fixing patch to cookies, i have attempted to apply your 0.6.4 patch 
+> and it fails alot.
+> 
+> > find . -name \*.rej -exec ls -l {} \;
+> -rw-r--r-- 1 spaz wheel 26186 May 17 09:54 ./src/IO/IO.c.rej
+> -rw-r--r-- 1 spaz wheel 2706 May 17 09:54 ./src/IO/Url.c.rej
+> -rw-r--r-- 1 spaz wheel 3555 May 17 09:55 ./src/IO/about.c.rej
+> -rw-r--r-- 1 spaz wheel 21574 May 17 09:55 ./src/IO/file.c.rej
+> -rw-r--r-- 1 spaz wheel 22410 May 17 09:55 ./src/IO/http.c.rej
+> -rw-r--r-- 1 spaz wheel 15030 May 17 09:55 ./src/cache.c.rej
+> -rw-r--r-- 1 spaz wheel 1666 May 17 10:00 ./src/dillo.c.rej
+> -rw-r--r-- 1 spaz wheel 583 May 17 09:53 ./configure.in.rej
+> -rw-r--r-- 1 spaz wheel 202 May 17 09:55 ./Makefile.am.rej
+> > 
+> 
+> i recognize that i am asking for a favor, and if you arent interested in
+> doing it ( i noted on the 0.6.4 patch mail that you offered to fix it for
+> the next release) plz let me know.
+> 
+> tnx!
+> 
+> johnu
+> 
+> -- 
+> 
+> John L. Utz III
+> john@ut...
+> 
+> Idiocy is the Impulse Function in the Convolution of Life
+> 
+
+-- 
+-Jonathan P Springer <jonathan.springer@ve...>
+------------------------------------------------------------------------------
+"A standard is an arbitrary solution to a recurring problem." - Joe Hazen 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Livio Baldini Soares <livio@im...> - 2002-05-23 11:28
+
+Hello Lawrence!
+
+Lawrence.Mayer@ds... writes:
+> Hi,
+> 
+> Can Dillo-0.6.5 compile and run with GTK+-2.0, or does it need GTK+-1.2 ?
+
+Currently Dillo works only with GTK+-1.2.
+
+> If Dillo needs GTK+-1.2, are there any plans to make a GTK+-2.0 version? If
+> so, any idea when it might become available?
+
+There have been a few individual tries to port Dillo do GTK+-2.0, as
+as far as I know, none of which have succeed completely. I think the
+main Dillo developers are not currently very motivated to do this
+port, at least while GTK+-2.0 isn't available on most mainstream
+stable distributions.
+
+This doesn't mean (of course!) that other developers (like you! ;-)
+shouldn't try the port if they like, and send in their results.
+
+So, sorry, we have no near future prediction to when this port will
+be ready. 
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Progress halted?
+
+From: Ralph Slooten <ralph@de...> - 2002-05-23 05:33
+
+Hi there all,
+
+Sorry if this is a dumb quaetion, but it appeard that the CVS from Dillo 
+had not been updated from May 4. Does this mean that progress has stopped 
+for the time being?
+
+Greetings
+Ralph
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+[Dillo-dev]Sorry
+
+From: Freya <Freya@he...> - 2002-05-22 21:17
+
+Sorry I sent those mails twice, I didn't think they would make it through, and didn't hit the cancel button in time. I wonder why I only ever remember after I have just hit the send button. *sigh*
+
+Anyway apologies to everyone and especially to those on low bandwidth connections. I really do sympathise as I was at 9600 baud till recently!
+
+love
+
+Freya
+
+P.S. Arrrrgh nearly did it again! :) 
+
+
+
+[Dillo-dev]Dillo and sylpheed
+
+From: Freya <Freya@he...> - 2002-05-22 21:14
+
+I meant to also say in my last posting that I couldn't see the details for the user mailing list anywhere, perhaps it hasn't been set up yet as these early versions are for developers.
+
+Anyway I wondered if you had seen this:
+
+http://melvin.hadasht.free.fr/home/dillo/sylpheed/
+
+Looks preety amazing, there was a whole thread on the sylpheed list recently from someone saying they should put a whole webbrowser into slypheed *sigh* Suffice to say a lot of people weren't keen on the idea, but this is a great way of doing that without all the nastyness and code bloat. 
+
+I really think the dillo side of this code should be intergrated into the next version of dillo because it could just have soooooo many uses! :)
+
+Perhaps you already know about it, it was the first I heard of it tho, after I started ranting about how great dillo was on the sylpheed list!
+
+Anyway I thik you should all take a peek! :)
+
+love
+
+Freya 
+
+
+
+[Dillo-dev]Dillo and sylpheed
+
+From: Freya <Freya@ga...> - 2002-05-22 21:13
+
+I meant to also say in my last posting that I couldn't see the details for the user mailing list anywhere, perhaps it hasn't been set up yet as these early versions are for developers.
+
+Anyway I wondered if you had seen this:
+
+http://melvin.hadasht.free.fr/home/dillo/sylpheed/
+
+Looks preety amazing, there was a whole thread on the sylpheed list recently from someone saying they should put a whole webbrowser into slypheed *sigh* Suffice to say a lot of people weren't keen on the idea, but this is a great way of doing that without all the nastyness and code bloat. 
+
+I really think the dillo side of this code should be intergrated into the next version of dillo because it could just have soooooo many uses! :)
+
+Perhaps you already know about it, it was the first I heard of it tho, after I started ranting about how great dillo was on the sylpheed list!
+
+Anyway I thik you should all take a peek! :)
+
+love
+
+Freya 
+
+
+
+[Dillo-dev]Dillo in 8mb
+
+From: Freya <Freya@he...> - 2002-05-22 21:07
+
+Hiya!
+I've managed to get my 8mb laptop that I rescued from a skip (currently held together with pollyfilla and pink nail varnish) to run X-windows and I've been really impressed at how well it all works, having been warned loads of times in the past that the minimum spec for running x-windows is 16mb of ram. It really struggles with some things, but dillo is not one of them. Dillo is still faster than opera even on my p200 mmx which sadly I'm having to use as a router at the moment (yes I know it's kind of the wrong way round but I need usb ports for the adsl modem :( ) anyway Dillo takes about half the time to start of opera on the P200, so it's not really fast (the computer is a 486-25) but it does work and it's great!
+
+BTW dillo on the P200 started instantly, but you probably knew that already! ;)
+
+I've also managed to get Sylpheed working on my 486 which shocked me, this really does take an age to start, probably about as long as opera on the P200, in fact I'm being unfair to say that dillo starts in half the time of opera on the P200, it actually starts quite quickly, which sylpheed doesn't but then the thing is that once Sylpheed has started it just works, the hard disk sits there silently and I type away or get my mail, it all works fine, I guess waiting for Sylpheed is only like having to wait for gnome to boot up (erm on the p200 of course *giggle*). ;) 
+
+Anyway I just thought I would drop a line and say how useful dillo is! There is no other browser that will run on this computer except links. Well there is but they aren't worth running because dillo is so infinitely better! :) I am really missing being able to get at yahoo mail and stuff but at least I can see most sites. Speaking of yahoo mail, I knew it used javascript for the passwords because opera goes on about it, but I thought I would have a look at the source and see if I could find a way to bypass the login javascript. I imagined a couple of lines that read stuff from the form. Wow was I wrong! A whole version of md5 written in javascript! eeeeeek! Has to be seen to be believed!
+
+I keep trying to tell people about Dillo but they just don't seem to believe me, or understand, I say that I'm running a browser on my 8mb laptop and it's great and they helpfully ask if I have tried links. "Yes of course I am running links, but this is a proper graphical broswer and it's really fast..." (actually the new version of links sounds preety incredible with javascript and even some support for X11 and graphics, it will be interesting when it is properly available!) Anyway I try and talk people into running it but they just won't believe me because they have never heard of dillo. Oh well their loss! One day they will hear of dillo again and again I am sure, but it is kind of depressing that there is this sort of herd mentality, that they will only try it if they have heard about it from lots of people. 
+
+Actually even more depressing is the software that people go on about, things like xcdroast and xine that seem really, really awful to me. I found dillo and sylpheed for myself by accident and I am really happy with them.
+
+I notice on the webpage it says that dillo works really well with iceWM. Strangely enough that is what I am running but a lot of people seem to think I should run blackbox or fluxbox. I'm not really keen on their user interfaces, partly because I like maximised full screen windows (which is the only way in 640x480 anyway!) but also because I like the task bar at the bottom of the screen. I could try using fspanel but I get a little worried about it all. Icewm may use a bit more resources but it adds so much to the experience for me that it is worth it! The only thing that really worries me is that someone told me just recently that IceWM leaks memory! This would be really bad on an 8mb computer! lol! I don't suppose any of you know how much truth there is in all that?
+
+
+love
+
+Freya 
+
+
+
+[Dillo-dev]Dillo in 8mb
+
+From: Freya <Freya@ga...> - 2002-05-22 21:06
+
+Hiya!
+I've managed to get my 8mb laptop that I rescued from a skip (currently held together with pollyfilla and pink nail varnish) to run X-windows and I've been really impressed at how well it all works, having been warned loads of times in the past that the minimum spec for running x-windows is 16mb of ram. It really struggles with some things, but dillo is not one of them. Dillo is still faster than opera even on my p200 mmx which sadly I'm having to use as a router at the moment (yes I know it's kind of the wrong way round but I need usb ports for the adsl modem :( ) anyway Dillo takes about half the time to start of opera on the P200, so it's not really fast (the computer is a 486-25) but it does work and it's great!
+
+BTW dillo on the P200 started instantly, but you probably knew that already! ;)
+
+I've also managed to get Sylpheed working on my 486 which shocked me, this really does take an age to start, probably about as long as opera on the P200, in fact I'm being unfair to say that dillo starts in half the time of opera on the P200, it actually starts quite quickly, which sylpheed doesn't but then the thing is that once Sylpheed has started it just works, the hard disk sits there silently and I type away or get my mail, it all works fine, I guess waiting for Sylpheed is only like having to wait for gnome to boot up (erm on the p200 of course *giggle*). ;) 
+
+Anyway I just thought I would drop a line and say how useful dillo is! There is no other browser that will run on this computer except links. Well there is but they aren't worth running because dillo is so infinitely better! :) I am really missing being able to get at yahoo mail and stuff but at least I can see most sites. Speaking of yahoo mail, I knew it used javascript for the passwords because opera goes on about it, but I thought I would have a look at the source and see if I could find a way to bypass the login javascript. I imagined a couple of lines that read stuff from the form. Wow was I wrong! A whole version of md5 written in javascript! eeeeeek! Has to be seen to be believed!
+
+I keep trying to tell people about Dillo but they just don't seem to believe me, or understand, I say that I'm running a browser on my 8mb laptop and it's great and they helpfully ask if I have tried links. "Yes of course I am running links, but this is a proper graphical broswer and it's really fast..." (actually the new version of links sounds preety incredible with javascript and even some support for X11 and graphics, it will be interesting when it is properly available!) Anyway I try and talk people into running it but they just won't believe me because they have never heard of dillo. Oh well their loss! One day they will hear of dillo again and again I am sure, but it is kind of depressing that there is this sort of herd mentality, that they will only try it if they have heard about it from lots of people. 
+
+Actually even more depressing is the software that people go on about, things like xcdroast and xine that seem really, really awful to me. I found dillo and sylpheed for myself by accident and I am really happy with them.
+
+I notice on the webpage it says that dillo works really well with iceWM. Strangely enough that is what I am running but a lot of people seem to think I should run blackbox or fluxbox. I'm not really keen on their user interfaces, partly because I like maximised full screen windows (which is the only way in 640x480 anyway!) but also because I like the task bar at the bottom of the screen. I could try using fspanel but I get a little worried about it all. Icewm may use a bit more resources but it adds so much to the experience for me that it is worth it! The only thing that really worries me is that someone told me just recently that IceWM leaks memory! This would be really bad on an 8mb computer! lol! I don't suppose any of you know how much truth there is in all that?
+
+
+love
+
+Freya 
+
+
+
+[Dillo-dev]Compiling dillo. What do I need?
+
+From: Leandro Gil <leagil@ho...> - 2002-05-21 23:50
+
+Attachments: Message as HTML      
+
+I'm trying to turn a 486DX4 100MHz with 16MB RAM into a Linux box. I =
+would like to know what version of GCC, libraries and GTK+ do I need to =
+compile and use Dillo. If possible, I would like to use one of the =
+distributions in my possesion: Redhat 5.1, Redhat 6.0 and Redhat 7.2
+I'm sorry if this seems a bit off-topic, but downloading more than =
+20MB from the net can be an expensive endeavor where I live, and =
+recently I've become aware of the customized GCC versions Redhat uses. I =
+intend switch to woody Debian when I can get my hands on it.
+Thanks in advance. 
+
+
+
+[Dillo-dev]new pref: auto-scaling images
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-05-21 18:32
+
+Hey dillo developers - 
+Love the browser - I use it on my lipaq (linux/ipaq) for both browsing w/
+wireless at work, and as a general eBook reader w/ HTML format books. I
+_really_ love the 'wrap to viewport' pref: it makes a lot of sites
+readable that would otherwise require a lot of scrolling around.
+
+One feature I've seen in other small-screen browsers that is surprisingly
+effective in making sites fit is auto-scaling of images by 1:2. "Well,"
+he says to himself "here's my chance to contribute". So, I pulled
+the CVS feed, and rebuilt it, and played with it a little (oh,
+shiny! cookies!) and perused the code for where and how images are
+built. Hmm, I seem to be lost in a series of nested structs, many with
+members with names like 'width', 'height', 'ascent', and 'descent'. After
+poking around a bit, it seems to me that these structures get built,
+then filled in later via signals and callbacks.
+
+Any suggestions on where to dig, and any 'gotchas'? I'm thinking i'll
+probably need a new boolean in the Dwimage struct, halfsize, or some
+such, so I can scale all the various sizes properly.
+
+BTW, I noticed that percentage sizes on images does not seem to be
+supported. HTML 4.01 certainly defines the width and height attributes
+generically, saying that percentages are supported for images.
+
+http://www.w3.org/TR/html401/struct/objects.html#adef-width-IMG
+
+Ross
+-- 
+Ross Reedstrom, Ph.D. reedstrm@ri...
+Executive Director phone: 713-348-6166
+Gulf Coast Consortium for Bioinformatics fax: 713-348-6182
+Rice University MS-39
+Houston, TX 77005 
+
+
+
+[Dillo-dev]HTTP-Authentification / User Agent / "Clear Cache"-Button
+
+From: Alex Kloss <alex@St...> - 2002-05-21 13:35
+
+Hi, dillo developers!
+
+First, I wanted to say that your browser is really great! Not only being
+fast as hell but too only rendering sane HTML. Only a few necessary
+options are missing.
+
+I don't want to ask about that plugin/ftp stuff. I know that this is
+current development, so keep up the good work in your time.
+
+It only lacks a few features I could use.
+
+1. HTTP/Authentification as in RFC 1945, 10.11/10.16):
+There are several ways to do this. I'd prefer the option to have an
+input widget (within or out of the main window?) opened on the
+"WWW-Authenticate"-challenge asking for username and password, sending
+the reply to the Host.
+This widget could be implemented as plugin or into the browser itself.
+I'd like you to have the choice which way to go there.
+This feature can be especially useful when using the CUPS printer
+driver's web interface (http://localhost:631).
+
+2. The User-Agent in the HTTP/GET request could be changeable in the
+dillorc config file or otherwise. Momentarily, a request looks like:
+
+GET / HTTP/1.0
+Host: localhost
+User-Agent: Dillo/0.6.5
+
+Some pages that asks for MSIE/Netscape/Mozilla or similar could be
+tricked with a changeable user agent. As an option, you could send yet a
+bit less information about your system, too (since dillo seems to be
+at home only on BSD/*nix style systems).
+
+3. Some button or else for "clear cache" can come in handy when you're
+browsing more sites than the cache could put in your ram/swap. ATM, you
+have to quit and restart dillo to keep on browsing. In other situations,
+this can be a fast way to hide the locations you've visited to other
+users when you want to show them something.
+
+Have fun coding!
+
+Alex 
+
+
+
+[Dillo-dev]GTK+-2.0 ?
+
+From: <Lawrence.Mayer@ds...> - 2002-05-18 19:23
+
+Hi,
+
+Can Dillo-0.6.5 compile and run with GTK+-2.0, or does it need GTK+-1.2 ?
+
+If Dillo needs GTK+-1.2, are there any plans to make a GTK+-2.0 version? If
+so, any idea when it might become available?
+
+Lawrence Mayer <lawmay@ki.se>
+Ume=E5, Sweden 
+
+
+
+[Dillo-dev]have you considered upgrading your SSL patch to 0.6.5?
+
+From: John Utz <john@ut...> - 2002-05-17 17:03
+
+Can anybody point me at it? has anybody tried it with 0.6.5?
+
+when i tried it with 0.6.4 to do my online banking, i wasnt successful 
+because i needed cookies.
+
+now, that i have cookies that work correctly after applying joergen's ? 
+path fixing patch to cookies, i have attempted to apply your 0.6.4 patch 
+and it fails alot.
+
+> find . -name \*.rej -exec ls -l {} \;
+-rw-r--r-- 1 spaz wheel 26186 May 17 09:54 ./src/IO/IO.c.rej
+-rw-r--r-- 1 spaz wheel 2706 May 17 09:54 ./src/IO/Url.c.rej
+-rw-r--r-- 1 spaz wheel 3555 May 17 09:55 ./src/IO/about.c.rej
+-rw-r--r-- 1 spaz wheel 21574 May 17 09:55 ./src/IO/file.c.rej
+-rw-r--r-- 1 spaz wheel 22410 May 17 09:55 ./src/IO/http.c.rej
+-rw-r--r-- 1 spaz wheel 15030 May 17 09:55 ./src/cache.c.rej
+-rw-r--r-- 1 spaz wheel 1666 May 17 10:00 ./src/dillo.c.rej
+-rw-r--r-- 1 spaz wheel 583 May 17 09:53 ./configure.in.rej
+-rw-r--r-- 1 spaz wheel 202 May 17 09:55 ./Makefile.am.rej
+> 
+
+i recognize that i am asking for a favor, and if you arent interested in
+doing it ( i noted on the 0.6.4 patch mail that you offered to fix it for
+the next release) plz let me know.
+
+tnx!
+
+johnu
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Meta-refresh patch?
+
+From: madis <madis.janson@ma...> - 2002-05-16 22:30
+
+i've 'ported' one old Jorgen Viksell's meta refresh patch to dillo-0.6.5 
+(or dillo-0.6.6-pre, these two are not very different yet). this works 
+like 'real' meta refresh - waits and loads specified url. refresh loops 
+are not checked (but it thinks that timeout 0 is 300 ms). it is currently 
+together with other modifications i have made to dillo source, which i 
+use, but if there is interest i can extract the meta refresh code into 
+separate patch.
+
+the mixed diff thing is avaible here: 
+http://www.zone.ee/myzz/dillo/dillo-0.6.5-mzz.diff
+(meta refresh modifications are in html.h and html.c)
+
+and comments about it here:
+http://www.zone.ee/myzz/dillo/dillo-0.6.5-mzz.txt
+
+On Mon, 13 May 2002, Andreas Schweitzer wrote:
+
+> On Mon, May 13, 2002 at 12:14:33PM -0500, Patrick Glennon wrote:
+> > Can someone hook me up or point me to either the person who wrote, or
+> > possibly the patch itself for support for Meta-refresh? Ideally, i'd
+> > like to find the person....
+> 
+> Try
+> http://projects.gnome.hu/dillo/
+> 
+> I'm posting this to the list because I was staring at this patch
+> for a while a few weeks back. And I was thinking, maybe dillo could
+> at least insert a link for the refresh URL, like "The web page
+> designer wants you to go to ....". Maybe only for empty pages.
+> But I didn't start code.
+> 
+> Cheers,
+> Andreas
+> 
+> 
+
+-- 
+mzz 
+
+
+
+[Dillo-dev]bug 335, Cookies_create_timestamp
+
+From: madis <madis.janson@ma...> - 2002-05-16 21:57
+
+Attachments: patch-dillo-cookies_timestamp      
+
+patch for fixing this bug
+
+-- 
+mzz 
+
+
+
+[Dillo-dev]Re: validating HTML
+
+From: <s.geerken@pi...> - 2002-05-15 15:36
+
+Attachments: createdtd.pl      
+
+Gombok Arthur wrote:
+> does anyone knows how to validate HTML, (or generated HTML)
+> for *real* browser compatibility? 
+> 
+> it's easy to validate HTML3 HTML32 HTML4 pages, using sgml-tools
+> (like nsgmls from James Clark) with the published DTD's from W3C. 
+> 
+> when writing HTML using a plain Editor (like SciTe) it would
+> be very comfortable to be able to check for compatibility with
+> several browsers (like IE5 IE55 Mozilla Dillo Lynx...). 
+> 
+> so there has to be a spec. (catalog and dtd) to use with nsgmls.
+> i've thought that this is really trivial and would have been done 
+> by all browser manufacturers, but obviously i can only validate
+> by loading the page. this wont list useles tags and attributes... 
+> 
+> can anyone help?
+
+I don't think that browser specific specs make any sense (and, of course,
+elements will degrade gracefully in dillo), but if someone really wants
+to work on this, he may enhance the attached script, which scans the source
+code. Note that many problems are hidden by this dtd, e.g. the limited
+frame support. 
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]validating HTML
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-05-14 21:03
+
+Hi,
+
+on Tue, 14 May 2002 16:15:21 +0100 (Wild Europe Standard Time)
+Gombok Arthur <gombok@so...> wrote:
+
+> No, that's not what i want to do. 
+> I would like to quick offline validate HTML-Pages if they have any tags
+> Dillo would ignore. (And of course i wanna do this on windows too)
+> I would like to check if proprietary ie tags are ~well formed~...
+> I would like to check which constructs will need a workaround if using
+> this browser ore any other
+
+Maybe this can help you a bit:
+
+http://www.willcam.com/cmat/html/crossref.html
+
+it lists the existing tags and what browser/hmtl version supports them.
+
+(Netscape and IE. It's maybe old, too).
+
+Cheers
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]validating HTML
+
+From: Gombok Arthur <gombok@so...> - 2002-05-14 14:19
+
+Gombok Arthur wrote:
+>> does anyone knows how to validate HTML, (or generated HTML)
+>> for *real* browser compatibility?
+>> 
+<snip />
+>> 
+>> so there has to be a spec. (catalog and dtd) to use with nsgmls.
+>> i've thought that this is really trivial and would have been done 
+>> by all browser manufacturers, 
+>
+>You wish:)
+
+Yes i do!
+
+>Unfortunately, browser combatibility is very rarely well defined. There's
+>a slight chance that Mozilla has an actual definition, as they're heavily
+>XML based, but other than that, it's all in the implementation. The best
+>choice IMO is to validate with the W3C DTDs and blame the browsers when
+>they fail to display it correctly.
+
+No, that's not what i want to do. 
+I would like to quick offline validate HTML-Pages if they have any tags
+Dillo would ignore. (And of course i wanna do this on windows too)
+I would like to check if proprietary ie tags are ~well formed~...
+I would like to check which constructs will need a workaround if using
+this browser ore any other
+
+>-Lars
+
+Thx for your response,
+Gombok 
+
+
+
+[Dillo-dev]Splash screen
+
+From: Courtney Grimland <cgrimland@ya...> - 2002-05-14 03:59
+
+Is it currently possible to not bring up the splash screen and go directly to my homepage when opening dillo?
+
+Is there a reason that this is not an option?
+
+-- 
+Brought to you by the letters G, N, and U.
+And now, a word from our sponsor... 
+
+
+
+[Dillo-dev]alt title text
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-05-13 19:41
+
+I've fotgotten, how does one access the title text, or indeed fire an on 
+mouseover event using a touch screen?
+
+thanks
+
+jonathan 
+
+
+
+Re: [Dillo-dev]validating HTML
+
+From: Lars Clausen <lrclause@cs...> - 2002-05-13 17:44
+
+On Mon, 13 May 2002, Gombok Arthur wrote:
+> Hi,
+>=20
+> does anyone knows how to validate HTML, (or generated HTML)
+> for *real* browser compatibility?
+>=20
+> it's easy to validate HTML3 HTML32 HTML4 pages, using sgml-tools
+> (like nsgmls from James Clark) with the published DTD's from W3C.
+>=20
+> when writing HTML using a plain Editor (like SciTe) it would
+> be very comfortable to be able to check for compatibility with
+> several browsers (like IE5 IE55 Mozilla Dillo Lynx...).
+>=20
+> so there has to be a spec. (catalog and dtd) to use with nsgmls.
+> i've thought that this is really trivial and would have been done=20
+> by all browser manufacturers,=20
+
+You wish:)
+
+> but obviously i can only validate
+> by loading the page. this wont list useles tags and attributes...
+
+Unfortunately, browser combatibility is very rarely well defined. There's
+a slight chance that Mozilla has an actual definition, as they're heavily
+XML based, but other than that, it's all in the implementation. The best
+choice IMO is to validate with the W3C DTDs and blame the browsers when
+they fail to display it correctly.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Meta-refresh patch?
+
+From: Andreas Schweitzer <andy@ph...> - 2002-05-13 17:26
+
+On Mon, May 13, 2002 at 12:14:33PM -0500, Patrick Glennon wrote:
+> Can someone hook me up or point me to either the person who wrote, or
+> possibly the patch itself for support for Meta-refresh? Ideally, i'd
+> like to find the person....
+
+Try
+http://projects.gnome.hu/dillo/
+
+I'm posting this to the list because I was staring at this patch
+for a while a few weeks back. And I was thinking, maybe dillo could
+at least insert a link for the refresh URL, like "The web page
+designer wants you to go to ....". Maybe only for empty pages.
+But I didn't start code.
+
+Cheers,
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Meta-refresh patch?
+
+From: Patrick Glennon <pglennon@me...> - 2002-05-13 17:17
+
+Attachments: Message as HTML      
+
+Can someone hook me up or point me to either the person who wrote, or
+possibly the patch itself for support for Meta-refresh? Ideally, i'd
+like to find the person....
+
+Cheers,
+Patrick 
+
+
+
+Re: [Dillo-dev]validating HTML
+
+From: Ralph Slooten <ralph@de...> - 2002-05-13 14:55
+
+Yes, http://validator.w3.org/
+
+On Mon, 13 May 2002, Gombok Arthur wrote:
+
+> Hi,
+> 
+> does anyone knows how to validate HTML, (or generated HTML)
+> for *real* browser compatibility?
+> 
+> it's easy to validate HTML3 HTML32 HTML4 pages, using sgml-tools
+> (like nsgmls from James Clark) with the published DTD's from W3C.
+> 
+> when writing HTML using a plain Editor (like SciTe) it would
+> be very comfortable to be able to check for compatibility with
+> several browsers (like IE5 IE55 Mozilla Dillo Lynx...).
+> 
+> so there has to be a spec. (catalog and dtd) to use with nsgmls.
+> i've thought that this is really trivial and would have been done 
+> by all browser manufacturers, but obviously i can only validate
+> by loading the page. this wont list useles tags and attributes...
+> 
+> can anyone help?
+> 
+> thx
+> 
+> 
+> 
+> _______________________________________________________________
+> 
+> Have big pipes? SourceForge.net is looking for download mirrors. We supply
+> the hardware. You get the recognition. Email Us: bandwidth@so...
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+[Dillo-dev]validating HTML
+
+From: Gombok Arthur <gombok@so...> - 2002-05-13 13:41
+
+Hi,
+
+does anyone knows how to validate HTML, (or generated HTML)
+for *real* browser compatibility?
+
+it's easy to validate HTML3 HTML32 HTML4 pages, using sgml-tools
+(like nsgmls from James Clark) with the published DTD's from W3C.
+
+when writing HTML using a plain Editor (like SciTe) it would
+be very comfortable to be able to check for compatibility with
+several browsers (like IE5 IE55 Mozilla Dillo Lynx...).
+
+so there has to be a spec. (catalog and dtd) to use with nsgmls.
+i've thought that this is really trivial and would have been done 
+by all browser manufacturers, but obviously i can only validate
+by loading the page. this wont list useles tags and attributes...
+
+can anyone help?
+
+thx 
+
+
+
+[Dillo-dev]Compatibility addition
+
+From: Brian Dushaw <dushaw@ap...> - 2002-05-12 00:08
+
+Noting that the Dillo website asks for input on machines that
+run Dillo, I write to note that Dillo works on Psions that run 
+linux (http://linux-7110.so....net/) Specifically:
+
+Machine: Psion 5MX/5MXPro
+CPU: 32bit ARM 710T (37MHz)
+OS: Debian ARM linux
+
+(The Debian *deb packages do not yet have 0.6.5 for ARM, so we
+use 0.6.4 for now)
+
+Thanks for the fine browser!
+B.D.
+
+(I presume this is the right place to post this...) 
+
+
+
+Re: [Dillo-dev]keyboard shortcuts
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-05-09 05:54
+
+Thanks for that, as the keyboard is yet to work, I'll get back some time 
+soon.
+
+jonathan 
+
+
+
+Re: [Dillo-dev]keyboard shortcuts
+
+From: Imad <magius@pu...> - 2002-05-09 02:51
+
+On Wed, 8 May 2002, jonathan chetwynd wrote:
+
+> Does dillo allow keyboard access as well as pen/mouse?
+> if so is there a help file around eg
+>
+> backspace revisit previous page
+> ctrl-s save
+> ctrl-o open uri
+> ctrl-r refresh page
+> ...... .....
+>
+> or somesuch....
+
+Yes. There are a number of built-in shortcuts, and you can define more
+either in-session (as with most GTK+ apps) or by editing "menu.c"
+before compiling.
+
+
+-- 
+Best,
+Imad Hussain
++========== GBAfan Editor in Chief == http://www.gbafan.net ==========+
++===== OpenBSD. Functional. Secure. Free. http://www.openbsd.org =====+ 
+
+
+
+[Dillo-dev]keyboard shortcuts
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-05-08 20:24
+
+Does dillo allow keyboard access as well as pen/mouse?
+if so is there a help file around eg
+
+backspace revisit previous page 
+ctrl-s save
+ctrl-o open uri
+ctrl-r refresh page
+...... .....
+
+or somesuch....
+
+
+hope to have a keyboard working on the ipaq soon
+
+thanks
+jonathan 
+
+
+
+[Dillo-dev]splint / lint
+
+From: Klaus <Klaus.Bruessel@ep...> - 2002-05-08 10:00
+
+Would it be useful to make dillo "lint clean" ? To detect memory leaks and 
+bogus pointers automatically.
+Klaus 
+
+
+
+[Dillo-dev]gethostbyname
+
+From: madis <madis.janson@ma...> - 2002-05-07 19:01
+
+I read dns.c and found, that gethostbyname is used with pthreads.
+Is it safe to do so (i thought that gethostbyname is not thread-safe due 
+to static buffers usage)?
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 -- Compiling under Slackware 8.0
+
+From: Gil Andre <gandre@ar...> - 2002-05-06 09:31
+
+Stephen/Andreas:
+
+(First of all, thanks a lot for answering my message!)
+
+On Sat, 4 May 2002 15:36:41 +1200, Stephen wrote:
+> I'm running dillo on Slackware 8 - the best solution I've found is to
+> add /opt/gnome/bin to your PATH - this will let you run other gnome
+> apps from the command prompt too :)
+
+Well, here is where the plot thickens... =)
+
+This is the output of a "PATH" command:
+
+bash-2.05$ echo $PATH
+/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:.:/opt/gnome/bin:/usr/openwin/bin
+
+This is confirmed when I type, for instance:
+
+bash-2.05$ which gnumeric
+/opt/gnome/bin/gnumeric
+
+bash-2.05$ which gtk-config
+/opt/gnome/bin/gtk-config
+
+So far, so good... But how come I get error messages during the
+compilation of Dillo if the system path is OK?
+
+Anyway, I'll try setting up GTK_CONFIG like Andreas pointed out
+and I'll get back to you.
+
+Thanks again!
+
+-- 
+
+Gil Andre gandre@ar...
+Technical Writer
+Arkeia Corp. http://www.arkeia.com 
+
+
+
+[Dillo-dev]RE: Does dillo support proxy settings?
+
+From: Jason Kang <poh_sing@ho...> - 2002-05-05 09:44
+
+<html><div style='background-color:'><DIV>Hi,</DIV>
+<DIV>&nbsp;</DIV>
+<DIV>My network is within a proxy firewall and I need to supply a proxy server and user name and password before I can access the Internet? Does dillo have support for this? </DIV>
+<DIV>&nbsp;</DIV>
+<DIV>Tks,</DIV>
+<DIV>&nbsp;</DIV>
+<DIV>Jason</DIV></div><br clear=all><hr>Send and receive Hotmail on your mobile device: <a href='http://g.msn.com/1HM104901/39'>Click Here</a><br></html> 
+
+
+
+[Dillo-dev]Fwd: Re: small dillo patch
+
+From: Andreas Schweitzer <andy@ph...> - 2002-05-03 15:13
+
+Hi everybody,
+
+After bugging the *BSD folks about the new version
+I got a small patch back :-) I think this patch
+makes sense. Oh - and the calls to uname are standard.
+
+Cheers,
+Andreas
+
+
+----- Forwarded message from Hostmaster BSWS <hostmaster@bs...> -----
+
+Date: Thu, 2 May 2002 16:50:33 +0200
+From: Hostmaster BSWS <hostmaster@bs...>
+To: Couderc Damien <couderc@op...>,
+Andreas Schweitzer <andy@ph...>
+Subject: Re: small dillo patch
+In-Reply-To: <20020502144646.56450329.couderc@op...>; from couderc@op... on Thu, May 02, 2002 at 02:46:46PM +0200
+X-PGP-Key: http://misc.bsws.de/hb/pubkey.asc
+
+Hi Damien, Hi Andreas,
+
+On Thu, May 02, 2002 at 02:46:46PM +0200, Couderc Damien wrote:
+> > thought dillo should include OS info in the UserAgent like every
+> > other Browser does... ;-)
+> [SNIP]
+> > I have no clue wether this stuff is portable, if it is the dillo
+> > programmers should include it IMHO.
+
+[...]
+
+> Well your idea is good, but i think you should submit this upstream to
+> the authors of dillo.
+
+[...]
+
+> I propose you to contact Andreas Schweitzer <andy@ph...> who
+> is an OpenBSD user and an active coder for dillo. Just say that i've
+> recommended you and see with him what he can do for you in the dillo
+> project to include OS info.
+
+so here's the patch. Tested on OpenBSD/sparc only. I have no clue wether
+this is portable.
+I might add that I am quite pleased by dillo ;-)
+
+Greetz
+
+Henning
+
+--- dillo-0.6.4/src/IO/http.c Thu Jan 24 15:00:04 2002
++++ dillo-patched/src/IO/http.c Mon Apr 22 13:28:59 2002
+@@ -23,6 +23,9 @@
+#include <sys/wait.h>
+#include <sys/socket.h> /* for lots of socket stuff */
+#include <netinet/in.h> /* for ntohl and stuff */
++#include <sys/param.h>
++#include <sys/utsname.h>
++#include <sys/sysctl.h>
+
+#include "Url.h"
+#include "IO.h"
+@@ -125,6 +128,7 @@
+GString *s_port = g_string_new(""),
+*query = g_string_new(""),
+*full_path = g_string_new("");
++ struct utsname u;
+
+/* Sending the default port in the query may cause a 302-answer. --Jcid */
+if (URL_PORT(url) && URL_PORT(url) != DILLO_URL_HTTP_PORT)
+@@ -143,18 +147,20 @@
+URL_QUERY(url) ? URL_QUERY(url) : "",
+(URL_PATH(url) || URL_QUERY(url)) ? "" : "/");
+}
++ 
++ uname(&u);
+
+if ( URL_FLAGS(url) & URL_Post ){
+g_string_sprintfa(
+query,
+"POST %s HTTP/1.0\r\n"
+"Host: %s%s\r\n"
+- "User-Agent: Dillo/%s\r\n"
++ "User-Agent: Dillo/%s; %s/%s %s\r\n"
+"Content-type: application/x-www-form-urlencoded\r\n"
+"Content-length: %ld\r\n"
+"\r\n"
+"%s",
+- full_path->str, URL_HOST(url), s_port->str, VERSION,
++ full_path->str, URL_HOST(url), s_port->str, VERSION, u.sysname, u.machine, u.release,
+(glong)strlen(URL_DATA(url)), URL_DATA(url));
+
+} else {
+@@ -163,12 +169,12 @@
+"GET %s HTTP/1.0\r\n"
+"%s"
+"Host: %s%s\r\n"
+- "User-Agent: Dillo/%s\r\n"
++ "User-Agent: Dillo/%s; %s/%s %s\r\n"
+"\r\n",
+full_path->str,
+(URL_FLAGS(url) & URL_E2EReload) ?
+"Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+- URL_HOST(url), s_port->str, VERSION);
++ URL_HOST(url), s_port->str, VERSION, u.sysname, u.machine, u.release);
+}
+
+str = query->str;
+
+
+-- 
+| Henning Brauer | PGP-Key: http://misc.bsws.de/hb/pubkey.asc 
+| BS Web Services | Roedingsmarkt 14, 20459 Hamburg, DE | http://bsws.de
+Unix is very simple, but it takes a genius to understand the simplicity.
+(Dennis Ritchie)
+
+
+
+----- End forwarded message -----
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Dillo 0.6.5 -- Compiling under Slackware 8.0
+
+From: Gil Andre <gandre@ar...> - 2002-05-03 14:59
+
+Hello, everyone.
+
+I have been running Dillo 0.6.4 for several weeks now, and
+I really like it. Configured it to open the Gnome help files
+by default, which a much, much better solution than using
+Mozilla or Galeon.
+
+I downloaded 0.6.5 today and attempted to compile it on my
+Linux Slackware 8.0 box, but it repeatedly fails to compile
+and/or configure properly.
+
+Under Slackware 8.0, Gnome is installed in "/opt/gnome" by
+default. the file gtk-config is in "/opt/gnome/bin" and the
+"gtk.h" file is in "/opt/gnome/include/gtk-1.2/gtk/"
+
+Dillo 0.6.5 complains it cannot find gtk-config and gtk.h,
+even if "configure" is launched with:
+
+./configure
+--with-gtk-prefix=/opt/gnome
+--with-gtk-exec-prefix=/opt/gnome/bin
+
+I also tried setting GTK_CONFIG to "/opt/gnome" and 
+"/opt/gnome/bin", but this did not work either.
+
+Here are the errors returned by "configure":
+
+_____
+
+which: no gtk-config in (/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin)
+which: no gtk12-config in (/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin)
+checking for gtk-config... no
+checking for GTK - version >= 1.2.0... no
+*** The gtk-config script installed by GTK could not be found
+*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
+*** your path, or set the GTK_CONFIG environment variable to the
+*** full path to gtk-config.
+configure: WARNING: Unable to find Gtk+ with a version >= 1.2.0
+
+_____
+
+Please note that these errors are obtained even if paths have
+been given to "configure" on the command line, which makes it
+very confusing... 
+
+Is there anyone with Slackware experience that could offer tips
+or pointers on how to compile Dillo on a Slackware workstation?
+
+Any and all help is greatly appreciated!
+
+Final question: does Dillo 0.6.5 uses the same icons as v0.6.4?
+If yes, could I offer some (good-looking!) icons to replace the
+default ones?
+
+Many thanks in advance...
+
+-- 
+
+Gil Andre gandre@ar...
+Technical Writer
+Arkeia Corp. http://www.arkeia.com 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: CRX Driver <crxssi@ho...> - 2002-05-03 13:21
+
+I applied the patch successfully, and it appears I can get much further now 
+than before with the WebCalendar; but there are still problems with 
+authentication on other sections of the calendar. Doesn't seem to save the 
+cookies on exit now, but I am not sure.... I am off today, so I can only 
+test it a little bit. Will try more tests on Monday and let you know. 
+Anyone else that wants to test it can do so by going to 
+http://www.math.utexas.edu/users/mzou/webCal/try.html and creating their 
+own calendar; login, then try to create an appointment.
+
+Thank you very much!
+-Mark A. Davis
+
+
+>From: Jorgen Viksell <jorgen.viksell@te...>
+>To: CRX Driver <crxssi@ho...>
+>CC: john@ut..., dillo-dev@li...
+>Subject: Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+>Date: 03 May 2002 07:43:02 +0200
+>
+>tor 2002-05-02 klockan 21.43 skrev CRX Driver:
+> > What I am trying to do is use Dillo with "WebCalendar" (
+> > http://www.math.utexas.edu/webcalendar ) which is a fantastic web-based
+> > scheduling system. I have it loaded on the same host as Dillo, and I 
+>access
+> > it using either localhost/wcal/wcal.pl or
+> > taylor2.laketaylor.org/wcal/wcal.pl
+>
+>There is a problem with the handling of paths. I used g_dirname() to
+>strip of the filename, not knowing it also stripped of the rightmost /.
+> So in this case we compared the cookie's path /wcal/ with /wcal which
+>obviously fails.
+>
+>The attached patch fixes it.
+>
+>Regards,
+>Jörgen
+>
+><< patch-cookies-path >>
+
+
+Try Linux, the free, multitasking, multiuser, multiprocessing,
+multithreading, multivendor, multiplatform, multistandard,
+"multi-everything" operating system!
+
+
+_________________________________________________________________
+Join the world’s largest e-mail service with MSN Hotmail. 
+http://www.hotmail.com 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-05-03 05:39
+
+Attachments: patch-cookies-path      
+
+tor 2002-05-02 klockan 21.43 skrev CRX Driver:
+> OK, I am only PARTIALLY stupid. I saw no cookies, but they WERE written =
+to=20
+> the cookies file AFTER I exited dillo. So they are there, but don't appe=
+ar=20
+> to work. What I am trying to do is use Dillo with "WebCalendar" (=20
+> http://www.math.utexas.edu/webcalendar ) which is a fantastic web-based=20
+> scheduling system. I have it loaded on the same host as Dillo, and I acc=
+ess=20
+> it using either localhost/wcal/wcal.pl or=20
+> taylor2.laketaylor.org/wcal/wcal.pl
+
+There is a problem with the handling of paths. I used g_dirname() to
+strip of the filename, not knowing it also stripped of the rightmost /.
+So in this case we compared the cookie's path /wcal/ with /wcal which
+obviously fails.
+=20
+The attached patch fixes it.
+
+Regards,
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: CRX Driver <crxssi@ho...> - 2002-05-03 02:26
+
+>From: John Utz <john@ut...>
+
+>Ok, tried the webcalandar and it misbehaved as you indicated.
+>i allso tried msn, because i expected that to be a cookie rich area :-)
+>cookies dont seem to be working. i agree.
+>
+>dont really know what to do about it tho...
+
+o o
+>
+___
+/ \
+
+
+
+--
+Try Linux, the free, multitasking, multiuser, multiprocessing,
+multithreading, multivendor, multiplatform, multistandard,
+"multi-everything" operating system!
+
+_________________________________________________________________
+MSN Photos is the easiest way to share and print your photos: 
+http://photos.msn.com/support/worldwide.aspx 
+
+
+
+Re: [Dillo-dev]Tool tips
+
+From: Ben Woolley <ben@ta...> - 2002-05-03 01:10
+
+Hello Jonathan and list,
+
+On Thu, 2 May 2002, jonathan chetwynd wrote:
+
+> can anyone tell me if tooltips (also known as labels, and frequently
+> showing alt or title info) are supported?
+> if so how does one see them?
+>
+> I'm using dillo on an ipaq, with touchscreen.
+
+In my dillorc file I have:
+
+# Show ALT popup for images?
+show_alt=YES
+
+
+
+I don't know about this functionality in Ipaq, though.
+
+I filed a bug report (#302) for not supporting title attributes (BTW, part
+of standard HTML), but I don't know C and therefore can't deal with this
+myself... yet. Title attributes are often very useful, and it seems that
+since alt is supported (at least on my setup), title shouldn't be too far
+behind. I often avoid Dillo for pages that I haven't visited yet, in case
+I miss something marked-up in the title attributes (I can go without
+stylesheets for awhile). Despite that, I started using Dillo for my main
+news site browser, if I don't have Galeon open already.
+
+Ben Woolley
+http://ben.tautology.org
+
+>
+> thanks
+>
+> jonathan
+>
+>
+> _______________________________________________________________
+>
+> Have big pipes? SourceForge.net is looking for download mirrors. We supply
+> the hardware. You get the recognition. Email Us: bandwidth@so...
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: John Utz <john@ut...> - 2002-05-02 20:08
+
+Ok, tried the webcalandar and it misbehaved as you indicated.
+
+i allso tried msn, because i expected that to be a cookie rich area :-)
+
+cookies dont seem to be working. i agree.
+
+dont really know what to do about it tho...
+
+On Thu, 2 May 2002, CRX Driver wrote:
+
+> OK, I am only PARTIALLY stupid. I saw no cookies, but they WERE written to 
+> the cookies file AFTER I exited dillo. So they are there, but don't appear 
+> to work. What I am trying to do is use Dillo with "WebCalendar" ( 
+> http://www.math.utexas.edu/webcalendar ) which is a fantastic web-based 
+> scheduling system. I have it loaded on the same host as Dillo, and I access 
+> it using either localhost/wcal/wcal.pl or 
+> taylor2.laketaylor.org/wcal/wcal.pl
+> 
+> It is local, so you can't access MY calendar server, but you can try the 
+> public one on that website, above. Just go to "try it out" then "create 
+> your own calendar on my demo server". Every time you move from one day to 
+> another on the calendar, it requires you to log in again (it uses cookies to 
+> keep you remembered). Works fine with Netscape and Mozilla but not with 
+> Dillo :(
+> 
+> Here is what my cookies looked like from the local server:
+> 
+> 0 localhost "" /wcal/ 0 2145830400 wcalusername 
+> mark2
+> 0 localhost "" /wcal/ 0 2145830400 wcalpassword 
+> majStH6uHqpfU
+> 0 taylor2.laketaylor.org "" /wcal/ 0 2145830400 
+> wcalusername mark2
+> 0 taylor2.laketaylor.org "" /wcal/ 0 2145830400 
+> wcalpassword majStH6uHqpfU
+> 
+> 
+> >From: John Utz <john@ut...>
+> >To: CRX Driver <crxssi@ho...>
+> >CC: dillo-dev@li...
+> >Subject: Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+> >Date: Thu, 2 May 2002 14:27:22 -0500 (CDT)
+> >
+> >can you supply a site for us to try? that might be helpful..
+> >
+> >On Thu, 2 May 2002, CRX Driver wrote:
+> >
+> > > I have downloaded, compiled and installed 0.6.5 with configure
+> > > --enable-cookies. I suppose it is possible I am doing something 
+> >wrong... It
+> > > does create ~/.dillo/cookies and cookiesrc files, it just never puts
+> > > anything in them. I edited cookiesrc to "DEFAULT=ACCEPT". Still 
+> >nothing.
+> > > I verified the test sites were using cookies by comparing with Mozilla 
+> >and
+> > > examining the cookies myself.
+> > >
+> > > Nobody has posted anything about cookies NOT working in 0.6.5, so I have 
+> >to
+> > > wonder if I am crazy...
+> > >
+> > > Built under Mandrake 8.2. Any assistance or ideas appreciated, 
+> >thanks.
+> > >
+> > > Mark A. Davis
+> > > Director of Information Systems
+> > > Lake Taylor Hospital
+> > > Norfolk VA 23502
+> --
+> Try Linux, the free, multitasking, multiuser, multiprocessing,
+> multithreading, multivendor, multiplatform, multistandard,
+> "multi-everything" operating system!
+> 
+> 
+> _________________________________________________________________
+> Send and receive Hotmail on your mobile device: http://mobile.msn.com
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: CRX Driver <crxssi@ho...> - 2002-05-02 19:44
+
+OK, I am only PARTIALLY stupid. I saw no cookies, but they WERE written to 
+the cookies file AFTER I exited dillo. So they are there, but don't appear 
+to work. What I am trying to do is use Dillo with "WebCalendar" ( 
+http://www.math.utexas.edu/webcalendar ) which is a fantastic web-based 
+scheduling system. I have it loaded on the same host as Dillo, and I access 
+it using either localhost/wcal/wcal.pl or 
+taylor2.laketaylor.org/wcal/wcal.pl
+
+It is local, so you can't access MY calendar server, but you can try the 
+public one on that website, above. Just go to "try it out" then "create 
+your own calendar on my demo server". Every time you move from one day to 
+another on the calendar, it requires you to log in again (it uses cookies to 
+keep you remembered). Works fine with Netscape and Mozilla but not with 
+Dillo :(
+
+Here is what my cookies looked like from the local server:
+
+0 localhost "" /wcal/ 0 2145830400 wcalusername 
+mark2
+0 localhost "" /wcal/ 0 2145830400 wcalpassword 
+majStH6uHqpfU
+0 taylor2.laketaylor.org "" /wcal/ 0 2145830400 
+wcalusername mark2
+0 taylor2.laketaylor.org "" /wcal/ 0 2145830400 
+wcalpassword majStH6uHqpfU
+
+
+>From: John Utz <john@ut...>
+>To: CRX Driver <crxssi@ho...>
+>CC: dillo-dev@li...
+>Subject: Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+>Date: Thu, 2 May 2002 14:27:22 -0500 (CDT)
+>
+>can you supply a site for us to try? that might be helpful..
+>
+>On Thu, 2 May 2002, CRX Driver wrote:
+>
+> > I have downloaded, compiled and installed 0.6.5 with configure
+> > --enable-cookies. I suppose it is possible I am doing something 
+>wrong... It
+> > does create ~/.dillo/cookies and cookiesrc files, it just never puts
+> > anything in them. I edited cookiesrc to "DEFAULT=ACCEPT". Still 
+>nothing.
+> > I verified the test sites were using cookies by comparing with Mozilla 
+>and
+> > examining the cookies myself.
+> >
+> > Nobody has posted anything about cookies NOT working in 0.6.5, so I have 
+>to
+> > wonder if I am crazy...
+> >
+> > Built under Mandrake 8.2. Any assistance or ideas appreciated, 
+>thanks.
+> >
+> > Mark A. Davis
+> > Director of Information Systems
+> > Lake Taylor Hospital
+> > Norfolk VA 23502
+--
+Try Linux, the free, multitasking, multiuser, multiprocessing,
+multithreading, multivendor, multiplatform, multistandard,
+"multi-everything" operating system!
+
+
+_________________________________________________________________
+Send and receive Hotmail on your mobile device: http://mobile.msn.com 
+
+
+
+Re: [Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: John Utz <john@ut...> - 2002-05-02 19:27
+
+can you supply a site for us to try? that might be helpful..
+
+On Thu, 2 May 2002, CRX Driver wrote:
+
+> I have downloaded, compiled and installed 0.6.5 with configure 
+> --enable-cookies. I suppose it is possible I am doing something wrong... It 
+> does create ~/.dillo/cookies and cookiesrc files, it just never puts 
+> anything in them. I edited cookiesrc to "DEFAULT=ACCEPT". Still nothing. 
+> I verified the test sites were using cookies by comparing with Mozilla and 
+> examining the cookies myself.
+> 
+> Nobody has posted anything about cookies NOT working in 0.6.5, so I have to 
+> wonder if I am crazy...
+> 
+> Built under Mandrake 8.2. Any assistance or ideas appreciated, thanks.
+> 
+> Mark A. Davis
+> Director of Information Systems
+> Lake Taylor Hospital
+> Norfolk VA 23502
+> 
+> --
+> Try Linux, the free, multitasking, multiuser, multiprocessing,
+> multithreading, multivendor, multiplatform, multistandard,
+> "multi-everything" operating system!
+> 
+> 
+> _________________________________________________________________
+> Send and receive Hotmail on your mobile device: http://mobile.msn.com
+> 
+> 
+> _______________________________________________________________
+> 
+> Have big pipes? SourceForge.net is looking for download mirrors. We supply
+> the hardware. You get the recognition. Email Us: bandwidth@so...
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]Dillo 0.6.5 Cookies not working
+
+From: CRX Driver <crxssi@ho...> - 2002-05-02 19:17
+
+I have downloaded, compiled and installed 0.6.5 with configure 
+--enable-cookies. I suppose it is possible I am doing something wrong... It 
+does create ~/.dillo/cookies and cookiesrc files, it just never puts 
+anything in them. I edited cookiesrc to "DEFAULT=ACCEPT". Still nothing. 
+I verified the test sites were using cookies by comparing with Mozilla and 
+examining the cookies myself.
+
+Nobody has posted anything about cookies NOT working in 0.6.5, so I have to 
+wonder if I am crazy...
+
+Built under Mandrake 8.2. Any assistance or ideas appreciated, thanks.
+
+Mark A. Davis
+Director of Information Systems
+Lake Taylor Hospital
+Norfolk VA 23502
+
+--
+Try Linux, the free, multitasking, multiuser, multiprocessing,
+multithreading, multivendor, multiplatform, multistandard,
+"multi-everything" operating system!
+
+
+_________________________________________________________________
+Send and receive Hotmail on your mobile device: http://mobile.msn.com 
+
+
+
+[Dillo-dev]Tool tips
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-05-02 14:42
+
+can anyone tell me if tooltips (also known as labels, and frequently 
+showing alt or title info) are supported?
+if so how does one see them?
+
+I'm using dillo on an ipaq, with touchscreen.
+
+thanks
+
+jonathan 
+
+
+
+Re: [Dillo-dev]introduction, plugins and wild ideas
+
+From: Paul Chamberlain <tif@ti...> - 2002-05-02 14:05
+
+Doug Kearns wrote:
+> On Thu, May 02, 2002 at 10:23:05AM +0100, Geoff Lane wrote:
+> > I also hope to provide a generic helper plugin that will allow
+> > quick-and-dirty plugins to be written using shell, perl or other
+> > languages.
+> 
+> Please do, I think this is important.
+
+Me too, but don't forget the security aspects of this.
+I had thought of mimicing CGI by manipulating stdin
+and the environment of locally executed programs. You
+might call it "localcgi:" or "exec:". For security I
+would recommend that only HTML from "exec:" or "file:"
+would be allowed to have these URLs.
+
+And BTW, I would think there would be quite a bit of
+optimizations available for handling one-pixel images.
+Probably the most significant of which is that there's
+guaranteed to be only one color. A scaled one-pixel
+image is equivalent to a simple filled rectangle, etc.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]introduction, plugins and wild ideas
+
+From: Doug Kearns <djkea2@mu...> - 2002-05-02 10:31
+
+On Thu, May 02, 2002 at 10:23:05AM +0100, Geoff Lane wrote:
+
+<snip>
+
+> I also hope to provide a generic helper plugin that will allow
+> quick-and-dirty plugins to be written using shell, perl or other
+> languages.
+
+Please do, I think this is important.
+
+Regards,
+Doug 
+
+
+
+[Dillo-dev]introduction, plugins and wild ideas
+
+From: Geoff Lane <zzassgl@tw...> - 2002-05-02 09:23
+
+Hello, I'm Geoff Lane and I've been asked to try and get the Dillo plugin
+implementation started. In the past I wrote the PNG image support for the
+Armadillo browser (I also wrote code to support a number of other image
+formats which didn't make it into Armadillo.)
+
+My objective is to get an initial implementation of the plugin code, based
+on current ideas (be they good or bad), developed and made available as soon
+as possible. Then everybody can rip it apart and tell me what a lousy
+programmer I am :-) In the process we will get a much better idea of what
+the plugin protocol should actually contain and how it should be
+implemented. I'm a firm believer in the "release early, release often"
+method of open software development.
+
+I hope to be able to show prototype plugins for mailto: and ftp:. I also
+hope to provide a generic helper plugin that will allow quick-and-dirty
+plugins to be written using shell, perl or other languages.
+
+Right now I'm working my way through the existing Dillo sources trying to
+understand the flow of data through the program. I guess it is going to
+take a couple of months before I can discuss the finer points of the IO code
+with confidence and start to write any code that is worth making public.
+
+OK, that's enough about me. Here's some other ideas I've been thinking
+about, one with actual code being developed and one which is just a vague
+design idea.
+
+Advert Buster
+
+The design of Dillo attempts to get a web page from the server onto the
+users screen as fast as possible. Anything that slows down the transfer is
+to be avoided if possible. Adverts tend to be large animated images
+provided by busy servers -- if we can stop these being accessed, Dillo will
+seem even faster and there is the added advantage that the adverts do not
+appear.
+
+With most other browsers, blocking adverts is done by using a small proxy
+program (You can also do tricks with /etc/hosts to block adverts but you
+cannot expect non-experts to do this.) The proxy checks URLs and substitutes
+a local replacement whenever an advert server is detected. If the proxy is
+not as fast as Dillo, the proxy will become a limiting factor when loading
+web pages.
+
+You cannot use a Dillo plugin to filter out adverts because _every_ URL
+would have to be handled by the plugin. This would negate the entire design
+of Dillo.
+
+An effective Advert Buster would have to be internal to Dillo. I already
+have some code that kind of works (at least it doesn't crash Dillo any more)
+for some kinds of advert server. I've got to tidy and port to the latest
+Dillo release then I'll let people know where to get it.
+
+(One thing I have discovered while developing this code is the huge number
+of single pixel GIFs that DoubleClick and others sprinkle about web pages
+for tracking purposes. As each requires a network connection to be
+established to a remote and possibly busy server these single pixel GIFs may
+be a a significant cause of slow page loading.)
+
+Image Plugins
+
+We want plugins so Dillo can remain small. Including specialist code to
+support mailto:, ftp:, news:, pop:, imap: etc leads to bloat and programs
+like Netscape that have runtime code sizes of 30Mbytes and greater. We
+accept the small overhead of running an external program for the less common
+types of URL. Dillo supports only three image formats, GIF, JPG and PNG,
+because these cover the overwhelming majority of images to be found on the
+http://www. But not supporting the less common image formats does mean that Dillo
+cannot be used for some specialist web based services.
+
+Everybody should be aware of NETPBM, Jef Poskanzer's collection of image
+format conversion programs. These allow conversion between a huge number of
+image formats by defining an intermediate image format called ppm - portable
+pixmap. It occurs to me that Dillo could support a vast, extensible,
+collection of image formats by allowing the use of image plugins. When
+Dillo detects an image format it doesn't support, an image plugin is started
+that performs a format conversion on-the-fly and Dillo sees the result in a
+format it can understand. I would also suggest that the Dillo core be
+enhanced to support PPM format images to avoid the need for double
+conversion (the fact I once did PPM support for Armadillo hasn't biased me
+at all...)
+
+Another use for image plugins would be to implement Scalable Vector Graphics
+(SVG -- http://www.w3.org/TR/2001/REC-SVG-20010904/) The vector instructions
+would be interpreted by the plugin and a PPM image generated for display.
+
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+4 food groups: fast, frozen, microwaved, and junk 
+
+
+
+Re: [Dillo-dev]GTK2 port
+
+From: xavier ordoquy <xordoquy@au...> - 2002-05-02 08:46
+
+On Thu, 2002-05-02 at 00:10, Jorgen Viksell wrote:
+> Hi!
+>=20
+> > Hello guys.
+> > I try to port my own applications to GTK2.
+> > It's nice and look stable enough.
+> > May be it's time to port dillo to GTK2?
+>=20
+> Xavier Ordoquy posted about having started this last august. I haven't
+> heard anything about it since.
+> http://www.geocrawler.com/mail/thread.php3?subject=3D%5BDillo-dev%5DGtk%2=
+B+2.0+Port&list=3D702
+>=20
+> I am willing to play with it if Xavier hasn't got time. There are some
+> goodies in GTK2. UTF8, more efficient drawing, etc.
+>=20
+> Cheers,
+> J=F6rgen
+
+Well, since my hard drive crashed loosing my work, I hadn't the
+willpower to redo it.
+I'll try to see if I can recover someting tonight, but I'm afraid it
+won't give much result.
+Anyway, I still can help you. You'll find me either on irc.gnome.org on
+#gnome or irc.openprojects.net on #gael. My nick is MCArkan.
+
+Regards.
+
+--=20
+Xavier Ordoquy
+"Complexity has nothing to do with intelligence.
+Simplicity does."
+(Larry Bossidy, CEO, Allied Signal) 
+
+
+
+[Dillo-dev]RE: GTK2 port
+
+From: Ken Hayber <khayber@so...> - 2002-05-02 01:25
+
+I just got through getting it to compile and link - but it crashes hard. =
+=20
+Lots of GTK/GDK errors. I took the 'I don't really know what I'm doing'=20=
+
+approach and let the compiler show me what needed changing.
+
+Now I'm firing up gdb/ddd to fix all the problems I caused. :-(
+
+Anyway, I'd also be willing to contribute. I'd love to see AA text in=20=
+
+Dillo which was my main reason for attempting this. But this being my=20=
+
+first GTK-anything effort, I'm on the steep part of the learning curve.
+
+
+Ken
+
+
+>Hi!
+>
+>> Hello guys.
+>> I try to port my own applications to GTK2.
+>> It's nice and look stable enough.
+>> May be it's time to port dillo to GTK2?
+>
+>Xavier Ordoquy posted about having started this last august. I haven't
+>heard anything about it since.
+=
+>http://www.geocrawler.com/mail/thread.php3?subject=3D%5BDillo-dev%5DGtk%2=
+B+
+2.0+Port&list=3D702
+>
+>I am willing to play with it if Xavier hasn't got time. There are some
+>goodies in GTK2. UTF8, more efficient drawing, etc.
+>
+>Cheers,
+>J=F6rgen
+
+"this .Sig no verb"
+=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
+-=3D-=3D-=3D-=3D-=3D-=3D-=3D
+Ken Hayber
+mailto:khayber@so...
+http://khayber.dyndns.org 
+
+
+
+Re: [Dillo-dev]GTK2 port
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-05-01 22:06
+
+Hi!
+
+> Hello guys.
+> I try to port my own applications to GTK2.
+> It's nice and look stable enough.
+> May be it's time to port dillo to GTK2?
+
+Xavier Ordoquy posted about having started this last august. I haven't
+heard anything about it since.
+http://www.geocrawler.com/mail/thread.php3?subject=3D%5BDillo-dev%5DGtk%2B+=
+2.0+Port&list=3D702
+
+I am willing to play with it if Xavier hasn't got time. There are some
+goodies in GTK2. UTF8, more efficient drawing, etc.
+
+Cheers,
+J=F6rgen 
+
+
+
+[Dillo-dev]GTK2 port
+
+From: Grigory Bakunov <black@as...> - 2002-05-01 20:48
+
+Hello guys.
+I try to port my own applications to GTK2.
+It's nice and look stable enough.
+May be it's time to port dillo to GTK2? 
+
+
+
+Re: [Dillo-dev]patch for virtual host... games 
+
+From: John Utz <john@ut...> - 2002-05-01 20:08
+
+argh.
+
+i am so sorry vincent! i should have also reminded you that the patches 
+should go directly to jorge.
+
+i think that not sending my patch directly to jorge was the reason that 
+my navigation patch didnt get in..... i think :-)
+
+On Wed, 1 May 2002, Vincent Labrecque wrote:
+
+> 
+> and here's the feature one:
+> 
+> 
+> diff -pru dillo-0.6.4/src/IO/http.c ./IO/http.c
+> --- dillo-0.6.4/src/IO/http.c Thu Jan 24 09:00:04 2002
+> +++ ./IO/http.c Tue Apr 30 20:00:31 2002
+> @@ -154,7 +154,7 @@ static char *Http_query(const DilloUrl *
+> "Content-length: %ld\r\n"
+> "\r\n"
+> "%s",
+> - full_path->str, URL_HOST(url), s_port->str, VERSION,
+> + full_path->str, URL_HHOST(url), s_port->str, VERSION,
+> (glong)strlen(URL_DATA(url)), URL_DATA(url));
+> 
+> } else {
+> @@ -168,7 +168,7 @@ static char *Http_query(const DilloUrl *
+> full_path->str,
+> (URL_FLAGS(url) & URL_E2EReload) ?
+> "Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+> - URL_HOST(url), s_port->str, VERSION);
+> + URL_HHOST(url), s_port->str, VERSION);
+> }
+> 
+> str = query->str;
+> 
+> diff -pru dillo-0.6.4/src/url.c ./url.c
+> --- dillo-0.6.4/src/url.c Thu Jan 24 06:19:58 2002
+> +++ ./url.c Tue Apr 30 20:18:04 2002
+> @@ -57,11 +57,13 @@ gchar *a_Url_str(const DilloUrl *u)
+> if (!url->url_string) {
+> url->url_string = g_string_sized_new(60);
+> g_string_sprintf(
+> - url->url_string, "%s%s%s%s%s%s%s%s%s%s",
+> + url->url_string, "%s%s%s%s%s%s%s%s%s%s%s%s",
+> url->scheme ? url->scheme : "",
+> url->scheme ? ":" : "",
+> url->authority ? "//" : "",
+> url->authority ? url->authority : "",
+> + url->force_hostname ? "$" : "",
+> + url->force_hostname ? url->force_hostname : "",
+> (url->path && url->path[0] != '/' && url->authority) ? "/" : "",
+> url->path ? url->path : "",
+> url->query ? "?" : "",
+> @@ -110,9 +112,9 @@ static DilloUrl *Url_object_new(const gc
+> 
+> /* remove leading & trailing space from buffer */
+> for (p = (gchar *)uri_str; isspace(*p); ++p);
+> - url->buffer = g_strchomp(g_strdup(p));
+> 
+> - s = (gchar *) url->buffer;
+> + s = url->buffer = g_strchomp(g_strdup(p));
+> +
+> p = strpbrk(s, ":/?#");
+> if (p && p[0] == ':' && p > s) { // scheme
+> *p = 0;
+> @@ -122,7 +124,7 @@ static DilloUrl *Url_object_new(const gc
+> // p = strpbrk(s, "/");
+> if (p && p[0] == '/' && p[1] == '/') { // authority
+> s = p + 2;
+> - p = strpbrk(s, "/?#");
+> + p = strpbrk(s, "$/?#");
+> if (p) {
+> memmove(s - 2, s, MAX(p - s, 1));
+> url->authority = s - 2;
+> @@ -133,6 +135,9 @@ static DilloUrl *Url_object_new(const gc
+> return url;
+> }
+> }
+> + p = strpbrk(s, "$");
+> + if (p)
+> + url->force_hostname = p + 1;
+> 
+> p = strpbrk(s, "?#");
+> if (p) { // path
+> @@ -178,6 +183,11 @@ void a_Url_free(DilloUrl *url)
+> 
+> /*
+> * Resolve the URL as RFC2396 suggests.
+> + *
+> + * Additionaly, we allow the IP$hostname syntax that i just invented to
+> + * allow virtual hosts games. (for example, if you know the IP of the
+> + * machine but it, for any reason, does not resolve. If that machines
+> + * uses vhosts you're pretty much screwed)
+> */
+> static GString *Url_resolve_relative(const gchar *RelStr,
+> DilloUrl *BaseUrlPar,
+> 
+> diff -pru dillo-0.6.4/src/url.h ./url.h
+> --- dillo-0.6.4/src/url.h Sun Jan 20 06:51:23 2002
+> +++ ./url.h Tue Apr 30 20:00:04 2002
+> @@ -46,7 +46,8 @@
+> #define URL_PATH(u) u->path
+> #define URL_QUERY(u) u->query
+> #define URL_FRAGMENT(u) u->fragment
+> -#define URL_HOST(u) a_Url_hostname(u)
+> +#define URL_HHOST(u) ((u)->force_hostname)?(u)->force_hostname:a_Url_hostname(u)
+> +#define URL_HOST(u) a_Url_hostname(u)
+> #define URL_PORT(u) (URL_HOST(u) ? u->port : u->port)
+> #define URL_FLAGS(u) u->flags
+> #define URL_DATA(u) u->data
+> @@ -80,6 +81,7 @@ struct _DilloUrl {
+> const gchar *query; // (no need to free them)
+> const gchar *fragment; //
+> const gchar *hostname; //
+> + const gchar *force_hostname;
+> gint port;
+> gint flags;
+> const gchar *data; /* POST */
+> 
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]patch for virtual host... games
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-05-01 18:28
+
+Hi,
+
+On Tue, 30 Apr 2002, Vincent Labrecque wrote:
+
+>
+> Hi, here's a quite small diff.
+>
+> There is a little buffer overflow removal (look for the strncpy part),
+> strncpy is not assured to NUL-terminate the string.
+
+Well, I decided to fix two problems at the same time by making
+a new patch. It's already in CVS and it also removes the < 256
+hostname length restraint from http queries).
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]patch for virtual host... games 
+
+From: Vincent Labrecque <vincent@op...> - 2002-05-01 12:22
+
+and here's the feature one:
+
+
+diff -pru dillo-0.6.4/src/IO/http.c ./IO/http.c
+--- dillo-0.6.4/src/IO/http.c Thu Jan 24 09:00:04 2002
++++ ./IO/http.c Tue Apr 30 20:00:31 2002
+@@ -154,7 +154,7 @@ static char *Http_query(const DilloUrl *
+"Content-length: %ld\r\n"
+"\r\n"
+"%s",
+- full_path->str, URL_HOST(url), s_port->str, VERSION,
++ full_path->str, URL_HHOST(url), s_port->str, VERSION,
+(glong)strlen(URL_DATA(url)), URL_DATA(url));
+
+} else {
+@@ -168,7 +168,7 @@ static char *Http_query(const DilloUrl *
+full_path->str,
+(URL_FLAGS(url) & URL_E2EReload) ?
+"Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+- URL_HOST(url), s_port->str, VERSION);
++ URL_HHOST(url), s_port->str, VERSION);
+}
+
+str = query->str;
+
+diff -pru dillo-0.6.4/src/url.c ./url.c
+--- dillo-0.6.4/src/url.c Thu Jan 24 06:19:58 2002
++++ ./url.c Tue Apr 30 20:18:04 2002
+@@ -57,11 +57,13 @@ gchar *a_Url_str(const DilloUrl *u)
+if (!url->url_string) {
+url->url_string = g_string_sized_new(60);
+g_string_sprintf(
+- url->url_string, "%s%s%s%s%s%s%s%s%s%s",
++ url->url_string, "%s%s%s%s%s%s%s%s%s%s%s%s",
+url->scheme ? url->scheme : "",
+url->scheme ? ":" : "",
+url->authority ? "//" : "",
+url->authority ? url->authority : "",
++ url->force_hostname ? "$" : "",
++ url->force_hostname ? url->force_hostname : "",
+(url->path && url->path[0] != '/' && url->authority) ? "/" : "",
+url->path ? url->path : "",
+url->query ? "?" : "",
+@@ -110,9 +112,9 @@ static DilloUrl *Url_object_new(const gc
+
+/* remove leading & trailing space from buffer */
+for (p = (gchar *)uri_str; isspace(*p); ++p);
+- url->buffer = g_strchomp(g_strdup(p));
+
+- s = (gchar *) url->buffer;
++ s = url->buffer = g_strchomp(g_strdup(p));
++
+p = strpbrk(s, ":/?#");
+if (p && p[0] == ':' && p > s) { // scheme
+*p = 0;
+@@ -122,7 +124,7 @@ static DilloUrl *Url_object_new(const gc
+// p = strpbrk(s, "/");
+if (p && p[0] == '/' && p[1] == '/') { // authority
+s = p + 2;
+- p = strpbrk(s, "/?#");
++ p = strpbrk(s, "$/?#");
+if (p) {
+memmove(s - 2, s, MAX(p - s, 1));
+url->authority = s - 2;
+@@ -133,6 +135,9 @@ static DilloUrl *Url_object_new(const gc
+return url;
+}
+}
++ p = strpbrk(s, "$");
++ if (p)
++ url->force_hostname = p + 1;
+
+p = strpbrk(s, "?#");
+if (p) { // path
+@@ -178,6 +183,11 @@ void a_Url_free(DilloUrl *url)
+
+/*
+* Resolve the URL as RFC2396 suggests.
++ *
++ * Additionaly, we allow the IP$hostname syntax that i just invented to
++ * allow virtual hosts games. (for example, if you know the IP of the
++ * machine but it, for any reason, does not resolve. If that machines
++ * uses vhosts you're pretty much screwed)
+*/
+static GString *Url_resolve_relative(const gchar *RelStr,
+DilloUrl *BaseUrlPar,
+
+diff -pru dillo-0.6.4/src/url.h ./url.h
+--- dillo-0.6.4/src/url.h Sun Jan 20 06:51:23 2002
++++ ./url.h Tue Apr 30 20:00:04 2002
+@@ -46,7 +46,8 @@
+#define URL_PATH(u) u->path
+#define URL_QUERY(u) u->query
+#define URL_FRAGMENT(u) u->fragment
+-#define URL_HOST(u) a_Url_hostname(u)
++#define URL_HHOST(u) ((u)->force_hostname)?(u)->force_hostname:a_Url_hostname(u)
++#define URL_HOST(u) a_Url_hostname(u)
+#define URL_PORT(u) (URL_HOST(u) ? u->port : u->port)
+#define URL_FLAGS(u) u->flags
+#define URL_DATA(u) u->data
+@@ -80,6 +81,7 @@ struct _DilloUrl {
+const gchar *query; // (no need to free them)
+const gchar *fragment; //
+const gchar *hostname; //
++ const gchar *force_hostname;
+gint port;
+gint flags;
+const gchar *data; /* POST */ 
+
+
+
+Re: [Dillo-dev]patch for virtual host... games 
+
+From: Vincent Labrecque <vincent@op...> - 2002-05-01 12:20
+
+> my objection with this would be that it should be submitted as 2 separate 
+> patches..contributing vital security fixes is a worthy and wonderful 
+> thing, payloading it with your own personal favorite treat is kind of 
+> against the grain...
+> 
+> just my us$0.02....
+> 
+> johnu
+
+well, here goes the security diff. (i'll check the source-tree for other
+strn*() API misuse.)
+
+
+diff -pru dillo-0.6.4/src/IO/http.c ./IO/http.c
+--- dillo-0.6.4/src/IO/http.c Thu Jan 24 09:00:04 2002
++++ ./IO/http.c Tue Apr 30 20:00:31 2002
+@@ -334,7 +334,8 @@ static gint Http_get(ChainLink *Info, vo
+
+/* Proxy support */
+if (Http_must_use_proxy(Url)) {
+- strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname));
++ strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname) - 1);
++ hostname[sizeof hostname - 1] = 0;
+S->port = URL_PORT(HTTP_Proxy);
+S->use_proxy = TRUE;
+} else { 
+
+
+
+Re: [Dillo-dev]patch for virtual host... games
+
+From: John Utz <john@ut...> - 2002-05-01 04:21
+
+my objection with this would be that it should be submitted as 2 separate 
+patches..contributing vital security fixes is a worthy and wonderful 
+thing, payloading it with your own personal favorite treat is kind of 
+against the grain...
+
+just my us$0.02....
+
+johnu
+
+On Tue, 30 Apr 2002, Vincent Labrecque wrote:
+
+> 
+> Hi, here's a quite small diff.
+> 
+> There is a little buffer overflow removal (look for the strncpy part),
+> strncpy is not assured to NUL-terminate the string.
+> 
+> And there is the main part, a feature, non RFC compliant change :-)
+> 
+> It adds support for the connectHost$httpHost syntax. That allows me
+> to say what host provides the service, and what virtual host i want. The
+> use of this that spawned the idea is that i know the IP of a machine
+> providing HTTP service, it does not resolve, yet I want to access the
+> vhost.
+> 
+> I find this useful, maybe some others will, too.
+> 
+> Please check the patches carefuly, i don't know the codebase enough to
+> be 100% sure of my changes, even if they seem to work fine.
+> 
+> I'll be happy to reply to comments regarding this feature. (alternative
+> syntax, etc)
+> 
+> - Vincent
+> 
+> diff -pru dillo-0.6.4/src/IO/http.c ./IO/http.c
+> --- dillo-0.6.4/src/IO/http.c Thu Jan 24 09:00:04 2002
+> +++ ./IO/http.c Tue Apr 30 20:00:31 2002
+> @@ -154,7 +154,7 @@ static char *Http_query(const DilloUrl *
+> "Content-length: %ld\r\n"
+> "\r\n"
+> "%s",
+> - full_path->str, URL_HOST(url), s_port->str, VERSION,
+> + full_path->str, URL_HHOST(url), s_port->str, VERSION,
+> (glong)strlen(URL_DATA(url)), URL_DATA(url));
+> 
+> } else {
+> @@ -168,7 +168,7 @@ static char *Http_query(const DilloUrl *
+> full_path->str,
+> (URL_FLAGS(url) & URL_E2EReload) ?
+> "Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+> - URL_HOST(url), s_port->str, VERSION);
+> + URL_HHOST(url), s_port->str, VERSION);
+> }
+> 
+> str = query->str;
+> @@ -334,7 +334,8 @@ static gint Http_get(ChainLink *Info, vo
+> 
+> /* Proxy support */
+> if (Http_must_use_proxy(Url)) {
+> - strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname));
+> + strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname) - 1);
+> + hostname[sizeof hostname - 1] = 0;
+> S->port = URL_PORT(HTTP_Proxy);
+> S->use_proxy = TRUE;
+> } else {
+> 
+> diff -pru dillo-0.6.4/src/url.c ./url.c
+> --- dillo-0.6.4/src/url.c Thu Jan 24 06:19:58 2002
+> +++ ./url.c Tue Apr 30 20:18:04 2002
+> @@ -57,11 +57,13 @@ gchar *a_Url_str(const DilloUrl *u)
+> if (!url->url_string) {
+> url->url_string = g_string_sized_new(60);
+> g_string_sprintf(
+> - url->url_string, "%s%s%s%s%s%s%s%s%s%s",
+> + url->url_string, "%s%s%s%s%s%s%s%s%s%s%s%s",
+> url->scheme ? url->scheme : "",
+> url->scheme ? ":" : "",
+> url->authority ? "//" : "",
+> url->authority ? url->authority : "",
+> + url->force_hostname ? "$" : "",
+> + url->force_hostname ? url->force_hostname : "",
+> (url->path && url->path[0] != '/' && url->authority) ? "/" : "",
+> url->path ? url->path : "",
+> url->query ? "?" : "",
+> @@ -110,9 +112,9 @@ static DilloUrl *Url_object_new(const gc
+> 
+> /* remove leading & trailing space from buffer */
+> for (p = (gchar *)uri_str; isspace(*p); ++p);
+> - url->buffer = g_strchomp(g_strdup(p));
+> 
+> - s = (gchar *) url->buffer;
+> + s = url->buffer = g_strchomp(g_strdup(p));
+> +
+> p = strpbrk(s, ":/?#");
+> if (p && p[0] == ':' && p > s) { // scheme
+> *p = 0;
+> @@ -122,7 +124,7 @@ static DilloUrl *Url_object_new(const gc
+> // p = strpbrk(s, "/");
+> if (p && p[0] == '/' && p[1] == '/') { // authority
+> s = p + 2;
+> - p = strpbrk(s, "/?#");
+> + p = strpbrk(s, "$/?#");
+> if (p) {
+> memmove(s - 2, s, MAX(p - s, 1));
+> url->authority = s - 2;
+> @@ -133,6 +135,9 @@ static DilloUrl *Url_object_new(const gc
+> return url;
+> }
+> }
+> + p = strpbrk(s, "$");
+> + if (p)
+> + url->force_hostname = p + 1;
+> 
+> p = strpbrk(s, "?#");
+> if (p) { // path
+> @@ -178,6 +183,11 @@ void a_Url_free(DilloUrl *url)
+> 
+> /*
+> * Resolve the URL as RFC2396 suggests.
+> + *
+> + * Additionaly, we allow the IP$hostname syntax that i just invented to
+> + * allow virtual hosts games. (for example, if you know the IP of the
+> + * machine but it, for any reason, does not resolve. If that machines
+> + * uses vhosts you're pretty much screwed)
+> */
+> static GString *Url_resolve_relative(const gchar *RelStr,
+> DilloUrl *BaseUrlPar,
+> 
+> diff -pru dillo-0.6.4/src/url.h ./url.h
+> --- dillo-0.6.4/src/url.h Sun Jan 20 06:51:23 2002
+> +++ ./url.h Tue Apr 30 20:00:04 2002
+> @@ -46,7 +46,8 @@
+> #define URL_PATH(u) u->path
+> #define URL_QUERY(u) u->query
+> #define URL_FRAGMENT(u) u->fragment
+> -#define URL_HOST(u) a_Url_hostname(u)
+> +#define URL_HHOST(u) ((u)->force_hostname)?(u)->force_hostname:a_Url_hostname(u)
+> +#define URL_HOST(u) a_Url_hostname(u)
+> #define URL_PORT(u) (URL_HOST(u) ? u->port : u->port)
+> #define URL_FLAGS(u) u->flags
+> #define URL_DATA(u) u->data
+> @@ -80,6 +81,7 @@ struct _DilloUrl {
+> const gchar *query; // (no need to free them)
+> const gchar *fragment; //
+> const gchar *hostname; //
+> + const gchar *force_hostname;
+> gint port;
+> gint flags;
+> const gchar *data; /* POST */
+> Only in .: url.h~
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]patch for virtual host... games
+
+From: Vincent Labrecque <vincent@op...> - 2002-05-01 00:31
+
+Hi, here's a quite small diff.
+
+There is a little buffer overflow removal (look for the strncpy part),
+strncpy is not assured to NUL-terminate the string.
+
+And there is the main part, a feature, non RFC compliant change :-)
+
+It adds support for the connectHost$httpHost syntax. That allows me
+to say what host provides the service, and what virtual host i want. The
+use of this that spawned the idea is that i know the IP of a machine
+providing HTTP service, it does not resolve, yet I want to access the
+vhost.
+
+I find this useful, maybe some others will, too.
+
+Please check the patches carefuly, i don't know the codebase enough to
+be 100% sure of my changes, even if they seem to work fine.
+
+I'll be happy to reply to comments regarding this feature. (alternative
+syntax, etc)
+
+- Vincent
+
+diff -pru dillo-0.6.4/src/IO/http.c ./IO/http.c
+--- dillo-0.6.4/src/IO/http.c Thu Jan 24 09:00:04 2002
++++ ./IO/http.c Tue Apr 30 20:00:31 2002
+@@ -154,7 +154,7 @@ static char *Http_query(const DilloUrl *
+"Content-length: %ld\r\n"
+"\r\n"
+"%s",
+- full_path->str, URL_HOST(url), s_port->str, VERSION,
++ full_path->str, URL_HHOST(url), s_port->str, VERSION,
+(glong)strlen(URL_DATA(url)), URL_DATA(url));
+
+} else {
+@@ -168,7 +168,7 @@ static char *Http_query(const DilloUrl *
+full_path->str,
+(URL_FLAGS(url) & URL_E2EReload) ?
+"Cache-Control: no-cache\r\nPragma: no-cache\r\n" : "",
+- URL_HOST(url), s_port->str, VERSION);
++ URL_HHOST(url), s_port->str, VERSION);
+}
+
+str = query->str;
+@@ -334,7 +334,8 @@ static gint Http_get(ChainLink *Info, vo
+
+/* Proxy support */
+if (Http_must_use_proxy(Url)) {
+- strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname));
++ strncpy(hostname, URL_HOST(HTTP_Proxy), sizeof(hostname) - 1);
++ hostname[sizeof hostname - 1] = 0;
+S->port = URL_PORT(HTTP_Proxy);
+S->use_proxy = TRUE;
+} else {
+
+diff -pru dillo-0.6.4/src/url.c ./url.c
+--- dillo-0.6.4/src/url.c Thu Jan 24 06:19:58 2002
++++ ./url.c Tue Apr 30 20:18:04 2002
+@@ -57,11 +57,13 @@ gchar *a_Url_str(const DilloUrl *u)
+if (!url->url_string) {
+url->url_string = g_string_sized_new(60);
+g_string_sprintf(
+- url->url_string, "%s%s%s%s%s%s%s%s%s%s",
++ url->url_string, "%s%s%s%s%s%s%s%s%s%s%s%s",
+url->scheme ? url->scheme : "",
+url->scheme ? ":" : "",
+url->authority ? "//" : "",
+url->authority ? url->authority : "",
++ url->force_hostname ? "$" : "",
++ url->force_hostname ? url->force_hostname : "",
+(url->path && url->path[0] != '/' && url->authority) ? "/" : "",
+url->path ? url->path : "",
+url->query ? "?" : "",
+@@ -110,9 +112,9 @@ static DilloUrl *Url_object_new(const gc
+
+/* remove leading & trailing space from buffer */
+for (p = (gchar *)uri_str; isspace(*p); ++p);
+- url->buffer = g_strchomp(g_strdup(p));
+
+- s = (gchar *) url->buffer;
++ s = url->buffer = g_strchomp(g_strdup(p));
++
+p = strpbrk(s, ":/?#");
+if (p && p[0] == ':' && p > s) { // scheme
+*p = 0;
+@@ -122,7 +124,7 @@ static DilloUrl *Url_object_new(const gc
+// p = strpbrk(s, "/");
+if (p && p[0] == '/' && p[1] == '/') { // authority
+s = p + 2;
+- p = strpbrk(s, "/?#");
++ p = strpbrk(s, "$/?#");
+if (p) {
+memmove(s - 2, s, MAX(p - s, 1));
+url->authority = s - 2;
+@@ -133,6 +135,9 @@ static DilloUrl *Url_object_new(const gc
+return url;
+}
+}
++ p = strpbrk(s, "$");
++ if (p)
++ url->force_hostname = p + 1;
+
+p = strpbrk(s, "?#");
+if (p) { // path
+@@ -178,6 +183,11 @@ void a_Url_free(DilloUrl *url)
+
+/*
+* Resolve the URL as RFC2396 suggests.
++ *
++ * Additionaly, we allow the IP$hostname syntax that i just invented to
++ * allow virtual hosts games. (for example, if you know the IP of the
++ * machine but it, for any reason, does not resolve. If that machines
++ * uses vhosts you're pretty much screwed)
+*/
+static GString *Url_resolve_relative(const gchar *RelStr,
+DilloUrl *BaseUrlPar,
+
+diff -pru dillo-0.6.4/src/url.h ./url.h
+--- dillo-0.6.4/src/url.h Sun Jan 20 06:51:23 2002
++++ ./url.h Tue Apr 30 20:00:04 2002
+@@ -46,7 +46,8 @@
+#define URL_PATH(u) u->path
+#define URL_QUERY(u) u->query
+#define URL_FRAGMENT(u) u->fragment
+-#define URL_HOST(u) a_Url_hostname(u)
++#define URL_HHOST(u) ((u)->force_hostname)?(u)->force_hostname:a_Url_hostname(u)
++#define URL_HOST(u) a_Url_hostname(u)
+#define URL_PORT(u) (URL_HOST(u) ? u->port : u->port)
+#define URL_FLAGS(u) u->flags
+#define URL_DATA(u) u->data
+@@ -80,6 +81,7 @@ struct _DilloUrl {
+const gchar *query; // (no need to free them)
+const gchar *fragment; //
+const gchar *hostname; //
++ const gchar *force_hostname;
+gint port;
+gint flags;
+const gchar *data; /* POST */
+Only in .: url.h~ 
+
diff --git a/old/oldmail/200206.txt b/old/oldmail/200206.txt
new file mode 100644
index 0000000..95912d1
--- /dev/null
+++ b/old/oldmail/200206.txt
@@ -0,0 +1,4972 @@
+Re: [Dillo-dev]Sites that use SSI that work well with dillo
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-06-29 21:49
+
+Lee,
+
+> Hi,
+>
+> I'm looking for sites that work well with dillo, especially ones that
+> use server side include scripting. The point would be to demonstrate
+> the usefulness of dillo without the need for client side scripting, etc.
+>
+> Thanks in advance.
+
+Well, I think your best bet is for sites that use cookies to
+keep certain "state" information. For instance, freshmeat.net and
+http://www.linuxapps.com. I was able to make the 0.6.6-release
+announcement on both sites with dillo (which requires login, DB
+consulting and information updating using cookies and forms).
+
+I hope some other persons at this list point you to better
+examples. There was a guy sometime ago that was testing a web
+calendar application, but though I wrote to him, I never got an
+answer.
+
+Well, I think a radical example would be to enable dillo with
+the HTTPS patch (very unstable), and try so....net. I
+haven't done that yet, and maybe it doesn't work, but if it
+works --even barely--, it could be more convincing than the above
+mentioned examples.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Sad News
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-06-29 21:49
+
+Hi developers,
+
+
+As you have noticed since a few months, dillo project is in a
+dire need for funding in order to continue its development at
+full steam.
+
+As some of you already know, I have been working full time on
+it for two years and a half, at my expense. At the present time
+I've completely run out of money, and the current situation
+forces me to search for a regular job to pay my bills.
+
+This is not the result of lack of planning but of two disgraces
+in a row that hit me, the latest of them, being the decline of a
+Chilean enterprise whom which I had a closed-by-word agreement
+that was to let me work in dillo for a full year while waiting
+for the funding initiative to thrive.
+
+Currently, I'm trying to find a short term project job that
+lets me save some money, with a view to resume my work with dillo
+thereafter. God knows that's not the fate I hoped for the project
+I've devoted my best efforts to. So, if there's someone on this
+list studying whether dillo could suit their needs, and wants to
+hire me for a short working/consulting period, they'll have the
+highest priority.
+
+The irony in all this is that dillo project is in a point where
+it can boost into a new level. There're plenty of ideas and most
+of them have working prototypes: encryption (https), port to
+GTK2, support for different languages, interoperation, embedding
+dillo in a GTK+ application (a sylpheed branch does that), IPv6,
+CSS, serving as front end for embedded apps., etc.
+
+I know all the code inside dillo, and I know how close all
+those goals are. They need just a few months of full time work to
+flourish.
+
+Well, I'll try to keep the pace of patch reviewing and
+integration, but certainly, my development contributions will
+shrink as the new job starts.
+
+
+
+Best regards
+Jorge.- 
+
+
+
+Re: [Dillo-dev]BR taking extra space and problem with spaces in table
+
+From: Pekka Lampila <medar@ka...> - 2002-06-28 18:42
+
+On Tue, 25 Jun 2002 14:13:23 +0200
+Sebastian Geerken <sgeerken@st...> wrote:
+
+> In this case, multiple <br>'s would not be rendered properly. A
+> solution may be to examine if this is the first <br> in series (by
+> looking if there are DW_CONTENT_BREAK's before), but for my taste,
+> this is somehow too hackish. (Other opinions?)
+
+It's should work and is certainly better than the current situation.
+So in my opinion, that kind of fix should be committed.
+
+If someone figures out better approach it can be tought about later.
+
+> There are anyway problems with spaces, e.g. dillo does not render
+> something like
+> 
+> Some text with an <u> underliner </ul> word.
+> 
+> AFAIK, the spaces after <ul> and before </ul> should be ignored, as
+> they have to in after <table> and <tr>, etc. This should IMO solved
+> generally in the HTML parser.
+
+Sounds reasonable to me. And not all that complicated to implement either...
+
+
+PS. Your Mail-Followup-To header is a bit strange:
+Mail-Followup-To: sgeerken, Dillo-dev <dillo-dev@so...>
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+[Dillo-dev]Links graphics homepage
+
+From: Frank McCormick <fmccormick@sy...> - 2002-06-28 10:55
+
+Patrick, your email isn't working.
+
+This is the Links graphics homepage.
+
+
+
+http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/
+
+
+>>* Frank McCormick <fmccormick@sy...> [06-27-02 14:28]:
+>> 
+>> I have been testing out Links <graphics version> and am wondering if
+>any> of the code it uses could be borrowed for Dillo.
+
+
+
+>Cannot find the "Links <graphics version>". Please give direction. I
+>would like to give it a trial. 
+
+
+
+Re: [Dillo-dev]Links graphics
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-27 19:47
+
+Frank McCormick wrote:
+
+>I have been testing out Links <graphics version> and am wondering if any
+>of the code it uses could be borrowed for Dillo.
+>
+>It runs extremely well and fast even on my weak-kneed 100 mhz Pentium I,
+>I'd say almost as fast as Dillo. The executable size however is something
+>else..over 3 megs.
+>
+>It even does Hotmail, a site that throws even Opera into a frenzy from
+>time to time, it handles HTTP and FTP downloads, maintains a bookmark
+>list, and seems to handle most cookies well.
+>
+>Just a thought as I am no C programmer - I only dabble in uurgh Pascal.:)
+>
+>
+>
+>
+>-------------------------------------------------------
+>Sponsored by:
+>ThinkGeek at http://www.ThinkGeek.com/
+>_______________________________________________
+>Dillo-dev mailing list
+>Dillo-dev@li...
+>https://lists.so....net/lists/listinfo/dillo-dev
+>
+
+I've looked at the source code and the comments are in a language I 
+don't know, Czech I think.
+So this kind of inhibits using it. 
+
+
+
+[Dillo-dev]Links graphics
+
+From: Frank McCormick <fmccormick@sy...> - 2002-06-27 19:24
+
+I have been testing out Links <graphics version> and am wondering if any
+of the code it uses could be borrowed for Dillo.
+
+It runs extremely well and fast even on my weak-kneed 100 mhz Pentium I,
+I'd say almost as fast as Dillo. The executable size however is something
+else..over 3 megs.
+
+It even does Hotmail, a site that throws even Opera into a frenzy from
+time to time, it handles HTTP and FTP downloads, maintains a bookmark
+list, and seems to handle most cookies well.
+
+Just a thought as I am no C programmer - I only dabble in uurgh Pascal.:) 
+
+
+
+[Dillo-dev]Sites that use SSI that work well with dillo
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-27 19:05
+
+Hi,
+
+I'm looking for sites that work well with dillo, especially ones that
+use server side include scripting. The point would be to demonstrate
+the usefulness of dillo without the need for client side scripting, etc.
+
+Thanks in advance.
+
+Disclaimer: The information contained in this transmission, including any
+attachments, may contain confidential information of Matsushita Avionics
+Systems Corporation. This transmission is intended only for the use of the
+addressee(s) listed above. Unauthorized review, dissemination or other use
+of the information contained in this transmission is strictly prohibited.
+If you have received this transmission in error or have reason to believe
+you are not authorized to receive it, please notify the sender by return
+email and promptly delete the transmission. 
+
+
+
+Re: [Dillo-dev]size of binary
+
+From: Pat Shanahan <pat@em...> - 2002-06-26 21:54
+
+* William S. <wstan@xs...> [06-26-02 00:34]:
+> I just took a quick look at the size of the
+> dillo binary. I was wondering if this is
+> normal or related to the cache building up.
+> 
+> -rwxr-xr-x 1 root wheel 5469118 Jun 7 03:06 dillo
+> 
+> -- 
+> Bill
+> Amsterdam, NL
+
+-rwxr-xr-x 1 root root 244460 May 30 16:27 dillo
+?? 4 instances up ??
+-- 
+Patrick Shanahan
+Registered Linux User #207535 
+@ http://counter.li.org 
+
+
+
+Re: [Dillo-dev]size of binary
+
+From: William S. <wstan@xs...> - 2002-06-26 06:18
+
+-rwxr-xr-x 1 root wheel 229376 Jun 26 08:17 /usr/local/dillo/bin/dillo
+
+Looks like that did the trick.
+Thank you.
+
+On Tue, Jun 25, 2002 at 10:54:20PM -0700, Eric GAUDET wrote:
+> You probably still have the debug information in the binary (which is the
+> default, as dillo is still in alpha stage)
+> Try this:
+> 
+> strip --strip-all dillo
+> 
+
+-- 
+Bill
+Amsterdam, NL 
+
+
+
+RE: [Dillo-dev]size of binary
+
+From: Eric GAUDET <eric@rt...> - 2002-06-26 05:55
+
+You probably still have the debug information in the binary (which is the
+default, as dillo is still in alpha stage)
+Try this:
+
+strip --strip-all dillo
+
+-- En reponse de "[Dillo-dev]size of binary" de William S., le 26-Jun-2002 :
+> I just took a quick look at the size of the
+> dillo binary. I was wondering if this is
+> normal or related to the cache building up.
+> 
+> -rwxr-xr-x 1 root wheel 5469118 Jun 7 03:06 dillo
+> 
+> -- 
+> Bill
+> Amsterdam, NL
+> 
+> 
+> -------------------------------------------------------
+> This s...net email is sponsored by: Jabber Inc.
+> Don't miss the IM event of the season | Special offer for OSDN members! 
+> JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------------------------------------------
+Eric GAUDET <eric@rt...>
+Le 25-Jun-2002 a 22:53:22
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+[Dillo-dev]size of binary
+
+From: William S. <wstan@xs...> - 2002-06-26 05:27
+
+I just took a quick look at the size of the
+dillo binary. I was wondering if this is
+normal or related to the cache building up.
+
+-rwxr-xr-x 1 root wheel 5469118 Jun 7 03:06 dillo
+
+-- 
+Bill
+Amsterdam, NL 
+
+
+
+Re: [Dillo-dev]BR taking extra space and problem with spaces in table
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-06-25 12:14
+
+On Tue, Jun 25, 2002 at 08:56:53AM +0300, Pekka Lampila wrote:
+> Take a look at: http://kirjasto.org/medar/dillo/extraspace.html
+> 
+> The two green squares and the red "Hi-box" shouldn't have space between
+> them. This is solved by dw_page.c part of attached diff, setting
+> linebreak's ascent and descent to 0. I think this is right solution, but
+> could be wrong.
+
+In this case, multiple <br>'s would not be rendered properly. A
+solution may be to examine if this is the first <br> in series (by
+looking if there are DW_CONTENT_BREAK's before), but for my taste,
+this is somehow too hackish. (Other opinions?)
+
+> This error shows in many places, like slashdot.org for example :)
+> 
+> Second flaw in Dillo's rendering of my test page is that the red box
+> should cover the black cell beneath it entirely. It doesn't because
+> a space is inserted in the black cell.
+> 
+> The html.c part of the diff tries to deal with this simply by disabling
+> adding of spaces when in TABLE or TR. But this breaks some badly
+> formatted html that Dillo currently handles nicely. So after aplying the
+> diff, the "This is badly formatted HTML" part of test page is rendered
+> without spaces.
+
+There are anyway problems with spaces, e.g. dillo does not render
+something like
+
+Some text with an <u> underliner </ul> word.
+
+AFAIK, the spaces after <ul> and before </ul> should be ignored, as
+they have to in after <table> and <tr>, etc. This should IMO solved
+generally in the HTML parser.
+
+Sebastian 
+
+
+
+[Dillo-dev]BR taking extra space and problem with spaces in table
+
+From: Pekka Lampila <medar@ka...> - 2002-06-25 05:57
+
+Attachments: extraspace.diff      
+
+Hi,
+
+Take a look at: http://kirjasto.org/medar/dillo/extraspace.html
+
+The two green squares and the red "Hi-box" shouldn't have space between
+them. This is solved by dw_page.c part of attached diff, setting
+linebreak's ascent and descent to 0. I think this is right solution, but
+could be wrong.
+
+This error shows in many places, like slashdot.org for example :)
+
+Second flaw in Dillo's rendering of my test page is that the red box
+should cover the black cell beneath it entirely. It doesn't because
+a space is inserted in the black cell.
+
+The html.c part of the diff tries to deal with this simply by disabling
+adding of spaces when in TABLE or TR. But this breaks some badly
+formatted html that Dillo currently handles nicely. So after aplying the
+diff, the "This is badly formatted HTML" part of test page is rendered
+without spaces.
+
+So I'm hoping that someone can make better fix for this problem.
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+[Dillo-dev]Multiple URLs from commandline
+
+From: Johannes Hofmann <Johannes.Hofmann@gm...> - 2002-06-24 16:37
+
+Attachments: dillo_multi_url.patch      
+
+Hi all,
+
+here is a very small patch, that allows dillo to accept multiple URLs
+from the command line. With this patch you can do for example:
+
+"dillo http://www.slashdot.org 
+
+For each URL a new browser window will pop up. Don't know how others 
+feel about popping up multiple windows at startup, but it's useful 
+for me, especially for offline browsing.
+
+Regards,
+Johannes Hofmann 
+
+
+
+[Dillo-dev]2 requests: copy email adress and copy/paste text
+
+From: Mathieu Roy <yeupou@gn...> - 2002-06-24 08:34
+
+Hi,
+
+I can't copy/paste text in html page rendered by dillo. Is it normal? 
+If it is, should not this thing be a the goals list?
+
+Could it be possible to have, like in galeon, a "copy email adress" for 
+urls beginning with a mailto: ?
+
+Best regards,
+
+
+-- 
+Mathieu Roy
+http://savannah.gnu.org/users/yeupou
+http://yeupou.coleumes.org
+http://gpg.coleumes.org (GPG Key) 
+
+
+
+Re: [Dillo-dev]Newest bug entries
+
+From: Philip Blundell <pb@ne...> - 2002-06-23 11:38
+
+On Sat, 2002-06-22 at 20:15, Jorge Arellano Cid wrote:
+> Just some comments on newest bug entries. This is mainly of
+> interest to their authors.
+
+Did you have any thoughts on the IPv6 patch I sent you a few weeks ago?
+
+p. 
+
+
+
+[Dillo-dev]Newest bug entries
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-06-22 19:17
+
+Hi there!
+
+Just some comments on newest bug entries. This is mainly of
+interest to their authors.
+
+Note that some of these are to be deleted soon:
+
+#354:
+
+It seems a double problem, one with dillo not rendering two
+tables in a row (#355), and some bad HTML.
+
+
+#356
+
+Explained in HtmlParser.txt
+
+
+#357
+
+'METHODDEF' is defined in jmorecfg.h, included from jpeglib.h.
+
+Quoting from IJG's jmorecfg.h:
+>>
+[...]
+/* These macros are used in all function definitions and extern declarations.
+* You could modify them if you need to change function linkage conventions;
+* in particular, you'll need to do that to make the library a Windows DLL.
+* Another application is to make all functions global for use with debuggers
+* or code profilers that require it.
+*/
+
+/* a function called through method pointers: */
+#define METHODDEF(type) static type
+/* a function used only in its module: */
+#define LOCAL(type) static type
+/* a function referenced thru EXTERNs: */
+#define GLOBAL(type) type
+/* a reference to a GLOBAL function: */
+#define EXTERN(type) extern type
+[...]
+>>
+
+
+#358
+
+I just commited a patch for it. Please test it as I don't have
+that kind of filesystem a hand. I added some explicative messages
+too.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]killing the cache
+
+From: William S. <wstan@xs...> - 2002-06-22 08:50
+
+Is there any way to kill the cache that Dillo
+holds in memory or disk? It seems that just hitting
+reload does not remove the "attributes" of a particular
+page.
+
+Thank you,
+-- 
+Bill
+Amsterdam, NL 
+
+
+
+Re: [Dillo-dev]Very large table cells
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-06-21 15:51
+
+Hi,
+
+On Mon, Jun 17, 2002 at 08:12:53PM -0700, Eric GAUDET wrote:
+> I have been browsing a couple of web sites that use tables in a strange
+> fashion. At first I did not pay attention ("damn broken html"), but as this
+> seems to be pretty common so I wanted to share it with you:
+> 
+> <table width="100%>
+> <tr>
+> <td width="10000">My title bar</td>
+> <td>Here my regular body</td>
+> </tr>
+> </table>
+> 
+> Most broswers seem to deal fine with that, and W3C html specs are superbly
+> ignoring the topic. Dillo, however, draws a 10000 pix wide page.
+
+Sometimes the CSS spec is more precise (by nature), and from my
+understanding, the table has to make sure that the table cell fits
+into the 100%.
+
+The problem is that dillo currently deals with width specifications in
+the way that they are only honoured if they are not smaller than the
+minimal width, and for simplicity, if a table cell has a specified
+width w, the table sets min = max = w, so assuming that the table cell
+"needs" the 10000 pixels.
+
+(Generally, this behaviour has two reasons, first it may sometimes be
+useful to correct size specifications to make all the content visible;
+second, since clipping is not possible yet -- although planned -- you
+would get quite a mess of widgets drawing in other widgets'
+allocations.)
+
+I plan to redesign anything having to do with sizes, so this will
+probably change.
+
+On Tue, Jun 18, 2002 at 12:38:55AM -0400, Andreas Schweitzer wrote:
+> Well, the other browsers seem to ignore the 10000pix wide cell.
+> One could argue with 2 arguments :
+> 1. first come wins : i.e. the 100% is the definite spec
+
+In an other sense, dillo first handles the 10000pix and then the 100%
+:-)
+
+Sebastian 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-18 14:53
+
+>
+>
+>
+> The mission: if ever dillo segfaults, try to find out how it
+>happened and ideally, find a way to reproduce it (don't forget to
+>grab the latest debug messages too!).
+>
+> 
+>
+
+Have you tried using the script catchsegv? (On Redhat in /usr/bin) I
+just ran across it last week, appears promising. I will try it the
+first chance I get. 
+
+
+
+Re: [Dillo-dev]Very large table cells
+
+From: Andreas Schweitzer <andy@ph...> - 2002-06-18 04:39
+
+Hi
+
+On Mon, Jun 17, 2002 at 08:12:53PM -0700, Eric GAUDET wrote:
+> I have been browsing a couple of web sites that use tables in a strange
+> fashion. At first I did not pay attention ("damn broken html"), but as this
+> seems to be pretty common so I wanted to share it with you:
+> 
+> <table width="100%>
+> <tr>
+> <td width="10000">My title bar</td>
+> <td>Here my regular body</td>
+> </tr>
+> </table>
+> 
+> Most broswers seem to deal fine with that, and W3C html specs are superbly
+> ignoring the topic. Dillo, however, draws a 10000 pix wide page.
+
+Well, the other browsers seem to ignore the 10000pix wide cell.
+One could argue with 2 arguments :
+1. first come wins : i.e. the 100% is the definite spec
+2. a percent spec is much more device independent than a pixel spec.
+and shouldn't the web be device independet ? So, in conflict, take
+the least device dependent spec.
+
+Just my 2 cents - w/o having checked the standard ... trusting Eric there.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+[Dillo-dev]Very large table cells
+
+From: Eric GAUDET <eric@rt...> - 2002-06-18 03:13
+
+Hi all,
+
+I have been browsing a couple of web sites that use tables in a strange
+fashion. At first I did not pay attention ("damn broken html"), but as this
+seems to be pretty common so I wanted to share it with you:
+
+<table width="100%>
+<tr>
+<td width="10000">My title bar</td>
+<td>Here my regular body</td>
+</tr>
+</table>
+
+Most broswers seem to deal fine with that, and W3C html specs are superbly
+ignoring the topic. Dillo, however, draws a 10000 pix wide page.
+
+Here is my interpretation: explicit table cell dimensions (width attributes of
+td and tr) are always bound to the explicit dimension of the element including
+them (td->tr->table). However, table content drive the actual table cell
+dimensions (for instance a width="10000" image would stretch the table in every
+browser).
+
+I am not sure how you guys want to handle this, but it is really painful to
+read such pages.
+
+References:
+http://www.lik-sang.com/catalog/news.php?artc=2497
+http://www.imaging-resource.com/PRODS/D7I/D7IA.HTM
+
+Best,
+Eric
+
+------------------------------------------------------------------------
+Eric GAUDET <eric@rt...>
+Le 17-Jun-2002 a 19:43:54
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+Re: [Dillo-dev]Porting to GTK+-2.0
+
+From: Pekka Lampila <medar@ka...> - 2002-06-17 13:49
+
+On 16 Jun 2002 18:19:05 +0200
+Jorgen Viksell <jorgen.viksell@te...> wrote:
+
+Hi,
+
+> Hi,
+> 
+> > Hi,
+> > 
+> > I ported Dillo to GTK+-2.0. Please test.
+> 
+> Works great here! :-)
+
+Good. :)
+
+> I fiddled around some and added basic pango support. The most apparent
+> problem is speed, specificly the use of PangoLayout combined with UTF8
+> conversion.
+> There is a need to change the logics of DwPage and not use one
+> PangoLayout for each word, but reuse it.
+
+Yes, and the cache system should probably handle the conversion so that
+in html.c all the data is always UTF8?
+
+> I'll look into it some more tomorrow.
+
+If you get it to work, I can include it in my next patch.
+
+Which should BTW include user editable keybindings through
+gtk_accel_map_save/load() :)
+
+> Anyways, antialiased text is nice and fuzzy! ;-)
+
+And my graphic card is not supported by XF4.x, not fair!
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-06-16 22:14
+
+Hi there!
+
+> > [Livio wrote]
+> >
+> > I have a patch here which (seems) to fix it. There are two fixes in
+> > it:
+> >
+> > [1] The fix Jorge and I had made in 0.6.5-pre, which was removed. This
+> > will make IO_write and IO_callback correctly treat EAGAIN.
+> >
+> > [2] Remove the constraint for freeing the buffer in write operations.
+> > This error should not appear commonly in Dillo's regular use,
+> > because it is very rare to have a HTTP query with more than one
+> > buffer long, and therefore the IOvec.iov_base won't be
+> > modified. But this, in fact, can happen (resulting in a Seg
+> > Fault). What I've done to fix this problem, is added a
+> > `buffer_start` field to IOData_t, which is _private_. IO users
+> > shouldn't bother to set this, I have done so in a_IO_ccc().
+> >
+> > Jorge, do you think that [2] fixes other problems you might of had
+> > with the EAGAIN handler?
+>
+> I'm giving a deep review to the problem, and it seems [2] may
+> be the fix to the problems I had.
+>
+> Quoting myself:
+>
+> <<
+> I'm a bit hesitant with this subject. This is the story: I've
+> been working on presentation material for the site, and testing
+> its rendering with dillo; that is, small html files that are
+> re-created by a script very often, and then reloaded into dillo.
+> The sad news is that I've caught this problem twice:
+
+OK, I gave the patch a lot of thought and reviews, but with no
+clear results. :o
+
+The funny thing is that the only one using IOWrite then, was
+about:splash, and it does NOT free the buffer, so the hopes for
+the fix on freeing the buffer in write operations being able to
+silently cope with the "phantom" bug, seem gone now.
+
+The other interesting fact is that I was working on a directory
+(i.e. file:/ method), and it doesn't use IOWrite. The only one
+that could have requested to free the buffer is http:/, which I
+wasn't using.
+
+What does all this comes down to?
+
+Well, considering all the facts, I decided to commit a slightly
+modified version of the patch (that does the same! :), so we can
+give it more testing and hopefully get some debug messages to
+review.
+
+The mission: if ever dillo segfaults, try to find out how it
+happened and ideally, find a way to reproduce it (don't forget to
+grab the latest debug messages too!).
+
+
+Good luck
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Porting to GTK+-2.0
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-06-16 16:12
+
+Hi,
+
+> Hi,
+>=20
+> I ported Dillo to GTK+-2.0. Please test.
+
+Works great here! :-)
+=20
+> Diff against current CVS:
+> http://kirjasto.org/medar/dillo/gtk2_dillo_2002-06-16.diff.gz
+>=20
+> Screenshot, which looks just like GTK+-1.2 version :)
+> http://kirjasto.org/medar/dillo/gtk2_dillo_2002-06-16.png
+>=20
+> There are three problems that I'm aware of. Copy Link Location,
+> scrolling with arrow keys and accelator keys in menus are all broken.
+> I should hopefully be able to fix these soon.
+>=20
+> And of course there is more bugs, that I haven't spotted.
+> (Please help in finding them.)
+>=20
+> Note that this patch just tries to convert current functionality to
+> gtk2. There are more features in gtk2 that we can take advantage of.
+> Most importantly Pango.
+
+I fiddled around some and added basic pango support. The most apparent
+problem is speed, specificly the use of PangoLayout combined with UTF8
+conversion.
+There is a need to change the logics of DwPage and not use one
+PangoLayout for each word, but reuse it.
+
+I'll look into it some more tomorrow.
+
+Anyways, antialiased text is nice and fuzzy! ;-)
+
+Regards,
+J=F6rgen 
+
+
+
+[Dillo-dev]Porting to GTK+-2.0
+
+From: Pekka Lampila <medar@ka...> - 2002-06-16 12:12
+
+Hi,
+
+I ported Dillo to GTK+-2.0. Please test.
+
+Diff against current CVS:
+http://kirjasto.org/medar/dillo/gtk2_dillo_2002-06-16.diff.gz
+
+Screenshot, which looks just like GTK+-1.2 version :)
+http://kirjasto.org/medar/dillo/gtk2_dillo_2002-06-16.png
+
+There are three problems that I'm aware of. Copy Link Location,
+scrolling with arrow keys and accelator keys in menus are all broken.
+I should hopefully be able to fix these soon.
+
+And of course there is more bugs, that I haven't spotted.
+(Please help in finding them.)
+
+Note that this patch just tries to convert current functionality to
+gtk2. There are more features in gtk2 that we can take advantage of.
+Most importantly Pango.
+
+-- 
+Pekka Lampila *
+medar@ka... * If pro is the opposite of con,
+http://kirjasto.org/medar * what is the opposite of progress? 
+
+
+
+[Dillo-dev]remote url control and testing patch part 4
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-13 15:24
+
+Here is the test script. Note that the url MUST be quoted and terminated 
+with a ';' character.
+
+You can use a zero time delay but seems to interrupt html_close() and 
+leak memory.
+It is fun to watch how fast the cpu can render though.
+(For me anyway)
+-------------
+
+#!/bin/sh
+# rurl-cmeu99-2.sh
+
+if [ -n $1 ] ; then
+DURATION=$1
+else
+DURATION=3
+fi
+
+
+HOST="cmeu99"
+
+
+while true; do
+
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 "
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 
+"
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 
+"
+sleep $DURATION
+/home/lee/src/wpipe1/wpipe1/wpipe1 
+"
+sleep $DURATION
+
+
+done
+
+Disclaimer: The information contained in this transmission, including any
+attachments, may contain confidential information of Matsushita Avionics
+Systems Corporation. This transmission is intended only for the use of the
+addressee(s) listed above. Unauthorized review, dissemination or other use
+of the information contained in this transmission is strictly prohibited.
+If you have received this transmission in error or have reason to believe
+you are not authorized to receive it, please notify the sender by return
+email and promptly delete the transmission. 
+
+
+
+[Dillo-dev]remote url control and testing patch part 3
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-13 15:17
+
+Here is the header file, dillo.c patch. The make file was modified to 
+use mtrace, only -g and not -O2.
+
+----------------------
+/*
+* File : rurl.h - Dillo
+*
+*
+* 
+*
+* Remote url
+*/
+
+#ifndef __RURL_H__
+#define __RURL_H__
+
+#include "browser.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define MAXURL 1024
+
+void rurl_server_req(BrowserWindow *bw);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* __RURL_H__ */
+
+
+--------------------------------------------------
+Only in dillo-0.6.6-namedpipe/: CVS
+Only in dillo-0.6.6/: ChangeLog.old
+diff -pru dillo-0.6.6/config.log dillo-0.6.6-namedpipe/config.log
+--- dillo-0.6.6/config.log Tue Jun 4 10:43:32 2002
++++ dillo-0.6.6-namedpipe/config.log Mon Jun 10 10:15:43 2002
+@@ -10,11 +10,11 @@ generated by GNU Autoconf 2.50. Invocat
+## Platform. ##
+## ---------- ##
+
+-hostname = borabora
++hostname = fiji
+uname -m = i686
+-uname -r = 2.4.18-4
++uname -r = 2.4.18
+uname -s = Linux
+-uname -v = #1 Thu May 2 18:47:38 EDT 2002
++uname -v = #2 Sat Mar 9 03:16:53 PST 2002
+
+/usr/bin/uname -p = unknown
+/bin/uname -X = unknown
+@@ -27,7 +27,7 @@ hostinfo = unknown
+/usr/bin/oslevel = unknown
+/bin/universe = unknown
+
+-PATH = /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/home/lee/bin
++PATH = /bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/usr/java/j2re1.4.0/bin
+
+## ------------ ##
+## Core tests. ##
+@@ -119,7 +119,7 @@ configure:2468: checking how to run the
+configure:2495: gcc -E -I/usr/local/include conftest.c
+configure:2501: $? = 0
+configure:2528: gcc -E -I/usr/local/include conftest.c
+-configure:2525:28: ac_nonexistent.h: No such file or directory
++configure:2525: ac_nonexistent.h: No such file or directory
+configure:2534: $? = 1
+configure: failed program was:
+#line 2524 "configure"
+@@ -129,7 +129,7 @@ configure:2571: result: gcc -E
+configure:2586: gcc -E -I/usr/local/include conftest.c
+configure:2592: $? = 0
+configure:2619: gcc -E -I/usr/local/include conftest.c
+-configure:2616:28: ac_nonexistent.h: No such file or directory
++configure:2616: ac_nonexistent.h: No such file or directory
+configure:2625: $? = 1
+configure: failed program was:
+#line 2615 "configure"
+@@ -173,8 +173,6 @@ configure:3087: checking for ANSI C head
+configure:3101: gcc -E -I/usr/local/include conftest.c
+configure:3107: $? = 0
+configure:3194: gcc -o conftest -I/usr/include/gtk-1.2 
+-I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g 
+-O2 -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return 
+-I/usr/local/include -L/usr/local/lib conftest.c -lpng -lz -lpthread 
+-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl 
+-lXi -lXext -lX11 -lm >&5
+-configure: In function `main':
+-configure:3186: warning: implicit declaration of function `exit'
+configure:3197: $? = 0
+configure:3199: ./conftest
+configure:3202: $? = 0
+@@ -205,7 +203,7 @@ configure:3427: creating ./config.status
+
+This file was extended by config.status 2.50, executed with
+> ./config.status
+-on borabora
++on fiji
+
+config.status:3877: creating Makefile
+config.status:3877: creating doc/Makefile
+@@ -217,45 +215,45 @@ config.status:3969: creating config.h
+## Cache variables. ##
+## ----------------- ##
+
+-ac_cv_c_compiler_gnu=yes
+-ac_cv_env_CC_set=
+-ac_cv_env_CC_value=
+-ac_cv_env_CFLAGS_set=
+-ac_cv_env_CFLAGS_value=
+-ac_cv_env_CPPFLAGS_set=
+-ac_cv_env_CPPFLAGS_value=
+-ac_cv_env_CPP_set=
+-ac_cv_env_CPP_value=
+-ac_cv_env_LDFLAGS_set=
+-ac_cv_env_LDFLAGS_value=
+-ac_cv_env_build_alias_set=
+-ac_cv_env_build_alias_value=
+-ac_cv_env_host_alias_set=
+-ac_cv_env_host_alias_value=
+-ac_cv_env_target_alias_set=
+-ac_cv_env_target_alias_value=
+-ac_cv_func_socket=yes
+-ac_cv_header_fcntl_h=yes
+-ac_cv_header_jconfig_h=yes
+-ac_cv_header_jerror_h=yes
+-ac_cv_header_jmorecfg_h=yes
+-ac_cv_header_jpeglib_h=yes
+-ac_cv_header_stdc=yes
+-ac_cv_header_sys_uio_h=yes
+-ac_cv_header_unistd_h=yes
+-ac_cv_lib_jpeg_jpeg_destroy_decompress=yes
+-ac_cv_lib_png_png_check_sig=yes
+-ac_cv_lib_pthread_pthread_create=yes
+-ac_cv_lib_z_zlibVersion=yes
+-ac_cv_objext=o
+-ac_cv_path_GTK_CONFIG=/usr/bin/gtk-config
++ac_cv_c_compiler_gnu='yes'
++ac_cv_env_CC_set=''
++ac_cv_env_CC_value=''
++ac_cv_env_CFLAGS_set=''
++ac_cv_env_CFLAGS_value=''
++ac_cv_env_CPPFLAGS_set=''
++ac_cv_env_CPPFLAGS_value=''
++ac_cv_env_CPP_set=''
++ac_cv_env_CPP_value=''
++ac_cv_env_LDFLAGS_set=''
++ac_cv_env_LDFLAGS_value=''
++ac_cv_env_build_alias_set=''
++ac_cv_env_build_alias_value=''
++ac_cv_env_host_alias_set=''
++ac_cv_env_host_alias_value=''
++ac_cv_env_target_alias_set=''
++ac_cv_env_target_alias_value=''
++ac_cv_func_socket='yes'
++ac_cv_header_fcntl_h='yes'
++ac_cv_header_jconfig_h='yes'
++ac_cv_header_jerror_h='yes'
++ac_cv_header_jmorecfg_h='yes'
++ac_cv_header_jpeglib_h='yes'
++ac_cv_header_stdc='yes'
++ac_cv_header_sys_uio_h='yes'
++ac_cv_header_unistd_h='yes'
++ac_cv_lib_jpeg_jpeg_destroy_decompress='yes'
++ac_cv_lib_png_png_check_sig='yes'
++ac_cv_lib_pthread_pthread_create='yes'
++ac_cv_lib_z_zlibVersion='yes'
++ac_cv_objext='o'
++ac_cv_path_GTK_CONFIG='/usr/bin/gtk-config'
+ac_cv_path_install='/usr/bin/install -c'
+ac_cv_prog_CPP='gcc -E'
+-ac_cv_prog_ac_ct_CC=gcc
+-ac_cv_prog_ac_ct_RANLIB=ranlib
+-ac_cv_prog_cc_g=yes
+-ac_cv_prog_make_make_set=yes
+-am_cv_prog_cc_stdc=
++ac_cv_prog_ac_ct_CC='gcc'
++ac_cv_prog_ac_ct_RANLIB='ranlib'
++ac_cv_prog_cc_g='yes'
++ac_cv_prog_make_make_set='yes'
++am_cv_prog_cc_stdc=''
+
+## ------------ ##
+## confdefs.h. ##
+Only in dillo-0.6.6-namedpipe/doc: CVS
+diff -pru dillo-0.6.6/mkinstalldirs dillo-0.6.6-namedpipe/mkinstalldirs
+--- dillo-0.6.6/mkinstalldirs Tue Aug 29 19:43:34 2000
++++ dillo-0.6.6-namedpipe/mkinstalldirs Mon Jun 10 10:15:43 2002
+@@ -4,7 +4,7 @@
+# Created: 1993-05-16
+# Public domain
+
+-# $Id: mkinstalldirs,v 1.8 2000/08/30 02:43:34 jcid Exp $
++# $Id: mkinstalldirs,v 1.1.1.1 2002/06/10 17:15:43 lee Exp $
+
+errstatus=0
+
+Only in dillo-0.6.6-namedpipe/src/.deps: CVS
+diff -pru dillo-0.6.6/src/.deps/bookmark.P 
+dillo-0.6.6-namedpipe/src/.deps/bookmark.P
+--- dillo-0.6.6/src/.deps/bookmark.P Tue Jun 4 10:43:58 2002
++++ dillo-0.6.6-namedpipe/src/.deps/bookmark.P Mon Jun 10 12:50:39 2002
+@@ -110,16 +110,15 @@ bookmark.o: bookmark.c /usr/include/gtk-
+/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/alloca.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h list.h interface.h browser.h url.h dillo.h \
+- web.h cache.h chain.h html.h dw_widget.h dw_style.h dw_image.h \
+- dw_tooltip.h image.h bitvec.h nav.h misc.h history.h menu.h
++ /usr/include/bits/stdio_lim.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/alloca.h /usr/include/string.h list.h interface.h \
++ browser.h url.h dillo.h web.h cache.h chain.h html.h dw_widget.h \
++ dw_style.h dw_image.h dw_tooltip.h image.h bitvec.h nav.h misc.h \
++ history.h menu.h
+bookmark.c :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+@@ -264,7 +263,6 @@ bookmark.c :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -277,8 +275,6 @@ bookmark.c :
+/usr/include/sys/sysmacros.h :
+/usr/include/alloca.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+list.h :
+interface.h :
+browser.h :
+diff -pru dillo-0.6.6/src/.deps/cache.P 
+dillo-0.6.6-namedpipe/src/.deps/cache.P
+--- dillo-0.6.6/src/.deps/cache.P Tue Jun 4 10:43:45 2002
++++ dillo-0.6.6-namedpipe/src/.deps/cache.P Mon Jun 10 12:50:27 2002
+@@ -8,8 +8,7 @@ cache.o: cache.c /usr/include/ctype.h /u
+/usr/include/bits/select.h /usr/include/bits/sigset.h \
+/usr/include/bits/time.h /usr/include/sys/sysmacros.h \
+/usr/include/sys/stat.h /usr/include/bits/stat.h /usr/include/stdlib.h \
+- /usr/include/alloca.h /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/fcntl.h \
++ /usr/include/alloca.h /usr/include/string.h /usr/include/fcntl.h \
+/usr/include/bits/fcntl.h /usr/include/unistd.h \
+/usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+/usr/include/getopt.h ../config.h list.h IO/Url.h \
+@@ -122,8 +121,8 @@ cache.o: cache.c /usr/include/ctype.h /u
+dw_widget.h dw_style.h dw_image.h /usr/include/stdio.h \
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h dw_tooltip.h \
+- image.h bitvec.h dicache.h interface.h nav.h cookies.h debug.h
++ /usr/include/bits/stdio_lim.h dw_tooltip.h image.h bitvec.h dicache.h \
++ interface.h nav.h cookies.h debug.h
+cache.c :
+/usr/include/ctype.h :
+/usr/include/features.h :
+@@ -147,8 +146,6 @@ cache.c :
+/usr/include/stdlib.h :
+/usr/include/alloca.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/fcntl.h :
+/usr/include/bits/fcntl.h :
+/usr/include/unistd.h :
+@@ -302,7 +299,6 @@ dw_image.h :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+dw_tooltip.h :
+image.h :
+bitvec.h :
+diff -pru dillo-0.6.6/src/.deps/colors.P 
+dillo-0.6.6-namedpipe/src/.deps/colors.P
+--- dillo-0.6.6/src/.deps/colors.P Tue Jun 4 10:44:12 2002
++++ dillo-0.6.6-namedpipe/src/.deps/colors.P Mon Jun 10 12:50:50 2002
+@@ -1,11 +1,10 @@
+colors.o: colors.c /usr/include/string.h /usr/include/features.h \
+/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
++ /usr/include/stdlib.h /usr/include/sys/types.h \
+/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h \
+- /usr/include/sys/types.h /usr/include/time.h /usr/include/sys/select.h \
++ /usr/include/bits/sched.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
+/usr/include/bits/select.h /usr/include/bits/sigset.h \
+/usr/include/bits/time.h /usr/include/sys/sysmacros.h \
+/usr/include/alloca.h /usr/include/glib-1.2/glib.h \
+@@ -24,16 +23,14 @@ colors.c :
+/usr/include/sys/cdefs.h :
+/usr/include/gnu/stubs.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
++/usr/include/stdlib.h :
++/usr/include/sys/types.h :
+/usr/include/bits/types.h :
+/usr/include/bits/pthreadtypes.h :
+/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+-/usr/include/sys/types.h :
+/usr/include/time.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/bits/sigset.h :
+diff -pru dillo-0.6.6/src/.deps/commands.P 
+dillo-0.6.6-namedpipe/src/.deps/commands.P
+--- dillo-0.6.6/src/.deps/commands.P Tue Jun 4 10:43:43 2002
++++ dillo-0.6.6-namedpipe/src/.deps/commands.P Mon Jun 10 12:50:26 2002
+@@ -108,18 +108,16 @@ commands.o: commands.c /usr/include/gtk-
+/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/sys/time.h /usr/include/time.h /usr/include/bits/time.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/unistd.h \
+- /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+- /usr/include/getopt.h /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h bookmark.h browser.h \
+- /usr/include/sys/types.h /usr/include/sys/sysmacros.h url.h interface.h \
+- dillo.h web.h cache.h chain.h html.h dw_widget.h dw_style.h dw_image.h \
+- dw_tooltip.h image.h bitvec.h history.h nav.h misc.h commands.h prefs.h \
+- menu.h
++ /usr/include/bits/stdio_lim.h /usr/include/sys/time.h \
++ /usr/include/time.h /usr/include/bits/time.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/unistd.h /usr/include/bits/posix_opt.h \
++ /usr/include/bits/confname.h /usr/include/getopt.h \
++ /usr/include/string.h bookmark.h browser.h /usr/include/sys/types.h \
++ /usr/include/endian.h /usr/include/bits/endian.h \
++ /usr/include/sys/sysmacros.h url.h interface.h dillo.h web.h cache.h \
++ chain.h html.h dw_widget.h dw_style.h dw_image.h dw_tooltip.h image.h \
++ bitvec.h history.h nav.h misc.h commands.h prefs.h menu.h
+commands.c :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+@@ -260,7 +258,6 @@ commands.c :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/sys/time.h :
+/usr/include/time.h :
+/usr/include/bits/time.h :
+@@ -272,14 +269,11 @@ commands.c :
+/usr/include/bits/confname.h :
+/usr/include/getopt.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+bookmark.h :
+browser.h :
+/usr/include/sys/types.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/sysmacros.h :
+url.h :
+interface.h :
+diff -pru dillo-0.6.6/src/.deps/cookies.P 
+dillo-0.6.6-namedpipe/src/.deps/cookies.P
+--- dillo-0.6.6/src/.deps/cookies.P Tue Jun 4 10:44:13 2002
++++ dillo-0.6.6-namedpipe/src/.deps/cookies.P Mon Jun 10 12:50:50 2002
+@@ -12,17 +12,15 @@ cookies.o: cookies.c /usr/include/sys/ty
+/usr/include/stdio.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/ctype.h IO/Url.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/ctype.h IO/Url.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+/usr/include/bits/local_lim.h /usr/include/linux/limits.h \
+/usr/include/bits/posix2_lim.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/float.h ../config.h \
+- chain.h url.h /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h IO/IO.h /usr/include/unistd.h \
++ chain.h url.h /usr/include/string.h IO/IO.h /usr/include/unistd.h \
+/usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+/usr/include/getopt.h /usr/include/sys/uio.h /usr/include/bits/uio.h \
+misc.h list.h cookies.h debug.h
+@@ -58,7 +56,6 @@ cookies.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/ctype.h :
+IO/Url.h :
+/usr/include/glib-1.2/glib.h :
+@@ -75,8 +72,6 @@ IO/Url.h :
+chain.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+IO/IO.h :
+/usr/include/unistd.h :
+/usr/include/bits/posix_opt.h :
+diff -pru dillo-0.6.6/src/.deps/dicache.P 
+dillo-0.6.6-namedpipe/src/.deps/dicache.P
+--- dillo-0.6.6/src/.deps/dicache.P Tue Jun 4 10:43:59 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dicache.P Mon Jun 10 12:50:39 2002
+@@ -110,15 +110,13 @@ dicache.o: dicache.c /usr/include/glib-1
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/time.h /usr/include/bits/time.h /usr/include/sys/select.h \
+/usr/include/bits/select.h /usr/include/bits/sigset.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h /usr/include/stdio.h \
+- /usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+- /usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h image.h \
+- dw_image.h dw_widget.h dw_style.h dw_tooltip.h url.h bitvec.h web.h \
+- cache.h chain.h html.h browser.h /usr/include/sys/types.h \
+- /usr/include/sys/sysmacros.h dicache.h interface.h prefs.h
++ /usr/include/string.h /usr/include/stdio.h /usr/include/libio.h \
++ /usr/include/_G_config.h /usr/include/wchar.h /usr/include/bits/wchar.h \
++ /usr/include/gconv.h /usr/include/bits/stdio_lim.h image.h dw_image.h \
++ dw_widget.h dw_style.h dw_tooltip.h url.h bitvec.h web.h cache.h \
++ chain.h html.h browser.h /usr/include/sys/types.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/sysmacros.h dicache.h \
++ interface.h prefs.h
+dicache.c :
+/usr/include/glib-1.2/glib.h :
+/usr/lib/glib/include/glibconfig.h :
+@@ -259,11 +257,6 @@ dicache.c :
+/usr/include/bits/select.h :
+/usr/include/bits/sigset.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+/usr/include/stdio.h :
+/usr/include/libio.h :
+/usr/include/_G_config.h :
+@@ -271,7 +264,6 @@ dicache.c :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+image.h :
+dw_image.h :
+dw_widget.h :
+@@ -285,6 +277,8 @@ chain.h :
+html.h :
+browser.h :
+/usr/include/sys/types.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/sysmacros.h :
+dicache.h :
+interface.h :
+diff -pru dillo-0.6.6/src/.deps/dillo.P 
+dillo-0.6.6-namedpipe/src/.deps/dillo.P
+--- dillo-0.6.6/src/.deps/dillo.P Tue Jun 4 10:43:58 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dillo.P Mon Jun 10 12:50:38 2002
+@@ -5,10 +5,9 @@ dillo.o: dillo.c /usr/include/stdio.h /u
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+- /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -114,13 +113,12 @@ dillo.o: dillo.c /usr/include/stdio.h /u
+/usr/include/sys/select.h /usr/include/bits/select.h \
+/usr/include/bits/sigset.h /usr/include/bits/time.h \
+/usr/include/sys/sysmacros.h /usr/include/sys/stat.h \
+- /usr/include/bits/stat.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/stdlib.h /usr/include/errno.h /usr/include/bits/errno.h \
+- /usr/include/linux/errno.h /usr/include/asm/errno.h \
+- /usr/include/fcntl.h /usr/include/bits/fcntl.h /usr/include/unistd.h \
+- /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+- /usr/include/getopt.h /usr/include/alloca.h /usr/include/signal.h \
++ /usr/include/bits/stat.h /usr/include/string.h /usr/include/errno.h \
++ /usr/include/bits/errno.h /usr/include/linux/errno.h \
++ /usr/include/asm/errno.h /usr/include/fcntl.h /usr/include/bits/fcntl.h \
++ /usr/include/unistd.h /usr/include/bits/posix_opt.h \
++ /usr/include/bits/confname.h /usr/include/getopt.h \
++ /usr/include/stdlib.h /usr/include/alloca.h /usr/include/signal.h \
+/usr/include/bits/signum.h /usr/include/bits/siginfo.h \
+/usr/include/bits/wordsize.h /usr/include/bits/sigaction.h \
+/usr/include/bits/sigcontext.h /usr/include/asm/sigcontext.h \
+@@ -129,7 +127,7 @@ dillo.o: dillo.c /usr/include/stdio.h /u
+dw_image.h dw_tooltip.h image.h bitvec.h misc.h dw_gtk_statuslabel.h \
+nav.h history.h bookmark.h dicache.h dns.h IO/Url.h ../config.h IO/IO.h \
+/usr/include/sys/uio.h /usr/include/bits/uio.h IO/mime.h prefs.h \
+- interface.h dw.h cookies.h
++ interface.h dw.h cookies.h rurl.h
+dillo.c :
+/usr/include/stdio.h :
+/usr/include/features.h :
+@@ -146,7 +144,6 @@ dillo.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+@@ -283,9 +280,6 @@ dillo.c :
+/usr/include/sys/stat.h :
+/usr/include/bits/stat.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+/usr/include/errno.h :
+/usr/include/bits/errno.h :
+/usr/include/linux/errno.h :
+@@ -296,6 +290,7 @@ dillo.c :
+/usr/include/bits/posix_opt.h :
+/usr/include/bits/confname.h :
+/usr/include/getopt.h :
++/usr/include/stdlib.h :
+/usr/include/alloca.h :
+/usr/include/signal.h :
+/usr/include/bits/signum.h :
+@@ -336,3 +331,4 @@ prefs.h :
+interface.h :
+dw.h :
+cookies.h :
++rurl.h :
+diff -pru dillo-0.6.6/src/.deps/dns.P dillo-0.6.6-namedpipe/src/.deps/dns.P
+--- dillo-0.6.6/src/.deps/dns.P Tue Jun 4 10:44:00 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dns.P Mon Jun 10 12:50:40 2002
+@@ -31,13 +31,11 @@ dns.o: dns.c /usr/include/pthread.h /usr
+/usr/include/stdlib.h /usr/include/alloca.h /usr/include/stdio.h \
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/gconv.h /usr/include/bits/stdio_lim.h \
+- /usr/include/bits/stdio.h /usr/include/bits/signum.h \
+- /usr/include/bits/siginfo.h /usr/include/bits/sigaction.h \
+- /usr/include/bits/sigcontext.h /usr/include/asm/sigcontext.h \
+- /usr/include/bits/sigstack.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h dns.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+- /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/bits/signum.h /usr/include/bits/siginfo.h \
++ /usr/include/bits/sigaction.h /usr/include/bits/sigcontext.h \
++ /usr/include/asm/sigcontext.h /usr/include/bits/sigstack.h \
++ /usr/include/string.h dns.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
+/usr/include/gtk-1.2/gdk/gdkcursors.h /usr/include/gtk-1.2/gdk/gdkrgb.h \
+/usr/include/gtk-1.2/gtk/gtkaccelgroup.h \
+/usr/include/gtk-1.2/gtk/gtkobject.h /usr/include/gtk-1.2/gtk/gtkarg.h \
+@@ -198,7 +196,6 @@ dns.c :
+/usr/include/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/bits/signum.h :
+/usr/include/bits/siginfo.h :
+/usr/include/bits/sigaction.h :
+@@ -206,8 +203,6 @@ dns.c :
+/usr/include/asm/sigcontext.h :
+/usr/include/bits/sigstack.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+dns.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+diff -pru dillo-0.6.6/src/.deps/dw_aligned_page.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_aligned_page.P
+--- dillo-0.6.6/src/.deps/dw_aligned_page.P Tue Jun 4 10:43:45 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_aligned_page.P Mon Jun 10 
+12:50:27 2002
+@@ -23,8 +23,7 @@ dw_aligned_page.o: dw_aligned_page.c dw_
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/endian.h /usr/include/bits/endian.h url.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/stdlib.h list.h
++ /usr/include/string.h list.h
+dw_aligned_page.c :
+dw_aligned_page.h :
+dw_page.h :
+@@ -70,7 +69,4 @@ findtext.h :
+/usr/include/bits/endian.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+list.h :
+diff -pru dillo-0.6.6/src/.deps/dw_gtk_scrolled_window.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_gtk_scrolled_window.P
+--- dillo-0.6.6/src/.deps/dw_gtk_scrolled_window.P Tue Jun 4 
+10:43:49 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_gtk_scrolled_window.P Mon Jun 
+10 12:50:31 2002
+@@ -33,9 +33,8 @@ dw_gtk_scrolled_window.o: dw_gtk_scrolle
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/endian.h /usr/include/bits/endian.h url.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/stdlib.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gtk/gtkaccellabel.h \
++ /usr/include/string.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gtk/gtkaccellabel.h \
+/usr/include/gtk-1.2/gtk/gtklabel.h /usr/include/gtk-1.2/gtk/gtkmisc.h \
+/usr/include/gtk-1.2/gtk/gtkalignment.h \
+/usr/include/gtk-1.2/gtk/gtkaspectframe.h \
+@@ -168,9 +167,6 @@ findtext.h :
+/usr/include/bits/endian.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gtk/gtkaccellabel.h :
+/usr/include/gtk-1.2/gtk/gtklabel.h :
+diff -pru dillo-0.6.6/src/.deps/dw_gtk_statuslabel.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_gtk_statuslabel.P
+--- dillo-0.6.6/src/.deps/dw_gtk_statuslabel.P Tue Jun 4 10:43:49 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_gtk_statuslabel.P Mon Jun 10 
+12:50:31 2002
+@@ -20,11 +20,7 @@ dw_gtk_statuslabel.o: dw_gtk_statuslabel
+/usr/include/gtk-1.2/gtk/gtkadjustment.h \
+/usr/include/gtk-1.2/gtk/gtkdata.h /usr/include/gtk-1.2/gtk/gtkstyle.h \
+dw_gtk_statuslabel.h /usr/include/string.h \
+- /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h
++ /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h
+dw_gtk_statuslabel.c :
+/usr/include/gtk-1.2/gtk/gtklabel.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+@@ -60,11 +56,3 @@ dw_gtk_statuslabel.c :
+dw_gtk_statuslabel.h :
+/usr/include/string.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/bits/types.h :
+-/usr/include/bits/pthreadtypes.h :
+-/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+diff -pru dillo-0.6.6/src/.deps/dw_image.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_image.P
+--- dillo-0.6.6/src/.deps/dw_image.P Tue Jun 4 10:43:51 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_image.P Mon Jun 10 12:50:32 2002
+@@ -6,7 +6,7 @@ dw_image.o: dw_image.c dw_image.h /usr/i
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h dw_widget.h \
++ /usr/include/bits/stdio_lim.h dw_widget.h \
+/usr/include/gtk-1.2/gtk/gtkobject.h /usr/include/gtk-1.2/gtk/gtkarg.h \
+/usr/include/gtk-1.2/gtk/gtktypeutils.h /usr/include/glib-1.2/glib.h \
+/usr/lib/glib/include/glibconfig.h \
+@@ -24,10 +24,8 @@ dw_image.o: dw_image.c dw_image.h /usr/i
+/usr/include/gtk-1.2/gtk/gtkaccelgroup.h \
+/usr/include/gtk-1.2/gtk/gtkadjustment.h \
+/usr/include/gtk-1.2/gtk/gtkdata.h /usr/include/gtk-1.2/gtk/gtkstyle.h \
+- dw_style.h dw_tooltip.h url.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h /usr/include/stdlib.h \
+- dw_gtk_viewport.h /usr/include/gtk-1.2/gtk/gtklayout.h \
++ dw_style.h dw_tooltip.h url.h /usr/include/string.h dw_gtk_viewport.h \
++ /usr/include/gtk-1.2/gtk/gtklayout.h \
+/usr/include/gtk-1.2/gtk/gtkcontainer.h prefs.h dw_marshal.h list.h \
+dicache.h bitvec.h image.h /usr/include/gtk-1.2/gtk/gtk.h \
+/usr/include/gtk-1.2/gtk/gtkaccellabel.h \
+@@ -132,7 +130,6 @@ dw_image.h :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+dw_widget.h :
+/usr/include/gtk-1.2/gtk/gtkobject.h :
+/usr/include/gtk-1.2/gtk/gtkarg.h :
+@@ -163,11 +160,6 @@ dw_style.h :
+dw_tooltip.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+dw_gtk_viewport.h :
+/usr/include/gtk-1.2/gtk/gtklayout.h :
+/usr/include/gtk-1.2/gtk/gtkcontainer.h :
+diff -pru dillo-0.6.6/src/.deps/dw_list_item.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_list_item.P
+--- dillo-0.6.6/src/.deps/dw_list_item.P Tue Jun 4 10:43:51 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_list_item.P Mon Jun 10 
+12:50:33 2002
+@@ -23,8 +23,7 @@ dw_list_item.o: dw_list_item.c dw_list_i
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/endian.h /usr/include/bits/endian.h url.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/stdlib.h
++ /usr/include/string.h
+dw_list_item.c :
+dw_list_item.h :
+dw_aligned_page.h :
+@@ -71,6 +70,3 @@ findtext.h :
+/usr/include/bits/endian.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+diff -pru dillo-0.6.6/src/.deps/dw_page.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_page.P
+--- dillo-0.6.6/src/.deps/dw_page.P Tue Jun 4 10:43:52 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_page.P Mon Jun 10 12:50:34 2002
+@@ -4,15 +4,12 @@ dw_page.o: dw_page.c /usr/include/ctype.
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/endian.h /usr/include/bits/endian.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/stdlib.h /usr/include/stdio.h /usr/include/libio.h \
+- /usr/include/_G_config.h /usr/include/wchar.h /usr/include/bits/wchar.h \
+- /usr/include/gconv.h \
++ /usr/include/stdio.h /usr/include/libio.h /usr/include/_G_config.h \
++ /usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+- /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -128,9 +125,6 @@ dw_page.c :
+/usr/include/endian.h :
+/usr/include/bits/endian.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+/usr/include/stdio.h :
+/usr/include/libio.h :
+/usr/include/_G_config.h :
+@@ -139,7 +133,6 @@ dw_page.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+diff -pru dillo-0.6.6/src/.deps/dw_style.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_style.P
+--- dillo-0.6.6/src/.deps/dw_style.P Tue Jun 4 10:43:53 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_style.P Mon Jun 10 12:50:34 2002
+@@ -20,14 +20,12 @@ dw_style.o: dw_style.c dw_style.h /usr/i
+/usr/include/gtk-1.2/gtk/gtkdata.h /usr/include/gtk-1.2/gtk/gtkstyle.h \
+prefs.h url.h /usr/include/string.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h /usr/include/stdio.h \
++ /usr/include/stdio.h /usr/include/bits/types.h \
++ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/ctype.h debug.h
++ /usr/include/bits/stdio_lim.h /usr/include/ctype.h \
++ /usr/include/endian.h /usr/include/bits/endian.h debug.h
+dw_style.c :
+dw_style.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+@@ -64,21 +62,17 @@ prefs.h :
+url.h :
+/usr/include/string.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
++/usr/include/stdio.h :
+/usr/include/bits/types.h :
+/usr/include/bits/pthreadtypes.h :
+/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+-/usr/include/stdio.h :
+/usr/include/libio.h :
+/usr/include/_G_config.h :
+/usr/include/wchar.h :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/ctype.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+debug.h :
+diff -pru dillo-0.6.6/src/.deps/dw_table.P 
+dillo-0.6.6-namedpipe/src/.deps/dw_table.P
+--- dillo-0.6.6/src/.deps/dw_table.P Tue Jun 4 10:43:54 2002
++++ dillo-0.6.6-namedpipe/src/.deps/dw_table.P Mon Jun 10 12:50:34 2002
+@@ -1,10 +1,6 @@
+dw_table.o: dw_table.c /usr/include/string.h /usr/include/features.h \
+/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
+- /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h dw_table.h \
++ /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h dw_table.h \
+dw_container.h dw_widget.h /usr/include/gtk-1.2/gtk/gtkobject.h \
+/usr/include/gtk-1.2/gtk/gtkarg.h \
+/usr/include/gtk-1.2/gtk/gtktypeutils.h /usr/include/glib-1.2/glib.h \
+@@ -24,8 +20,10 @@ dw_table.o: dw_table.c /usr/include/stri
+/usr/include/gtk-1.2/gtk/gtkaccelgroup.h \
+/usr/include/gtk-1.2/gtk/gtkadjustment.h \
+/usr/include/gtk-1.2/gtk/gtkdata.h /usr/include/gtk-1.2/gtk/gtkstyle.h \
+- dw_style.h findtext.h /usr/include/ctype.h bitvec.h list.h prefs.h \
+- url.h dw_gtk_viewport.h /usr/include/gtk-1.2/gtk/gtklayout.h \
++ dw_style.h findtext.h /usr/include/ctype.h /usr/include/bits/types.h \
++ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
++ /usr/include/endian.h /usr/include/bits/endian.h bitvec.h list.h \
++ prefs.h url.h dw_gtk_viewport.h /usr/include/gtk-1.2/gtk/gtklayout.h \
+/usr/include/gtk-1.2/gtk/gtkcontainer.h debug.h
+dw_table.c :
+/usr/include/string.h :
+@@ -33,14 +31,6 @@ dw_table.c :
+/usr/include/sys/cdefs.h :
+/usr/include/gnu/stubs.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/bits/types.h :
+-/usr/include/bits/pthreadtypes.h :
+-/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+dw_table.h :
+dw_container.h :
+dw_widget.h :
+@@ -73,6 +63,11 @@ dw_widget.h :
+dw_style.h :
+findtext.h :
+/usr/include/ctype.h :
++/usr/include/bits/types.h :
++/usr/include/bits/pthreadtypes.h :
++/usr/include/bits/sched.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+bitvec.h :
+list.h :
+prefs.h :
+diff -pru dillo-0.6.6/src/.deps/findtext.P 
+dillo-0.6.6-namedpipe/src/.deps/findtext.P
+--- dillo-0.6.6/src/.deps/findtext.P Tue Jun 4 10:43:56 2002
++++ dillo-0.6.6-namedpipe/src/.deps/findtext.P Mon Jun 10 12:50:36 2002
+@@ -1,12 +1,10 @@
+findtext.o: findtext.c /usr/include/string.h /usr/include/features.h \
+/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
+- /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
++ /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h findtext.h \
++ /usr/include/ctype.h /usr/include/bits/types.h \
++ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h findtext.h \
+- /usr/include/ctype.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -31,16 +29,13 @@ findtext.c :
+/usr/include/sys/cdefs.h :
+/usr/include/gnu/stubs.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
++findtext.h :
++/usr/include/ctype.h :
+/usr/include/bits/types.h :
+/usr/include/bits/pthreadtypes.h :
+/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+-findtext.h :
+-/usr/include/ctype.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/glib-1.2/glib.h :
+/usr/lib/glib/include/glibconfig.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h :
+diff -pru dillo-0.6.6/src/.deps/gif.P dillo-0.6.6-namedpipe/src/.deps/gif.P
+--- dillo-0.6.6/src/.deps/gif.P Tue Jun 4 10:44:01 2002
++++ dillo-0.6.6-namedpipe/src/.deps/gif.P Mon Jun 10 12:50:41 2002
+@@ -5,10 +5,7 @@ gif.o: gif.c /usr/include/stdio.h /usr/i
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h \
++ /usr/include/bits/stdio_lim.h /usr/include/string.h \
+/usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+/usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+/usr/lib/glib/include/glibconfig.h \
+@@ -115,6 +112,7 @@ gif.o: gif.c /usr/include/stdio.h /usr/i
+/usr/include/gtk-1.2/gtk/gtkvseparator.h image.h dw_image.h dw_widget.h \
+dw_style.h dw_tooltip.h url.h bitvec.h web.h cache.h chain.h html.h \
+browser.h /usr/include/sys/types.h /usr/include/time.h \
++ /usr/include/endian.h /usr/include/bits/endian.h \
+/usr/include/sys/select.h /usr/include/bits/select.h \
+/usr/include/bits/sigset.h /usr/include/bits/time.h \
+/usr/include/sys/sysmacros.h dicache.h prefs.h
+@@ -134,13 +132,7 @@ gif.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+@@ -279,6 +271,8 @@ html.h :
+browser.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/bits/sigset.h :
+diff -pru dillo-0.6.6/src/.deps/history.P 
+dillo-0.6.6-namedpipe/src/.deps/history.P
+--- dillo-0.6.6/src/.deps/history.P Tue Jun 4 10:44:08 2002
++++ dillo-0.6.6-namedpipe/src/.deps/history.P Mon Jun 10 12:50:46 2002
+@@ -9,11 +9,7 @@ history.o: history.c list.h history.h /u
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/float.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h url.h \
+/usr/include/string.h \
+- /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h
++ /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h
+history.c :
+list.h :
+history.h :
+@@ -34,11 +30,3 @@ history.h :
+url.h :
+/usr/include/string.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/bits/types.h :
+-/usr/include/bits/pthreadtypes.h :
+-/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+diff -pru dillo-0.6.6/src/.deps/html.P 
+dillo-0.6.6-namedpipe/src/.deps/html.P
+--- dillo-0.6.6/src/.deps/html.P Tue Jun 4 10:44:06 2002
++++ dillo-0.6.6-namedpipe/src/.deps/html.P Mon Jun 10 12:50:44 2002
+@@ -4,7 +4,6 @@ html.o: html.c /usr/include/ctype.h /usr
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/endian.h /usr/include/bits/endian.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+/usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+/usr/include/sys/select.h /usr/include/bits/select.h \
+/usr/include/bits/sigset.h /usr/include/bits/time.h \
+@@ -12,10 +11,9 @@ html.o: html.c /usr/include/ctype.h /usr
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/math.h /usr/include/bits/huge_val.h \
+- /usr/include/bits/mathdef.h /usr/include/bits/mathcalls.h \
+- /usr/include/bits/mathinline.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/bits/stdio_lim.h /usr/include/math.h \
++ /usr/include/bits/huge_val.h /usr/include/bits/mathdef.h \
++ /usr/include/bits/mathcalls.h /usr/include/gtk-1.2/gtk/gtk.h \
+/usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
+/usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+@@ -139,8 +137,6 @@ html.c :
+/usr/include/endian.h :
+/usr/include/bits/endian.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -158,12 +154,10 @@ html.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/math.h :
+/usr/include/bits/huge_val.h :
+/usr/include/bits/mathdef.h :
+/usr/include/bits/mathcalls.h :
+-/usr/include/bits/mathinline.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+diff -pru dillo-0.6.6/src/.deps/image.P 
+dillo-0.6.6-namedpipe/src/.deps/image.P
+--- dillo-0.6.6/src/.deps/image.P Tue Jun 4 10:44:06 2002
++++ dillo-0.6.6-namedpipe/src/.deps/image.P Mon Jun 10 12:50:45 2002
+@@ -108,10 +108,7 @@ image.o: image.c /usr/include/gtk-1.2/gt
+/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h image.h dw_image.h \
++ /usr/include/bits/stdio_lim.h /usr/include/string.h image.h dw_image.h \
+dw_widget.h dw_style.h dw_tooltip.h url.h bitvec.h
+image.c :
+/usr/include/gtk-1.2/gtk/gtk.h :
+@@ -253,13 +250,7 @@ image.c :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+image.h :
+dw_image.h :
+dw_widget.h :
+diff -pru dillo-0.6.6/src/.deps/interface.P 
+dillo-0.6.6-namedpipe/src/.deps/interface.P
+--- dillo-0.6.6/src/.deps/interface.P Tue Jun 4 10:44:08 2002
++++ dillo-0.6.6-namedpipe/src/.deps/interface.P Mon Jun 10 12:50:46 2002
+@@ -5,8 +5,8 @@ interface.o: interface.c /usr/include/st
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/ctype.h /usr/include/endian.h /usr/include/bits/endian.h \
++ /usr/include/bits/stdio_lim.h /usr/include/ctype.h \
++ /usr/include/endian.h /usr/include/bits/endian.h \
+/usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+/usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+/usr/lib/glib/include/glibconfig.h \
+@@ -116,16 +116,14 @@ interface.o: interface.c /usr/include/st
+/usr/include/bits/time.h /usr/include/sys/sysmacros.h \
+/usr/include/sys/stat.h /usr/include/bits/stat.h \
+/usr/include/sys/time.h /usr/include/fcntl.h /usr/include/bits/fcntl.h \
+- list.h dillo.h browser.h url.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/stdlib.h web.h cache.h chain.h html.h dw_widget.h \
+- dw_style.h dw_image.h dw_tooltip.h image.h bitvec.h history.h nav.h \
+- IO/Url.h ../config.h IO/IO.h /usr/include/unistd.h \
+- /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+- /usr/include/getopt.h /usr/include/sys/uio.h /usr/include/bits/uio.h \
+- interface.h commands.h menu.h bookmark.h prefs.h \
+- dw_gtk_scrolled_window.h dw_gtk_viewport.h dw_gtk_statuslabel.h \
+- dw_container.h findtext.h progressbar.h pixmaps.h \
++ list.h dillo.h browser.h url.h /usr/include/string.h web.h cache.h \
++ chain.h html.h dw_widget.h dw_style.h dw_image.h dw_tooltip.h image.h \
++ bitvec.h history.h nav.h IO/Url.h ../config.h IO/IO.h \
++ /usr/include/unistd.h /usr/include/bits/posix_opt.h \
++ /usr/include/bits/confname.h /usr/include/getopt.h \
++ /usr/include/sys/uio.h /usr/include/bits/uio.h interface.h commands.h \
++ menu.h bookmark.h prefs.h dw_gtk_scrolled_window.h dw_gtk_viewport.h \
++ dw_gtk_statuslabel.h dw_container.h findtext.h progressbar.h pixmaps.h \
+/usr/include/gtk-1.2/gdk/gdkkeysyms.h debug.h
+interface.c :
+/usr/include/stdio.h :
+@@ -143,7 +141,6 @@ interface.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/ctype.h :
+/usr/include/endian.h :
+/usr/include/bits/endian.h :
+@@ -288,9 +285,6 @@ dillo.h :
+browser.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+web.h :
+cache.h :
+chain.h :
+diff -pru dillo-0.6.6/src/.deps/jpeg.P 
+dillo-0.6.6-namedpipe/src/.deps/jpeg.P
+--- dillo-0.6.6/src/.deps/jpeg.P Tue Jun 4 10:44:02 2002
++++ dillo-0.6.6-namedpipe/src/.deps/jpeg.P Mon Jun 10 12:50:42 2002
+@@ -5,10 +5,9 @@ jpeg.o: jpeg.c /usr/include/stdio.h /usr
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+- /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -113,12 +112,11 @@ jpeg.o: jpeg.c /usr/include/stdio.h /usr
+/usr/include/bits/setjmp.h /usr/include/bits/sigset.h \
+/usr/include/jpeglib.h /usr/include/jconfig.h /usr/include/jmorecfg.h \
+image.h dw_image.h dw_widget.h dw_style.h dw_tooltip.h url.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h bitvec.h web.h cache.h \
+- chain.h html.h browser.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/time.h /usr/include/sys/sysmacros.h dicache.h
++ /usr/include/string.h bitvec.h web.h cache.h chain.h html.h browser.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/time.h \
++ /usr/include/sys/sysmacros.h dicache.h
+jpeg.c :
+/usr/include/stdio.h :
+/usr/include/features.h :
+@@ -135,7 +133,6 @@ jpeg.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+@@ -273,11 +270,6 @@ dw_style.h :
+dw_tooltip.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+bitvec.h :
+web.h :
+cache.h :
+@@ -286,6 +278,8 @@ html.h :
+browser.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/bits/time.h :
+diff -pru dillo-0.6.6/src/.deps/menu.P 
+dillo-0.6.6-namedpipe/src/.deps/menu.P
+--- dillo-0.6.6/src/.deps/menu.P Tue Jun 4 10:44:11 2002
++++ dillo-0.6.6-namedpipe/src/.deps/menu.P Mon Jun 10 12:50:49 2002
+@@ -5,16 +5,15 @@ menu.o: menu.c /usr/include/stdio.h /usr
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/alloca.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/gtk-1.2/gtk/gtk.h \
+- /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
+- /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/alloca.h /usr/include/string.h \
++ /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
++ /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
++ /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -135,7 +134,6 @@ menu.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -148,8 +146,6 @@ menu.c :
+/usr/include/sys/sysmacros.h :
+/usr/include/alloca.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+diff -pru dillo-0.6.6/src/.deps/misc.P 
+dillo-0.6.6-namedpipe/src/.deps/misc.P
+--- dillo-0.6.6/src/.deps/misc.P Tue Jun 4 10:44:07 2002
++++ dillo-0.6.6-namedpipe/src/.deps/misc.P Mon Jun 10 12:50:45 2002
+@@ -108,16 +108,14 @@ misc.o: misc.c /usr/include/gtk-1.2/gtk/
+/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/alloca.h \
+- /usr/include/unistd.h /usr/include/bits/posix_opt.h \
+- /usr/include/bits/confname.h /usr/include/getopt.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/ctype.h
++ /usr/include/bits/stdio_lim.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/alloca.h /usr/include/unistd.h \
++ /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
++ /usr/include/getopt.h /usr/include/string.h /usr/include/ctype.h
+misc.c :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+@@ -258,7 +256,6 @@ misc.c :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -275,6 +272,4 @@ misc.c :
+/usr/include/bits/confname.h :
+/usr/include/getopt.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/ctype.h :
+diff -pru dillo-0.6.6/src/.deps/nav.P dillo-0.6.6-namedpipe/src/.deps/nav.P
+--- dillo-0.6.6/src/.deps/nav.P Tue Jun 4 10:44:09 2002
++++ dillo-0.6.6-namedpipe/src/.deps/nav.P Mon Jun 10 12:50:47 2002
+@@ -5,10 +5,9 @@ nav.o: nav.c /usr/include/stdio.h /usr/i
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+- /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -114,11 +113,9 @@ nav.o: nav.c /usr/include/stdio.h /usr/i
+/usr/include/bits/endian.h /usr/include/sys/select.h \
+/usr/include/bits/select.h /usr/include/bits/sigset.h \
+/usr/include/bits/time.h /usr/include/sys/sysmacros.h url.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/stdlib.h dw_widget.h \
+- dw_style.h history.h web.h cache.h chain.h html.h dw_image.h \
+- dw_tooltip.h image.h bitvec.h menu.h interface.h \
+- dw_gtk_scrolled_window.h prefs.h commands.h debug.h
++ /usr/include/string.h dw_widget.h dw_style.h history.h web.h cache.h \
++ chain.h html.h dw_image.h dw_tooltip.h image.h bitvec.h menu.h \
++ interface.h dw_gtk_scrolled_window.h prefs.h commands.h debug.h
+nav.c :
+/usr/include/stdio.h :
+/usr/include/features.h :
+@@ -135,7 +132,6 @@ nav.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+@@ -274,9 +270,6 @@ browser.h :
+/usr/include/sys/sysmacros.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/stdlib.h :
+dw_widget.h :
+dw_style.h :
+history.h :
+diff -pru dillo-0.6.6/src/.deps/plain.P 
+dillo-0.6.6-namedpipe/src/.deps/plain.P
+--- dillo-0.6.6/src/.deps/plain.P Tue Jun 4 10:44:10 2002
++++ dillo-0.6.6-namedpipe/src/.deps/plain.P Mon Jun 10 12:50:48 2002
+@@ -1,12 +1,8 @@
+plain.o: plain.c /usr/include/string.h /usr/include/features.h \
+/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h /usr/include/math.h \
+- /usr/include/bits/huge_val.h /usr/include/bits/mathdef.h \
+- /usr/include/bits/mathcalls.h /usr/include/bits/mathinline.h \
++ /usr/include/math.h /usr/include/bits/huge_val.h \
++ /usr/include/bits/mathdef.h /usr/include/bits/mathcalls.h \
+/usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+/usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+/usr/lib/glib/include/glibconfig.h \
+@@ -113,34 +109,26 @@ plain.o: plain.c /usr/include/string.h /
+/usr/include/gtk-1.2/gtk/gtkvscale.h \
+/usr/include/gtk-1.2/gtk/gtkvseparator.h prefs.h url.h dw_page.h \
+dw_container.h dw_widget.h dw_style.h findtext.h /usr/include/ctype.h \
+- cache.h chain.h browser.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h web.h html.h dw_image.h \
+- /usr/include/stdio.h /usr/include/libio.h /usr/include/_G_config.h \
+- /usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h dw_tooltip.h \
+- image.h bitvec.h interface.h progressbar.h misc.h history.h nav.h \
+- menu.h
++ /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
++ /usr/include/bits/sched.h /usr/include/endian.h \
++ /usr/include/bits/endian.h cache.h chain.h browser.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h web.h html.h \
++ dw_image.h /usr/include/stdio.h /usr/include/libio.h \
++ /usr/include/_G_config.h /usr/include/wchar.h /usr/include/bits/wchar.h \
++ /usr/include/gconv.h /usr/include/bits/stdio_lim.h dw_tooltip.h image.h \
++ bitvec.h interface.h progressbar.h misc.h history.h nav.h menu.h
+plain.c :
+/usr/include/string.h :
+/usr/include/features.h :
+/usr/include/sys/cdefs.h :
+/usr/include/gnu/stubs.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/bits/types.h :
+-/usr/include/bits/pthreadtypes.h :
+-/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+/usr/include/math.h :
+/usr/include/bits/huge_val.h :
+/usr/include/bits/mathdef.h :
+/usr/include/bits/mathcalls.h :
+-/usr/include/bits/mathinline.h :
+/usr/include/gtk-1.2/gtk/gtk.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+@@ -274,6 +262,11 @@ dw_widget.h :
+dw_style.h :
+findtext.h :
+/usr/include/ctype.h :
++/usr/include/bits/types.h :
++/usr/include/bits/pthreadtypes.h :
++/usr/include/bits/sched.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+cache.h :
+chain.h :
+browser.h :
+@@ -294,7 +287,6 @@ dw_image.h :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+dw_tooltip.h :
+image.h :
+bitvec.h :
+diff -pru dillo-0.6.6/src/.deps/png.P dillo-0.6.6-namedpipe/src/.deps/png.P
+--- dillo-0.6.6/src/.deps/png.P Tue Jun 4 10:44:03 2002
++++ dillo-0.6.6-namedpipe/src/.deps/png.P Mon Jun 10 12:50:43 2002
+@@ -5,18 +5,17 @@ png.o: png.c /usr/include/stdio.h /usr/i
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h \
+- /usr/include/sys/types.h /usr/include/time.h /usr/include/sys/select.h \
+- /usr/include/bits/select.h /usr/include/bits/sigset.h \
+- /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
+- /usr/include/alloca.h /usr/include/zlib.h /usr/include/zconf.h \
+- /usr/include/png.h /usr/include/pngconf.h /usr/include/setjmp.h \
+- /usr/include/bits/setjmp.h /usr/include/gtk-1.2/gtk/gtk.h \
+- /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
+- /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/string.h \
++ /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
++ /usr/include/endian.h /usr/include/bits/endian.h \
++ /usr/include/sys/select.h /usr/include/bits/select.h \
++ /usr/include/bits/sigset.h /usr/include/bits/time.h \
++ /usr/include/sys/sysmacros.h /usr/include/alloca.h /usr/include/zlib.h \
++ /usr/include/zconf.h /usr/include/png.h /usr/include/pngconf.h \
++ /usr/include/setjmp.h /usr/include/bits/setjmp.h \
++ /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
++ /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
++ /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -136,15 +135,12 @@ png.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/bits/sigset.h :
+diff -pru dillo-0.6.6/src/.deps/prefs.P 
+dillo-0.6.6-namedpipe/src/.deps/prefs.P
+--- dillo-0.6.6/src/.deps/prefs.P Tue Jun 4 10:44:12 2002
++++ dillo-0.6.6-namedpipe/src/.deps/prefs.P Mon Jun 10 12:50:49 2002
+@@ -16,11 +16,10 @@ prefs.o: prefs.c /usr/include/glib-1.2/g
+/usr/include/bits/sigset.h /usr/include/bits/time.h \
+/usr/include/sys/sysmacros.h /usr/include/sys/stat.h \
+/usr/include/bits/stat.h /usr/include/stdlib.h /usr/include/alloca.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/fcntl.h \
+- /usr/include/bits/fcntl.h /usr/include/locale.h \
+- /usr/include/bits/locale.h prefs.h url.h colors.h dillo.h browser.h \
+- /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/string.h /usr/include/fcntl.h /usr/include/bits/fcntl.h \
++ /usr/include/locale.h /usr/include/bits/locale.h prefs.h url.h colors.h \
++ dillo.h browser.h /usr/include/gtk-1.2/gdk/gdk.h \
++ /usr/include/gtk-1.2/gdk/gdktypes.h \
+/usr/include/gtk-1.2/gdk/gdkcursors.h /usr/include/gtk-1.2/gdk/gdkrgb.h \
+/usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gtk/gtkaccelgroup.h \
+/usr/include/gtk-1.2/gtk/gtkobject.h /usr/include/gtk-1.2/gtk/gtkarg.h \
+@@ -119,8 +118,7 @@ prefs.o: prefs.c /usr/include/glib-1.2/g
+dw_widget.h dw_style.h dw_image.h /usr/include/stdio.h \
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h dw_tooltip.h \
+- image.h bitvec.h misc.h
++ /usr/include/bits/stdio_lim.h dw_tooltip.h image.h bitvec.h misc.h
+prefs.c :
+/usr/include/glib-1.2/glib.h :
+/usr/lib/glib/include/glibconfig.h :
+@@ -154,8 +152,6 @@ prefs.c :
+/usr/include/stdlib.h :
+/usr/include/alloca.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/fcntl.h :
+/usr/include/bits/fcntl.h :
+/usr/include/locale.h :
+@@ -293,7 +289,6 @@ dw_image.h :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+dw_tooltip.h :
+image.h :
+bitvec.h :
+diff -pru dillo-0.6.6/src/.deps/progressbar.P 
+dillo-0.6.6-namedpipe/src/.deps/progressbar.P
+--- dillo-0.6.6/src/.deps/progressbar.P Tue Jun 4 10:43:57 2002
++++ dillo-0.6.6-namedpipe/src/.deps/progressbar.P Mon Jun 10 12:50:37 
+2002
+@@ -2,16 +2,14 @@ progressbar.o: progressbar.c /usr/includ
+/usr/include/features.h /usr/include/sys/cdefs.h \
+/usr/include/gnu/stubs.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h /usr/include/stdio.h \
++ /usr/include/stdio.h /usr/include/bits/types.h \
++ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
+- /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/gtk-1.2/gdk/gdk.h \
++ /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
++ /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -119,15 +117,10 @@ progressbar.c :
+/usr/include/sys/cdefs.h :
+/usr/include/gnu/stubs.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
++/usr/include/stdio.h :
+/usr/include/bits/types.h :
+/usr/include/bits/pthreadtypes.h :
+/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+-/usr/include/stdio.h :
+/usr/include/libio.h :
+/usr/include/_G_config.h :
+/usr/include/wchar.h :
+@@ -135,7 +128,6 @@ progressbar.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/gtk-1.2/gdk/gdk.h :
+/usr/include/gtk-1.2/gdk/gdktypes.h :
+/usr/include/glib-1.2/glib.h :
+diff -pru dillo-0.6.6/src/.deps/url.P dillo-0.6.6-namedpipe/src/.deps/url.P
+--- dillo-0.6.6/src/.deps/url.P Tue Jun 4 10:44:13 2002
++++ dillo-0.6.6-namedpipe/src/.deps/url.P Mon Jun 10 12:50:50 2002
+@@ -5,14 +5,12 @@ url.o: url.c /usr/include/stdio.h /usr/i
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/alloca.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/ctype.h \
++ /usr/include/bits/stdio_lim.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/alloca.h /usr/include/string.h /usr/include/ctype.h \
+/usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+@@ -36,7 +34,6 @@ url.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -49,8 +46,6 @@ url.c :
+/usr/include/sys/sysmacros.h :
+/usr/include/alloca.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/ctype.h :
+/usr/include/glib-1.2/glib.h :
+/usr/lib/glib/include/glibconfig.h :
+diff -pru dillo-0.6.6/src/.deps/web.P dillo-0.6.6-namedpipe/src/.deps/web.P
+--- dillo-0.6.6/src/.deps/web.P Tue Jun 4 10:43:56 2002
++++ dillo-0.6.6-namedpipe/src/.deps/web.P Mon Jun 10 12:50:37 2002
+@@ -5,15 +5,14 @@ web.o: web.c /usr/include/stdio.h /usr/i
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/alloca.h \
+- /usr/include/gtk-1.2/gtk/gtk.h /usr/include/gtk-1.2/gdk/gdk.h \
+- /usr/include/gtk-1.2/gdk/gdktypes.h /usr/include/glib-1.2/glib.h \
+- /usr/lib/glib/include/glibconfig.h \
++ /usr/include/bits/stdio_lim.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/alloca.h /usr/include/gtk-1.2/gtk/gtk.h \
++ /usr/include/gtk-1.2/gdk/gdk.h /usr/include/gtk-1.2/gdk/gdktypes.h \
++ /usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -116,9 +115,8 @@ web.o: web.c /usr/include/stdio.h /usr/i
+/usr/include/gtk-1.2/gtk/gtkvscale.h \
+/usr/include/gtk-1.2/gtk/gtkvseparator.h /usr/include/math.h \
+/usr/include/bits/huge_val.h /usr/include/bits/mathdef.h \
+- /usr/include/bits/mathcalls.h /usr/include/bits/mathinline.h dillo.h \
+- browser.h url.h /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h web.h cache.h chain.h html.h dw_widget.h \
++ /usr/include/bits/mathcalls.h dillo.h browser.h url.h \
++ /usr/include/string.h web.h cache.h chain.h html.h dw_widget.h \
+dw_style.h dw_image.h dw_tooltip.h image.h bitvec.h nav.h interface.h \
+IO/IO.h /usr/include/unistd.h /usr/include/bits/posix_opt.h \
+/usr/include/bits/confname.h /usr/include/getopt.h \
+@@ -140,7 +138,6 @@ web.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -280,13 +277,10 @@ web.c :
+/usr/include/bits/huge_val.h :
+/usr/include/bits/mathdef.h :
+/usr/include/bits/mathcalls.h :
+-/usr/include/bits/mathinline.h :
+dillo.h :
+browser.h :
+url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+web.h :
+cache.h :
+chain.h :
+Only in dillo-0.6.6-namedpipe/src: CVS
+Only in dillo-0.6.6-namedpipe/src/IO/.deps: CVS
+diff -pru dillo-0.6.6/src/IO/.deps/IO.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/IO.P
+--- dillo-0.6.6/src/IO/.deps/IO.P Tue Jun 4 10:43:42 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/IO.P Mon Jun 10 12:50:25 2002
+@@ -5,18 +5,18 @@ IO.o: IO.c /usr/include/stdio.h /usr/inc
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/errno.h /usr/include/bits/errno.h \
+- /usr/include/linux/errno.h /usr/include/asm/errno.h \
+- /usr/include/fcntl.h /usr/include/bits/fcntl.h /usr/include/sys/types.h \
+- /usr/include/time.h /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/unistd.h \
+- /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+- /usr/include/getopt.h /usr/include/sys/stat.h /usr/include/bits/stat.h \
+- /usr/include/sys/uio.h /usr/include/bits/uio.h \
+- /usr/include/sys/socket.h /usr/include/bits/socket.h \
++ /usr/include/bits/stdio_lim.h /usr/include/errno.h \
++ /usr/include/bits/errno.h /usr/include/linux/errno.h \
++ /usr/include/asm/errno.h /usr/include/fcntl.h /usr/include/bits/fcntl.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/unistd.h /usr/include/bits/posix_opt.h \
++ /usr/include/bits/confname.h /usr/include/getopt.h \
++ /usr/include/sys/stat.h /usr/include/bits/stat.h /usr/include/sys/uio.h \
++ /usr/include/bits/uio.h /usr/include/sys/socket.h \
++ /usr/include/bits/socket.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/syslimits.h \
+/usr/include/limits.h /usr/include/bits/posix1_lim.h \
+@@ -44,7 +44,6 @@ IO.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/errno.h :
+/usr/include/bits/errno.h :
+/usr/include/linux/errno.h :
+diff -pru dillo-0.6.6/src/IO/.deps/Url.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/Url.P
+--- dillo-0.6.6/src/IO/.deps/Url.P Tue Jun 4 10:43:39 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/Url.P Mon Jun 10 12:50:22 2002
+@@ -17,8 +17,7 @@ Url.o: Url.c /usr/include/glib-1.2/glib.
+/usr/include/bits/sigset.h /usr/include/bits/time.h \
+/usr/include/sys/sysmacros.h /usr/include/alloca.h /usr/include/ctype.h \
+../list.h ../misc.h Url.h ../../config.h ../chain.h ../url.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h IO.h /usr/include/unistd.h \
++ /usr/include/string.h IO.h /usr/include/unistd.h \
+/usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+/usr/include/getopt.h /usr/include/sys/uio.h /usr/include/bits/uio.h
+Url.c :
+@@ -59,8 +58,6 @@ Url.h :
+../chain.h :
+../url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+IO.h :
+/usr/include/unistd.h :
+/usr/include/bits/posix_opt.h :
+diff -pru dillo-0.6.6/src/IO/.deps/about.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/about.P
+--- dillo-0.6.6/src/IO/.deps/about.P Tue Jun 4 10:43:39 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/about.P Mon Jun 10 12:50:22 2002
+@@ -14,12 +14,10 @@ about.o: about.c /usr/include/pthread.h
+/usr/include/bits/posix2_lim.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/float.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h ../../config.h \
+- ../chain.h ../url.h /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/endian.h \
+- /usr/include/bits/endian.h /usr/include/stdlib.h IO.h \
+- /usr/include/unistd.h /usr/include/bits/posix_opt.h \
+- /usr/include/bits/confname.h /usr/include/getopt.h \
+- /usr/include/sys/uio.h /usr/include/sys/types.h \
++ ../chain.h ../url.h /usr/include/string.h IO.h /usr/include/unistd.h \
++ /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
++ /usr/include/getopt.h /usr/include/sys/uio.h /usr/include/sys/types.h \
++ /usr/include/endian.h /usr/include/bits/endian.h \
+/usr/include/sys/select.h /usr/include/bits/select.h \
+/usr/include/sys/sysmacros.h /usr/include/bits/uio.h ../nav.h \
+../browser.h /usr/include/gtk-1.2/gdk/gdk.h \
+@@ -122,8 +120,7 @@ about.o: about.c /usr/include/pthread.h
+../web.h ../cache.h ../html.h ../dw_image.h /usr/include/stdio.h \
+/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
+/usr/include/bits/wchar.h /usr/include/gconv.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h ../dw_tooltip.h \
+- ../image.h ../bitvec.h
++ /usr/include/bits/stdio_lim.h ../dw_tooltip.h ../image.h ../bitvec.h
+about.c :
+/usr/include/pthread.h :
+/usr/include/features.h :
+@@ -156,11 +153,6 @@ Url.h :
+../chain.h :
+../url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/stdlib.h :
+IO.h :
+/usr/include/unistd.h :
+/usr/include/bits/posix_opt.h :
+@@ -168,6 +160,8 @@ IO.h :
+/usr/include/getopt.h :
+/usr/include/sys/uio.h :
+/usr/include/sys/types.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/sys/sysmacros.h :
+@@ -301,7 +295,6 @@ IO.h :
+/usr/include/bits/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+../dw_tooltip.h :
+../image.h :
+../bitvec.h :
+diff -pru dillo-0.6.6/src/IO/.deps/file.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/file.P
+--- dillo-0.6.6/src/IO/.deps/file.P Tue Jun 4 10:43:41 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/file.P Mon Jun 10 12:50:24 2002
+@@ -15,17 +15,15 @@ file.o: file.c /usr/include/pthread.h /u
+/usr/include/bits/dirent.h /usr/include/bits/posix1_lim.h \
+/usr/include/bits/local_lim.h /usr/include/linux/limits.h \
+/usr/include/fcntl.h /usr/include/bits/fcntl.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+/usr/include/stdio.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/bits/signum.h /usr/include/bits/siginfo.h \
+- /usr/include/bits/wordsize.h /usr/include/bits/sigaction.h \
+- /usr/include/bits/sigcontext.h /usr/include/asm/sigcontext.h \
+- /usr/include/bits/sigstack.h /usr/include/math.h \
+- /usr/include/bits/huge_val.h /usr/include/bits/mathdef.h \
+- /usr/include/bits/mathcalls.h /usr/include/bits/mathinline.h \
++ /usr/include/bits/stdio_lim.h /usr/include/bits/signum.h \
++ /usr/include/bits/siginfo.h /usr/include/bits/wordsize.h \
++ /usr/include/bits/sigaction.h /usr/include/bits/sigcontext.h \
++ /usr/include/asm/sigcontext.h /usr/include/bits/sigstack.h \
++ /usr/include/math.h /usr/include/bits/huge_val.h \
++ /usr/include/bits/mathdef.h /usr/include/bits/mathcalls.h \
+/usr/include/errno.h /usr/include/bits/errno.h \
+/usr/include/linux/errno.h /usr/include/asm/errno.h Url.h \
+/usr/include/glib-1.2/glib.h /usr/lib/glib/include/glibconfig.h \
+@@ -172,8 +170,6 @@ file.c :
+/usr/include/fcntl.h :
+/usr/include/bits/fcntl.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/stdio.h :
+/usr/include/libio.h :
+/usr/include/_G_config.h :
+@@ -182,7 +178,6 @@ file.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/bits/signum.h :
+/usr/include/bits/siginfo.h :
+/usr/include/bits/wordsize.h :
+@@ -194,7 +189,6 @@ file.c :
+/usr/include/bits/huge_val.h :
+/usr/include/bits/mathdef.h :
+/usr/include/bits/mathcalls.h :
+-/usr/include/bits/mathinline.h :
+/usr/include/errno.h :
+/usr/include/bits/errno.h :
+/usr/include/linux/errno.h :
+diff -pru dillo-0.6.6/src/IO/.deps/http.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/http.P
+--- dillo-0.6.6/src/IO/.deps/http.P Tue Jun 4 10:43:42 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/http.P Mon Jun 10 12:50:25 2002
+@@ -5,10 +5,9 @@ http.o: http.c /usr/include/unistd.h /us
+/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
+/usr/include/bits/confname.h /usr/include/getopt.h /usr/include/errno.h \
+/usr/include/bits/errno.h /usr/include/linux/errno.h \
+- /usr/include/asm/errno.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h /usr/include/stdlib.h \
+- /usr/include/sys/types.h /usr/include/time.h /usr/include/sys/select.h \
++ /usr/include/asm/errno.h /usr/include/string.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
+/usr/include/bits/select.h /usr/include/bits/sigset.h \
+/usr/include/bits/time.h /usr/include/sys/sysmacros.h \
+/usr/include/alloca.h /usr/include/signal.h /usr/include/bits/signum.h \
+@@ -134,8 +133,8 @@ http.o: http.c /usr/include/unistd.h /us
+../browser.h ../dw_widget.h ../dw_style.h ../dw_image.h \
+/usr/include/stdio.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/gconv.h /usr/include/bits/stdio_lim.h \
+- /usr/include/bits/stdio.h ../dw_tooltip.h ../image.h ../bitvec.h \
+- ../interface.h ../cookies.h ../prefs.h ../debug.h
++ ../dw_tooltip.h ../image.h ../bitvec.h ../interface.h ../cookies.h \
++ ../prefs.h ../debug.h
+http.c :
+/usr/include/unistd.h :
+/usr/include/features.h :
+@@ -153,13 +152,11 @@ http.c :
+/usr/include/linux/errno.h :
+/usr/include/asm/errno.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/bits/sigset.h :
+@@ -339,7 +336,6 @@ IO.h :
+/usr/include/wchar.h :
+/usr/include/gconv.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+../dw_tooltip.h :
+../image.h :
+../bitvec.h :
+diff -pru dillo-0.6.6/src/IO/.deps/mime.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/mime.P
+--- dillo-0.6.6/src/IO/.deps/mime.P Tue Jun 4 10:43:38 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/mime.P Mon Jun 10 12:50:21 2002
+@@ -106,18 +106,16 @@ mime.o: mime.c mime.h \
+/usr/include/gtk-1.2/gtk/gtkvruler.h \
+/usr/include/gtk-1.2/gtk/gtkvscale.h \
+/usr/include/gtk-1.2/gtk/gtkvseparator.h ../dw_widget.h ../dw_style.h \
+- ../cache.h ../chain.h ../url.h /usr/include/string.h \
+- /usr/include/bits/string.h /usr/include/bits/string2.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
+- /usr/include/bits/sched.h /usr/include/stdlib.h ../IO/Url.h \
++ ../cache.h ../chain.h ../url.h /usr/include/string.h ../IO/Url.h \
+../../config.h ../IO/IO.h /usr/include/unistd.h \
+- /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
+- /usr/include/getopt.h /usr/include/sys/uio.h /usr/include/sys/types.h \
+- /usr/include/time.h /usr/include/sys/select.h \
+- /usr/include/bits/select.h /usr/include/bits/sigset.h \
+- /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
+- /usr/include/bits/uio.h ../list.h
++ /usr/include/bits/posix_opt.h /usr/include/bits/types.h \
++ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
++ /usr/include/bits/confname.h /usr/include/getopt.h \
++ /usr/include/sys/uio.h /usr/include/sys/types.h /usr/include/time.h \
++ /usr/include/endian.h /usr/include/bits/endian.h \
++ /usr/include/sys/select.h /usr/include/bits/select.h \
++ /usr/include/bits/sigset.h /usr/include/bits/time.h \
++ /usr/include/sys/sysmacros.h /usr/include/bits/uio.h ../list.h
+mime.c :
+mime.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h :
+@@ -255,24 +253,21 @@ mime.h :
+../chain.h :
+../url.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+-/usr/include/endian.h :
+-/usr/include/bits/endian.h :
+-/usr/include/bits/types.h :
+-/usr/include/bits/pthreadtypes.h :
+-/usr/include/bits/sched.h :
+-/usr/include/stdlib.h :
+../IO/Url.h :
+../../config.h :
+../IO/IO.h :
+/usr/include/unistd.h :
+/usr/include/bits/posix_opt.h :
++/usr/include/bits/types.h :
++/usr/include/bits/pthreadtypes.h :
++/usr/include/bits/sched.h :
+/usr/include/bits/confname.h :
+/usr/include/getopt.h :
+/usr/include/sys/uio.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
++/usr/include/endian.h :
++/usr/include/bits/endian.h :
+/usr/include/sys/select.h :
+/usr/include/bits/select.h :
+/usr/include/bits/sigset.h :
+diff -pru dillo-0.6.6/src/IO/.deps/proto.P 
+dillo-0.6.6-namedpipe/src/IO/.deps/proto.P
+--- dillo-0.6.6/src/IO/.deps/proto.P Tue Jun 4 10:43:40 2002
++++ dillo-0.6.6-namedpipe/src/IO/.deps/proto.P Mon Jun 10 12:50:23 2002
+@@ -5,16 +5,14 @@ proto.o: proto.c /usr/include/stdio.h /u
+/usr/include/bits/sched.h /usr/include/libio.h /usr/include/_G_config.h \
+/usr/include/wchar.h /usr/include/bits/wchar.h /usr/include/gconv.h \
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h \
+- /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \
+- /usr/include/stdlib.h /usr/include/sys/types.h /usr/include/time.h \
+- /usr/include/endian.h /usr/include/bits/endian.h \
+- /usr/include/sys/select.h /usr/include/bits/select.h \
+- /usr/include/bits/sigset.h /usr/include/bits/time.h \
+- /usr/include/sys/sysmacros.h /usr/include/alloca.h \
+- /usr/include/unistd.h /usr/include/bits/posix_opt.h \
+- /usr/include/bits/confname.h /usr/include/getopt.h \
+- /usr/include/string.h /usr/include/bits/string.h \
+- /usr/include/bits/string2.h /usr/include/fcntl.h \
++ /usr/include/bits/stdio_lim.h /usr/include/stdlib.h \
++ /usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
++ /usr/include/bits/endian.h /usr/include/sys/select.h \
++ /usr/include/bits/select.h /usr/include/bits/sigset.h \
++ /usr/include/bits/time.h /usr/include/sys/sysmacros.h \
++ /usr/include/alloca.h /usr/include/unistd.h \
++ /usr/include/bits/posix_opt.h /usr/include/bits/confname.h \
++ /usr/include/getopt.h /usr/include/string.h /usr/include/fcntl.h \
+/usr/include/bits/fcntl.h /usr/include/errno.h \
+/usr/include/bits/errno.h /usr/include/linux/errno.h \
+/usr/include/asm/errno.h /usr/include/signal.h \
+@@ -147,7 +145,6 @@ proto.c :
+/usr/include/gconv.h :
+/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h :
+/usr/include/bits/stdio_lim.h :
+-/usr/include/bits/stdio.h :
+/usr/include/stdlib.h :
+/usr/include/sys/types.h :
+/usr/include/time.h :
+@@ -164,8 +161,6 @@ proto.c :
+/usr/include/bits/confname.h :
+/usr/include/getopt.h :
+/usr/include/string.h :
+-/usr/include/bits/string.h :
+-/usr/include/bits/string2.h :
+/usr/include/fcntl.h :
+/usr/include/bits/fcntl.h :
+/usr/include/errno.h :
+Only in dillo-0.6.6-namedpipe/src/IO: CVS
+diff -pru dillo-0.6.6/src/IO/Makefile dillo-0.6.6-namedpipe/src/IO/Makefile
+--- dillo-0.6.6/src/IO/Makefile Tue Jun 4 10:43:32 2002
++++ dillo-0.6.6-namedpipe/src/IO/Makefile Mon Jun 10 11:17:20 2002
+@@ -78,15 +78,17 @@ CONFIG_HEADER = ../../config.h
+CONFIG_CLEAN_FILES =
+LIBRARIES = $(noinst_LIBRARIES)
+
+-
++#DEBUG=-O2
++DEBUG=-g
+DEFS = -DHAVE_CONFIG_H -I. -I$(srcdir) -I../..
+CPPFLAGS = -I/usr/local/include
+-LDFLAGS = -L/usr/local/lib
++LDFLAGS = -L/usr/local/lib $(DEBUG)
+LIBS = -lpng -lz -lpthread -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk 
+-rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
+libDio_a_LIBADD =
+libDio_a_OBJECTS = mime.o about.o Url.o proto.o file.o http.o IO.o
+AR = ar
+-CFLAGS = -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
+-I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT 
+-D_THREAD_SAFE -Wall -Waggregate-return
++#CFLAGS = -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
+-I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT 
+-D_THREAD_SAFE -Wall -Waggregate-return
++CFLAGS = -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
+-I/usr/lib/glib/include -I/usr/X11R6/include $(DEBUG) -D_REENTRANT 
+-D_THREAD_SAFE -Wall -Waggregate-return
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
+$(AM_CFLAGS) $(CFLAGS)
+CCLD = $(CC)
+LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@
+Only in dillo-0.6.6-namedpipe/src/IO: Makefile.~1.1.1.1.~
+diff -pru dillo-0.6.6/src/Makefile dillo-0.6.6-namedpipe/src/Makefile
+--- dillo-0.6.6/src/Makefile Tue Jun 4 10:43:32 2002
++++ dillo-0.6.6-namedpipe/src/Makefile Mon Jun 10 11:16:55 2002
+@@ -84,10 +84,11 @@ CONFIG_HEADER = ../config.h
+CONFIG_CLEAN_FILES =
+PROGRAMS = $(bin_PROGRAMS)
+
+-
++#DEBUG=-O2
++DEBUG=-g
+DEFS = -DHAVE_CONFIG_H -I. -I$(srcdir) -I..
+CPPFLAGS = -I/usr/local/include
+-LDFLAGS = -L/usr/local/lib
++LDFLAGS = -L/usr/local/lib $(DEBUG)
+LIBS = -lpng -lz -lpthread -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk 
+-rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
+dillo_OBJECTS = chain.o commands.o cache.o dw.o dw_aligned_page.o \
+dw_bullet.o dw_button.o dw_container.o dw_embed_gtk.o \
+@@ -99,7 +100,9 @@ png.o html.o image.o misc.o interface.o
+prefs.o colors.o bitvec.o klist.o url.o cookies.o
+dillo_DEPENDENCIES = IO/libDio.a
+dillo_LDFLAGS =
+-CFLAGS = -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
+-I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT 
+-D_THREAD_SAFE -Wall -Waggregate-return
++
++#CFLAGS = -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
+-I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT 
+-D_THREAD_SAFE -Wall -Waggregate-return
++CFLAGS = -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
+-I/usr/lib/glib/include -I/usr/X11R6/include $(DEBUG) -D_REENTRANT 
+-D_THREAD_SAFE -Wall -Waggregate-return
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
+$(AM_CFLAGS) $(CFLAGS)
+CCLD = $(CC)
+LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@
+Only in dillo-0.6.6-namedpipe/src: Makefile.~1.1.1.1.~
+diff -pru dillo-0.6.6/src/dillo.c dillo-0.6.6-namedpipe/src/dillo.c
+--- dillo-0.6.6/src/dillo.c Mon Mar 18 07:02:50 2002
++++ dillo-0.6.6-namedpipe/src/dillo.c Mon Jun 10 12:48:51 2002
+@@ -17,6 +17,12 @@
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
++
++
++New Command line order
++./dillo http://url.com -geometry
++
++
+*/
+
+#include <stdio.h>
+@@ -46,6 +52,7 @@
+#include "dw.h"
+#include "dw_widget.h"
+#include "cookies.h"
++#include "rurl.h"
+
+
+/*
+@@ -54,6 +61,154 @@
+static void Dillo_check_home_dir(char *dir);
+
+
++// Globals (To Do: consider moving to rurl.h)
++int pfd=-1;
++char pipe_buf[MAXURL];
++char * pipe_buf_p = pipe_buf;
++BrowserWindow *bwp;
++const int DEBUG1=0;
++const int DEBUG2=0;
++const int DEBUG3=0;
++const int DEBUG33=0;
++
++
++// Read from the named pipe and lauch url. Read one char at a time 
+until ';'
++static void pipe_input_callback (gpointer data,
++ gint source,
++ GdkInputCondition condition ) {
++ 
++ DilloUrl *start_url;
++ char rurl_str[MAXURL];
++ int numread=0;
++ char c='\0';
++ int i=0;
++
++ if (DEBUG1) printf("pipe_input_callback2:: condition = %d\n", condition);
++ if (DEBUG1) printf("source %d\n", source);
++
++ memset(pipe_buf,0,sizeof(pipe_buf));
++ memset(rurl_str,0,sizeof(rurl_str));
++ numread=0; i=0;
++
++ numread=read(pfd,&c,1);
++ pipe_buf[i++]=c;
++
++ if (numread > 0) {
++ // Verify the URL syntax
++ while (c != ';') {
++ numread=read(pfd,&c,1);
++ pipe_buf[i++]=c;
++
++ }
++ //replace ';'
++ if (pipe_buf[i-1] == ';') pipe_buf[i-1]=(char)NULL;
++
++ if (DEBUG1) {
++ printf("URL:%s\n",pipe_buf);
++ printf("Number of bytes read:%d\n",numread);
++ }
++
++ strncpy(rurl_str,pipe_buf,MAXURL);
++
++ /* Send dillo remote url */
++ start_url = a_Url_new(rurl_str, NULL, 0, 0);
++ if (DEBUG1) {
++ printf ("url_string=%s\n", start_url->url_string->str);
++ }
++
++ a_Nav_push(bwp, start_url);
++ if (DEBUG1) printf("After a_Nav_push\n");
++ a_Url_free(start_url);
++ if (DEBUG1) printf("After a_Url_free\n");
++ 
++ }
++
++}
++
++
++//Setup the named pipe and callback
++
++void a_rurl_init(void *data) {
++
++ char* pipe="/dev/dilremurl";
++ const int DEBUG1=1;
++ int mode=O_RDWR | O_NONBLOCK ;
++ struct stat statbuf;
++ gint RemoveMe;
++
++ bwp = (BrowserWindow *)data;
++
++ //Make sure pipe exists
++ if (lstat(pipe, &statbuf) < 0) {
++ fprintf(stderr,"Cannot stat named pipe %s\n",pipe);
++ exit (-1);
++ }
++
++ // Open in non blocking
++ pfd=open(pipe,mode);
++ if (pfd < 0) {
++ fprintf(stderr, "Failed to open named pipe\n");
++ }
++ else
++ if (DEBUG1) printf("pfd = %d\n", pfd);
++
++ // Monitor named pipe descriptor
++ RemoveMe = gdk_input_add(pfd, GDK_INPUT_READ, pipe_input_callback, 
+NULL);
++}
++
++// This is for command line parsing of -geometry=XSIZExYSIZE only. The 
+offsets would need "+/-" to be resolved.
++// A window manager has to be running or the size request is ignored.
++int ParseGeometry(char * ingeometry, int *X, int *Y, int *Xoffset, int 
+*Yoffset) {
++
++ int status=0;
++ int len=strlen(ingeometry);
++ char icopy[len];
++ char *p;
++ const char *delims="=x+-";
++ int count=0;
++
++ memset(icopy,0, sizeof(icopy));
++ strncpy(icopy,ingeometry,len);
++
++ p = strtok(icopy,delims);
++
++ // First token will be X
++ if (p) { 
++ *X = (int) strtol(p, (char **)NULL, 10);
++ if (DEBUG2) g_print("X =%d\n", *X);
++ }
++ else
++ return (-1); // No token
++
++ count=0;
++ do {
++ p = strtok('\0', delims);
++ if (p) {
++ switch (count) {
++ case 0: // 2nd will be Y
++ *Y = (int) strtol(p, (char **)NULL, 10);
++ if (DEBUG2) g_print("Y = %d Count=%d \n", *Y, count);
++ break;
++ case 1:
++ *Xoffset = (int) strtol(p, (char **)NULL, 10);
++ if (DEBUG2) g_print("Xoffset = %d Count=%d \n", *Xoffset, count);
++ break;
++ case 2:
++ *Yoffset = (int) strtol(p, (char **)NULL, 10);
++ if (DEBUG2) g_print("Yoffset = %d Count=%d \n", *Yoffset, count);
++ break;
++ default:
++ status=-1; // Shouldn't happen
++ }
++ }
++ count++;
++ } while (p);
++
++ return (status);
++
++}
++
++
+
+/*
+* ******************************** MAIN 
+*************************************
+@@ -63,6 +218,40 @@ gint main(int argc, char *argv[])
+gchar *file;
+DilloUrl *start_url;
+BrowserWindow *bw;
++ int Xsize=640;
++ int Ysize=480;
++ int Xoffset=0;
++ int Yoffset=0;
++ const int GSIZE=255;
++ char geometry[GSIZE];
++ int i=1;
++ int retval=0;
++
++ memset(geometry,0, sizeof(geometry));
++ 
++ for (i=1; i< argc; i++) {
++ if (( !g_strcasecmp (argv[i], "-geometry")) || ( !g_strcasecmp 
+(argv[i], "-g"))) {
++ if (argv[i+1]) {
++ strncpy(geometry, argv[i+1], GSIZE);
++ retval=ParseGeometry(geometry, &Xsize, &Ysize, &Xoffset, &Yoffset);
++ if (retval)
++ g_print("Error in ParseGeometry\n");
++ } 
++ else
++ g_print("argv[i+1] doesn't exist\n");
++ }
++ }
++
++
++
++
++ if (DEBUG1) {
++ g_print("Xsize = %d\n", Xsize);
++ g_print("Ysize = %d\n", Ysize);
++ g_print("Xoffset = %d\n", Xoffset);
++ g_print("Yoffset = %d\n", Yoffset);
++ }
++ 
+
+/* This lets threads in the file module end peacefully when aborted
+* todo: implement a cleaner mechanism (in file.c) */
+@@ -87,6 +276,10 @@ gint main(int argc, char *argv[])
+a_Dw_init();
+a_Cookies_init();
+
++ //Override prefs file with command line
++ prefs.width=Xsize;
++ prefs.height=Ysize;
++
+/* a_Nav_init() has been moved into this call because it needs to be
+* initialized with the new browser_window structure */
+bw = a_Interface_browser_window_new(prefs.width, prefs.height);
+@@ -98,7 +291,7 @@ gint main(int argc, char *argv[])
+a_Nav_push(bw, start_url);
+a_Url_free(start_url);
+
+- if (argc == 2) {
++ if (argc >= 2) {
+if (access(argv[1], F_OK) == 0) {
+GString *UrlStr = g_string_sized_new(128);
+
+@@ -120,6 +313,9 @@ gint main(int argc, char *argv[])
+}
+
+
++ //Start the remote url listener
++ a_rurl_init(bw);
++
+gtk_main();
+
+/*
+Only in dillo-0.6.6-namedpipe/src: dillo.c.~1.1.1.1.~
+Only in dillo-0.6.6-namedpipe/src: rurl.h
+
+
+Disclaimer: The information contained in this transmission, including any
+attachments, may contain confidential information of Matsushita Avionics
+Systems Corporation. This transmission is intended only for the use of the
+addressee(s) listed above. Unauthorized review, dissemination or other use
+of the information contained in this transmission is strictly prohibited.
+If you have received this transmission in error or have reason to believe
+you are not authorized to receive it, please notify the sender by return
+email and promptly delete the transmission. 
+
+
+
+[Dillo-dev]remote url control and testing patch part 2
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-13 15:03
+
+This is the pipe writer, called wpipe1 in the script.
+------------------------------------------------------------------------
+
+/***************************************************************************
+main.c - description
+-------------------
+begin : Thu May 9 10:57:59 PDT 2002
+copyright : (C) 2002 by Lee Van Dyke
+email : lee@borabora
+
+***************************************************************************/
+
+/***************************************************************************
+* *
+* This program is free software; you can redistribute it and/or modify *
+* it under the terms of the GNU General Public License as published by *
+* the Free Software Foundation; either version 2 of the License, or *
+* (at your option) any later version. *
+* *
+
+***************************************************************************/
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+
+
+const int MAXBUF=1024;
+
+
+int main(int argc, char *argv[])
+{
+
+char buf[MAXBUF];
+char usage[]="Usage: %s 
+char* pipe="/dev/dilremurl";
+int id=0;
+int mode=O_WRONLY;
+int numwritten=0;
+int slen=0;
+
+memset(buf,'\0',(size_t)MAXBUF);
+
+if (argc == 2) {
+
+slen=strlen(argv[1]);
+printf("Size of input: %d\n",slen);
+
+if (slen < MAXBUF)
+strncpy(buf,argv[1],slen);
+else {
+printf("Input size exceeds buffer length, exiting\n");
+exit (-1);
+}
+
+}
+else{
+printf(usage,argv[0]);
+exit (-1);
+}
+
+// Will block until both sides opened.
+id=open(pipe,mode);
+if (id < 0) {
+fprintf(stderr,"Failed to open named pipe\n");
+// Do error processing
+}
+
+numwritten=write(id,buf,slen);
+printf("buf=%s numwritten=%d\n", buf, numwritten);
+return EXIT_SUCCESS;
+}
+
+Disclaimer: The information contained in this transmission, including any
+attachments, may contain confidential information of Matsushita Avionics
+Systems Corporation. This transmission is intended only for the use of the
+addressee(s) listed above. Unauthorized review, dissemination or other use
+of the information contained in this transmission is strictly prohibited.
+If you have received this transmission in error or have reason to believe
+you are not authorized to receive it, please notify the sender by return
+email and promptly delete the transmission. 
+
+
+
+[Dillo-dev]remote url control and testing patch part 1
+
+From: Lee Van Dyke <VandykeL@ma...> - 2002-06-13 14:54
+
+Hi,
+
+Here is a (1st cut) patch that allows another process to control
+dillo's current url via a named pipe. The pipe writer test program,
+wpipe1, reads a string, writes to the pipe and dillo responds. The
+test script, rurl-cmeu99-2.sh, demonstrates how to use wpipe1.The test
+script takes one parameter, a delay in seconds, which can be zero.
+
+The other side benefit of this patch is automated testing. Now you can
+apply industrial strength tests easily (and without the refresh
+meta-tag). For example, the above script can be used to measure memory
+leaks by running overnight, etc.
+
+One thing I'm not sure of is how far dillo renders the current page
+when a new request arrives. I have to dig deeper to verify but I
+assume a new request aborts the current one?
+
+Well, it appears to interrupt the html parser so html_close() probably
+doesn't get called and does leak memory if the delay time is less than
+the render time.
+
+To use the patch create the named pipe on the target machine:
+mknod /dev/dilremurl p
+chmod 666 /dev/dilremurl
+
+-----------------------------------------------------
+The mail list restricts messages over 100k.
+So I will break up the pieces until I find an ftp server to use.
+
+
+
+Disclaimer: The information contained in this transmission, including any
+attachments, may contain confidential information of Matsushita Avionics
+Systems Corporation. This transmission is intended only for the use of the
+addressee(s) listed above. Unauthorized review, dissemination or other use
+of the information contained in this transmission is strictly prohibited.
+If you have received this transmission in error or have reason to believe
+you are not authorized to receive it, please notify the sender by return
+email and promptly delete the transmission. 
+
+
+
+Re: [Dillo-dev]offline cache
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-06-13 07:12
+
+thanks for that!
+
+still confused as to why it would be so difficult to have a switch so 
+that the cache was saved, but I'll drop it for now.
+
+thanks again
+
+jonathan 
+
+
+
+Re: [Dillo-dev]offline cache
+
+From: Geoff Lane <zzassgl@tw...> - 2002-06-13 06:48
+
+> 
+> you've misunderstood my desire, I use dsl when online, however to 
+> demonstrate dillo to other colleagues and students, it would be useful.
+> 
+> I realise one can save pages, however our pages are more or less only 
+> images.
+> 
+> so the only simple way I know is if it is possible to cache images.....
+> 
+> Perhaps this could be a feature that had to be 'added'
+
+Probably the quickest/easiest/least code method would be to use the proxy
+mechanism and run a small, local caching proxy such as WWWOFFLE
+(http://www.gedanken.demon.co.uk/wwwoffle/)
+
+I haven't tried this though.
+
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\ 
+
+
+
+Re: [Dillo-dev]feature request: frames support
+
+From: Imad <magius@pu...> - 2002-06-13 00:23
+
+On Thu, 13 Jun 2002, Robert [unknown-8bit] Blacqui=E8re wrote:
+
+> Hi, dillo developers and users,
+>
+> I started using dillo a few days ago with great joy. But for some reaso=
+n
+> i need (would like) support for frames. I have setup a set of web pages
+> to monitor some machines an display the results graphs and cgi answers
+> in to a reponse frame. So i was wondering if there is a plan for this t=
+o
+> implement frame support. This would make mozilla and netscape disappear
+> from my disc. No need for them any more.
+
+Full frames support, to the best of my knowledge, is on the todo list.
+You could use Links 2.x (the new, graphical version:
+http://freshmeat.net/redir/links/5817/url_homepage/) until Dillo adds in
+frames support and still free your system of bloated Mozilla/Netscape.
+
+--=20
+Best,
+Imad Hussain 
+
+
+
+[Dillo-dev]feature request: frames support
+
+From: Robert <dillo@gu...> - 2002-06-12 23:04
+
+Hi, dillo developers and users,
+
+I started using dillo a few days ago with great joy. But for some reason
+i need (would like) support for frames. I have setup a set of web pages
+to monitor some machines an display the results graphs and cgi answers
+in to a reponse frame. So i was wondering if there is a plan for this to
+implement frame support. This would make mozilla and netscape disappear
+from my disc. No need for them any more. 
+
+
+Robert
+
+
+-- 
+Microsoft: Where do you want to go today?
+Linux: Where do you want to go tomorrow?
+FreeBSD: Are you guys coming or what?
+OpenBSD: He guys you left some holes out there! 
+
+
+
+Re: [Dillo-dev]offline cache
+
+From: no one <neverbefound@su...> - 2002-06-12 21:19
+
+Ack, stop spreading FUD you lot :-P
+
+Dillo has a full memory-cache system, a default dillo will cache
+everything that it surfs across into memory - this will persist until that
+instance of dillo is closed.
+
+There is however, no hard-drive cache - so you'll have to leave the Dillo
+executable running from when you were connected to the internet.
+
+For instance, if you surf to http://slashdot.org, and then type the same
+URL into Dillo 'X' hrs later, a full copy of the page will be pulled out
+the cache...
+
+If you want to see what's actually in the cache, 
+
+apply this patch:
+http://www.ime.usp.br/~livio/dillo/patches/cache-size-limit.diff
+by Livio Baldini Soares
+
+& a URL of 'about:cache' will bring up a nice listing of what's in the
+cache...
+
+I wrote quick 1-line patch to the above patch :) to make the cache list
+into a load of clickable hyperlinks, but I seem to have lost it... if
+you'd like a better search for it, or a x86 linux binary - mail me ;)
+
+Just to reiterate: Dillo has a lovely efficient cache, but its entirely
+memory based so you'll have to use the same executable that was running
+when you were connected to the net...
+
+Jarvist
+
+P.S. A quicker (as in works without having to install any extra programs)
+method of making a local copy of a website for demonstration purposes is
+to use 'wget' such as
+wget -rkl 1 http://slashdot.org
+
+(-r: recursive
+-k: locallised links
+-l 1: goes 1-'click' deep
+)
+
+On Wed, 12 Jun 2002 15:18:58 -0400
+Andreas Schweitzer <andy@ph...> pleasently wrote:
+
+> On Wed, Jun 12, 2002 at 07:50:07PM +0100, jonathan chetwynd wrote:
+> > you've misunderstood my desire, I use dsl when online, however to 
+> > demonstrate dillo to other colleagues and students, it would be
+> > useful.
+> 
+> I think you still could use wwwoffle for that.
+> 
+> > I realise one can save pages, however our pages are more or less only 
+> > images.
+> > 
+> > so the only simple way I know is if it is possible to cache
+> > images.....
+> > 
+> > Perhaps this could be a feature that had to be 'added'
+> 
+> I think this is what Livio tried to explain. Namely, that
+> dillo will not maintain a writable cache.
+> 
+> In the meantime try
+> http://langfeldt.net/w3mir/
+> to create a local copy of what you want to demonstrate.
+
+-- 
+
+Courdoroy pillows- They're making headlines! 
+
+
+
+Re: [Dillo-dev]offline cache
+
+From: Andreas Schweitzer <andy@ph...> - 2002-06-12 19:19
+
+On Wed, Jun 12, 2002 at 07:50:07PM +0100, jonathan chetwynd wrote:
+> you've misunderstood my desire, I use dsl when online, however to 
+> demonstrate dillo to other colleagues and students, it would be useful.
+
+I think you still could use wwwoffle for that.
+
+> I realise one can save pages, however our pages are more or less only 
+> images.
+> 
+> so the only simple way I know is if it is possible to cache images.....
+> 
+> Perhaps this could be a feature that had to be 'added'
+
+I think this is what Livio tried to explain. Namely, that
+dillo will not maintain a writable cache.
+
+In the meantime try
+http://langfeldt.net/w3mir/
+to create a local copy of what you want to demonstrate.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev]offline cache
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-06-12 19:01
+
+you've misunderstood my desire, I use dsl when online, however to 
+demonstrate dillo to other colleagues and students, it would be useful.
+
+I realise one can save pages, however our pages are more or less only 
+images.
+
+so the only simple way I know is if it is possible to cache images.....
+
+Perhaps this could be a feature that had to be 'added'
+
+thanks
+
+jonathan 
+
+
+
+Re: [Dillo-dev]Dillo scaling hack
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-06-12 18:53
+
+thanks for that, I see there is a new version of dillo out.
+
+I liked the scaling feature, it particularly suits our website 
+http://www.peepo.com, take a look.
+
+for some reason the images are more spreadout than in the original 
+dillo, cannot fathom why this should be.
+
+does anyone know?
+
+the actual control seems a littl awkward, it is hard to tell if one has 
+activated it or not.
+
+thanks
+
+jonathan 
+
+
+
+Re: [Dillo-dev]Dillo scaling hack
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-06-12 15:20
+
+On Wed, Jun 12, 2002 at 09:40:11PM +1000, Pigeon wrote:
+> 
+> Dear all,
+> 
+> After a few months I finally got time to redo this dillo scaling hack.
+> 
+> Details at http://pigeond.net/dillo/
+> 
+> Right now the hack is pretty much a "hack".
+> 
+> Basically the scaling is done in the image and the font. I wanted to put the scaling in the DwStyles but due the way dillo works, it wasn't quite appropriate. So right now, the scaling is done a bit everywhere when needed.
+> 
+> Also I'd like make the scale work for more widgets and stuffs. For instance, table right now is not scaled yet, and viewing standalone images will not be scaled yet. Stuffs like that.
+> 
+> I think scaling for a web browser is pretty useful and I'm wondering if anyone got any suggestions for more proper hack for this feature...
+
+I've some thoughts on this, yes. I'm of the opinion that scaling the entire
+webpage is probably the wrong way to go: we've only got 240x320 pixels, after
+all: If I try to fit a page designed for 800x600 by scaling it, the font
+will get unreadable before the whole page width is in place. Sometimes,
+actually, I want to scale fonts _up_ for low light, etc.
+
+I've been pleased, actually, with how well a lot of pages work with just 
+font scaling and the limit_text_width wrapping text to the viewport. If a
+table is all text, the columns narrow down to a single viewports width, and
+that works fine for the multicolumn layout sort of problems, as long as:
+
+1. columns only contain text (images blow the column widths out)
+2. columns are dimensioned with widths in pixels
+
+In both cases, you can still read the text, it's just hard to scroll across
+to the next column. Both of these are a pixel sizing issues. There are
+other pixel sizing issues, as well: HRs, etc. Basically, anything that
+can be sized in absolute pixels will blow away tables and screen space.
+
+I'm trying out a hack that scales _all_ absolute sizes by half, as well as
+image dimensions (for unsized images) This solves the direct view problem,
+BTW.
+
+My hack is at:
+
+http://wallace.ece.rice.edu/dillo/
+
+No ARM binaries to test, I'm afraid. Do you have a cross-compile setup
+working for dillo? I'd love to know how you set it up.
+
+Ross
+-- 
+Ross Reedstrom, Ph.D. reedstrm@ri...
+Executive Director phone: 713-348-6166
+Gulf Coast Consortium for Bioinformatics fax: 713-348-6182
+Rice University MS-39
+Houston, TX 77005 
+
+
+
+Re: [Dillo-dev]Dillo scaling hack
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-06-12 14:13
+
+On Wed, Jun 12, 2002 at 01:19:42PM +0100, jonathan chetwynd wrote:
+> Looks great, I usually use ipkg install, so could you please remind me, 
+> Or frankly, tell me, as I dont do this much how to try your version?
+> 
+> presumably ipkg remove dillo
+
+From what I see on his website, _don't_ remove your existing dillo,
+just replace the file /usr/bin/dillo with the dillo-scale-hack-0.6.5-arm
+file, and either rename it to 'dillo', or make a symlink named 'dillo'
+pointing to it. That way, you keep your menu entries, config file, etc.,
+that come in the ipkg.
+
+Ross 
+
+
+
+Re: [Dillo-dev]offline cache
+
+From: Livio Baldini Soares <livio@im...> - 2002-06-12 12:47
+
+Hi Jonathan!
+
+jonathan chetwynd writes:
+> is there a simple way to cache pages for offline viewing?
+
+First of all read dillo/doc/Cache.txt, particularly the section
+entitled "Cache Philosophy". I personally feel that Dillo will start
+to become bloated if it tried to do too many jobs at once. Plus you
+can bet that a cache server which was conceived to do that function
+will do a better job than Dillo, which was conceived to be a browser. 
+
+I'm not sure if Squid allows you to cache and browse offline, but
+I'm sure wwwoffle[1] can. I used to use it when I had a very (_very_)
+bad dial-up connection. I know that there are other packages which
+also cache for offline browsing, but as far as I know, wwwoffle is the
+most famous/used. 
+
+[1] http://www.gedanken.demon.co.uk/wwwoffle/
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]offline cache
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-06-12 12:31
+
+is there a simple way to cache pages for offline viewing?
+
+thanks
+
+jonathan 
+
+
+
+Re: [Dillo-dev]Dillo scaling hack
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-06-12 12:31
+
+Looks great, I usually use ipkg install, so could you please remind me, 
+Or frankly, tell me, as I dont do this much how to try your version?
+
+presumably ipkg remove dillo
+
+.....
+
+mine is 0.6.5
+
+thanks
+
+jonathan chetwynd
+
+I'm particularly interested, as our site for people with a severe 
+learning difficulty, uses plenty of images, and we've discussed using 
+svg, to respond to scaling needs. 
+
+
+
+[Dillo-dev]Dillo scaling hack
+
+From: Pigeon <pigeon@pi...> - 2002-06-12 11:40
+
+Dear all,
+
+After a few months I finally got time to redo this dillo scaling hack.
+
+Details at http://pigeond.net/dillo/
+
+Right now the hack is pretty much a "hack".
+
+Basically the scaling is done in the image and the font. I wanted to put the scaling in the DwStyles but due the way dillo works, it wasn't quite appropriate. So right now, the scaling is done a bit everywhere when needed.
+
+Also I'd like make the scale work for more widgets and stuffs. For instance, table right now is not scaled yet, and viewing standalone images will not be scaled yet. Stuffs like that.
+
+I think scaling for a web browser is pretty useful and I'm wondering if anyone got any suggestions for more proper hack for this feature...
+
+Thanks.
+
+
+Pigeon. 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-06-12 03:22
+
+Oi Livio!
+
+
+> My previous patch (for limiting the size of cache), will not work
+> correctly because IO_write():IO.c doesn't behave correctly when it
+> gets a EAGAIN error (it will enter an eternal loop, making infinite
+> writev() calls).
+>
+> I have a patch here which (seems) to fix it. There are two fixes in
+> it:
+>
+> [1] The fix Jorge and I had made in 0.6.5-pre, which was removed. This
+> will make IO_write and IO_callback correctly treat EAGAIN.
+>
+> [2] Remove the constraint for freeing the buffer in write operations.
+> This error should not appear commonly in Dillo's regular use,
+> because it is very rare to have a HTTP query with more than one
+> buffer long, and therefore the IOvec.iov_base won't be
+> modified. But this, in fact, can happen (resulting in a Seg
+> Fault). What I've done to fix this problem, is added a
+> `buffer_start` field to IOData_t, which is _private_. IO users
+> shouldn't bother to set this, I have done so in a_IO_ccc().
+>
+> Jorge, do you think that [2] fixes other problems you might of had
+> with the EAGAIN handler?
+
+I'm giving a deep review to the problem, and it seems [2] may
+be the fix to the problems I had.
+
+Quoting myself:
+
+<<
+I'm a bit hesitant with this subject. This is the story: I've
+been working on presentation material for the site, and testing
+its rendering with dillo; that is, small html files that are
+re-created by a script very often, and then reloaded into dillo.
+The sad news is that I've caught this problem twice:
+
+--
+Nav_open_url: Url=>file:/tmp/funding/advantages.html#eff<
+[New Thread 31776 (LWP 413)]
+Delayed SIGSTOP caught for LWP 413.
+LWP 413 exited.
+Nav_open_url: Url=>file:/tmp/funding/advantages.html#eff<
+Cannot find thread 33: invalid thread handle
+(gdb) bt
+#0 0x40083881 in __linuxthreads_create_event () at events.c:26
+#1 0x4007d4da in pthread_handle_create (thread=0x40088e90, attr=0x0,
+start_routine=0x8075a38 <File_transfer_file>, arg=0x80eda08,
+mask=0x80f9dfc, father_pid=276, report_events=1, event_maskp=0x40088fec)
+at manager.c:615
+#2 0x4007ce78 in __pthread_manager (arg=0xd) at manager.c:157
+#3 0x4007cf80 in pthread_start_thread (arg=0xd) at manager.c:221
+--
+
+When it continues, a SEGFAULT pops...
+>>
+
+Finally, FWIW, I hit the problem four times while making the
+presentation, but never with the old handler...
+
+
+> If it doesn't, can you please try to give me
+> some directions into reproducing your problems?
+
+Unfortunately not. All I know is I had those problems, but my
+efforts to reproduce them again have been sterile. Well, I could
+start working just as I did then, but if I hit the bug, I'll have
+barely more than the quoted backtrace.
+
+I'll keep on reviewing the code trying to get to the roots.
+
+> So the IO patch is at:
+> http://www.ime.usp.br/~livio/dillo/patches/fix-io-egain-and-free-write.diff
+
+Good idea.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]patch to manage submenus in bookmarks
+
+From: Tomas Guemes <tomas@pa...> - 2002-06-11 13:19
+
+Attachments: Message as HTML      
+
+Hi all,
+
+I know the bookmark stuff is planned to be manage with the simple
+plugins idea but meanwhile i though it could be practical to be able to
+handle submenus in it. 
+
+I dig a little bit in the bookmark of other browsers and found the xbel
+format, i wonder if making xbel the native format for dillo bookmarks is
+a good choice. If you think is good idea i can work on it.
+
+You can find the patch, and more information in 
+
+http://aseed.antenna.nl/~tomas/web/dillo/ 
+or
+http://pasky.dhs.org/tomas/dillo/
+
+Any sugestion to the source is wellcome.
+
+greetings
+
+Tomas
+
+(O0o.. . . . . ..o0O0o.. . . . . ..o0O)
+
+Tomas Guemes Sanchez 
+tomas@pa... 
+tguemes@mi... 
+
+(O0o.. . . . . ..o0O0o.. . . . . ..o0O) 
+
+
+
+Re: [Dillo-dev]Dillo vs. mailman
+
+From: Ralph Slooten <ralph@de...> - 2002-06-10 20:39
+
+I have just discovered that dillo's cookies aren't working at all with the 
+latest CVS, and in fact tracing back to pre-compiled versions I have made 
+haven't been working for the last week or more. I'm sorry, I'm not a 
+programmer, just a great admirer of Dillo, so I cannot point out what's 
+wrong here at all. Whether I use the --enable-cookies or not, it makes no 
+difference. I have even tried deleting my whole ~/.dillo folder (actually 
+renaming), but this does not work either. Something tells me something is 
+broken in the code. And yes, before anyone doubts my intelligence (cough 
+cough) the cookiesrc states "DEFAULT ACCEPT" ;-)
+
+Is it just me, or am I correct?
+
+Greetings
+Ralph
+
+On 10 Jun 2002, Lars Clausen wrote:
+
+> 
+> Dillo has for a while not been able to send cookies to Mailman's admin
+> interface, to my great annoyance. Dillo does it right, Mailman doesn't
+> parse the quotes correctly. This is apparently fixed in the development
+> version 2.1, but the 2.0.* versions will not be fixed. For those who want
+> to use Mailman with Dillo, here's a really ugly kludge to turn off the
+> quotes:
+> 
+> Index: cookies.c
+> ===================================================================
+> RCS file: /cvsroot/dillo/dillo/src/cookies.c,v
+> retrieving revision 1.10
+> diff -u -r1.10 cookies.c
+> --- cookies.c 27 May 2002 21:11:58 -0000 1.10
+> +++ cookies.c 10 Jun 2002 19:42:35 -0000
+> @@ -940,6 +940,9 @@
+> matching_cookies = g_list_next(matching_cookies)) {
+> cookie = (CookieData_t *) matching_cookies->data;
+> q = (cookie->version == 0 ? "" : "\"");
+> + /* Kludge to allow admindb to work */
+> + if (cookie->path && strstr(cookie->path, "/mailman/"))
+> + q = "";
+> 
+> g_string_sprintfa(cookie_gstring, 
+
+-- 
+Homepage: http://tuxpower.f2g.net/ 
+
+
+
+[Dillo-dev]Dillo vs. mailman
+
+From: Lars Clausen <lrclause@cs...> - 2002-06-10 19:43
+
+Dillo has for a while not been able to send cookies to Mailman's admin
+interface, to my great annoyance. Dillo does it right, Mailman doesn't
+parse the quotes correctly. This is apparently fixed in the development
+version 2.1, but the 2.0.* versions will not be fixed. For those who wan=
+t
+to use Mailman with Dillo, here's a really ugly kludge to turn off the
+quotes:
+
+Index: cookies.c
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+RCS file: /cvsroot/dillo/dillo/src/cookies.c,v
+retrieving revision 1.10
+diff -u -r1.10 cookies.c
+--- cookies.c 27 May 2002 21:11:58 -0000 1.10
++++ cookies.c 10 Jun 2002 19:42:35 -0000
+@@ -940,6 +940,9 @@
+matching_cookies =3D g_list_next(matching_cookies)) {
+cookie =3D (CookieData_t *) matching_cookies->data;
+q =3D (cookie->version =3D=3D 0 ? "" : "\"");
++ /* Kludge to allow admindb to work */
++ if (cookie->path && strstr(cookie->path, "/mailman/"))
++ q =3D "";
+=20
+g_string_sprintfa(cookie_gstring, "%s=3D%s%s%s",
+cookie->name, q, cookie->value, q);
+
+This is not intended to go into the sources, of course.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: John Utz <john@ut...> - 2002-06-10 17:30
+
+i'd hafta say that's a pretty powerful advantage.
+
+sure, it's irrelevant to an ascii-native user, but ascii-native is a 
+pretty small chunk of the real world and supporting native charsets is 
+going to make life a little better for 3rd world netusers...
+
+On 10 Jun 2002, Lars Clausen wrote:
+
+> 
+> On Thu, 30 May 2002, Freya@he... wrote:
+> > 
+> > But why would you want to port it to gtk2?
+> > What advantage does that bring?
+> 
+> In a word: Pango. Full support for just about any charset out there. We
+> tried hacking things into Dia to support East Asian fonts, and it was a
+> nightmare. Pango has this wheel implemented once and for all. 
+> 
+> -Lars
+> 
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]GTK+-2.0 ?
+
+From: Lars Clausen <lrclause@cs...> - 2002-06-10 16:43
+
+On Thu, 30 May 2002, Freya@he... wrote:
+>=20
+> But why would you want to port it to gtk2?
+> What advantage does that bring?
+
+In a word: Pango. Full support for just about any charset out there. We
+tried hacking things into Dia to support East Asian fonts, and it was a
+nightmare. Pango has this wheel implemented once and for all. =20
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |----------------------=
+------
+will defend to the death your right to say it." | Where are we going, a=
+nd
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handb=
+asket? 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: no one <neverbefound@su...> - 2002-06-04 00:27
+
+On Mon, 3 Jun 2002 17:58:27 -0300
+Livio Baldini Soares <livio@im...> pleasently wrote:
+
+> Hum, bad news :-/ My patch isn't responsible for this crash. What
+> may be happening is that my patch makes this bug a _little_ bit more
+> reproducible, but I've managed to hit this with _current_ CVS code.
+
+Easyily (sic) reproducible bug in a cache-limit & IO-bug-fix patched
+dillo-0.6.6:
+
+Open up a site linking to many graphics files such as:
+http://www.slackware.com/~msimons/slackware/grfx/
+
+As images are loading, call a 'about:cache-clear'
+
+Segfault _guranteed_ :), 
+though empty about:cache-clear sometimes loads before it goes under...
+
+Jarvist
+-- 
+
+Courdoroy pillows- They're making headlines! 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Livio Baldini Soares <livio@im...> - 2002-06-03 20:58
+
+Hello Andreas!
+
+Andreas Schweitzer writes:
+> Hi
+
+[...]
+
+> > Jorge, do you think that [2] fixes other problems you might of had
+> > with the EAGAIN handler? If it doesn't, can you please try to give me
+> > some directions into reproducing your problems?
+> 
+> With this patch, the cache page no longer freezes. But, I do get a segfault
+> when doing "extreme websurfing" ;-) .... I have 2 or 3 windows open and
+> click like a madman in all of them :-) .... with this patch I eventually
+> get a segfault, without I cannot (I tried hard, though :-) ... I'm
+> afraid this is not very specific, but maybe it helps.
+
+Hum, bad news :-/ My patch isn't responsible for this crash. What
+may be happening is that my patch makes this bug a _little_ bit more
+reproducible, but I've managed to hit this with _current_ CVS code.
+
+Sometimes, I get this segfault:
+
+#2 0x401fe70b in g_free () from /usr/lib/libglib-1.2.so.0
+#3 0x08087c44 in IO_free (io=0x8126fe8) at IO.c:93
+#4 0x0808803f in a_IO_ccc (Op=5, Branch=-1, Info=0x8271370, Data=0x0, ExtraData=0x0) at IO.c:339
+
+Which is the free-during-write bug. I can "fix" this either by using
+my IO patch, or simply commenting off the g_free() in IO_free() just
+for the sake of testing (but yes, the latter will leak memory).
+
+But the problem Andreas was referring to is another one. It takes me
+about 15 minutes of *madly* loading and reloading pages to hit this
+(it is very difficult even with or without my pathes).
+
+I can't really get to the bottom of this issue, but all my stack
+traces look very similar:
+
+#0 0x08081b4a in a_Url_str (u=0x81519a8) at url.c:59
+#1 0x080534ee in Cache_url_hash (key=0x81519a8) at cache.c:91
+#2 0x401f9dec in g_hash_table_lookup () from /usr/lib/libglib-1.2.so.0
+#3 0x08053854 in Cache_entry_search (Url=0x81519a8) at cache.c:232
+#4 0x080549ae in Cache_process_io (Op=3, VPtr=0x816e620) at cache.c:700
+#5 0x0805530e in a_Cache_ccc (Op=4, Branch=2, Info=0x8148ed0, Data=0x816e620, ExtraData=0x0) at cache.c:1043
+#6 0x08052910 in a_Chain_fcb (Op=4, Branch=2, Info=0x815da08, Data=0x816e620, ExtraData=0x0) at chain.c:71
+#7 0x08088000 in a_IO_ccc (Op=4, Branch=2, Info=0x815da08, Data=0x816e620, ExtraData=0x0) at IO.c:327
+#8 0x08087d01 in IO_read (io=0x816e620) at IO.c:156
+#9 0x08087e14 in IO_callback (src=0x815a978, cond=G_IO_IN, data=0x22) at IO.c:238
+#10 0x401fbe10 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
+
+And the contents of (u) in a_Url_str are just non-sense.
+
+I believe that when this error is discovered inside Dillo's current
+code, my patch will probably stop misbehaving.
+
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Paul Chamberlain <tif@ti...> - 2002-06-03 14:56
+
+Michael Govorun wrote:
+> It seems to me that about:cache working with few entries in cache, but
+> freeze dillo after number exceeds ~ 35 entries.
+
+Just a thought... What happens if the cache code can't
+find anything that is removable, due to everything being
+in use? It seems like this might cause such behavior.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+[Dillo-dev]Font Faces
+
+From: Chris Hawks <chrish@sy...> - 2002-06-02 22:28
+
+Thanks for all the replies to my question about the #ifdefed font face
+support. I agree with Livio that this should be a preference controlled
+item and am still willing to share my patch for changing the font faces
+(and sizes) on the widgets.
+
+
+Christopher R. Hawks
+HAWKSoft
+-------------------------------------------------------------------------
+"There's nothing wrong with Microsoft that taking a machine-gun to their
+entire Marketing and Advertising department wouldn't cure." 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Andreas Schweitzer <andy@ph...> - 2002-06-02 18:12
+
+Hi
+
+> I've done the following test: opened 5-6 windows with different
+> pages, then on another window used "Save Link As..." on a very big
+> file (for example, go to http://www.kernel.org/pub/linux/kernel/v2.4/,
+> and pick a kernel there), and watched the about:cache page. I kept
+> reloading it and saw that when current cache size reached the maximum,
+> it started trying to "clean" the cache. It then removed all images and
+> other pages. The only ones that remain are:
+> 
+> [1] Entries that have a client (that is, which are being downloaded).
+> 
+> [2] Entries that are RootURLs currently beeing viewed on browser
+> windows.
+
+This does remind me of some issues I thought about when I had the bold
+idea to implement the cache size myself ;-) ....
+
+- What happens if the data for one page is larger than the cache size ?
+
+- Is the cache size a strict upper limit ? Or can we exceed it until
+the page is fully loaded and then clean up, or should we clean up
+before a page gets loaded ? E.g. what happens when the server does not send
+the page size ?
+
+- For viewing or downloading files of the size approximatley the RAM size,
+do we want to have a safty break ? Or should this be the job of the OS ?
+Will dillo know when its ulimit is reached ?
+
+Just some food for though ... maybe some tough ones ...
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Andreas Schweitzer <andy@ph...> - 2002-06-02 18:04
+
+Hi
+
+> [2] Remove the constraint for freeing the buffer in write operations.
+> This error should not appear commonly in Dillo's regular use,
+> because it is very rare to have a HTTP query with more than one
+> buffer long, and therefore the IOvec.iov_base won't be
+> modified. But this, in fact, can happen (resulting in a Seg
+> Fault). What I've done to fix this problem, is added a
+> `buffer_start` field to IOData_t, which is _private_. IO users
+> shouldn't bother to set this, I have done so in a_IO_ccc().
+> 
+> Jorge, do you think that [2] fixes other problems you might of had
+> with the EAGAIN handler? If it doesn't, can you please try to give me
+> some directions into reproducing your problems?
+
+With this patch, the cache page no longer freezes. But, I do get a segfault
+when doing "extreme websurfing" ;-) .... I have 2 or 3 windows open and
+click like a madman in all of them :-) .... with this patch I eventually
+get a segfault, without I cannot (I tried hard, though :-) ... I'm
+afraid this is not very specific, but maybe it helps.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Livio Baldini Soares <livio@im...> - 2002-06-02 18:01
+
+Hello Hugo!
+
+Hugo Hallqvist writes:
+> On 2 Jun, Livio Baldini Soares wrote:
+> 
+> > My previous patch (for limiting the size of cache), will not work
+> > correctly because IO_write():IO.c doesn't behave correctly when it
+> > gets a EAGAIN error (it will enter an eternal loop, making infinite
+> > writev() calls).
+> > 
+> > I have a patch here which (seems) to fix it. There are two fixes in
+> > it:
+
+[...]
+
+> After a little testing, atleast I cannot find the reload-bug again.
+> However, I have found a way to easy go beyond the cache-limits of this
+> patch. Just use "save link as..." from popupmenu over a filelink that is
+> bigger than current cachesize limit.
+
+Yes, this is absolutely true. Let me please try to explain a little
+bit better what my patch tries to do and why:
+
+There are several ways of bypassing the cache_size limit, one of
+them is that which you have described. The main issues here are a
+number of restrictions which currently exists in the cache and IO
+modules. For instance, downloading currently requires that the whole
+file be brought to the cache. Also, all URLs which are being viewed
+are required to be in Cache, so that HTML font viewing ("View page
+Source") and "Save page As..." work correctly. They both "assume"
+that their data is in the Cache.
+
+But these restrictions can be dealt with later on, and when they are
+resolved, cache_size limit will be a "tighter" limit than it is today.
+
+I've done the following test: opened 5-6 windows with different
+pages, then on another window used "Save Link As..." on a very big
+file (for example, go to http://www.kernel.org/pub/linux/kernel/v2.4/,
+and pick a kernel there), and watched the about:cache page. I kept
+reloading it and saw that when current cache size reached the maximum,
+it started trying to "clean" the cache. It then removed all images and
+other pages. The only ones that remain are:
+
+[1] Entries that have a client (that is, which are being downloaded).
+
+[2] Entries that are RootURLs currently beeing viewed on browser
+windows.
+
+But, as soon as the file gets downloaded, it is _also_removed_ from
+the cache.
+
+I hope this helps you to understand what the patch is supposed to
+do... 
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev][PATCH] Fixing IO_write
+
+From: Hugo Hallqvist <hugha495@st...> - 2002-06-02 17:19
+
+On 2 Jun, Livio Baldini Soares wrote:
+
+> My previous patch (for limiting the size of cache), will not work
+> correctly because IO_write():IO.c doesn't behave correctly when it
+> gets a EAGAIN error (it will enter an eternal loop, making infinite
+> writev() calls).
+> 
+> I have a patch here which (seems) to fix it. There are two fixes in
+> it:
+> 
+> [1] The fix Jorge and I had made in 0.6.5-pre, which was removed. This
+> will make IO_write and IO_callback correctly treat EAGAIN.
+> 
+> [2] Remove the constraint for freeing the buffer in write operations.
+> This error should not appear commonly in Dillo's regular use,
+> because it is very rare to have a HTTP query with more than one
+> buffer long, and therefore the IOvec.iov_base won't be
+> modified. But this, in fact, can happen (resulting in a Seg
+> Fault). What I've done to fix this problem, is added a
+> `buffer_start` field to IOData_t, which is _private_. IO users
+> shouldn't bother to set this, I have done so in a_IO_ccc().
+
+After a little testing, atleast I cannot find the reload-bug again.
+However, I have found a way to easy go beyond the cache-limits of this
+patch. Just use "save link as..." from popupmenu over a filelink that is
+bigger than current cachesize limit.
+
+Maybe this is not intended to be fixed by the patch, since it says "half
+implemented" in web.c?
+
+Anyway, normal browsing seems to work just fine.
+
+-- 
+//Hugo Hallqvist 
+
+
+
+[Dillo-dev][PATCH] Fixing IO_write
+
+From: Livio Baldini Soares <livio@im...> - 2002-06-02 16:45
+
+Hello again!
+
+Thanks Hugo and Andreas for helping discover this error!
+
+My previous patch (for limiting the size of cache), will not work
+correctly because IO_write():IO.c doesn't behave correctly when it
+gets a EAGAIN error (it will enter an eternal loop, making infinite
+writev() calls).
+
+I have a patch here which (seems) to fix it. There are two fixes in
+it:
+
+[1] The fix Jorge and I had made in 0.6.5-pre, which was removed. This
+will make IO_write and IO_callback correctly treat EAGAIN.
+
+[2] Remove the constraint for freeing the buffer in write operations.
+This error should not appear commonly in Dillo's regular use,
+because it is very rare to have a HTTP query with more than one
+buffer long, and therefore the IOvec.iov_base won't be
+modified. But this, in fact, can happen (resulting in a Seg
+Fault). What I've done to fix this problem, is added a
+`buffer_start` field to IOData_t, which is _private_. IO users
+shouldn't bother to set this, I have done so in a_IO_ccc().
+
+Jorge, do you think that [2] fixes other problems you might of had
+with the EAGAIN handler? If it doesn't, can you please try to give me
+some directions into reproducing your problems?
+
+So the IO patch is at:
+http://www.ime.usp.br/~livio/dillo/patches/fix-io-egain-and-free-write.diff
+
+And the previously announced patch for limiting the size of cache:
+http://www.ime.usp.br/~livio/dillo/patches/cache-size-limit.diff
+
+I would like to hear feedback with respect to his IO patch too. 
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Andreas Schweitzer <andy@ph...> - 2002-06-02 15:56
+
+Just to confirm what Livio said
+
+> After applying the patch to dillo i tested it out a bit and found a few
+> strange things:
+> 
+> 2. I of course thought about hitting reload, and that made dillo freeze 
+> with 100% cpu usage.
+
+Sounds just like my problem.
+
+> 3. When having browsed a bit, it seems that it won't take away anything
+> from the cache. I set my size to ~ 5 MB and dillo was over 18 MB
+> after a while.
+
+I tested that as well - but works for me. I set the size to 100k or so.
+
+Cheers
+Andreas
+
+-- 
+Department of Physics & Astronomy and Center for Simulational Physics
+University of Georgia !!! NEW !!! : Phone ++1 (706) 583 8227
+Athens, GA 30602-2451 Fax ++1 (706) 542 2492
+USA http://dilbert.physast.uga.edu/~andy/ 
+
+
+
+Re: [Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Hugo Hallqvist <hugha495@st...> - 2002-06-02 15:21
+
+On 2 Jun, Livio Baldini Soares wrote:
+
+>> After applying the patch to dillo i tested it out a bit and found a few
+>> strange things:
+>> 
+>> 1. Quite often the about:cache won't get updated, it says it has found
+>> my cachesize limit from dillorc, but not much else. 
+> 
+> You have to hit reload, or else you'll get a cached version of
+> about:cache, that's why it doesn't get updated.
+
+Yes, I think I overloaded it too quickly with this 4KB limit, because
+everything just froze after having visited a few pages and hitting
+reload in about:cache. However now that I've tested it a bit more it
+seems to function well, apart from this reload thing. 
+
+>> 2. I of course thought about hitting reload, and that made dillo freeze 
+>> with 100% cpu usage. 
+> 
+> Ok, this was also reported by Andreas, and I _think_ it isn't the
+> patch's fault. I'm pretty sure it has to do with the IO.c EAGAIN issue
+> during writes. Jorge and I tried to fix the problem, but he said there
+> were some issues with that patch (which I couldn't reproduce), so he
+> backed it out for the 0.6.5 release. I'll try to get on top of that
+> today.
+> 
+> Anyway the problem arises when the about:cache page is over 4KiB
+> long (which is the size of a buffer, at least in Linux). When it is
+> over 4KiB, we have to write in in "chunks" (i.e. one buffer at a
+> time). So everything should work ok, as long as about:cache is smaller
+> than 4KiB.
+> 
+>> 3. When having browsed a bit, it seems that it won't take away anything
+>> from the cache. I set my size to ~ 5 MB and dillo was over 18 MB
+>> after a while.
+> 
+> Humm, I'm not sure what the problem is here, but be sure to notice
+> the difference between Dillo's memory usage and _cache_! My patch
+> doesn't promise to control Dillo's memory size, only the size of
+> _cache_.
+
+Yes, this was an error of mine, I loaded dillo with a bunch of graphics
+intensive sites, a couple of windows open. It probably should take some
+memory in such situations. :-)
+
+> 
+> There are two ways to verifiy if the patch is working:
+> 
+> [1] Look at the about:cache and check the "Current cache size: "
+> field, for big cache_sizes (I think over 1MiB), it should almost
+> never get over the "Maximum specified size: ".
+> 
+
+Well, this part is hard, I cannot go to more than a few pages, before
+the about:cache reload-bug hits me. So I cannot really verify that it
+keeps it within the limits, however it doesn't impact stability as far
+as I can tell.
+
+> [2] Put cache_size=00 and see if the about:cache always contains
+> _only_ the URL which are currently beeing viewed (remember to
+> reload the page to updated it).
+
+This one I can verify, it works as you describe it. It lists the urls of
+the browser windows, and size is very small. Also in this mode I cannot
+reproduce the reload-bug, which probably is correct, since it would
+require _many_ open windows at the same time to get to 4kb size of
+about:cache when it is only displaying toplevel urls.
+
+-- 
+//Hugo Hallqvist 
+
+
+
+Re: [Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Livio Baldini Soares <livio@im...> - 2002-06-02 14:55
+
+Hello Hugo!
+
+Hugo Hallqvist writes:
+> On 1 Jun, Livio Baldini Soares wrote:
+> 
+> > Ok, so before sending this oficially to Jorge, I think I would like
+> > some feedback. First, any comments about the functionalities I've
+> > inserted, but most importantly about the stability of the code. I
+> > would be very interested in receiving bug reports. Send replies only
+> > to me _if_ your comments won't be of interest to other subscribers to
+> > this list. 
+> 
+> After applying the patch to dillo i tested it out a bit and found a few
+> strange things:
+> 
+> 1. Quite often the about:cache won't get updated, it says it has found
+> my cachesize limit from dillorc, but not much else. 
+
+You have to hit reload, or else you'll get a cached version of
+about:cache, that's why it doesn't get updated.
+
+> 2. I of course thought about hitting reload, and that made dillo freeze 
+> with 100% cpu usage. 
+
+Ok, this was also reported by Andreas, and I _think_ it isn't the
+patch's fault. I'm pretty sure it has to do with the IO.c EAGAIN issue
+during writes. Jorge and I tried to fix the problem, but he said there
+were some issues with that patch (which I couldn't reproduce), so he
+backed it out for the 0.6.5 release. I'll try to get on top of that
+today.
+
+Anyway the problem arises when the about:cache page is over 4KiB
+long (which is the size of a buffer, at least in Linux). When it is
+over 4KiB, we have to write in in "chunks" (i.e. one buffer at a
+time). So everything should work ok, as long as about:cache is smaller
+than 4KiB.
+
+> 3. When having browsed a bit, it seems that it won't take away anything
+> from the cache. I set my size to ~ 5 MB and dillo was over 18 MB
+> after a while.
+
+Humm, I'm not sure what the problem is here, but be sure to notice
+the difference between Dillo's memory usage and _cache_! My patch
+doesn't promise to control Dillo's memory size, only the size of
+_cache_.
+
+There are two ways to verifiy if the patch is working:
+
+[1] Look at the about:cache and check the "Current cache size: "
+field, for big cache_sizes (I think over 1MiB), it should almost
+never get over the "Maximum specified size: ".
+
+[2] Put cache_size=00 and see if the about:cache always contains
+_only_ the URL which are currently beeing viewed (remember to
+reload the page to updated it).
+
+
+Thanks a lot for the feedback! I'll try to see if I can fix the
+problems you and Andreas have seen. As soon as I do, I'll post the
+patch here. 
+
+best regards!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Michael Govorun <mike@sh...> - 2002-06-02 14:31
+
+Hugo Hallqvist <hugha495@st...> writes:
+
+> After applying the patch to dillo i tested it out a bit and found a few
+> strange things:
+> 
+> 1. Quite often the about:cache won't get updated, it says it has found
+> my cachesize limit from dillorc, but not much else.
+> 2. I of course thought about hitting reload, and that made dillo freeze 
+> with 100% cpu usage.
+
+It seems to me that about:cache working with few entries in cache, but
+freeze dillo after number exceeds ~ 35 entries.
+
+> 3. When having browsed a bit, it seems that it won't take away anything
+> from the cache. I set my size to ~ 5 MB and dillo was over 18 MB
+> after a while.
+
+In my case (cache_size=50000) I found cache limit working good. No speed
+penalities have been observed (but how to measure?). No crashes for 3
+hours.
+The patch applied to clean 0.6.6.
+-- 
+Michael Govorun 
+
+
+
+Re: [Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Hugo Hallqvist <hugha495@st...> - 2002-06-02 09:48
+
+On 1 Jun, Livio Baldini Soares wrote:
+
+> Ok, so before sending this oficially to Jorge, I think I would like
+> some feedback. First, any comments about the functionalities I've
+> inserted, but most importantly about the stability of the code. I
+> would be very interested in receiving bug reports. Send replies only
+> to me _if_ your comments won't be of interest to other subscribers to
+> this list. 
+
+After applying the patch to dillo i tested it out a bit and found a few
+strange things:
+
+1. Quite often the about:cache won't get updated, it says it has found
+my cachesize limit from dillorc, but not much else.
+2. I of course thought about hitting reload, and that made dillo freeze 
+with 100% cpu usage.
+3. When having browsed a bit, it seems that it won't take away anything
+from the cache. I set my size to ~ 5 MB and dillo was over 18 MB
+after a while.
+
+I will try a little more, a clean dillo without any other patches maybe
+will work better.
+
+-- 
+//Hugo Hallqvist 
+
+
+
+[Dillo-dev][ANNOUNCEMENT] Cache Limit! :-D (and other fun cache utilities)
+
+From: Livio Baldini Soares <livio@im...> - 2002-06-02 02:26
+
+Hya folks!!! 
+
+I'm _very_ happy to announce that I think I have (finally) a
+ready-to-use patch which limits the size of cache!
+
+Jorge, congratulations on the LinuxDevices article! I am hoping that
+this patch will be welcomed by the embedded devices people, and will
+help enhance the Dillo experience for them (and users of other low
+systems, where memory is an issue).
+
+Dificulties (sorry for the wait)
+-----------
+
+It has taken me a _looonngg_ time to complete this patch (seems that
+my first post about this was on 20-Feb-2002, with a beta version). The
+main problem was trying to keep track of which URLs are being
+displayed (these entries can't be removed from cache, for various
+reasons).
+
+My first try was to keep reference counters for all entries. This
+solution was very ugly (specially in the reload situation with more
+than one browser window viewing the same Url.. grrr :-/). I almost had
+a working solution to that, but the code started to look ugly and
+complicated! After spending more than 4 or 5 weekends on this, I
+finally I gave up. And then I had no more time to dedicate to Dillo
+(which is bad :_(. There was a Brazilian holiday this thursday, so I
+sat down and was determined to get this going.
+
+Finally, I had an _obvious_ idea to my problem, which I would reject
+at first, but as I've thought and tried a bunch of other solutions,
+this actually seemed the best. All I do now is check every
+browser_window's nav stack to see if this is the URL currectly viewed.
+Thus I implemented Cache_browser_window_search(), with a linear search
+through the browser windows (shouldn't hurt much, as it is linear on
+the number of windows the user has open).
+
+Now that I've finished this patch kind of looks trivial... ;-)
+
+Features
+--------
+
+The following patch adds these 3 features:
+
+[1] cache_size preference option to dillorc. The size should be
+specified in _bytes_. If you want to disable caching you have to
+use `00` instead of just plain `0`, or else the parser will
+complain.
+
+[2] about:cache This page should contain all the info about the
+current cache, which include: number of entries,
+total cache size, size specified in dillorc, all the
+entries (URLs and size). It also contains a link to
+about about:cache-clear.
+
+[3] about:cache-clear This clears all cache entries which currently
+don't have a client (i.e. are not in the middle
+of being downloaded/processed), and are not
+being displayed in any browser window. And then
+shows the new cache info in the about:cache
+format.
+
+I've tried the features out, and they seem to work correctly. Be
+careful with [2] and [3]. If you want to update the contents of the
+page, be sure to hit _reload_! If you want to clear the cache, go to
+about:cache-clear and hit reload, otherwise the cache-clear function
+will not be activated.
+
+I would like to know, which of these features are of interest?
+Initially, I had set out to do only [1], and used [2] and [3] for
+debugging. But now I'm thinking that this may be useful to others... 
+
+Implementation
+--------------
+
+I basically implemented this using a LRU (least recently used)
+policy. For those not familiar with Virtual Memory in operating
+systems, LRU is a very common policy to choose which memory pages
+should be evicted to swap. That is, LRU tries to choose a page which
+has the lowest probability of being chosen again, or of being needed
+in the near future.
+
+I considered this policy to suit Dillo's cache perfectly, because in
+a strict sense, it is the same problem as in the operating system's
+VM. In the VM we have physical memory (RAM) as cache, fast, and the
+disk as swap, slow, and in Dillo, memory also as cache, and the
+network as a "slow-medium".
+
+Does anybody see a better suited policy to use? 
+
+Another advantage of LRU, is it's simple implementation. I used a
+doubly-linked list where elements at the beginning are "recent" and
+the ones at the end are "old". Whenever a page gets revisited (in VM
+we call this "touched"), I simply remove the entry (with doubly-linked
+list, this operation is O(1)), and add the entry to the beginning
+(which is O(1) too).
+
+When I have to remove something from the list, I simply start
+removing from the end. 
+
+Patch
+-----
+
+The patch is at:
+
+http://www.ime.usp.br/~livio/dillo/patches/cache-size-limit.diff
+
+
+The files which are modified are:
+
+dillorc: Added the cache_size option are reorganized the sections. 
+
+about.c: Added the about:cache and about:cache-clear mechanisms, and
+changed About_send() to be more generic, and not just send
+the splash screen.
+
+cache.[ch]: The "bulk" of the changes. Basically added the LRU as
+described above in [Implementation], and
+a_Cache_list_entries, which builds a HTML from the entries
+for usage in about:cache. Also added a_Cache_clear() for
+usage in about:cache-clear.
+
+prefs.[ch]: Just added the cache_size preferences.
+
+
+Ok, so before sending this oficially to Jorge, I think I would like
+some feedback. First, any comments about the functionalities I've
+inserted, but most importantly about the stability of the code. I
+would be very interested in receiving bug reports. Send replies only
+to me _if_ your comments won't be of interest to other subscribers to
+this list. 
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]Article
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-06-01 17:03
+
+Hi there!
+
+Good news, the article I was writing for LinuxDevices.com is
+already at the front page! (http://LinuxDevices.com).
+
+Enjoy!
+
+
+Cheers
+Jorge.- 
+
diff --git a/old/oldmail/200207.txt b/old/oldmail/200207.txt
new file mode 100644
index 0000000..b0579d7
--- /dev/null
+++ b/old/oldmail/200207.txt
@@ -0,0 +1,1987 @@
+[Dillo-dev]Re: Patch: META http-equiv=refresh is BROKEN a little :(
+
+From: Nikita V. Borodikhin <eliterr@tk...> - 2002-07-31 07:30
+
+I'm so sorry...
+
+Patch is broken a little (DRC_TOKEN_USE_META_REFRESH placed in pref.c
+instead of DRC_TOKEN_ALLOW_META_REFRESH)...
+
+
+Here is the correct patch:
+
+diff -pruN dillo.orig/dillorc dillo/dillorc
+--- dillo.orig/dillorc Thu May 30 17:21:08 2002
++++ dillo/dillorc Wed Jul 31 14:07:07 2002
+@@ -15,6 +15,9 @@ geometry=640x550
+# If you have a lot of memory and a slow CPU, use YES, otherwise use NO
+use_dicache=NO
+
++# We do not allow http-equiv=refresh by default because it's not
++# conform to official HTML 4.01 standard
++allow_meta_refresh=NO
+
+#-------------------------------------------------------------------------
+# RENDERING SECTION
+diff -pruN dillo.orig/src/html.c dillo/src/html.c
+--- dillo.orig/src/html.c Mon Jul 1 10:13:37 2002
++++ dillo/src/html.c Wed Jul 31 14:10:52 2002
+@@ -2512,15 +2512,74 @@ static void Html_tag_close_form(DilloHtm
+
+/*
+* Handle <META>
+- * We do not support http-equiv=refresh because it's non standar,
+- * (the HTML 4.01 SPEC recommends explicitily to avoid it), and it
+- * can be easily abused!
++ * We disable http-equiv=refresh by default because it's non standard,
++ * (the HTML 4.01 SPEC recommends explicitily to avoid it),
++ * and it can be easily abused!
+*/
+static void Html_tag_open_meta(DilloHtml *html, char *tag, gint tagsize)
+{
++ const gchar *http_equiv;
++ const gchar *content;
++ const gchar *url_string;
++ DwPage *page;
++ DwStyle style_attrs, *link_style;
++ DilloUrl *url;
++ gint dummy;
++
++ page = DW_PAGE(html->dw);
++ style_attrs = *(html->stack[html->stack_top].style);
++
+/* only valid inside HEAD */
+- if (html->InFlags & IN_HEAD)
+- return;
++ if (! (html->InFlags & IN_HEAD))
++ DEBUG_HTML_MSG ("META tag is not inside HEAD\n");
++
++ if ((http_equiv = Html_get_attr(html, tag, tagsize, "http-equiv")))
++ {
++ if ((strcasecmp (http_equiv, "refresh") == 0) && prefs.allow_meta_refresh
++ && (content = Html_get_attr(html, tag, tagsize, "content")))
++ {
++ url_string = strstr (content, "URL=");
++ if (strlen (url_string) > 4)
++ url_string += 4;
++ else
++ url_string = NULL;
++
++ if (url_string && (url = a_Url_new(url_string,
++ URL_STR_(html->linkblock->base_url),
++ 0, 0)))
++ {
++ a_Dw_page_add_text (page, g_strdup ("This page uses META-refresh to "),
++ html->stack[(html)->stack_top].style);
++
++ if (a_Cache_url_read(url, &dummy)) /* visited frame */
++ style_attrs.color = a_Dw_style_color_new
++ (html->linkblock->visited_color, html->bw->main_window->window);
++ else /* unvisited frame */
++ style_attrs.color = a_Dw_style_color_new
++ (html->linkblock->link_color, html->bw->main_window->window);
++
++ style_attrs.uline = TRUE;
++ style_attrs.link = Html_set_new_link(html, &url);
++ link_style = a_Dw_style_new (&style_attrs,
++ html->bw->main_window->window);
++
++ a_Dw_page_add_text(page, g_strdup(url_string), link_style);
++
++ a_Dw_style_unref(link_style);
++ }
++ else
++ {
++ a_Dw_page_add_text (page, g_strdup ("Strange META-refresh argument: "),
++ html->stack[(html)->stack_top].style);
++ a_Dw_page_add_text (page, g_strdup (content),
++ html->stack[(html)->stack_top].style);
++ }
++
++ a_Dw_page_add_parbreak(page, 9, html->stack[(html)->stack_top].style);
++ }
++ }
++
++ return;
+}
+
+/*
+diff -pruN dillo.orig/src/prefs.c dillo/src/prefs.c
+--- dillo.orig/src/prefs.c Thu Apr 11 12:37:35 2002
++++ dillo/src/prefs.c Wed Jul 31 13:43:44 2002
+@@ -53,6 +53,7 @@ static const struct {
+{ "limit_text_width", DRC_TOKEN_LIMIT_TEXT_WIDTH },
+{ "font_factor", DRC_TOKEN_FONT_FACTOR },
+{ "use_dicache", DRC_TOKEN_USE_DICACHE },
++ { "allow_meta_refresh", DRC_TOKEN_ALLOW_META_REFRESH },
+{ "show_back", DRC_TOKEN_SHOW_BACK },
+{ "show_forw", DRC_TOKEN_SHOW_FORW },
+{ "show_home", DRC_TOKEN_SHOW_HOME },
+@@ -178,6 +179,9 @@ static guint Prefs_parser(GScanner *scan
+case DRC_TOKEN_USE_DICACHE:
+prefs.use_dicache = (strcmp(scanner->value.v_string, "YES") == 0);
+break;
++ case DRC_TOKEN_ALLOW_META_REFRESH:
++ prefs.allow_meta_refresh = (strcmp(scanner->value.v_string, "YES") == 0);
++ break;
+case DRC_TOKEN_SHOW_BACK:
+prefs.show_back = (strcmp(scanner->value.v_string, "YES") == 0);
+break;
+@@ -339,6 +343,7 @@ void a_Prefs_init(void)
+prefs.limit_text_width = FALSE;
+prefs.font_factor = 1.0;
+prefs.use_dicache = FALSE;
++ prefs.allow_meta_refresh = FALSE;
+prefs.show_back=TRUE;
+prefs.show_forw=TRUE;
+prefs.show_home=TRUE;
+diff -pruN dillo.orig/src/prefs.h dillo/src/prefs.h
+--- dillo.orig/src/prefs.h Thu Apr 11 12:37:35 2002
++++ dillo/src/prefs.h Wed Jul 31 13:44:01 2002
+@@ -43,6 +43,7 @@ typedef enum {
+DRC_TOKEN_SHOW_ALT,
+DRC_TOKEN_LIMIT_TEXT_WIDTH,
+DRC_TOKEN_USE_DICACHE,
++ DRC_TOKEN_ALLOW_META_REFRESH,
+DRC_TOKEN_SHOW_BACK,
+DRC_TOKEN_SHOW_FORW,
+DRC_TOKEN_SHOW_HOME,
+@@ -85,6 +86,7 @@ struct _DilloPrefs {
+gboolean limit_text_width;
+gdouble font_factor;
+gboolean use_dicache;
++ gboolean allow_meta_refresh;
+gboolean show_back;
+gboolean show_forw;
+gboolean show_home; 
+
+
+
+[Dillo-dev]Patch: META http-equiv=refresh
+
+From: Nikita V. Borodikhin <eliterr@tk...> - 2002-07-31 07:16
+
+Hello all Dillo users !
+
+I thought that META http-equiv=refresh parameter in fully not standard
+but recently I found Web Design Group's page about META tag
+(see http://www.htmlhelp.com/reference/html40/head/meta.html).
+
+They wrote <META http-equiv=refresh content='10; URL=>
+is usual tag but not all browsers can handle it, so I made patch that
+adds support for it (disabled by default) that adds ability to see
+URL refreshing to as link (like dillo's frame support does).
+
+Sincerely yours,
+Nikita V. Borodikhin
+
+
+
+Here is the patch:
+
+diff -pruN dillo.orig/dillorc dillo/dillorc
+--- dillo.orig/dillorc Thu May 30 17:21:08 2002
++++ dillo/dillorc Wed Jul 31 14:07:07 2002
+@@ -15,6 +15,9 @@ geometry=640x550
+# If you have a lot of memory and a slow CPU, use YES, otherwise use NO
+use_dicache=NO
+
++# We do not allow http-equiv=refresh by default because it's not
++# conform to official HTML 4.01 standard
++allow_meta_refresh=NO
+
+#-------------------------------------------------------------------------
+# RENDERING SECTION
+diff -pruN dillo.orig/src/html.c dillo/src/html.c
+--- dillo.orig/src/html.c Mon Jul 1 10:13:37 2002
++++ dillo/src/html.c Wed Jul 31 14:10:52 2002
+@@ -2512,15 +2512,74 @@ static void Html_tag_close_form(DilloHtm
+
+/*
+* Handle <META>
+- * We do not support http-equiv=refresh because it's non standar,
+- * (the HTML 4.01 SPEC recommends explicitily to avoid it), and it
+- * can be easily abused!
++ * We disable http-equiv=refresh by default because it's non standard,
++ * (the HTML 4.01 SPEC recommends explicitily to avoid it),
++ * and it can be easily abused!
+*/
+static void Html_tag_open_meta(DilloHtml *html, char *tag, gint tagsize)
+{
++ const gchar *http_equiv;
++ const gchar *content;
++ const gchar *url_string;
++ DwPage *page;
++ DwStyle style_attrs, *link_style;
++ DilloUrl *url;
++ gint dummy;
++
++ page = DW_PAGE(html->dw);
++ style_attrs = *(html->stack[html->stack_top].style);
++
+/* only valid inside HEAD */
+- if (html->InFlags & IN_HEAD)
+- return;
++ if (! (html->InFlags & IN_HEAD))
++ DEBUG_HTML_MSG ("META tag is not inside HEAD\n");
++
++ if ((http_equiv = Html_get_attr(html, tag, tagsize, "http-equiv")))
++ {
++ if ((strcasecmp (http_equiv, "refresh") == 0) && prefs.allow_meta_refresh
++ && (content = Html_get_attr(html, tag, tagsize, "content")))
++ {
++ url_string = strstr (content, "URL=");
++ if (strlen (url_string) > 4)
++ url_string += 4;
++ else
++ url_string = NULL;
++
++ if (url_string && (url = a_Url_new(url_string,
++ URL_STR_(html->linkblock->base_url),
++ 0, 0)))
++ {
++ a_Dw_page_add_text (page, g_strdup ("This page uses META-refresh to "),
++ html->stack[(html)->stack_top].style);
++
++ if (a_Cache_url_read(url, &dummy)) /* visited frame */
++ style_attrs.color = a_Dw_style_color_new
++ (html->linkblock->visited_color, html->bw->main_window->window);
++ else /* unvisited frame */
++ style_attrs.color = a_Dw_style_color_new
++ (html->linkblock->link_color, html->bw->main_window->window);
++
++ style_attrs.uline = TRUE;
++ style_attrs.link = Html_set_new_link(html, &url);
++ link_style = a_Dw_style_new (&style_attrs,
++ html->bw->main_window->window);
++
++ a_Dw_page_add_text(page, g_strdup(url_string), link_style);
++
++ a_Dw_style_unref(link_style);
++ }
++ else
++ {
++ a_Dw_page_add_text (page, g_strdup ("Strange META-refresh argument: "),
++ html->stack[(html)->stack_top].style);
++ a_Dw_page_add_text (page, g_strdup (content),
++ html->stack[(html)->stack_top].style);
++ }
++
++ a_Dw_page_add_parbreak(page, 9, html->stack[(html)->stack_top].style);
++ }
++ }
++
++ return;
+}
+
+/*
+diff -pruN dillo.orig/src/prefs.c dillo/src/prefs.c
+--- dillo.orig/src/prefs.c Thu Apr 11 12:37:35 2002
++++ dillo/src/prefs.c Wed Jul 31 13:43:44 2002
+@@ -53,6 +53,7 @@ static const struct {
+{ "limit_text_width", DRC_TOKEN_LIMIT_TEXT_WIDTH },
+{ "font_factor", DRC_TOKEN_FONT_FACTOR },
+{ "use_dicache", DRC_TOKEN_USE_DICACHE },
++ { "allow_meta_refresh", DRC_TOKEN_USE_META_REFRESH },
+{ "show_back", DRC_TOKEN_SHOW_BACK },
+{ "show_forw", DRC_TOKEN_SHOW_FORW },
+{ "show_home", DRC_TOKEN_SHOW_HOME },
+@@ -178,6 +179,9 @@ static guint Prefs_parser(GScanner *scan
+case DRC_TOKEN_USE_DICACHE:
+prefs.use_dicache = (strcmp(scanner->value.v_string, "YES") == 0);
+break;
++ case DRC_TOKEN_ALLOW_META_REFRESH:
++ prefs.allow_meta_refresh = (strcmp(scanner->value.v_string, "YES") == 0);
++ break;
+case DRC_TOKEN_SHOW_BACK:
+prefs.show_back = (strcmp(scanner->value.v_string, "YES") == 0);
+break;
+@@ -339,6 +343,7 @@ void a_Prefs_init(void)
+prefs.limit_text_width = FALSE;
+prefs.font_factor = 1.0;
+prefs.use_dicache = FALSE;
++ prefs.allow_meta_refresh = FALSE;
+prefs.show_back=TRUE;
+prefs.show_forw=TRUE;
+prefs.show_home=TRUE;
+diff -pruN dillo.orig/src/prefs.h dillo/src/prefs.h
+--- dillo.orig/src/prefs.h Thu Apr 11 12:37:35 2002
++++ dillo/src/prefs.h Wed Jul 31 13:44:01 2002
+@@ -43,6 +43,7 @@ typedef enum {
+DRC_TOKEN_SHOW_ALT,
+DRC_TOKEN_LIMIT_TEXT_WIDTH,
+DRC_TOKEN_USE_DICACHE,
++ DRC_TOKEN_ALLOW_META_REFRESH,
+DRC_TOKEN_SHOW_BACK,
+DRC_TOKEN_SHOW_FORW,
+DRC_TOKEN_SHOW_HOME,
+@@ -85,6 +86,7 @@ struct _DilloPrefs {
+gboolean limit_text_width;
+gdouble font_factor;
+gboolean use_dicache;
++ gboolean allow_meta_refresh;
+gboolean show_back;
+gboolean show_forw;
+gboolean show_home; 
+
+
+
+[Dillo-dev]Bug 254, Table width is too large.
+
+From: Matias Aguirre <yo_soy@fa...> - 2002-07-31 07:16
+
+Hi list, Im new to dillo and you maked a great work.
+
+In 254 bug describes "table width is too large" but this is not the reason of this bug.
+The reason is that if you read the source of http://linux.oreillynet.com/pub/a/linux/2001/11/15/learnunixos.html you found <IFRAME> tag, and this dont put in dillo sources.
+
+This is a <IFRAME> referense: http://www.htmlhelp.com/reference/html40/special/iframe.html
+
+Greetings
+
+ps: sorry by my bad english 
+
+
+
+[Dillo-dev]Nav push consistency
+
+From: Eric GAUDET <eric@rt...> - 2002-07-28 22:45
+
+Hi all,
+
+I just occured to me that the way Dillo handles URL is somewhat inconsist=
+ent.
+Choosing an already visited URL from the back history pushes the old page=
+, and
+remembers the position in this page. However, clicking on a link for an a=
+lready
+visited URL pushes the same link, only a the top of the page.
+What=B4s really inconsistent, is if you have several time the same page i=
+n the
+back history, the remembered position in the page is unique (the last
+position), no matter what history entry you choose.
+
+I understand that there is two different codepath and only one cache entr=
+y, be
+still.
+
+To be more polished, we have to choose between two consistent behaviors:
+- the position is stored in the back history, not in the cache entry. Tha=
+t way,
+every back history remembers its own position, and newly clicked link ope=
+n the
+page at the top
+- the position remains stored in the cache entry, and is always used no m=
+atter
+what. All nav push to this URL positions the page at this unique position=
+,
+regardless of if it is clicked from the back history, a link in the page,=
+or
+entered in the location bar.
+
+I think I prefer the latter myself. What do you guys think?
+
+Best,
+Eric 
+
+
+
+Re: [Dillo-dev]Copy/paste in Dillo
+
+From: Eric GAUDET <eric@rt...> - 2002-07-28 03:52
+
+There is no problem asking for new features, but before doing that, it mi=
+ght be
+wise to read le web site, especially the bug track. I am sick and tired o=
+f the
+new visitors asking the same question again and again, even if there is a
+published todo list.
+
+John was right on: Dillo is open source and contributions have always bee=
+n
+welcome.
+
+If you feel like a feature is missing, go head and code it.=20
+
+If you don=B4t want/can=B4t do it, just wait. It might not be there eithe=
+r because
+it is difficult, or because Dillo=B4s developers have other priority, or =
+are too
+busy doing something else. We are all coding Dillo on our free time, and =
+we can
+not answer to individual demands. Dillo has been progressing a lot since =
+the
+very being, only driven by the needs of contributors.
+
+If you don=B4t want to wait, use another browser.
+
+As for copy/paste, it is actually the oldest entry in the bug-track engin=
+e, and
+I agree this is an important one. I filed it, then I volunteered to imple=
+ment
+it. However, many issues are in the way. First of all, Dillo=B4s internal
+representation has changed a lot and keeps changing. Secondly, I didn=B4t=
+have
+time so far to give a try to the new iterators.
+
+In short, this is far from being =A8a simple task=A8.
+
+You want to know when: when somebody codes it! Simple as that. I am doing=
+it,
+slowly (don=B4t hold your breath). If somebody else does it before me, mo=
+re power
+to him!
+
+Just sit tight and wait.
+
+Best,
+Eric
+
+-- En reponse de "Re: [Dillo-dev]Copy/paste in Dillo" de Jamin W. Collins=
+, le
+27-Jul-2002 :
+> On Sat, 27 Jul 2002 13:42:21 -0500 (CDT)
+> John Utz <john@ut...> wrote:
+>=20
+>> We await your patch!
+>>=20
+>> (which is a nice way of saying, if you wont fix it yourself, stop=20
+>> bitching)
+>=20
+> Curious, is there a problem with users of Dillo asking for or expressin=
+g
+> interested in having a feature added? I didn't take the OP's request a=
+s
+> "bitching".
+>=20
+> --=20
+> Jamin W. Collins
+>=20
+>=20
+> -------------------------------------------------------
+> This s...net email is sponsored by:ThinkGeek
+> Welcome to geek heaven.
+> http://thinkgeek.com/sf
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+
+------------------------------------------------------------------------
+Eric GAUDET <eric@rt...>
+Le 27-Jul-2002 a 20:30:25
+"Parler pour ne rien dire et ne rien dire pour parler sont les deux
+principes majeurs et rigoureux de tous ceux qui feraient mieux de la
+fermer avant de l'ouvrir."
+------------------------------------------------------------------------ 
+
+
+
+Re: [Dillo-dev]libdillo
+
+From: Jonathan Gardner <gardnerj@pr...> - 2002-07-28 01:48
+
+On Tue, 23 Jul 2002 09:06:26 +0200
+Melvin Hadasht <melvin.hadasht@fr...> wrote:
+
+> Mean while, I made a small patch for the same reason but with another
+> approach, if you're interested:
+> http://melvin.hadasht.free.fr/home/dillo/sylpheed/ 
+
+Speaking of this patch. It still worked as of the 0.7.8claws release of
+Sylpheed-claws but now as of the 0.8.0claws release it doesn't patch so
+well and the make doesn't work.
+Any plans on updating the patch?
+Thanks much for it. It really makes Sylpheed even more nifty than it
+already was.
+
+Cheers,
+Jonathan
+
+-- 
+#define __INTELLECTUAL_CHRISTIAN__
+
+#include <JESUS><
+#include ><DARWIN>
+L L 
+
+
+
+Re: [Dillo-dev]Copy/paste in Dillo
+
+From: John Utz <john@ut...> - 2002-07-28 01:19
+
+umm, i overspoke.
+
+sorry.
+
+On Sat, 27 Jul 2002, Jamin W. Collins wrote:
+
+> On Sat, 27 Jul 2002 13:42:21 -0500 (CDT)
+> John Utz <john@ut...> wrote:
+> 
+> > We await your patch!
+> > 
+> > (which is a nice way of saying, if you wont fix it yourself, stop 
+> > bitching)
+> 
+> Curious, is there a problem with users of Dillo asking for or expressing
+> interested in having a feature added? I didn't take the OP's request as
+> "bitching".
+> 
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+Re: [Dillo-dev]Copy/paste in Dillo
+
+From: Jamin W. Collins <jcollins@as...> - 2002-07-27 19:54
+
+On Sat, 27 Jul 2002 13:42:21 -0500 (CDT)
+John Utz <john@ut...> wrote:
+
+> We await your patch!
+> 
+> (which is a nice way of saying, if you wont fix it yourself, stop 
+> bitching)
+
+Curious, is there a problem with users of Dillo asking for or expressing
+interested in having a feature added? I didn't take the OP's request as
+"bitching".
+
+-- 
+Jamin W. Collins 
+
+
+
+Re: [Dillo-dev]Copy/paste in Dillo
+
+From: John Utz <john@ut...> - 2002-07-27 18:42
+
+We await your patch!
+
+(which is a nice way of saying, if you wont fix it yourself, stop 
+bitching)
+
+On 27 Jul 2002, mightyunclean wrote:
+
+> Anyone know when support for text copy/paste will be incorporated into
+> Dillo ?
+> 
+> Or if there is a patch available to enable support for this ?
+> 
+> Have been following Dillo's development from about 0.4.0, but there
+> still hasn't been any support for this.
+> I wonder if anyone has even thought of this simple but important
+> feature.
+> It is so frustrating being forced to use some other browser all the time
+> simply because Dillo lacks basic functionality.
+> Apart from this, everything is fine & dandy.
+> 
+> Keep up the good work fellas.
+> 
+> 
+> 
+> http://www.sold.com.au - SOLD.com.au
+> - Find yourself a bargain!
+> 
+> 
+> -------------------------------------------------------
+> This s...net email is sponsored by:ThinkGeek
+> Welcome to geek heaven.
+> http://thinkgeek.com/sf
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+
+John L. Utz III
+john@ut...
+
+Idiocy is the Impulse Function in the Convolution of Life 
+
+
+
+[Dillo-dev]Copy/paste in Dillo
+
+From: mightyunclean <mightyunclean@ne...> - 2002-07-27 07:52
+
+Anyone know when support for text copy/paste will be incorporated into
+Dillo ?
+
+Or if there is a patch available to enable support for this ?
+
+Have been following Dillo's development from about 0.4.0, but there
+still hasn't been any support for this.
+I wonder if anyone has even thought of this simple but important
+feature.
+It is so frustrating being forced to use some other browser all the time
+simply because Dillo lacks basic functionality.
+Apart from this, everything is fine & dandy.
+
+Keep up the good work fellas.
+
+
+
+http://www.sold.com.au - SOLD.com.au
+- Find yourself a bargain! 
+
+
+
+Re: [Dillo-dev]libdillo
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-07-23 07:06
+
+Hi erez@sa...,
+
+on Tue, 23 Jul 2002 03:18:37 -1:00
+erez@sa... wrote:
+
+> I was wondering if it is possible to
+> split dillo into a gtk-widget-lib
+> 
+> (libdillo) and an application, 
+> so people could use libdillo and have
+> html in their apps
+
+that would be great. 
+
+Mean while, I made a small patch for the same reason but with another approach,
+if you're interested:
+http://melvin.hadasht.free.fr/home/dillo/sylpheed/ 
+
+Namlala unono (Comoran: Goodbye)
+
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]libdillo
+
+From: <erez@sa...> - 2002-07-23 06:17
+
+hello
+
+I`m currently writing a mail client for
+linux/ipaq, and I need a html widget.
+
+I thought of using dillo for this
+( porting it`s source into my app)
+but as I already have dillo, this will
+make the same code twice, and it`s a
+waste of flash,and I will have to
+port again when there will be a new
+vesion of dillo.
+
+I was wondering if it is possible to
+split dillo into a gtk-widget-lib
+
+(libdillo) and an application, 
+so people could use libdillo and have
+html in their apps
+
+
+ps,
+I`m not on this mailing list so please
+also CC to me.
+
+thanks,
+erez. 
+
+
+
+RE: [Dillo-dev]ecmascript, javascript and CSS 
+
+From: floorzat floorzat <floorzat@ho...> - 2002-07-22 21:58
+
+Um.....
+The codebase structure severely restricts the possibility of reasonable 
+implementation of script controlled DOM.
+New Eventloop structures and highly complex semaphor systems would be 
+required and a complete ground up recode would probably be simpler.
+
+
+
+_________________________________________________________________
+Join the world’s largest e-mail service with MSN Hotmail. 
+http://www.hotmail.com 
+
+
+
+Re: [Dillo-dev]Pixmap GTK themes
+
+From: Patrick Glennon <pglennon@me...> - 2002-07-21 17:31
+
+Attachments: Message as HTML      
+
+I have done a lot of pixmap themeing with dillo with no problems, from
+v. 0.6.2 up to relatively current CVS builds. Also used thinice engine
+and xenophilia with no problems...
+
+do you have gtk themes properly set up? are your path names to the
+engine libraries properly referenced in the gtkrc file? Also, do you
+have the gtk/gdk libs installed? another thing to check is to make
+sure that the theme engine libraries are in ( usually )
+/usr/lib/gtk/themes/engines
+
+libpixmap.so - pixmap theme engine
+libxeno.so - xenophilia theme engine
+libthinice.so - thinice theme engine
+( etc.. )
+
+hope this helps, and is not just a regurgitation of the obvious...
+
+Cheers,
+-Patrick
+
+On Sat, 2002-07-20 at 21:59, Mark Schreiber wrote:
+
+Does anyone else have any problems using pixmap GTK themes with dillo?
+I'm not seeing any pixmaps in pixmap engine gtk themes being drawn in
+a dillo (current CVS) window, though all the other GTK apps I use work
+fine. I'd like to see whether this is just my copy of dillo first,
+though.
+
+If anyone has a pixmap gtk theme on their computer, could you try
+switching to it and see whether the pixmaps are visible in your dillo
+window?
+
+Thanks!
+
+-- 
+Best of luck,
+Mark Schreiber 
+
+
+
+[Dillo-dev]Pixmap GTK themes
+
+From: Mark Schreiber <mark7@an...> - 2002-07-21 02:59
+
+Attachments: Message as HTML      
+
+Does anyone else have any problems using pixmap GTK themes with dillo?
+I'm not seeing any pixmaps in pixmap engine gtk themes being drawn in
+a dillo (current CVS) window, though all the other GTK apps I use work
+fine. I'd like to see whether this is just my copy of dillo first,
+though.
+
+If anyone has a pixmap gtk theme on their computer, could you try
+switching to it and see whether the pixmaps are visible in your dillo
+window?
+
+Thanks!
+
+--=20
+Best of luck,
+Mark Schreiber 
+
+
+
+[Dillo-dev]Re: Reading gzipped files
+
+From: Vikas G P <vikasgp386@ho...> - 2002-07-17 13:20
+
+On Mon,15 Jul 2002 07:23 PM Ken Hayber wrote,
+
+>My point was that I believe that when http servers like apache support
+>gzip they do not change the filename, they just compress the data on the
+>fly. I could be wrong too, but that's what I believe is the case. It is
+>the content-coding attribute that tells the browser it is compressed, not
+>the filename.
+>
+>Maybe they're just two complementary ways to accomplish the same thing:
+>.gz for local files, content-coding for http-served files. Would it be
+>hard to implement both
+
+Ah,
+I get it now. What Ken is saying is that we need to support on-the-fly decompession of content sent via http, by checking their
+content-encoding attribute. The reason I did it only for local files is :
+I don't think there are many sites out there which put up index.html.gz. And gzipped files on the server should probably be
+downloaded, and I didn't know how to do it.
+BTW, most other browsers offer to download a .html.gz sent over http.
+
+On Mon, 15 Jul 2002 08:04 PM madis wrote,
+
+>On Mon, 15 Jul 2002, Ken Hayber wrote:
+
+>> Maybe they're just two complementary ways to accomplish the same thing:
+>> ..gz for local files, content-coding for http-served files. Would it be
+>> hard to implement both?
+
+>I looked for it now, seems that it requires modifing IO/http.c and cache.c
+>(at least). Implementing this way would be *the right thing* imho, but it
+>requires fully understanding how these two things talk with each other
+>(what i didn't bothered). Main problem is that a part of http traffic is
+>gzip'ed (body), but another part is not (header).
+
+Yes, IMHO it is the *right thing* to do.
+
+Vikas G P 
+
+
+
+[Dillo-dev]gzipped HTML files
+
+From: Geoff Lane <zzassgl@tw...> - 2002-07-17 07:46
+
+A few months ago I posted some patches for gzipped HTML support. These can
+be found at
+http://twirl.mcc.ac.uk/dillo/dillo_gzip.html
+There is also a very brief discussion about the requirements and possible
+improvements. The patches will probably need to be re-worked for the recent
+dillo releases. Anyone who want's to grab a copy and work up a proper patch
+for dillo, please do so.
+
+I see that Apache2 contains mod_gzip as a standard module - there's probably
+going to be a lot more compressed web pages in the future.
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+Govt investigations contribute more to amusement than knowledge. 
+
+
+
+Re: [Dillo-dev]RE: Dillo-dev digest, Vol 1 #539 - 1 msg
+
+From: madis <madis@cy...> - 2002-07-16 19:53
+
+On 16 Jul 2002, Patrick Glennon wrote:
+
+> Go into ~/.dillo/dillorc and make changes to these entries, depending on
+> how much you want to strip it down:
+> 
+> show_back=NO
+> show_forw=NO
+> show_home=NO 
+> show_reload=NO
+> show_save=NO
+> show_stop=NO
+> show_menubar=NO
+> show_clear_url=NO
+> show_url=NO
+> show_progress_box=NO
+> 
+and...
+panel_size=tiny
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]RE: Dillo-dev digest, Vol 1 #539 - 1 msg
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-07-16 19:43
+
+Hi Jedediah,
+
+on Tue, 16 Jul 2002 16:31:41 -0300 "Jedediah Ferguson"
+<jFerguson@tr...> wrote:
+
+> I was wondering if there is a means to suppress the navigation bar.
+> I am only running a 1/4 VGA display and it would be advantageous is
+> the naviagtion bar could be removed or hidden upon initialization as
+> it would make for a cleaner GUI.
+
+You can double-click inside the window to go into full-window mode.
+There is no command line option to run it from the start in that mode. But I
+have a preliminary patch here:
+
+http://melvin.hadasht.free.fr/home/dillo/fullwindow/index.html
+
+Cheers
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]RE: Dillo-dev digest, Vol 1 #539 - 1 msg
+
+From: Jamin W. Collins <jcollins@as...> - 2002-07-16 19:41
+
+On Tue, 16 Jul 2002 16:31:41 -0300 "Jedediah Ferguson"
+<jFerguson@tr...> wrote:
+
+> I was wondering if there is a means to suppress the navigation bar. I
+> am only running a 1/4 VGA display and it would be advantageous is the
+> naviagtion bar could be removed or hidden upon initialization as it
+> would make for a cleaner GUI.
+
+Double-click the background of the browser's page.
+
+-- 
+Jamin W. Collins 
+
+
+
+Re: [Dillo-dev]RE: Dillo-dev digest, Vol 1 #539 - 1 msg
+
+From: Patrick Glennon <pglennon@me...> - 2002-07-16 19:38
+
+Attachments: Message as HTML      
+
+Go into ~/.dillo/dillorc and make changes to these entries, depending on
+how much you want to strip it down:
+
+show_back=NO
+show_forw=NO
+show_home=NO 
+show_reload=NO
+show_save=NO
+show_stop=NO
+show_menubar=NO
+show_clear_url=NO
+show_url=NO
+show_progress_box=NO
+
+I also use it on an embedded system, and have also found it helpful to
+blank the X cursor... let me know if you would like a patch for
+that... it just amounts to replacing the gdk cursor call with an inline
+blank gdk cursor creation, and it is just two files that need to be
+modified....
+
+Cheers!
+
+-Patrick
+
+On Tue, 2002-07-16 at 14:31, Jedediah Ferguson wrote:
+
+Dillo-Dev,
+
+Dillo is an impressive web browser. I am currently running it on a minimal Debian system on a single board computer in the hopes of using it as a GUI. Dillo runs much more quickly than other browsers I have tried. It can even render complex sites like Slashdot almost as fast as the video can refresh.
+
+I was wondering if there is a means to suppress the navigation bar. I am only running a 1/4 VGA display and it would be advantageous is the naviagtion bar could be removed or hidden upon initialization as it would make for a cleaner GUI.
+
+Thanks for a Great Program.
+
+
+Best Regards,
+
+Jedediah Ferguson
+Computer Engineering Co-op
+
+mailto:Jedediah.Ferguson@tr...
+http://www.trecan.com
+
+4049 St. Margaret's Bay Road
+Hubley, Nova Scotia, B3Z 1C2, Canada
+
+Phone: 902 876-0457
+Fax: 902 876-8275
+
+
+
+
+
+-------------------------------------------------------
+This s...net email is sponsored by: Jabber - The world's fastest growing 
+real-time communications platform! Don't just IM. Build it in! 
+http://www.jabber.com/osdn/xim
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]RE: Dillo-dev digest, Vol 1 #539 - 1 msg
+
+From: Jedediah Ferguson <jFerguson@tr...> - 2002-07-16 19:31
+
+Dillo-Dev,
+
+Dillo is an impressive web browser. I am currently running it on a =
+minimal Debian system on a single board computer in the hopes of using =
+it as a GUI. Dillo runs much more quickly than other browsers I have =
+tried. It can even render complex sites like Slashdot almost as fast as =
+the video can refresh.
+
+I was wondering if there is a means to suppress the navigation bar. I =
+am only running a 1/4 VGA display and it would be advantageous is the =
+naviagtion bar could be removed or hidden upon initialization as it =
+would make for a cleaner GUI.
+
+Thanks for a Great Program.
+
+
+Best Regards,
+
+Jedediah Ferguson
+Computer Engineering Co-op
+
+mailto:Jedediah.Ferguson@tr...
+http://www.trecan.com
+
+4049 St. Margaret's Bay Road
+Hubley, Nova Scotia, B3Z 1C2, Canada
+
+Phone: 902 876-0457
+Fax: 902 876-8275 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-07-16 15:14
+
+On Thu, Jul 11, 2002 at 01:16:53PM -0500, Paul Chamberlain wrote:
+> I think you set my expectations too high. I have a LOT of
+> bookmarks in mozilla. I'm not sure which one caused it,
+> but when dillo tried to load, it said:
+> 
+> Loading bookmarks...
+> 
+> GLib-ERROR **: could not allocate -75 bytes
+> aborting...
+> Aborted (core dumped)
+
+Funnily, I had them in the booksmark.html file, i.e. something like
+
+---
+...
+<li><A HREF="...">...</A></li>
+
+** CRITICAL **: file web.c: line 56 (a_Web_dispatch_by_type): assertion `dw != NULL' failed.
+<li><A HREF="...">...</A></li>
+
+** WARNING **: 11 styles left
+
+** WARNING **: 2 fonts (11 references) left
+
+** WARNING **: 2 colors (11 references) left
+
+** WARNING **: 1 shaded colors (8 references) left
+<li><A HREF="...">...</A></li>
+...
+---
+
+I cannot reproduce this, someone who can should insert an entry in to
+the bug tracking engine. (I'm not even sure if these bugs still exist,
+I rarely use the "View Bookmarks" function.)
+
+> This s...net email is sponsored by:ThinkGeek
+> PC Mods, Computing goodies, cases & more
+> http://thinkgeek.com/sf
+
+Seems that is time to switch the list hoster.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]Re:Reading gzipped files
+
+From: Ken Hayber <khayber@so...> - 2002-07-15 14:48
+
+I looked a bit more at the RFCs and see that there is also a 
+transfer-coding attribute that seems to be more directed at what I am 
+talking about. It seems a bit confusing; maybe I'll take a look at the 
+apache code and see if I can tell what they are doing. It seems that 
+content-coding may be intended to describe the content (not modify it) and 
+transfer coding describes how it is being transferred (on the fly, e.g. 
+chunked, gzip, etc).
+
+I found a small discussion indicating that a content-coding of gzip might 
+indicate to the browser (UA) to save the file rather than display it, 
+whereas the transfer-encoding would indicate that the UA should decode it.
+
+(http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1999/0197.html)
+
+
+
+On Monday, July 15, 2002, at 07:52 AM, madis wrote:
+
+> On Mon, 15 Jul 2002, Ken Hayber wrote:
+>
+>> My point was that I believe that when http servers like apache support
+>> gzip they do not change the filename, they just compress the data on the
+>> fly. I could be wrong too, but that's what I believe is the case. It is
+>> the content-coding attribute that tells the browser it is compressed, not
+>> the filename.
+>>
+>> Maybe they're just two complementary ways to accomplish the same thing:
+>> ..gz for local files, content-coding for http-served files. Would it be
+>> hard to implement both?
+>
+> I looked for it now, seems that it requires modifing IO/http.c and cache.
+> c
+> (at least). Implementing this way would be *the right thing* imho, but it
+> requires fully understanding how these two things talk with each other
+> (what i didn't bothered). Main problem is that a part of http traffic is
+> gzip'ed (body), but another part is not (header).
+> 
+
+
+
+Re: [Dillo-dev]Re:Reading gzipped files
+
+From: madis <madis@cy...> - 2002-07-15 14:35
+
+On Mon, 15 Jul 2002, Ken Hayber wrote:
+
+> My point was that I believe that when http servers like apache support 
+> gzip they do not change the filename, they just compress the data on the 
+> fly. I could be wrong too, but that's what I believe is the case. It is 
+> the content-coding attribute that tells the browser it is compressed, not 
+> the filename.
+> 
+> Maybe they're just two complementary ways to accomplish the same thing: 
+> ..gz for local files, content-coding for http-served files. Would it be 
+> hard to implement both?
+
+I looked for it now, seems that it requires modifing IO/http.c and cache.c 
+(at least). Implementing this way would be *the right thing* imho, but it 
+requires fully understanding how these two things talk with each other 
+(what i didn't bothered). Main problem is that a part of http traffic is 
+gzip'ed (body), but another part is not (header).
+
+--
+mzz 
+
+
+
+Re: [Dillo-dev]Re:Reading gzipped files
+
+From: Ken Hayber <khayber@so...> - 2002-07-15 13:53
+
+Well, if you're trying to add support to open .html.gz files like some 
+other apps (I've seen others like .ps.gz, ...?) can do then I think you're 
+fine.
+
+My point was that I believe that when http servers like apache support 
+gzip they do not change the filename, they just compress the data on the 
+fly. I could be wrong too, but that's what I believe is the case. It is 
+the content-coding attribute that tells the browser it is compressed, not 
+the filename.
+
+Maybe they're just two complementary ways to accomplish the same thing: 
+.gz for local files, content-coding for http-served files. Would it be 
+hard to implement both?
+
+On Sunday, July 14, 2002, at 11:22 PM, Vikas G P wrote:
+
+> On Friday, July 12, 2002, Ken Hayber wrote,
+>
+>> Not to be negative, but isn't the proper way to handle gzip in a browser
+>> to check the content-coding attribute and not the filename/ext?
+>
+> As I said, the patch only works for _local_ files, so we get it's type 
+> from it's extension, and if the ext is .gz,
+> it is stripped and the resulting name is examined again.
+>
+>> I thought
+>> the filename stays the same.
+>
+> Where does the filename change ?
+> Or am I getting this wrong ?
+>
+> Vikas G P
+>
+>
+>
+>
+> -------------------------------------------------------
+> This s...net email is sponsored by:ThinkGeek
+> Welcome to geek heaven.
+> http://thinkgeek.com/sf
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>
+>
+
+"Nothing is impossible for anyone impervious to reason."
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+Ken Hayber
+mailto:khayber@so...
+http://khayber.dyndns.org 
+
+
+
+[Dillo-dev]Re:Reading gzipped files
+
+From: Vikas G P <vikasgp386@ho...> - 2002-07-15 07:00
+
+On Friday, July 12, 2002, Ken Hayber wrote,
+
+> Not to be negative, but isn't the proper way to handle gzip in a browser 
+> to check the content-coding attribute and not the filename/ext? 
+
+As I said, the patch only works for _local_ files, so we get it's type from it's extension, and if the ext is .gz,
+it is stripped and the resulting name is examined again.
+
+> I thought 
+> the filename stays the same.
+
+Where does the filename change ?
+Or am I getting this wrong ?
+
+Vikas G P 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Tomas Guemes <tomas@pa...> - 2002-07-14 02:20
+
+On 13 Jul 2002 09:56:31 -0500
+"Lars Clausen" <lrclause@cs.uiuc.edu> wrote:
+
+> 
+> On Sat, 13 Jul 2002, Tomas Guemes wrote:
+> 
+> > I made a patch so dillo can support subdirectories in the bookmarks
+> > menu, cause otherwise if you have a lot of entries, part of the menu
+> > will be out of the screen and could not be reached with the actual
+> > flat bookmarks scheme. Also I have modified the python script
+> > xbel2html, to fit the format of the patch.
+> 
+> Ohhh! I wanted to see that! Thank you.
+> 
+> > You can find the patch and the script xbel2dbm in
+> > http://golem/tomas/dillo/
+> 
+> Uhm... golem? That must be a new top-level domain that I've never
+> heard of before:)
+> 
+
+Sorry, this is the internal name :)
+http://pasky.dhs.org/tomas/dillo/
+
+> -Lars
+> 
+> -- 
+> Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of
+> Numenor"I do not agree with a word that you say, but I 
+> |---------------------------- will defend to the death your right to
+> |say it." | Where are we going, and --Evelyn Beatrice Hall
+> |paraphrasing Voltaire | what's with the handbasket?
+> 
+> 
+> -------------------------------------------------------
+> This s...net email is sponsored by:ThinkGeek
+> Welcome to geek heaven.
+> http://thinkgeek.com/sf
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Lars Clausen <lrclause@cs...> - 2002-07-13 14:56
+
+On Sat, 13 Jul 2002, Tomas Guemes wrote:
+
+> I made a patch so dillo can support subdirectories in the bookmarks
+> menu, cause otherwise if you have a lot of entries, part of the menu
+> will be out of the screen and could not be reached with the actual flat
+> bookmarks scheme. Also I have modified the python script xbel2html, to
+> fit the format of the patch.
+
+Ohhh! I wanted to see that! Thank you.
+
+> You can find the patch and the script xbel2dbm in
+> http://golem/tomas/dillo/
+
+Uhm... golem? That must be a new top-level domain that I've never heard of
+before:)
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Tomas Guemes <tomas@pa...> - 2002-07-13 13:14
+
+On Thu, 11 Jul 2002 03:16:21 +0200 (MET DST)
+"Lawrence Mayer" <Lawrence.Mayer@ds...> wrote:
+
+> Hi,
+> 
+> I use Dillo, Links, Lynx, and Netscape. So far, all my bookmarks are
+> in Netscape, but I would love to be able to share my bookmarks between
+> these 4 browsers.
+
+> 2. Any utilities which CONVERT bookmarks back and forth between the
+> above browsers, or at least some of them?
+
+I found a way to convert through xbel. 
+
+Xbel is the XML format used by konqueror, there are some programs to
+convert xbel to other formats and viceversa, the debian packages are
+xbel and xbel-utils you can read more and find them in
+http://pyxml.so....net/topics/xbel/
+
+I made a patch so dillo can support subdirectories in the bookmarks
+menu, cause otherwise if you have a lot of entries, part of the menu
+will be out of the screen and could not be reached with the actual flat
+bookmarks scheme. Also I have modified the python script xbel2html, to
+fit the format of the patch.
+
+You can find the patch and the script xbel2dbm in
+http://golem/tomas/dillo/
+
+greetings
+
+Tomas 
+
+
+
+Re: [Dillo-dev][PATCH] reading gzipped files
+
+From: Ken Hayber <khayber@so...> - 2002-07-12 13:35
+
+Not to be negative, but isn't the proper way to handle gzip in a browser 
+to check the content-coding attribute and not the filename/ext? The rfc 
+says on-the-fly encoding/decoding between server and client. I thought 
+the filename stays the same.
+
+bug #156:
+Impact: feature fault
+At: run time
+Type: misbehaviour
+Comments: Dillo doesn't render gzipped html's. Sourceforge (once) put
+up a gzipped inde.html and all I got was binary :-(
+This is kind of new, but nice!
+HTReproduce: Just gzip a local .html. Try to look at it in Netscape and
+then in Dillo.
+
+
+On Friday, July 12, 2002, at 12:38 AM, Vikas G P wrote:
+
+> Hi everyone,
+>
+> Here's a small patch to make dillo read gzipped files[BUG #156]. It only 
+> works only on local files, since a .gz file on a server is
+> probably there for download. It sends the content-length as 0, which is 
+> ugly, but seems to work fine.
+>
+> Happy coding,
+> Vikas 
+
+
+
+[Dillo-dev][PATCH] reading gzipped files
+
+From: Vikas G P <vikasgp386@ho...> - 2002-07-12 07:33
+
+Hi everyone,
+
+Here's a small patch to make dillo read gzipped files[BUG #156]. It only works only on local files, since a .gz file on a server is
+probably there for download. It sends the content-length as 0, which is ugly, but seems to work fine.
+
+Happy coding,
+Vikas
+
+--------------------
+--- dillo-0.6.6/src/IO/file.c Wed Apr 10 06:29:42 2002
++++ dillo-0.6.6.patch/src/IO/file.c Thu Jul 11 18:08:23 2002
+@@ -29,6 +29,7 @@
+#include <stdio.h>
+#include <signal.h>
+#include <math.h> /* for rint */
++#include <zlib.h>
+
+#include <errno.h> /* for errno */
+#include "Url.h"
+@@ -80,7 +81,8 @@ static gint File_get_file(const gchar *F
+static gint File_get_dir(const gchar *DirName);
+static char *File_dir2html(DilloDir *Ddir);
+static void File_not_found_msg(DilloWeb *web, const char *filename, int fd);
+-
++static gint File_ext(const char *filename,const char *ext);
++static char *File_content_type_gz(const char *filename);
+
+/*
+* Allocate a DilloFile structure, and set working values in it.
+@@ -162,6 +164,7 @@ static void *File_transfer_file(void *da
+char buf[8192];
+DilloFile *Dfile = data;
+ssize_t nbytes;
++ gzFile gzipfile;
+
+/* Set this thread to detached state */
+pthread_detach(Dfile->th1);
+@@ -172,7 +175,8 @@ static void *File_transfer_file(void *da
+
+/* Send File Size info */
+if (Dfile->FileSize != -1) {
+- sprintf(buf, "Content-length: %ld\n", Dfile->FileSize);
++ sprintf(buf, "Content-length: %ld\n",
++ File_ext(Dfile->Filename,"gz") ? 0l : Dfile->FileSize );
+write(Dfile->FD_Write, buf, strlen(buf));
+}
+/* Send end-of-header */
+@@ -181,8 +185,23 @@ static void *File_transfer_file(void *da
+
+
+/* Append raw file contents */
+- while ( (nbytes = read(Dfile->FD, buf, 8192)) != 0 ) {
+- write(Dfile->FD_Write, buf, nbytes);
++
++ /* gzipped */
++ if( File_ext(Dfile->Filename,"gz")){
++ if( (gzipfile = gzdopen(Dfile->FD,"rb")) ){;
++ while( (nbytes = gzread(gzipfile, buf, 8192)) != 0){
++ write(Dfile->FD_Write, buf, nbytes);
++ }
++ }
++ else{
++ g_print("Error: Could not decompress gzipped file\n");
++ }
++ }
++ /* not gzipped */
++ else{
++ while ( (nbytes = read(Dfile->FD, buf, 8192)) != 0 ) {
++ write(Dfile->FD_Write, buf, nbytes);
++ }
+}
+
+close(Dfile->FD);
+@@ -258,8 +277,21 @@ static char *File_content_type(const cha
+} else if (File_ext(filename, "html") || File_ext(filename, "htm") ||
+File_ext(filename, "shtml")) {
+return "text/html";
++ } else if(File_ext(filename, "gz")){
++ return File_content_type_gz(filename);
+}
+return "text/plain";
++}
++
++/*
++ * Return content_type of the uncompressed file
++ */
++static char *File_content_type_gz(const char *filename)
++{
++ gchar *original_name = g_strndup(filename,rindex(filename,(int)'.')-filename);
++ gchar *content_type = File_content_type(original_name);
++ g_free(original_name);
++ return content_type;
+}
+
+/* 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Paul Chamberlain <tif@ti...> - 2002-07-11 18:17
+
+Ross J. Reedstrom wrote:
+> Well, for dillo and netscape, you can just put a symlink in one or the other's
+> dot directory to the others bookmarks.html file. I just tested this by
+> symlinking ~/.diullorc/bookmarks.html to ~/.mozilla/default/bookmarks.html
+
+I think you set my expectations too high. I have a LOT of
+bookmarks in mozilla. I'm not sure which one caused it,
+but when dillo tried to load, it said:
+
+Loading bookmarks...
+
+GLib-ERROR **: could not allocate -75 bytes
+aborting...
+Aborted (core dumped)
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Pat Shanahan <pat@em...> - 2002-07-11 11:34
+
+* Ross J. Reedstrom <reedstrm@ri...> [07-11-02 05:05]:
+> On Thu, Jul 11, 2002 at 03:16:21AM +0200, Lawrence Mayer wrote:
+> > Hi,
+> > 
+> > I use Dillo, Links, Lynx, and Netscape. So far, all my bookmarks are in
+> > Netscape, but I would love to be able to share my bookmarks between these
+> > 4 browsers.
+> 
+> Well, for dillo and netscape, you can just put a symlink in one or the other's
+> dot directory to the others bookmarks.html file. I just tested this by
+> symlinking ~/.diullorc/bookmarks.html to ~/.mozilla/default/bookmarks.html
+> 
+> It worked fine: the 'View bookmarks" function in dillo handled the page just
+> fine. with sections and everything.
+
+You may also make bookmarks in netscape/dillo for each, ie:
+file:///home/yurName/.dillo/bookmarks.html in Netacape &
+file:///home/yurName/.mozilla/default/bookmarks.html in Dillo
+
+-- 
+Patrick Shanahan
+Registered Linux User #207535 
+@ http://counter.li.org 
+
+
+
+Re: [Dillo-dev]Netscape bookmarks conversion?
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-07-11 05:49
+
+On Thu, Jul 11, 2002 at 03:16:21AM +0200, Lawrence Mayer wrote:
+> Hi,
+> 
+> I use Dillo, Links, Lynx, and Netscape. So far, all my bookmarks are in
+> Netscape, but I would love to be able to share my bookmarks between these
+> 4 browsers.
+
+Well, for dillo and netscape, you can just put a symlink in one or the other's
+dot directory to the others bookmarks.html file. I just tested this by
+symlinking ~/.diullorc/bookmarks.html to ~/.mozilla/default/bookmarks.html
+
+It worked fine: the 'View bookmarks" function in dillo handled the page just
+fine. with sections and everything.
+
+Ross 
+
+
+
+[Dillo-dev]Netscape bookmarks conversion?
+
+From: Lawrence Mayer <Lawrence.Mayer@ds...> - 2002-07-11 01:16
+
+Hi,
+
+I use Dillo, Links, Lynx, and Netscape. So far, all my bookmarks are in
+Netscape, but I would love to be able to share my bookmarks between these
+4 browsers.
+
+Can anyone offer any advice?
+
+1. Will Netscape's bookmark import do me any good here?
+
+2. Any utilities which CONVERT bookmarks back and forth between the above
+browsers, or at least some of them?
+
+3. Any utilities which SYNCHRONIZE bookmarks between the above browsers,
+or at least some of them?
+
+
+I would be thankful for your advice or tips.
+
+Friendly Greetings,
+Lawrence Mayer <lawmay@ki.se>
+Ume=E5, Sweden 
+
+
+
+Re: [Dillo-dev]Cookies don't work
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-07-10 13:49
+
+> Allo,
+
+Hi,
+=20
+> I compiled dillo-0.6.6, passing the parameter --enable-cookies, and got n=
+o
+> errors; made sure my ~/.dillo/cookiesrc says:
+> DEFAULT ACCEPT
+>=20
+> yet cookies don't appear to work. ~/.dillo/cookies remains empty (0 byte=
+)
+> and web pages I visit don't retain my login information. Tested against
+> http://www.livejournal.com, http://www.w30wnzj00.com, http://www.slashdot.org. =20
+
+Slashdot works for me.=20
+http://www.w30wnzj00.com seems to send a malformed expiry date and gets
+ignored.=20
+Unfortunately, I can't test livejournal ATM.
+
+> Please advise; is there anything I did wrong, or any logfiles I should be=
+looking at?
+> Thanks.
+
+You could change the line (in cookies.c) which says:
+#define DEBUG_LEVEL 8
+to:
+#define DEBUG_LEVEL 1
+
+Then it would tell you pretty much everything it does. A good starting
+point would be to check if the date strings are parsed correctly.
+
+>=20
+> matthew@de...
+>=20
+
+Cheers,
+J=F6rgen 
+
+
+
+[Dillo-dev]Cookies don't work
+
+From: matthew <matthew@de...> - 2002-07-10 12:59
+
+Allo,
+
+I compiled dillo-0.6.6, passing the parameter --enable-cookies, and got no
+errors; made sure my ~/.dillo/cookiesrc says:
+DEFAULT ACCEPT
+
+yet cookies don't appear to work. ~/.dillo/cookies remains empty (0 byte)
+and web pages I visit don't retain my login information. Tested against
+http://www.livejournal.com, http://www.w30wnzj00.com, http://www.slashdot.org. Please advise;
+is there anything I did wrong, or any logfiles I should be looking at?
+Thanks.
+
+
+matthew@de... 
+
+
+
+[Dillo-dev]dillo user notes
+
+From: Abc Xyz <abc@an...> - 2002-07-10 10:35
+
+fbsd 4.5 dillo .66
+
+i didn't use this more than a few minutes, but this is what
+i was missing severely enough to stop ...
+
+no keyboard navigation (esp backward foreward - Left/Right arrows).
+(i hate having to reach for my mouse needlessly).
+animated gifs apparently broken.
+reload HTML meta tags don't work.
+missing backwards/forewards in right-click mouse menu.
+
+minor stuff ...
+
+would be nice if "view source" opened to the same size as parent window.
+i dunno if it does YahooMail and Hotmail, but that would be nice.
+hopefully it uses ~/.mailcap ...
+hopefully it allows https? for online ordering?
+HTML warning: hexadecimal color lacks leading '#' - oh pooh.
+WARNING: Cache_stop_client, inexistent client - lots of these.
+
+wish list:
+
+UP-ARW - up one link (or half/most of a page if no link).
+DN-ARW - same, but downwards (like lynx - invert link colors).
+
+ALT-UP-ARW - smooth scrolling up.
+ALT-DN-ARW - smooth scrolling down.
+ALT-LT-ARW - smooth scrolling left.
+ALT-RT-ARW - smooth scrolling right.
+
+i guess i would like to see that the user interface is
+as snappy and hassle free as the browser :)
+
+but all in all, this browser is small and snappy,
+and renders *extremely* nicely. i can't wait till
+i can use it and toss my 14MB Navigator!
+with 40MB of Linux emulation :) 
+
+
+
+Re: [Dillo-dev]ecmascript, javascript and CSS
+
+From: Freya <Freya@he...> - 2002-07-09 11:31
+
+> > Is there an intention to implement these scripts?
+> 
+> Both JavaScript and Java would greatly increase the size of Dillo and
+
+Incidently, I've never felt the need to have java, I've never come
+across any site that really required it that much on the client side
+beyone a spectrum emulator and some really clever audio/video
+technology. I think most Java is done through servlets and the like, I
+do hope so anyway! :)
+
+> require numerous hooks into the existing code to obtain the
+> functionallity seen in other browsers. For example, in DHTML, you
+> perform special effects by tagging various events with a fragment of
+> JavaScript so, for example, when the mouse moves over a specific area
+> of the screen a button lights up or additional text appears. This has
+> some deep implications about the way that Dillo paints the window
+> images.
+
+I've been wondering about this, Mozilla of course has preety good
+javascript support and the thing is, is that it uses some kind of plugin
+architechture for the scripting, so I was wondering if we could just
+provide support for the plugin architexture and just use their scripting
+engine, or whatever scripting engines are available, or even no
+scripting engine.
+
+The trouble I have with this idea, is that all this talk of Mozilla just
+having a javascript plugin, is I suspect a real oversimplification of
+things. It surely must talk directly to the rendering engine at a really
+low and nasty level. Whats worse, is I don't even think it's as simple
+as having implications in the way that dillo paints the window images,
+as I understand it you would have to implement some kind of object model
+in the rendering engine too? This seems to me like a massive task unless
+the object model is implemented in the js engine which I strongly
+suspect it isn't, it's too specific to rendering and I think their
+javascript engine is also used in the netscape webserver, or at least
+used to be.
+
+Personally I can also live without things like DHTML support. I'd really
+just like support something like that of Netscape 3, enough to let me
+log in to yahoo mail and the like, however the more I think about it the
+more nasty it seems. 
+
+
+> > how about flash?
+
+I've often thought it would be nice to just have a flash browser
+seperately from my webbrowser that could just open flash site if I felt
+the need or show animations, I don't see much point in it being part of
+the browser and I generally hate flash as it's mostly just used for
+really annoying adverts.
+
+> If anyone has some spare time, one project that would usefully
+> demonstrate the kind of changes that would be needed in the Dillo
+> image code is implementing GIF and PNG animations. You would need
+> some kind of regular"update animation" event and some state
+> information associated with animation files. A thread[1] per animated
+> image using some kind of "server push" scheme may work; or more
+> crudely, you could get the cache to manage it all and set up some kind
+> of list of "repaint screen area x,y,w,h" events.
+
+IF anyone does implement this please also implement an option to turn it
+off! I think this is kind of low priority myself as it doesn't affect
+the usability of a website much. 
+CSS was mentioned in the subject line, but no-one has really talked
+about it here. Of all the technologies unimplimented, this is in a way
+the nicest, as it's not actually fudamentally bad technology in the way
+that javascript or flash is. From the point of view of dillo
+implementing good technology really well, my vote would be for css but
+of course, thats just looking at creating a good browser based on nice
+technology as opposed to the real world of websites. :(
+
+love
+
+Freya 
+
+
+
+Re: [Dillo-dev]ecmascript, javascript and CSS
+
+From: Geoff Lane <zzassgl@tw...> - 2002-07-09 07:59
+
+> Is there an intention to implement these scripts?
+
+Both JavaScript and Java would greatly increase the size of Dillo and
+require numerous hooks into the existing code to obtain the functionallity
+seen in other browsers. For example, in DHTML, you perform special effects
+by tagging various events with a fragment of JavaScript so, for example,
+when the mouse moves over a specific area of the screen a button lights up
+or additional text appears. This has some deep implications about the way
+that Dillo paints the window images.
+
+> how about flash?
+
+The flash "interpreter" is quite small and for simple images you could run
+it as an external helper (I have actually thought about doing this) but you
+wouldn't get any of the interactive or animation features. Again, proper
+implementation of flash would require some extensive changes in the way
+Dillo paints the window images.
+
+If anyone has some spare time, one project that would usefully demonstrate
+the kind of changes that would be needed in the Dillo image code is
+implementing GIF and PNG animations. You would need some kind of regular
+"update animation" event and some state information associated with
+animation files. A thread[1] per animated image using some kind of "server
+push" scheme may work; or more crudely, you could get the cache to manage it
+all and set up some kind of list of "repaint screen area x,y,w,h" events.
+
+BTW, for those of you waiting for the external helper code - sorry, Real
+World events have delayed any progress recently. Work is continuing, just
+very, very slowly.
+
+[1] True threads acting as "data generators" is a very powerful design idea
+for browsers and can hugely simplify the code in some cases.
+
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+Syntax is another name for conscience money. 
+
+
+
+Re: [Dillo-dev]ecmascript, javascript and CSS
+
+From: Scott Barnes <reeve@du...> - 2002-07-08 19:45
+
+Attachments: Message as HTML      Message as HTML      
+
+
+
+
+
+[Dillo-dev]ecmascript, javascript and CSS
+
+From: jonathan chetwynd <j.chetwynd@bt...> - 2002-07-08 16:26
+
+Is there an intention to implement these scripts?
+how about flash?
+
+thanks
+
+jonathan 
+
+
+
+[Dillo-dev]A quick Thankyou
+
+From: Freya <Freya@he...> - 2002-07-08 14:26
+
+Madis sent me a binary of the latest CVS with some extra stuff patched.
+Thankyou Madis!
+
+I'm rather taken aback at how much faster and stable it is than my old
+copy. So far it's never crashed at all and I'm able to use a lot more
+websites etc now that I have cookies! I'm not sure where the speed
+increase is coming from. Madis stripped it before sending it to me but
+I've been led to believe that this shouldn't make a lot of difference.
+Perhaps it does when you only have 8mb!
+
+Anyway thankyou to you all for your help which makes my nasty old laptop
+almost as usable as the Duron downstairs.
+
+love
+
+Freya 
+
+
+
+Re: [Dillo-dev]valign="middle"
+
+From: Freya <Freya@he...> - 2002-07-06 17:24
+
+A bit of further investigation shows this is definitely a dillo thing.
+Hard breaks also don't seem to render in dillo.
+
+I booted a computer using konoppix, (a version of linux that runs
+directly off a cd-rom with a read only live file system) and tried a
+number of webbrowsers that it comes with. I also tried some pages in IE
+under windows.
+
+The results were kind of interesting. All of them seem to render valign
+properly. My page seemed to render best in Mozzilla. Konquerer a close
+second, but what shocked me was how ghastly everything looked in IE, and
+I'm not just talking about my page but a lot of sites I looked at.
+Interestingly, dillo seems to my eye to make webpages look the nicest.
+The valign bug even makes one page I use look much better! ;)
+
+I guess theres still a few problems in the dillo rendering engine. It
+tends to render pages so well usually that I always just kind of assume
+that part of dillo is perfect! :)
+
+love
+
+Freya
+
+
+> I'm writing a webpage and I'm trying to centere the text vertically in
+> a cell of a table. I'm using valign="middle" in a td element but it
+> seems to have absolutely no effect. Is this supported in dillo or is
+> there something very wierd about my webpage?
+> 
+> I don't presently have the latest dillo, so it might be related to
+> that? I'm currently running 0.62, if anyone has a more recent compiled
+> binary they could e-mail me that would be great as I don't presently
+> have a working compiler. :(
+> 
+> love
+> 
+> Freya
+> 
+> 
+> -------------------------------------------------------
+> This s...net email is sponsored by:ThinkGeek
+> Got root? We do.
+> http://thinkgeek.com/sf
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]valign="middle"
+
+From: Freya <Freya@he...> - 2002-07-06 10:05
+
+I'm writing a webpage and I'm trying to centere the text vertically in a
+cell of a table. I'm using valign="middle" in a td element but it seems
+to have absolutely no effect. Is this supported in dillo or is there
+something very wierd about my webpage?
+
+I don't presently have the latest dillo, so it might be related to that?
+I'm currently running 0.62, if anyone has a more recent compiled binary
+they could e-mail me that would be great as I don't presently have a
+working compiler. :(
+
+love
+
+Freya 
+
+
+
+Re: [Dillo-dev]Dillo scaling hack
+
+From: Pigeon <pigeon@pi...> - 2002-07-03 13:34
+
+> No ARM binaries to test, I'm afraid. Do you have a cross-compile setup
+> working for dillo? I'd love to know how you set it up.
+
+I have both cross compiling and native compiling environment setup. For cross compiling I basically use the one found on handhelds.org, the skiff one.
+
+
+Pigeon. 
+
+
+
+[Dillo-dev]ematic is down again :(
+
+From: Jorge Arellano Cid <jcid@in...> - 2002-07-02 18:34
+
+Hi there,
+
+Once again, when at crossroads, the ematic server goes down (I'll
+begin to think about a correlation there ;).
+
+Well, just send me email to [jcid at inf.utfsm.cl]
+
+
+Cheers
+Jorge.-
+
+
+-- 
+
diff --git a/old/oldmail/200208.txt b/old/oldmail/200208.txt
new file mode 100644
index 0000000..90d3fbf
--- /dev/null
+++ b/old/oldmail/200208.txt
@@ -0,0 +1,1858 @@
+[Dillo-dev]End of ematic account.
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-08-30 20:32
+
+**** Important ****
+
+Hi there!
+
+
+Ematic did it again, but this will be the last time!
+
+I switched my email address, so please update your bookmarks.
+
+
+Thanks
+Jorge.-
+
+
+PD: Don't ask where! 
+
+
+
+[Dillo-dev]Tuxscreen: No Images
+
+From: Brad Colbert <brad@rn...> - 2002-08-30 05:19
+
+Hi folks,
+
+I finally got dillo to compile and run on a Tuxscreen phone but it won't
+seem to render images. I compiled it against both, jpeglib and pnglib
+but it doesn't seem to matter.
+
+Has anyone else had a similar problem? If so, did you fix it? If so
+how?
+
+Thanks,
+Brad 
+
+
+
+Re: [Dillo-dev]Dpi progress
+
+From: Jamin W. Collins <jcollins@as...> - 2002-08-27 18:34
+
+On Tue, 27 Aug 2002 14:09:37 -0400 (CLT)
+Jorge Arellano Cid <jcid@em...> wrote:
+
+> -----------
+> The Problem
+> -----------
+> 
+> My Thinkpad laptop decided to go dark,
+> and as I keep all of my dillo project stuff in it,
+> it's a serious problem.
+> 
+> 
+> The LCD is hard to read, maybe showing 50% of the brightness it
+> should. May it be the inverter? I don't know.
+> 
+> Just in case there's someone knowledgeable here, any help would
+> be highly appreciated.
+
+Perhaps a bit of over simplication, but how about pulling the data off
+said laptop and putting it into a CVS server or other storage location. I
+(and I'm sure others) can offer storage and replication of the data. 
+
+Doesn't help much with the laptop, but it does preserve the data.
+
+-- 
+Jamin W. Collins 
+
+
+
+[Dillo-dev]Hyperlinks as images
+
+From: <jbradford@di...> - 2002-08-27 18:15
+
+Hi everyone,
+
+I thought of this idea a while ago, but I'm not sure how useful/practical it would be in practice, but at least it is an original, (as far as I know) and interesting idea:
+
+How about an option to render all hyperlinks as small, (e.g. 128x128), thumbnails of the page they link to? Ignoring the fact that it would be wasteful of bandwidth, (fetching the html and inline images of all the linked pages), I can think of at least one instance where it would be very useful - locating a site that you found by following 20 links from one page to another, and then didn't bother to bookmark, but wished you had. Everybody has done it from time to time, you can 'see' the page in your head, but none or your searches turns it up. Now, if you could quickly glance down a load of thumbails of search results, wouldn't that help?
+
+Even if this isn't deemed a workable idea, at least I can use this post as prior art when somebody patents the idea, (which they are bound to try to do eventually) :-).
+
+John. 
+
+
+
+Re: [Dillo-dev]Downloads & hacking
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-08-27 18:14
+
+Matthieu,
+
+On 24 Aug 2002, Matthieu Sozeau wrote:
+
+> Hello dillo devs,
+>
+> this is my first post to this list so first I thank you for this
+> lightning-fast browser.
+
+Thanks, and welcome aboard.
+
+> I hacked up a download manager as I see no
+> volunteer had come to it until now. I made it similar to the Opera's
+> transfer manager, in a separate window, which can be hidden at
+> will. Just to name a few problems, there is no progress bar, first
+> because GtkCList do not support widget cell's in gtk-1.2 and second,
+> because the CacheClient_t struct has not the total length in it. As
+> this cache client is not attached to a browser window, it segfaults
+> when cache wants to remove its clients. There are "beware of
+> downloads, transitory code" messages around this functions, so I
+> hope we can find a nice solution.
+
+Well, the latest idea is to implement downloads with the new
+dpi framework (one minor glitch is that I haven't finished coding
+it yet! :).
+
+The point is to write an external program (dpi server) that
+handles download requests.
+
+Here's what you can do while I work on the dpi framework (my
+next post will be on my progress):
+
+Write a server that listens on a certain port for commands
+(don't care about cmd. syntax now). If it can queue the commands,
+and service them from there, that's enough.
+
+That is:
+
+--------------
+<some cmd> -----> | Dpi server |
+--------------
+|
+<answer> <-------------'
+
+
+Note: <answer may be void if an action is taken>
+
+
+So far you have a "get this URL" command and started
+downloading it to some local directory. If you keep the time it
+started, the downloaded bytes and the total size, some stats can
+be given back when required.
+
+For instance:
+
+--------------
+<stats please> -----> | Dpi server |
+--------------
+|
+<html answer> <-------------'
+
+
+A simple HTML page can do the trick:
+
+>>
+
+<h1>Downloads</h1>
+<table bgcolor='white' width='70%' border='1'>
+<tr>
+<td> file1.tgz </td>
+<td> 63000/100000 </td>
+<td> 63% </td>
+<td width='100%'> <table width='100%' cellpadding='8' cellspacing='1'>
+<tr><td bgcolor='blue' width='63%'></td>
+<td bgcolor='gray' width='37%'></td></tr>
+</table> </td>
+</tr>
+</table>
+
+>>
+
+That solves the status bar issue!
+
+There are some good advantages for this scheme.
+
+You may like to read my previous posts about the new dpi, and
+certainly the one I'm about to write :).
+
+Ok, if you code it as sketched above, you'd end up with a
+server that can listen to commands while it downloads, and
+consequently answer some statistics about what's going on.
+
+The details should become clear when I release the first
+version of a dpi-program, that is: bookmarks.
+
+>
+> Anyway, I'm really willing to help this project grow rapidly, and
+> there are things I'd like to do when i understand it more, like
+> tabs, XML-ability or gestures. For now I just wait for your
+> comments/advices/flame and walks around the bug database :)
+>
+>
+> my diff is at http://mattam.ath.cx/progs/dillo/dl.diff.gz
+
+I read your diff, and hope this lines get you started.
+
+Tabs?
+
+I already have a patch for tabs, it may eventually get in, but
+as dpi is the bottleneck and first concern, I'm 99% on it.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Dpi progress
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-08-27 18:14
+
+Hi there!
+
+After some hard work on the required CCCs for the dpi, it all
+seemed to work smoothly, but after adding some random delays to
+fake asynchronous behaviour, it became clear that there were race
+conditions, and some events were not being generated.
+
+A deep analysis showed that forcing the events somehow could
+fix the problems, but I couldn't find a witty (and simple and
+portable) way to do the trick. Then, there was a stance for
+generating the events as glib does (very dangerous), and also of
+forcing the actions those events trigger, but frankly, that is
+asking for trouble because code maintenance becomes a nightmare
+from then.
+
+Hmmm, there was also the possibility of using threads; that way
+the events are generated automatically, but it also involved all
+the inherent complexity of threads.
+
+Tough decision.
+
+...
+
+
+After some more thoughts I decided to try the threaded stuff.
+
+Quite complex, if you ask me: threads always look simpler than
+they really are.
+
+Well, now I have a fancy thread (with mutex, conditions and
+local tricks), that does the job OK.
+
+Now, I need to test it on the querying branch (currently it
+sends the built-up HTML from DPI to the ordinary IO-Cache
+answer branch).
+
+Up to this point, it works.
+
+After setting it on the querying branch, it would be a matter
+of designing the appropriate CCCs for error control and message
+passing. From then, some improving of the bookmarks dpi-program,
+writing some docs and it could go to the CVS.
+
+
+
+-----------
+The Problem
+-----------
+
+My Thinkpad laptop decided to go dark,
+and as I keep all of my dillo project stuff in it,
+it's a serious problem.
+
+
+The LCD is hard to read, maybe showing 50% of the brightness it
+should. May it be the inverter? I don't know.
+
+Just in case there's someone knowledgeable here, any help would
+be highly appreciated.
+
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev][patch] Bug 220 - saving entered datas in forms
+
+From: Jamin W. Collins <jcollins@as...> - 2002-08-27 13:42
+
+On Tue, 27 Aug 2002 20:25:41 +0700
+"Nikita V. Borodikhin" <eliterr@tk...> wrote:
+
+> Question: Should we save values when user just filled controls
+> and pushes the back button whithout submitting ?
+
+IMO, yes.
+
+-- 
+Jamin W. Collins 
+
+
+
+Re: [Dillo-dev][patch] Bug 220 - saving entered datas in forms
+
+From: <jbradford@di...> - 2002-08-27 13:40
+
+Hi,
+
+> I made a patch that fixes bug 220.
+
+Thanks, that was one that irritated me quite a lot :-)
+
+> P.S.
+> Question: Should we save values when user just filled controls
+> and pushes the back button whithout submitting ?
+
+Best make it a configure option
+
+On a related note, could we make it so that middle clicking a form submit button opens the link in a new window? Amaya does this, and I liked it a lot.
+
+John. 
+
+
+
+[Dillo-dev][patch] Bug 220 - saving entered datas in forms
+
+From: Nikita V. Borodikhin <eliterr@tk...> - 2002-08-27 13:31
+
+Hello all Dillo developers !
+
+I made a patch that fixes bug 220.
+
+This is a description of how it shold work:
+-------------------------------------------------------------
+When user submits any form from page to server current values
+of all changable input elements in all forms are saved
+in array in browser window's history.
+
+If user shows this page again using backward/forward controls
+then input elements are filled with their last values again.
+
+Restoring of course if not performed when page is reloaded or
+the same URL is opened in other dillo's window or even when it
+is opened in the same window but in other position in history.
+--------------------------------------------------------------
+
+I tested this patch and found it works as I mean so enjoy.
+...and catch possible bugs
+
+Patch against current CVS tree:
+http://www.tkk.ru/~eliterr/dillo/dillo-saving-values.diff
+
+P.S.
+Question: Should we save values when user just filled controls
+and pushes the back button whithout submitting ?
+
+Nikita V. Borodikhin 
+
+
+
+[Dillo-dev]Downloads & hacking
+
+From: Matthieu Sozeau <mattam@ne...> - 2002-08-24 02:51
+
+Hello dillo devs,
+
+this is my first post to this list so first I thank you for this
+lightning-fast browser. I hacked up a download manager as I see no
+volunteer had come to it until now. I made it similar to the Opera's
+transfer manager, in a separate window, which can be hidden at
+will. Just to name a few problems, there is no progress bar, first 
+because GtkCList do not support widget cell's in gtk-1.2 and second,
+because the CacheClient_t struct has not the total length in it. As
+this cache client is not attached to a browser window, it segfaults
+when cache wants to remove its clients. There are "beware of
+downloads, transitory code" messages around this functions, so I
+hope we can find a nice solution.
+
+Anyway, I'm really willing to help this project grow rapidly, and
+there are things I'd like to do when i understand it more, like
+tabs, XML-ability or gestures. For now I just wait for your
+comments/advices/flame and walks around the bug database :)
+
+
+my diff is at http://mattam.ath.cx/progs/dillo/dl.diff.gz
+
+-- 
+"There are two ways of constructing a software design; one way is to
+make it so simple that there are obviously no deficiencies, and the
+other way is to make it so complicated that there are no obvious
+deficiencies. The first method is far more difficult."
+- C. A. R. Hoare 
+
+
+
+Re: [Dillo-dev]CVS
+
+From: Jamin W. Collins <jcollins@as...> - 2002-08-23 22:12
+
+On Fri, 23 Aug 2002 23:02:04 +0100
+jbradford@di... wrote:
+
+> I've been happily using Dillo for a couple of months, and I thought the
+> project had died - looking at CVS nothing has changed since about 1982 -
+> but now I've found everybody lurking on this mailing list :-)
+
+Not sure which CVS server you're looking at. Take a look here:
+
+http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/dillo/
+
+> So, basically, I was just wondering if there was a reason for not
+> updating the CVS tree, (apart from lack of time), because I don't really
+> feel like going through a couple of months of mailing list archive just
+> to pick out all the patches :-).
+
+You seem to be little out of touch with the current status. The project
+is now hosted here:
+
+http://dillo.cipsga.org.br/
+
+HTH
+
+-- 
+Jamin W. Collins 
+
+
+
+[Dillo-dev]CVS
+
+From: <jbradford@di...> - 2002-08-23 21:54
+
+Hi,
+
+I've been happily using Dillo for a couple of months, and I thought the project had died - looking at CVS nothing has changed since about 1982 - but now I've found everybody lurking on this mailing list :-)
+
+So, basically, I was just wondering if there was a reason for not updating the CVS tree, (apart from lack of time), because I don't really feel like going through a couple of months of mailing list archive just to pick out all the patches :-).
+
+Does the CVS tree need a maintainer or something? Can I help?
+
+Anyway, good work on Dillo, I've noticed a few unusual, and not-frequently-reproduced bugs, but they may well have been attended to since the begining of June, so I'll wait until I'm up to date with the lastest 'pre-patches' to comment :-).
+
+John. 
+
+
+
+Re: [Dillo-dev]Getting Dillo to work on arm7
+
+From: Philip Blundell <pb@ne...> - 2002-08-19 07:38
+
+On Sun, 2002-08-18 at 07:06, Alan DuBoff wrote:
+> Has anyone compiled Dillo and have it running on an arm7 cpu? I think one of 
+> the psions might have that chip, can't remember.
+
+The binary from Debian should work on an EP7312. You will indeed need
+an X server; TinyX is probably your best bet, but "big X" with the fbdev
+driver would be OK also.
+
+p. 
+
+
+
+[Dillo-dev]Getting Dillo to work on arm7
+
+From: Alan DuBoff <aland@So...> - 2002-08-18 06:09
+
+I'm trying to get Dillo running on a Cirrus Logic EP7312, which has an arm7 
+chip in it.
+
+I have downloaded the latest source 0.6.6 and grabbed the gtk+-1.2.10 and 
+glib-1.2.10 sources as well.
+
+I think I'll need some flavor of X, and I wasn't sure if I can do that with 
+MicroWindows/Nano-X, or if I'll need some other X server.
+
+I wasn't able to find a list of dependancies, but I'm sure it's somewhere.
+
+Has anyone compiled Dillo and have it running on an arm7 cpu? I think one of 
+the psions might have that chip, can't remember.
+
+-- 
+
+Alan DuBoff
+Software Orchestration, Inc.
+GPG: 1024D/B7A9EBEE 5E00 57CD 5336 5E0B 288B 4126 0D49 0D99 B7A9 EBEE 
+
+
+
+[Dillo-dev]anchor support for navigation (back/forward) [PATCH]
+
+From: Frank Gevaerts <frank@ge...> - 2002-08-16 18:58
+
+Hi,
+
+I needed a small fast browser for some html we have produced. I needed
+navigation within the html file, which dillo does not provide as of
+v0.66. So I had a look and came up with the following patch. Can you
+advise me on whether this is the right way to do it ? It seems to work
+here.
+
+Frank
+
+
+diff -ur dillo-0.6.6/src/history.c dillo-0.6.6.fg/src/history.c
+--- dillo-0.6.6/src/history.c 2002-04-10 02:53:58.000000000 +0200
++++ dillo-0.6.6.fg/src/history.c 2002-08-16 17:58:55.000000000 +0200
+@@ -38,7 +38,7 @@
+gint i, idx;
+
+for (i = 0; i < history_size; ++i)
+- if (a_Url_cmp(history[i].url, url) == 0)
++ if (a_Url_cmp(history[i].url, url) == 0 && URL_STRCAMP_EQ(history[i].url->fragment,url->fragment))
+return i;
+
+idx = history_size;
+diff -ur dillo-0.6.6/src/nav.c dillo-0.6.6.fg/src/nav.c
+--- dillo-0.6.6/src/nav.c 2002-04-10 03:10:16.000000000 +0200
++++ dillo-0.6.6.fg/src/nav.c 2002-08-16 20:34:52.000000000 +0200
+@@ -176,7 +176,7 @@
+MustLoad = ForceReload || !old_url;
+if (old_url){
+MustLoad |= a_Url_cmp(old_url, url);
+- MustLoad |= strcmp(URL_STR(old_url), a_Interface_get_location_text(bw));
++ MustLoad |= strcmp(URL_STR_NOANCHOR(old_url), a_Interface_get_location_text(bw));
+}
+
+if ( MustLoad ) {
+@@ -195,9 +195,19 @@
+a_Interface_set_cursor(bw, GDK_LEFT_PTR);
+}
+
+- /* Jump to #anchor position */
++ /* Push on stack and jump to #anchor position */
+if (URL_FRAGMENT_(url)) {
+- /* todo: push on stack */
++ gint idx;
++ DilloUrl *hist_url=a_Url_dup(url);
++
++ /* unset E2EReload before adding this url to history */
++ a_Url_set_flags(hist_url, URL_FLAGS(hist_url) & ~URL_E2EReload);
++ idx = a_History_add_url(hist_url);
++ Nav_stack_add(bw, idx);
++ Nav_stack_clean(bw);
++ a_Interface_set_button_sens(bw);
++ a_Url_free(hist_url);
++
+a_Dw_gtk_scrolled_window_set_anchor(
+GTK_DW_SCROLLED_WINDOW(bw->docwin), URL_FRAGMENT_(url));
+}
+diff -ur dillo-0.6.6/src/url.c dillo-0.6.6.fg/src/url.c
+--- dillo-0.6.6/src/url.c 2002-04-10 03:10:28.000000000 +0200
++++ dillo-0.6.6.fg/src/url.c 2002-08-16 20:20:59.000000000 +0200
+@@ -56,19 +56,47 @@
+
+if (!url->url_string) {
+url->url_string = g_string_sized_new(60);
+- g_string_sprintf(
+- url->url_string, "%s%s%s%s%s%s%s%s%s%s",
+- url->scheme ? url->scheme : "",
+- url->scheme ? ":" : "",
+- url->authority ? "//" : "",
+- url->authority ? url->authority : "",
+- (url->path && url->path[0] != '/' && url->authority) ? "/" : "",
+- url->path ? url->path : "",
+- url->query ? "?" : "",
+- url->query ? url->query : "",
+- url->fragment ? "#" : "",
+- url->fragment ? url->fragment : "");
+}
++ g_string_sprintf(
++ url->url_string, "%s%s%s%s%s%s%s%s%s%s",
++ url->scheme ? url->scheme : "",
++ url->scheme ? ":" : "",
++ url->authority ? "//" : "",
++ url->authority ? url->authority : "",
++ (url->path && url->path[0] != '/' && url->authority) ? "/" : "",
++ url->path ? url->path : "",
++ url->query ? "?" : "",
++ url->query ? url->query : "",
++ url->fragment ? "#" : "",
++ url->fragment ? url->fragment : "");
++
++ return url->url_string->str;
++}
++
++/*
++ * Return the url as a string, without the anchor part.
++ * (initializing 'url_string' camp if necessary)
++ */
++gchar *a_Url_str_noanchor(const DilloUrl *u)
++{
++ /* Internal url handling IS transparent to the caller */
++ DilloUrl *url = (DilloUrl *) u;
++
++ g_return_val_if_fail (url != NULL, NULL);
++
++ if (!url->url_string) {
++ url->url_string = g_string_sized_new(60);
++ }
++ g_string_sprintf(
++ url->url_string, "%s%s%s%s%s%s%s%s",
++ url->scheme ? url->scheme : "",
++ url->scheme ? ":" : "",
++ url->authority ? "//" : "",
++ url->authority ? url->authority : "",
++ (url->path && url->path[0] != '/' && url->authority) ? "/" : "",
++ url->path ? url->path : "",
++ url->query ? "?" : "",
++ url->query ? url->query : "");
+
+return url->url_string->str;
+}
+diff -ur dillo-0.6.6/src/url.h dillo-0.6.6.fg/src/url.h
+--- dillo-0.6.6/src/url.h 2002-04-10 03:05:43.000000000 +0200
++++ dillo-0.6.6.fg/src/url.h 2002-08-16 20:25:02.000000000 +0200
+@@ -56,6 +56,7 @@
+#define URL_ALT_(u) u->alt
+#define URL_POS_(u) u->scrolling_position
+#define URL_STR_(u) a_Url_str(u)
++#define URL_STR_NOANCHOR_(u) a_Url_str_noanchor(u)
+
+/*
+* Access methods that always return a string:
+@@ -75,6 +76,7 @@
+#define URL_ALT(u) NPTR2STR(URL_ALT_(u))
+#define URL_POS(u) URL_POS_(u)
+#define URL_STR(u) NPTR2STR(URL_STR_(u))
++#define URL_STR_NOANCHOR(u) NPTR2STR(URL_STR_NOANCHOR_(u))
+
+
+
+@@ -117,6 +119,7 @@
+gint flags, gint pos);
+void a_Url_free(DilloUrl *u);
+gchar *a_Url_str(const DilloUrl *url);
++gchar *a_Url_str_noanchor(const DilloUrl *url);
+const gchar *a_Url_hostname(const DilloUrl *u);
+DilloUrl* a_Url_dup(const DilloUrl *u);
+gint a_Url_cmp(const DilloUrl* A, const DilloUrl* B); 
+
+
+
+Re: [Dillo-dev]turning images off
+
+From: madis <madis@cy...> - 2002-08-15 22:09
+
+On Sat, 10 Aug 2002, Lex Hider wrote:
+
+> I have done a bit of a patch for my own use
+> that gives a preference option to
+> turn images on or off. 
+> check it out.
+
+Dillo does not draw alt text for images and image links without alt text 
+are quite uncomfortable to use, when image is not loaded. I read this 
+patch and seems that it would not add ability drawing alt text. Here is a 
+patch to do this:
+
+diff -pru -x CVS -x 'Makefile*' -x config.h.in dillo-cvs/src/dw_image.c 
+dillo/src/dw_image.c
+--- dillo-cvs/src/dw_image.c 2002-04-10 16:08:18.000000000 +0300
++++ dillo/src/dw_image.c 2002-08-16 00:48:50.000000000 +0300
+@@ -281,19 +281,19 @@ static void Dw_image_draw (DwWidget *wid
+
+p_Dw_widget_draw_widget_box (widget, area);
+
+- if (image->buffer) {
+- content.x = p_Dw_style_box_offset_x (widget->style);
+- content.y = p_Dw_style_box_offset_y (widget->style);
+- content.width =
+- widget->allocation.width - p_Dw_style_box_diff_width (widget->style);
+- content.height = widget->allocation.ascent + widget->allocation.descent -
+- p_Dw_style_box_diff_height (widget->style);
+-
+- if (p_Dw_rectangle_intersect (area, &content, &intersection)) {
+- vx = p_Dw_widget_x_world_to_viewport (widget, widget->allocation.x);
+- vy = p_Dw_widget_y_world_to_viewport (widget, widget->allocation.y);
+- gc = widget->style->color->gc;
++ content.x = p_Dw_style_box_offset_x (widget->style);
++ content.y = p_Dw_style_box_offset_y (widget->style);
++ content.width =
++ widget->allocation.width - p_Dw_style_box_diff_width (widget->style);
++ content.height = widget->allocation.ascent + widget->allocation.descent -
++ p_Dw_style_box_diff_height (widget->style);
++
++ if (p_Dw_rectangle_intersect (area, &content, &intersection)) {
++ vx = p_Dw_widget_x_world_to_viewport (widget, widget->allocation.x);
++ vy = p_Dw_widget_y_world_to_viewport (widget, widget->allocation.y);
++ gc = widget->style->color->gc;
+
++ if (image->buffer) {
+if (image->scaled_buffer)
+buffer = image->scaled_buffer;
+else
+@@ -309,6 +309,39 @@ static void Dw_image_draw (DwWidget *wid
+vx + intersection.x, vy + intersection.y,
+intersection.width, intersection.height, GDK_RGB_DITHER_MAX,
+bstart, content.width * 3);
++ } else if (image->alt_tooltip) {
++ GdkFont *font;
++ const gchar *s;
++ int width = 0;
++
++ font = widget->style->font->font;
++ if (content.width) {
++ for (s = image->alt_tooltip->text; *s && width < content.width; )
++ width += gdk_char_width(font, *(s++));
++ } else
++ s = image->alt_tooltip->text + strlen(image->alt_tooltip->text);
++ gdk_draw_text(DW_WIDGET_WINDOW (widget), font, gc, vx, vy +
++ (content.height + font->ascent - font->descent) / 2,
++ image->alt_tooltip->text, s - image->alt_tooltip->text);
++ } else if (content.width > 2 && content.height > 2) {
++ int lx, ly, cx, cy;
++ 
++ lx = vx + intersection.x + intersection.width - 1;
++ ly = vy + intersection.y + intersection.height - 1;
++ cx = vx + content.width - 1;
++ cy = vy + content.height - 1;
++ if (!intersection.x)
++ gdk_draw_line(DW_WIDGET_WINDOW (widget), gc,
++ vx, vy + intersection.y, vx, ly);
++ if (!intersection.y)
++ gdk_draw_line(DW_WIDGET_WINDOW (widget), gc,
++ vx + intersection.x, vy, lx, vy);
++ if (cx <= lx)
++ gdk_draw_line(DW_WIDGET_WINDOW (widget), gc,
++ cx, vy + intersection.y, cx, ly);
++ if (cy <= ly)
++ gdk_draw_line(DW_WIDGET_WINDOW (widget), gc,
++ vx + intersection.x, cy, lx, cy);
+}
+}
+}
+
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]Hello
+
+From: higuita <higuita@GM...> - 2002-08-14 23:47
+
+Attachments: Message as HTML      
+
+On Fri, 9 Aug 2002 13:01:18 +0100 (BST), first last
+<prelude_2_murder@ya...> wrote:
+> This idea is to have a filtering proxy to enable disable images and/or 
+> cookies on a per-site basis.
+
+use the privoxy, the new version of junkbuster
+the new version, 3.0 is almost done, in some weeks will
+be released
+it was build to be portable, runs in almost all unix and win32
+
+just search in google, should be the first link
+
+> This proxy would be running on the computer when Dillo runs (if the 
+> option is set in the dillorc file) and Dillo would have an option in
+> one
+> of the menus (or maybe a button) to enable/disable images from the 
+> site, which communicates with the proxy (maybe the proxy accepts http 
+> get or post requests using a cgi interface, so no extra communication 
+> protocol has to be developed).
+
+privoxy talks with the user via some cgi to enable, disable, edit
+and other
+just bookmark the options or make a small patch to add a static
+bookmark in the right click
+
+> The proxy does not do html parsing, as this is too processor intensive,
+> but only filters files based on extension and/or mime type (or request 
+> type, I don't know that much of http yet).
+
+privoxy does html parsing in full mode, but you can configure it
+to the plain old junkbuster url&extension block
+
+privoxy use the html parsing to disable ads by size, pop-ups, 
+javascript cookies, web-bugs and many other things
+it can be used too to fix/change pages, like new theme for
+slashdot, fix bad html code that only work in IE to a more
+standard code that works in all browsers
+
+i run it in a old 486 in full filtering and never saw the cpu
+getting too high because of filtering
+
+> The reason for this is that for modem users like me, images are a 
+> nuisance most of the time and also we can enable ad-filtering. I know 
+> that i could use links or relatives, but the brower is the application 
+> that I think that it has to be graphical.
+
+you can use too lynx or links, this way you dont get any images,
+just stuff that matters
+lynx and links are still the faster browsers for modem users, 
+especially old/slow modems
+
+but a well tuned privoxy will make miracles too
+
+higuita
+-- 
+One Unix to rule them all, One Resolver to find them,
+One IP to bring them all and in the zone bind them. 
+
+
+
+[Dillo-dev]Current progress (14/Aug)
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-08-14 16:57
+
+Hi there!
+
+
+It's been a tough week of work here; I was squeezing my brains
+trying to get the extended CCC theory delineated. Now, I need a
+couple of days of rest before resuming.
+
+It has been very productive though!, maybe 70% of it is done,
+with _maybe_ just 20-30% of coding to reach the point that
+asserts that the whole theory can implement the dpi framework as
+thought.
+
+That's the twilight-zone between theory and practice.
+
+Full time dedication yields its gains, but as a side effect, a
+lot of other interesting, less prioritized ideas, have to wait.
+
+My first priority by now, is to get the dpi framework done,
+so please be patient.
+
+BTW, I have enough to-review patches and ideas, to build up a
+new release; but they need some work.
+
+To name a few:
+
+IPv6, auto{conf/make} fixes, push consistency, command line
+options (enabling integration with sylpheed), meta refresh
+warning message (in HTML) with a link, an some other ideas.
+
+Ah, before I forget, please read the nice article about FreeSW
+and UI from the links section of our site [Livio: please place a
+new-icon there. Obrigado!].
+
+With all that, plus a few dpi-programs we'll have more than
+enough for a full blown 0.7.0 release, but we need the dpi
+framework first...
+
+----
+
+We have been trying with Livio, to finish setting the CVS
+server and mailing lists from CIPSGA since more than a month, but
+none of us has been able to contact a sysadmin there! (?)
+
+Livio: please place note right in the front page of our site
+asking for a sysadmin from CIPSGA to contact us.
+
+[Lex wrote:]
+> Just thought people would be interested in the mention
+> in Linux Journal that dillo gets.
+>
+> http://www.linuxjournal.com/article.php?sid=6169
+
+Thanks a lot Lex.
+
+BTW, it'd be great to add it to our press section and also in
+the front page.
+
+(As you may have noticed, Livio and I maintain the site).
+
+
+Cheers
+Jorge.-
+
+
+PD: sorry for the "poutpourri" style, but there was a lot of
+little things to say ;) 
+
+
+
+Re: [Dillo-dev][patch] build dillo in a separate tree to the source code
+
+From: Matias Aguirre <yo_soy@fa...> - 2002-08-14 11:00
+
+On Wed, 14 Aug 2002 12:52:27 +0200
+Tomas Guemes <tomas@pa...> wrote:
+
+> Hi all,
+> 
+> I tried to build dillo in a separate tree to the source code
+> 
+> %mkdir dillo-build && cd dillo-build
+> %../dillo-0.6.6/configure
+> %make
+> 
+> <skip>
+> 
+> gcc -DHAVE_CONFIG_H -I. -I../../dillo-0.6.6/src -I.. 
+> -I/usr/local/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
+> -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT
+> -D_THREAD_SAFE -Wall -Waggregate-return -c ../../dillo-0.6.6/src/cache.c
+> In file included from ../../dillo-0.6.6/src/cache.c:27:
+> ../../dillo-0.6.6/src/IO/Url.h:5: ../../config.h: No such file or
+> directory
+> 
+> I just change all the #include "config.h" to <config.h>
+> 
+
+It is the same file?
+Maybe <config.h> call to other header...i dont know
+
+Greetings
+
+-- 
+Matias Aguirre
+Software Engineer
+Sinatec S.A.
+Linux User #: 78193
+
+Buenos Aires, Argentina 
+
+
+
+[Dillo-dev][patch] build dillo in a separate tree to the source code
+
+From: Tomas Guemes <tomas@pa...> - 2002-08-14 10:48
+
+Hi all,
+
+I tried to build dillo in a separate tree to the source code
+
+%mkdir dillo-build && cd dillo-build
+%../dillo-0.6.6/configure
+%make
+
+<skip>
+
+gcc -DHAVE_CONFIG_H -I. -I../../dillo-0.6.6/src -I.. 
+-I/usr/local/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
+-I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -D_REENTRANT
+-D_THREAD_SAFE -Wall -Waggregate-return -c ../../dillo-0.6.6/src/cache.c
+In file included from ../../dillo-0.6.6/src/cache.c:27:
+../../dillo-0.6.6/src/IO/Url.h:5: ../../config.h: No such file or
+directory
+
+I just change all the #include "config.h" to <config.h>
+
+You can find the patch in http://pasky.dhs.org/tomas/dillo/
+
+greetings 
+
+tomas 
+
+
+
+[Dillo-dev]linux journal mention
+
+From: <lexxx_h@ya...> - 2002-08-14 03:02
+
+Just thought people would be interested in the mention
+in Linux Journal that dillo gets.
+
+http://www.linuxjournal.com/article.php?sid=6169
+
+It's an article about running linux without it hogging
+all your resources.
+
+Says that dillo's memory usage is "rather impressive".
+
+Lex.
+
+http://digital.yahoo.com.au - Yahoo! Digital How To
+- Get the best out of your PC! 
+
+
+
+[Dillo-dev]Patch: updated command line options
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-08-14 00:42
+
+Hi,
+
+Instead of posting the patch here, I have filed a bug concerning the command
+line options (is this what Jorge suggested in his last mail to the ML?). I
+updated the patch and it is 100% complete. It is available at:
+
+http://melvin.hadasht.free.fr/home/dillo/cli/index.html
+
+In short, it adds:
+- portable short and long options (without using get_opt_long)
+- options can have optional arguments
+- support of '--' as a separator between options and URL/FILEs arguments
+- automatic help text creation.
+
+Any comments and suggestions are welcome (especially that I could find any
+improvement possibilities.)
+
+I'll update my other patches to support this new CLI patch in the coming days,
+so they could act as a reference implementation for the CLI options.
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]sending patches
+
+From: <lexxx_h@ya...> - 2002-08-12 01:35
+
+Hi everyone,
+
+sorry about sending the patches I was unaware of this
+etiquette and I won't do it again.
+
+As far as the rules regarding patches made the patches
+for my own use and then realised someonelse might
+find them useful.
+
+Lex.
+
+http://digital.yahoo.com.au - Yahoo! Digital How To
+- Get the best out of your PC! 
+
+
+
+[Dillo-dev]cookies date format problem
+
+From: madis <madis@cy...> - 2002-08-11 20:04
+
+I found that cookies didn't work very well in dillo when speaking with 
+forum.zone.ee server starting from some dillo version and reason is:
+
+This is HTTP header sent by server:
+
+HTTP/1.1 200 OK
+Date: Sun, 11 Aug 2002 19:21:23 GMT
+Server: Apache/1.3.26 (Unix) mod_fastcgi/2.2.10 PHP/4.1.2
+X-Powered-By: PHP/4.1.2
+Set-Cookie: sessionhash=8a534d4b820feafd422ab005bd8bf74e; path=/; domain=forum.zone.ee
+Set-Cookie: bblastvisit=1029093683; expires=Mon, 11-Aug-03 19:21:23 GMT; path=/; domain=forum.zone.ee
+Content-Length: 49478
+Connection: close
+Content-Type: text/html
+
+
+The cookies timestamp is in format that is almost RFC-850, but the weekday 
+is Mon instead Monday, which you would expect from RFC-850 date.
+This is probably a bug in PHP or vBulletin forum software (I'm not sure 
+which one).
+
+Dillo looks it and tells that this is a crap:
+
+Parsing cookie string `bblastvisit=1029094010; expires=Mon, 11-Aug-03 19:26:50 GMT; path=/; domain=forum.zone.ee'
+Cookies: Expire date is malformed! Ignoring cookie...
+Removing cookie 'bblastvisit'
+
+And result is that cookies don't work.
+
+It is possible to allow this kind RFC-850 date with short weekday name 
+(dillo doesn't use the weekday anyway) using trivial modification in 
+cookies.c Cookies_create_timestamp function:
+
+--- dillo-cvs/src/cookies.c 2002-05-29 17:44:46.000000000 +0300
++++ dillo/src/cookies.c 2002-08-11 22:44:47.000000000 +0300
+@@ -386,8 +386,8 @@ static time_t Cookies_create_timestamp(c
+minutes = strtol(cp + 14, NULL, 10); /* minutes */
+seconds = strtol(cp + 17, NULL, 10); /* seconds */
+
+- } else if (cp && ((cp - expires == 3 && strlen(cp) == 26) ||
+- (cp - expires > 5 && strlen(cp) == 24))) {
++ } else if (cp && ((cp - expires > 5 && cp - expires <= 10) ||
++ cp - expires == 3) && (strlen(cp) == 24 || strlen(cp) == 26)) {
+/* RFC-1123 | RFC-850 format */
+day = strtol(cp + 2, NULL, 10);
+month = Cookies_get_month(cp + 5);
+
+
+But I suspect this would not met very well dillo's goal to not support 
+bugs.
+
+--
+mzz 
+
+
+
+Re: [Dillo-dev]check out these dodgy patches
+
+From: Jamin W. Collins <jcollins@as...> - 2002-08-10 18:59
+
+On Sat, 10 Aug 2002 12:26:56 -0400 (CLT) Jorge Arellano Cid
+<jcid@em...> wrote:
+
+> On Sat, 10 Aug 2002, Lex Hider wrote:
+> 
+> > I've done these few patches for my own use.
+> > Just wondering if anyone thought they were useful.
+> 
+> OK Lex, would you mind reading the mailing list etiquette and
+> the patching directions in our site?
+
+I just took a second look at the site and it's guidelines regarding the
+list, I don't see where Lex did anything wrong. According to the site:
+
+<quote>
+If your patch is small and you need to share it for advice, send it to the
+mailing list. 
+</quote>
+
+Seems to be right in line with what Lex did. I don't consider 9 KB for
+two patches to be _big_. Granted Lex might have gzip'd them prior to
+adding them, but we are still only talking about 9 KB.
+
+As far as ettiquette, his post was very clear and concise. Can't speak
+for the patching portition as I haven't devel'd that far into Dillo.
+
+-- 
+Jamin W. Collins 
+
+
+
+Re: [Dillo-dev]check out these dodgy patches
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-08-10 16:30
+
+On Sat, 10 Aug 2002, Lex Hider wrote:
+
+> I've done these few patches for my own use.
+> Just wondering if anyone thought they were useful.
+
+OK Lex, would you mind reading the mailing list etiquette and
+the patching directions in our site?
+
+
+Jorge.- 
+
+
+
+[Dillo-dev]check out these dodgy patches
+
+From: <lexxx_h@ya...> - 2002-08-10 12:54
+
+Attachments: keys.diff      menu.diff      
+
+I've done these few patches for my own use.
+Just wondering if anyone thought they were useful.
+
+menu.diff adds functionality to the right click menu.
+keys.diff adds vi-style movement keys.
+
+http://digital.yahoo.com.au - Yahoo! Digital How To
+- Get the best out of your PC! 
+
+
+
+[Dillo-dev]turning images off
+
+From: <lexxx_h@ya...> - 2002-08-10 12:45
+
+Attachments: images-new.diff      
+
+I have done a bit of a patch for my own use
+that gives a preference option to
+turn images on or off. 
+check it out.
+
+Lex.
+
+http://digital.yahoo.com.au - Yahoo! Digital How To
+- Get the best out of your PC! 
+
+
+
+[Dillo-dev]Re: Patch to use an external html source code viewer.
+
+From: Cyril Bouthors <cyril@bo...> - 2002-08-09 21:59
+
+Attachments: external_viewer_doc.patch      Bindings.txt      
+
+I've forgot to include the tiny documentation I've made about this
+source viewer patch and binding. I've described the "source_viewer"
+option in the sample dillo initialization file and described generic
+bindings into a new file called doc/Bindings.txt.
+
+I felt the need to write Bindings.txt when I discovered that the
+bindings for "backward" and "forward" functions (ALT+, and ALT+.) were
+documented nowhere else than in the source code. :) 
+
+
+
+[Dillo-dev]Patch to use an external html source code viewer.
+
+From: Cyril Bouthors <cyril@bo...> - 2002-08-09 21:30
+
+Attachments: external_viewer.patch      
+
+Hello,
+
+As discussed briefly with Livio on #dillo on OPN, I've made a patch to
+allow an external program to view the HTML source code in Dillo. The
+external viewer can be customized with the variable "source_viewer" in
+user and system wide configuration files. If "source_viewer" is
+different than "internal", Dillo will run the external viewer in the
+background. Otherwise, "source_viewer" is defined as "internal" by
+default and Dillo will use the standard "internal" GTK viewer.
+
+I've also added a keyboard binding for the "view source" function (C-u
+as in Galeon and Mozilla).
+
+I hope the code is clean enough to be included in the CVS branch,
+please do not hesitate to tell me what you think about that.
+
+The patch is attached to this email. 
+
+
+
+Re: [Dillo-dev]plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-08-09 20:06
+
+On 9 Aug 2002, Lars Clausen wrote:
+
+> [...]
+> > I want you to know that it wouldn't have been possible without
+> > the hourly consulting contract I got from metro-techs to help
+> > coding a feature they needed with dillo.
+> >
+> > In fact, I was looking for a job when they sprung-in. Now, as
+> > you read the technical parts, please think about it, because it
+> > could have not been there.
+>
+> This is very good news! I am so happy for you, and for Dillo.
+
+Thanks Lars.
+
+BTW, don't get me wrong, that contract is done. Nobody knows
+what will happen next month.
+
+
+> > After carefully reading the latest plugins' thread, I decided
+> > to answer it as a whole, telling you some news.
+> >
+> > It's been a long effort to get to dpi spec, mainly working with
+> > Eric, and at the latter time with Geoff. As you may know, the
+> > main point of dpi is to become a powerful extension framework for
+> > dillo.
+> [...]
+>
+> I don't remember if I talked about this yet or not, but I have this idea
+> for a system to handle unknown mime types, only slightly similar to my
+> external handlers patch. As far as I can read the dpi spec, my idea
+> wouldn't be workable by dpi unless you allow dpi to handle "mime types not
+> handled by anybody else".
+
+Well, I think a "last-resort" dpi should do it.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]plugins
+
+From: Lars Clausen <lrclause@cs...> - 2002-08-09 18:20
+
+On Fri, 9 Aug 2002, Jorge Arellano Cid wrote:
+>=20
+> Hi developers,
+>=20
+>=20
+> I'm breaking my silence to tell you some news:
+>=20
+> I know this is an excellent project, some of you also know, and
+> most of the people following our project wandering if they could
+> make use of it in their products, also know that.
+[...]
+> I want you to know that it wouldn't have been possible without
+> the hourly consulting contract I got from metro-techs to help
+> coding a feature they needed with dillo.
+>=20
+> In fact, I was looking for a job when they sprung-in. Now, as
+> you read the technical parts, please think about it, because it
+> could have not been there.
+
+This is very good news! I am so happy for you, and for Dillo.
+
+> After carefully reading the latest plugins' thread, I decided
+> to answer it as a whole, telling you some news.
+>=20
+> It's been a long effort to get to dpi spec, mainly working with
+> Eric, and at the latter time with Geoff. As you may know, the
+> main point of dpi is to become a powerful extension framework for
+> dillo.
+[...]
+
+I don't remember if I talked about this yet or not, but I have this idea
+for a system to handle unknown mime types, only slightly similar to my
+external handlers patch. As far as I can read the dpi spec, my idea
+wouldn't be workable by dpi unless you allow dpi to handle "mime types not
+handled by anybody else".
+
+The idea is to have a handler for unknown mime types that opens a dialog
+for the user. The dialog should allow as-text, save-to-disk,
+browse-for-app and most importantly a selection of appropriate handlers as
+found in /etc/mailcap and ~/.mailcap. This will give the user enough
+choice to find his or her preference (which the current external handlers
+patch doesn't) yet narrow the choice down to the sensible candidates.
+The users choice should of course be persistently saved.
+
+While I haven't had much time for Dillo since I became co-maintainer of
+Dia, I would like to do this, whether or not it can be done with dpi.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+Re: [Dillo-dev]plugins
+
+From: Jorge Arellano Cid <jcid@em...> - 2002-08-09 17:48
+
+Hi developers,
+
+
+I'm breaking my silence to tell you some news:
+
+I know this is an excellent project, some of you also know, and
+most of the people following our project wandering if they could
+make use of it in their products, also know that.
+
+That makes a good point, because it signals recognition.
+
+Now, a project as complex as a web browser can't be developed
+in a spare time basis. I know that, and so I'm trying to get some
+funds to assemble a small team of core developers.
+
+It may be that we still don't get to the break point where
+everyone sees dillo as a very useful tool that's better to have
+and preserve.
+
+The good news is that dillo project is about to get to a new
+milestone that will prove it even better. That is: plugins.
+
+I want you to know that it wouldn't have been possible without
+the hourly consulting contract I got from metro-techs to help
+coding a feature they needed with dillo.
+
+In fact, I was looking for a job when they sprung-in. Now, as
+you read the technical parts, please think about it, because it
+could have not been there.
+
+Specially those of you working for a company that's evaluating
+or trying to decide whether to deploy dillo or not, this is the
+right time to help. A small consulting contract wouldn't hurt and
+it may keep the boat afloat.
+
+
+--------------
+Technical part
+--------------
+
+After carefully reading the latest plugins' thread, I decided
+to answer it as a whole, telling you some news.
+
+It's been a long effort to get to dpi spec, mainly working with
+Eric, and at the latter time with Geoff. As you may know, the
+main point of dpi is to become a powerful extension framework for
+dillo.
+
+This is by no means an easy task, as it involves core parts of
+dillo as the concomitant callback chain, IO engine and cache to
+name a few. So progress had been very slow.
+
+A month ago or so, an inspiring idea hit me bringing a somewhat
+different way of implementing dpi; as Geoff was working on the
+official dpi SPEC, I decided to give it a silent try and worked
+some prototype code, it went good, and I kept working changes on
+my dillo tree.
+
+At this moment it's not complete, but I have changes worth a
+70KB diff. That is, a new IO API, and an extension of the CCC
+theory to accomodate what Geoff accurately points as multi-phase
+exchanges vs. the single request-response scheme that dillo is
+happiest with.
+
+In other words, the CCC extensions were done to cope with the
+multi-phase exchanges.
+
+What do I have now?
+
+A new scheme that's potentially able to cope with:
+
+- One-request/One-response dpi
+- Multi-phase exchanges
+- dpis that exit when finished
+- dpis that keep resident when finished (servers)
+- message passing (back/forward)
+- special task requests (as setting preferences)
+- handling of FORM request data
+
+This is enough for:
+
+- Bookmarks, preferences, FTP, downloads, https, info, man, etc.
+- Being an API for embedded platforms
+
+Yes, dpi IS a powerful idea!
+
+
+Why do I say "potentially able"?
+
+Because it's not fully proven yet.
+I still have to properly code parsing of dpi protocol answers
+to be sure that the whole theory is implementation ready.
+
+So far, the exended CCC showed no problems to handle the old
+functionality, and I also have coded a resident bookmarks dpi
+server that shows/add bookmarks and also passes some messages to
+the status bar. So, it's very close!
+
+One of the best things of the dpi extension is that it will
+allow developing dillo applets (dpi programs) without having to
+know dillo internals, that is, just the dpi API.
+
+Another advantage is that you can use the dpi that best fits
+your needs. For instance, a full featured FTP or a light weight
+one.
+
+So, my advice is to wait until it's ready.
+
+(Well, unless you're confident enough to implement dpi from the
+spec and end with a solution that's better than mine! ;).
+
+But start coding your dpi program right now!
+
+Yes, if you think of FTP (for instance), a program that gets an
+FTP-URL at the command line, and then performs the whole FTPing
+to retrieve the URL (let's think of a directory), and translates
+it to HTML that's sent to stdout, would be a great advance.
+
+In fact, the only thing left to make it a real dpi, would be
+encapsulating it into dpi protocol.
+
+If you need an answer from the browser, as with https'
+allow/deny certificate, just assume you have the answer, and fake
+a routine to do it. When dpi is finished, it will be a matter of
+replacing it with the proper call.
+
+Well, you've got the idea.
+
+
+
+Sincerely
+Jorge.-
+
+
+PS: expect some news about it in a week or so. 
+
+
+
+[Dillo-dev]Hello
+
+From: <prelude_2_murder@ya...> - 2002-08-09 12:01
+
+Hello everyone. I just joined this list because Dillo really matches my
+
+ideas of what a useful browser should be and I would like to contribute
+
+to it.
+
+I have a couple of ideas that I would like to share with you.
+
+The first one is that I would like to have an option to not display
+images at all, but instead of doing it like Mozilla does (not
+displaying 
+anything), do it like Opera, displaying the "alt" text within a border 
+or "image" if there is no "alt" text.
+
+The way I thought of doing this was linking the code that renders the 
+image to check for a variable and then call the image renderer or a 
+table renderer instead, so it displays what I said before.
+
+This is an idea, and I am more than open to suggestions on how to do it
+
+correctly and in a way that would be accepted by the developers (no,
+I'm
+not keen on quick hacks and do agree that "properly written" code is 
+the most important thing for maintainability).
+
+The second one is something that I initially thought that it could be 
+added to Dillo itself, but I realised that it does not go well with the
+
+"do one thing and do it small" philosophy, so I thought of doing it 
+apart.
+
+This idea is to have a filtering proxy to enable disable images and/or 
+cookies on a per-site basis.
+
+This proxy would be running on the computer when Dillo runs (if the 
+option is set in the dillorc file) and Dillo would have an option in
+one
+of the menus (or maybe a button) to enable/disable images from the 
+site, which communicates with the proxy (maybe the proxy accepts http 
+get or post requests using a cgi interface, so no extra communication 
+protocol has to be developed).
+
+The proxy does not do html parsing, as this is too processor intensive,
+
+but only filters files based on extension and/or mime type (or request 
+type, I don't know that much of http yet).
+
+The reason for this is that for modem users like me, images are a 
+nuisance most of the time and also we can enable ad-filtering. I know 
+that i could use links or relatives, but the brower is the application 
+that I think that it has to be graphical.
+
+Sorry if this message is too long, but I wanted everyone to 
+understand what I want and to contribute with ideas on what/how should
+be done (or just convince me to forget about it if you're not
+interested).
+
+Thanks for reading this
+
+Gabriel
+
+__________________________________________________
+Do You Yahoo!?
+Everything you'll ever need on one web page
+from News and Sport to Email and Music Charts
+http://uk.my.yahoo.com 
+
+
+
+Re: [Dillo-dev]https
+
+From: madis <madis@cy...> - 2002-08-09 00:51
+
+On Tue, 6 Aug 2002, Lars Segerlund wrote:
+
+> 
+> Got any idea of how to do the https <-> dillo interaction ?
+> 
+> 1. quite easy to handle encryption.
+> 
+> 2. not so easy to handle certificates ?
+> 
+> If I got everyting right, a plugin must make dillo recognize its url 
+> type ? after this dillo will invoke it, thus it needs to be configured 
+> somewhere ... or have the ability to autoconfigure ( wich would be nicer 
+> ) but in this case this has to be able to be overrun ?
+> 
+
+Some thoughts (which may be wrong, of course) :
+
+Dillo must have knowledge about plugin existing, or it don't know that it 
+should start plugin (Dpi1 doc PI initialization paragraph has also remark 
+about pluginsrc file). When dillo sees url that matches one described in 
+pluginsrc and has no instance (process) of this plugin which is able to
+serve it, dillo should do fork-exec to create plugin process (i think 
+that there can be plugins which serve only one request and die after that 
+and such a plugin is not able to serve any request after receiveing first 
+request).
+
+Certificates - SSL plugin should be such a plugin, which serves all 
+requests within one process (and this process will not die before dillo 
+tells to it quit or quits by itself and closes pipe).
+Plugin gets other side's certificate with connection. Plugin may have a 
+some CA's public keys stored and if the certificate is signed by one of 
+these CA's check signatures validity. If it does not have public key it 
+would be nice to prompt to the user some choices: allow/deny certificate 
+or provide CA public key's URI. Prompting is possible in two ways:
+
+1. plugin talks with X.
+2. dpi protocol allows requesting dialog box from dillo.
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]plugins
+
+From: Geoff Lane <zzassgl@tw...> - 2002-08-07 08:53
+
+> Okie, are there any code for the plugins ? or only the proposal ?
+> If not I will get working on it.
+
+I'm supposed to be working on the plugin code but circumstances have meant
+I've had little time to work on it so far.
+
+If it's OK with the rest of the project, I'm happy to let someone else with
+more time available take over.
+
+I do have a some comments on the plugin concept I may as well share right
+now. 
+
+One of the first things I did when looking at implementing plugins was to
+add ftp: support directly into dillo as an internal facility. This is a
+total hack and currently breaks in "interesting" ways (ie ways I don't fully
+understand yet) under some conditions. Under Linux the stripped dillo+ftp
+binary increased in size by less than 6K.
+
+I did this by ignoring libraries such as cURL and libftp and coded the
+protocol directly. The basic ftp protocol is very simple. Within dillo the
+major implementation problem arises because ftp (as used within browsers) is
+a multi-phase exchange and dillo is happiest with a single request-response
+protocol as used by http. The multi-phase exchange was dealt with by
+running the protocol within a thread which communicates (via a pipe) with
+the dillo IO engine (which has no real idea where the data is actually
+coming from.)
+
+Using cURL results in a binary size increase of around 2Mb. For that you get
+a fuller implementation of the ftp protocol (active/passive transfers and
+proxy support for example) but you lose your small browser footprint _even_
+if the plugin is running as a seperate process. As a method of prototyping,
+using cURL is fine but if you care about size and performance you really
+have to hand craft the protocol code.
+
+Running protocols within threads is a powerful design concept for a browser
+as all kinds of protocol stuff can be hidden and all the IO engine sees is a
+simple datastream.
+
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\ 
+
+
+
+[Dillo-dev]about plug ins
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-08-07 08:40
+
+Is there any work done on the plugins at all ?
+
+I am thinking of starting an implementation by the spec. 
+
+
+
+Re: [Dillo-dev]Patch: command line options support
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-08-07 08:34
+
+Hi Andreas,
+
+on Wed, 7 Aug 2002 04:19:57 -0400
+Andreas Schweitzer <andy@ph...> wrote:
+
+> Hi,
+> 
+> > Having done a few patches that needed command line options, Jorge suggested
+to
+> > add a real command line options support to Dillo. 
+> 
+> > Any comments and ideas are welcome!
+> 
+> I have been thinking about command line options myself.
+> I was thinking about adding something like :
+> -o "dillorc-string"
+> which would allow to override settings in dillorc with the same
+> syntax. I think ssh has options like that, for example.
+> I have just moved, and, therefore, have not been able
+> to follow dillo very much but I may soon look into this.
+
+Yes, this will allow different profiles. This is another reason why I put the
+command line parsing before any serious initialisation. 
+
+
+
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]Patch: command line options support
+
+From: Andreas Schweitzer <andy@ph...> - 2002-08-07 08:20
+
+Hi,
+
+> Having done a few patches that needed command line options, Jorge suggested to
+> add a real command line options support to Dillo. 
+
+> Any comments and ideas are welcome!
+
+I have been thinking about command line options myself.
+I was thinking about adding something like :
+-o "dillorc-string"
+which would allow to override settings in dillorc with the same
+syntax. I think ssh has options like that, for example.
+I have just moved, and, therefore, have not been able
+to follow dillo very much but I may soon look into this.
+
+Cheers
+Andreas
+
+-- 
+**************************** NEW ADDRESS ******************************
+Hamburger Sternwarte
+Gojenbergsweg 112
+D-21029 Hamburg, Germany 
+
+
+
+[Dillo-dev]Patch: command line options support
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-08-06 20:04
+
+Attachments: dillo-cvs-2002-08-06-cli.patch      
+
+[Jorge, I'm CCing to you for patch reviewing as advised on Dillo's home page.]
+
+Hi,
+
+Having done a few patches that needed command line options, Jorge suggested to
+add a real command line options support to Dillo. 
+This would provide a framework so developers won't have to add the command line
+option parsing every time.
+
+So here is my proposal:
+
+This patch is a proposal for a simple and extensible command line options
+support in Dillo. It is based on the getopt() function found in unistd.h. It
+supports only short options, as the long options function getopt_long() is a GNU
+extension and is thus not portable. Though, it could be easily added.
+
+The patch comes with two command line options -v and -h to display version
+number and a short help message. The options are to be passed before any URL or
+filename. As a by-product of this patch, it is now possible to call Dillo with
+more than one URL/filename. In that case, more than one window will be opened.
+
+The command line options are parsed before any serious initialisation (even
+before display initialisation). Two #defines define the help message and the
+string of all known options. Some other define a flag for each option. These
+flags will be ORed and stored in an integer to remember later all the options
+found. They are not really used in this patch, but they are included for
+consistency. (For reference, my other patches[1] use them.)
+
+So to add a new option, it is a matter to update the DILLO_CLI_HELP_MESSAGE and
+the DILLO_CLI_OPTIONS. If the option is to be processed outside of the option
+parsing loop, you may add a "#define DILLO_CLI_YOUR_OPTION 1 << x" (as I did in
+this patch, but they are actually not really used) and a cli_option |=
+DILLO_CLI_YOUR_OPTION in the classical switch-case.
+
+Any comments and ideas are welcome!
+
+[1] The patch is also available at:
+http://melvin.hadasht.free.fr/home/dillo/cli/index.html
+
+
+
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]https
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-08-06 17:51
+
+Got any idea of how to do the https <-> dillo interaction ?
+
+1. quite easy to handle encryption.
+
+2. not so easy to handle certificates ?
+
+If I got everyting right, a plugin must make dillo recognize its url 
+type ? after this dillo will invoke it, thus it needs to be configured 
+somewhere ... or have the ability to autoconfigure ( wich would be nicer 
+) but in this case this has to be able to be overrun ?
+
+/ Segerlund. 
+
+
+
+[Dillo-dev]plugins
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-08-06 17:33
+
+Okie, are there any code for the plugins ? or only the proposal ?
+
+If not I will get working on it. 
+
+
+
+RE: [Dillo-dev]makefiles
+
+From: Eric Gaudet <ericg@ta...> - 2002-08-06 16:53
+
+Hi Lars,
+
+About your makefile, I don't know. Png should be detected by the
+./configure. Did you see it?
+
+About hadling url type, this is actually what plugins are designed for. It
+might not be clear in the current proposal (there is an example with
+prefix=bm, though), but my original version stated it explicititly in "2)
+Prefixed call to a Dillo-plugin".
+
+I don't know what's the status of plugins implementation.
+
+References:
+Current DPI1: http://dillo.cipsga.org.br/dpi1.html
+Original DPI: http://www.rti-zone.org/dillo/Plugins.txt.gz
+
+> -----Original Message-----
+> From: Lars Segerlund [mailto:lars.segerlund@co...]
+> Sent: Tuesday, August 06, 2002 3:58 AM
+> To: dillo-dev@li...
+> Subject: [Dillo-dev]makefiles
+> 
+> 
+> 
+> Hmm ... I had to edit src/Makefile and add -lpng to compile ??
+> 
+> Also, I had a look at the handling of url types ( https: , 
+> mailto: ) 
+> and I am wondering if there is a way to handle this with the plugin 
+> interface ? And the specification for the plugins seems to be 
+> done, but 
+> I haven't been able to find this in the code ? could anyone send a 
+> reference ( file:lineno ? ).
+> 
+> / Lars Segerlund.
+> 
+> 
+> 
+> -------------------------------------------------------
+> This s...net email is sponsored by:ThinkGeek
+> Welcome to geek heaven.
+> http://thinkgeek.com/sf
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+
+
+[Dillo-dev]makefiles
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-08-06 10:58
+
+Hmm ... I had to edit src/Makefile and add -lpng to compile ??
+
+Also, I had a look at the handling of url types ( https: , mailto: ) 
+and I am wondering if there is a way to handle this with the plugin 
+interface ? And the specification for the plugins seems to be done, but 
+I haven't been able to find this in the code ? could anyone send a 
+reference ( file:lineno ? ).
+
+/ Lars Segerlund. 
+
diff --git a/old/oldmail/200209.txt b/old/oldmail/200209.txt
new file mode 100644
index 0000000..4c4dc62
--- /dev/null
+++ b/old/oldmail/200209.txt
@@ -0,0 +1,1134 @@
+[Dillo-dev]dillo and sparc linux
+
+From: higuita <higuita@GM...> - 2002-09-30 00:12
+
+Attachments: Message as HTML      
+
+hi
+
+i tried to use dillo on a old sun ultra1.
+it have SuSE 7.3 sparc.
+
+i run the ./configure --enable-cookies and make without any
+problema, and finally make install
+
+but when i try yo run it, it crash on the startup
+
+i grabbed the gdb and the strace of the crash
+
+any tip is welcome
+
+execve("/usr/local/bin/dillo", ["dillo"], [/* 66 vars */]) = 0
+uname({sys="Linux", node="puma", ...}) = 0
+brk(0) = 0x6dd10
+open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
+open("/etc/ld.so.cache", O_RDONLY) = 3
+fstat64(3, {st_mode=S_IFREG|0644, st_size=93571, ...}) = 0
+mmap(NULL, 93571, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7002c000
+close(3) = 0
+open("/usr/lib/libjpeg.so.62", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0- \0"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=150423, ...}) = 0
+mmap(NULL, 196432, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x70044000
+mprotect(0x70064000, 65360, PROT_NONE) = 0
+mmap(0x70064000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0x70064000
+close(3) = 0
+open("/usr/lib/libpng.so.2", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0[@\0"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=225905, ...}) = 0
+mmap(NULL, 268880, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x70074000
+mprotect(0x700a6000, 64080, PROT_NONE) = 0
+mmap(0x700b4000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x30000) = 0x700b4000
+close(3) = 0
+open("/lib/libz.so.1", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\32"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=68012, ...}) = 0
+mmap(NULL, 124840, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x700b8000
+mprotect(0x700c6000, 67496, PROT_NONE) = 0
+mmap(0x700c8000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x700c8000
+close(3) = 0
+open("/usr/lib/libgtk-1.2.so.0", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\3)\0"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=1913958, ...}) = 0
+mmap(NULL, 1729504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x700d8000
+mprotect(0x70260000, 123872, PROT_NONE) = 0
+mmap(0x70268000, 90112, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x180000) = 0x70268000
+mmap(0x7027e000, 992, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7027e000
+close(3) = 0
+open("/usr/lib/libgdk-1.2.so.0", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\263"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=301871, ...}) = 0
+mmap(NULL, 318392, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x70280000
+mprotect(0x702bc000, 72632, PROT_NONE) = 0
+mmap(0x702c0000, 57344, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x30000) = 0x702c0000
+close(3) = 0
+open("/usr/lib/libgmodule-1.2.so.0", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\f\300"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0644, st_size=14956, ...}) = 0
+mmap(NULL, 75240, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x702d0000
+mprotect(0x702d4000, 58856, PROT_NONE) = 0
+mmap(0x702e0000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x702e0000
+close(3) = 0
+open("/usr/lib/libglib-1.2.so.0", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0|@\0"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=225843, ...}) = 0
+mmap(NULL, 253696, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x702e4000
+mprotect(0x70312000, 65280, PROT_NONE) = 0
+mmap(0x70314000, 57344, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x20000) = 0x70314000
+close(3) = 0
+open("/usr/X11R6/lib/libXi.so.6", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\24"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=38101, ...}) = 0
+mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7001a000
+mmap(NULL, 94872, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x70324000
+mprotect(0x7032c000, 62104, PROT_NONE) = 0
+mmap(0x70334000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x70334000
+close(3) = 0
+open("/usr/X11R6/lib/libXext.so.6", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0, \0"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=72547, ...}) = 0
+mmap(NULL, 124768, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7033c000
+mprotect(0x7034a000, 67424, PROT_NONE) = 0
+mmap(0x7034c000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7034c000
+close(3) = 0
+open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\1}\300"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=1106635, ...}) = 0
+mmap(NULL, 1031984, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7035c000
+mprotect(0x70442000, 89904, PROT_NONE) = 0
+mmap(0x7044c000, 49152, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0xe0000) = 0x7044c000
+close(3) = 0
+open("/lib/libc.so.6", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0027"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=1537287, ...}) = 0
+mmap(NULL, 1377936, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x70458000
+mprotect(0x7058e000, 108176, PROT_NONE) = 0
+mmap(0x70598000, 57344, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x130000) = 0x70598000
+mmap(0x705a6000, 9872, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x705a6000
+close(3) = 0
+open("/lib/libm.so.6", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\246"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=649398, ...}) = 0
+mmap(NULL, 621608, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x705ac000
+mprotect(0x70632000, 72744, PROT_NONE) = 0
+mmap(0x7063c000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x80000) = 0x7063c000
+close(3) = 0
+open("/lib/libdl.so.2", O_RDONLY) = 3
+read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0!\340"..., 1024) = 1024
+fstat64(3, {st_mode=S_IFREG|0755, st_size=16900, ...}) = 0
+mmap(NULL, 75800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x70644000
+mprotect(0x70648000, 59416, PROT_NONE) = 0
+mmap(0x70654000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x70654000
+close(3) = 0
+munmap(0x7002c000, 93571) = 0
+getpid() = 13025
+--- SIGSEGV (Segmentation fault) ---
++++ killed by SIGSEGV +++
+
+
+
+
+19:41:58 ~/download/dillo-0.6.6/$gdb dillo
+GNU gdb 4.18
+Copyright 1998 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and you are
+welcome to change it and/or distribute copies of it under certain conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB. Type "show warranty" for details.
+This GDB was configured as "sparc-suse-linux"...
+(gdb) run dillo
+Starting program: /usr/local/bin/dillo dillo
+
+Program received signal SIGSEGV, Segmentation fault.
+0x4a0a4 in __errno_location () at errno.c:26
+26 errno.c: No such file or directory.
+(gdb) bt full
+#0 0x4a0a4 in __errno_location () at errno.c:26
+No locals.
+#1 0x7048fff4 in sigaction () from /lib/libc.so.6
+No symbol table info available.
+#2 0x48c34 in pthread_initialize () at pthread.c:482
+sa = {__sigaction_handler = {sa_handler = 0x49320 <pthread_handle_sigrestart>, sa_sigaction = 0x49320 <pthread_handle_sigrestart>}, sa_mask = {__val = {
+0 <repeats 32 times>}}, sa_flags = 0, sa_restorer = 0}
+mask = {__val = {1880140472, 0, 0, 0, 4026528480, 0, 12, 920, 916, 912, 908, 400, 1883647568, 1879155784, 60, 15, 1879157528, 82652, 1884947408, 
+1883647568, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1881619880, 1881660688}}
+#3 0x4cae4 in __do_global_ctors_aux ()
+No symbol table info available.
+#4 0x1c450 in _init ()
+No symbol table info available.
+#5 0x7047b630 in __libc_start_main () from /lib/libc.so.6
+No symbol table info available.
+(gdb) 
+
+
+-- 
+One Unix to rule them all, One Resolver to find them,
+One IP to bring them all and in the zone bind them. 
+
+
+
+[Dillo-dev]Bug #349
+
+From: Manuel Menal <mmenal@hu...> - 2002-09-29 10:51
+
+Hey,
+
+While porting Dillo to the new implementation of POSIX threads for
+GNU/Hurd (code name: "Rubbish, I asked for mine with Minced Garlic,
+Please Take this back"), I found some minor « bugs » in the Dillo
+"installation system". The first bug I found out was a bug that was
+already reported as #349 in the Dillo bug report system. It seems a
+quite simple and not so annoying bug, but in fact it is quite pervert,
+as it makes the configure misdetect what is installed in the system:
+when it checks for jpeglib.h (& others), it tries to preprocess a simple
+C file which only includes jpeglib.h, and check if there is some
+output. If there is some output, then it assumes there is no
+jpeglib.h. Which is not true in this case: the output is just warning
+of cpp, which complains about the « -I/usr/local/include » (cpp 3.1
+already has /usr/local/include it its system directories). 
+
+There is a simple way to fix it, though. And Here is a patch:
+
+diff -pru old/dillo-0.6.6/configure dillo-0.6.6/configure
+--- old/dillo-0.6.6/configure 2002-09-29 12:41:20.000000000 +0200
++++ dillo-0.6.6/configure 2002-09-29 12:40:57.000000000 +0200
+@@ -1494,8 +1494,8 @@ ac_config_headers="$ac_config_headers co
+ac_config_commands="$ac_config_commands default-1"
+
+
+-CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+-LDFLAGS="$LDFLAGS -L/usr/local/lib"
++CPPFLAGS="$CPPFLAGS -idirafter=/usr/local/include"
++LDFLAGS="$LDFLAGS -idirafter=/usr/local/lib"
+
+idirafter makes cpp check /usr/local/include AFTER its system
+directories (and the other -I'ed directories), so it doesn't complain
+any more, and though it does include /usr/local/include on systems where
+cpp doesn't have it in its system directories. This seems to fix my bug
+and #349's reporter one. 
+
+HTH,
+
+-- 
+Manuel Menal 
+
+
+
+[Dillo-dev]CVS ...
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-09-26 07:52
+
+Haven't been updated on source forge for ages !
+
+Why ? 
+
+
+
+[Dillo-dev]Does this mean that the changes are in the cvs ?
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-09-26 06:43
+
+Where to get the dillo source with dpi CCC ?
+
+Is it in the cvs ? Or is there a new snapshot ?
+
+/ Lars Segerlund. 
+
+
+
+[Dillo-dev]dpi progress
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-09-26 01:21
+
+Hi there!
+
+I have two groups of news, the good ones and the bad ones, you
+choose:
+
+"Tell me the good ones"
+
+OK, I finished testing every single piece that composes the
+implementation of the dpi, and they're all OK. Even more, they
+work together showing good integration; that is: the dpi CCC, the
+new CCC functions, the pthreaded IOWrites operation, the dpi
+protocol and the test dpi-server!
+
+
+"Tell me the bad ones"
+
+My economic situation is at its worst point, the funding
+initiative hasn't raised a single dolar, my broken laptop didn't
+work with the new inverter, and I'm yet to find a place to live
+and code peacefully, so it will take more time (if ever), and I
+don't know how much.
+
+
+Sincerely
+Jorge.-
+
+
+PD1: If you are a laptop manufacturer and have some dust covered
+babies around, I'd be more than glad to adopt _one_.
+
+PD2: Considering that dillo-0.6.6 has more than 15000 downloads,
+you can expect a bigger number of persons reading about the
+happy event by the next release. 
+
+
+
+[Dillo-dev]Xft
+
+From: Tor Andersson <tor.andersson@ds...> - 2002-09-25 11:31
+
+Attachments: dillo-xft.patch      
+
+Hello all,
+
+Here is a small patch to make Dillo use Xft for text, so that
+it can use anti-aliased fonts. The patch is against 0.6.6,
+using new versions of Xft and fontconfig.
+
+Screenshot and patch can be found at
+http://www.df.lth.se/~mazirian/software/patches/
+
+Fontconfig and Xft
+http://fontconfig.org/
+
+Add the following to .fonts.conf to disable hinting:
+
+<match target="pattern">
+<edit name="hinting" mode="assign">
+<bool>false</bool>
+</edit>
+</match>
+
+/tor 
+
+
+
+[Dillo-dev]You've been hit ;)
+
+From: Nicola Girardi <nicola@g-...> - 2002-09-24 07:24
+
+For those who don't know, there's an article on LinuxToday about
+Dillo. :-)
+
+http://linuxtoday.com/news_story.php3?ltsn=2002-09-23-001-26-RV-DT-SW 
+
+
+
+[Dillo-dev]GIF
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-09-20 20:43
+
+Hi there!
+
+Is anyone libungif savvy here?
+
+The point is that I want to replace the current code inside
+gif.c because the license it carries forbids dillo from being
+included in any product sold for a fee.
+
+(Note that there's the possibility of it just being an obsolete
+remainder because a long long time ago Raph changed the decoder
+for, among others, distributing the code with a freer license.)
+
+Anyway, it may be good to use libungif (we currently use
+libjpeg and libpng) for animated GIFs.
+
+The technical point is that GIF data is to be fed in chunks to
+the decoder, and it MUST be possible to render it incrementally
+from the RGB buffer. I gave a look to the library docs, and
+source, and it seems possible.
+
+
+Cheers
+Jorge.-
+
+
+PS: I hope to write some good news on dpi by Monday. 
+
+
+
+Re: [Dillo-dev]Want to contribute
+
+From: Miernik <miernik@ct...> - 2002-09-20 11:57
+
+Attachments: Message as HTML      
+
+On Sat, Sep 14, 2002 at 01:37:04PM -0500, Parminder Singh wrote:
+
+> but there r 2 key things that are needed https and frames support. i
+> would like to contribute to dillo in some way. i am not an expert
+> programmer, but i do think i am good enough. so pls tell me where
+> should i start from. i need to understand how dillo clicks first and
+> then try adding the support for frames and https.
+
+You can look at this page:
+
+http://dillo.cipsga.org.br/cgi-bin/bugtrack/Dillo_query.cgi?what=3Dff&Submi=
+t=3DFind+It%21
+
+and contact the developers there.=20
+I'd join too, when I'll see some progress giving a chance to have it
+continued and reasonably usable in a reasonable time.=20
+
+--=20
+Miernik _____________________________________
+/ /
+tel.: +48603070983 / / mailto:miernik@ct...
+__________________/___/ ICQ UIN: 4004001 
+
+
+
+[Dillo-dev]Want to contribute
+
+From: Parminder Singh <param_mail@po...> - 2002-09-14 18:37
+
+Hi,
+First of all, thank you everyone for making such an excellent browser. but there r 2 key things that are needed https and frames support. i would like to contribute to dillo in some way. i am not an expert programmer, but i do think i am good enough.
+so pls tell me where should i start from. i need to understand how dillo clicks first and then try adding the support for frames and https.
+thanx,
+parminder singh. 
+
+
+
+[Dillo-dev]to the makers: dillo rocks!
+
+From: ben <benfoley@rc...> - 2002-09-14 09:18
+
+i'm literally just taking a break from some research that i have to 
+eventually make sense of, but the fact that i've been intimately all over 
+the world that i need to touch, extracting so much of the knowledge i need to 
+achieve my immediate goal and getting to much of it with the current deb of 
+dillo, i felt moved to leave a note to say thanks. i wish i had the 
+skill to contribute. if you should ever have need of a copy editor, send me 
+a word. i would love to help, but that's the only talent i can offer.
+
+the bottom line is
+
+thank you very much 
+
+
+
+[Dillo-dev]dillo is great! Some suggestions...
+
+From: Pablo De Napoli <pdenapo@ya...> - 2002-09-13 22:28
+
+Dear friends of the Dillo project:
+
+First let me say that I think that Dillo is a great project.
+It is is important to have a truly free web-browser, that is
+light-weighted and fast (I test is over a telephone conection
+to the internet (PPP) at it was great, much faster and stable
+that Netscape =)
+
+The most important thing that dillo is lacking (for me), is https
+and ftp support. I would love to help to implement https, but I'm
+not an expert programmer (even do I have contributed with
+patches to some free software projects). I don't know how should
+I use the open-ssl library to implement https.
+
+I've seen that the Lynx (text-mode) web-browser supports https.
+It uses a www library from the CERN and W3c , this library 
+provides an implementation of all the internet protocols.
+
+http://www.w3.org/Library/
+
+Lynx is GPL-ed software as well, so I suggest that you might
+avoid reinventing the wheel and use this library for doing the
+networking. This would be taking advantage of the free software
+concept.
+
+Besides that, you don't have to care about bugs in the networking
+layer =)
+
+Pablo De Napoli
+(from Argentina)
+pdenapo@ya...
+
+
+
+
+
+
+
+
+__________________________________________________
+Do you Yahoo!?
+Yahoo! News - Today's headlines
+http://news.yahoo.com 
+
+
+
+Re: [Dillo-dev]finding admins of CIPSGA
+
+From: Miernik <miernik@ct...> - 2002-09-13 20:15
+
+On Fri, Sep 13, 2002 at 02:24:29PM -0400, Jorge Arellano Cid wrote:
+> - Since nothing has helped to find them, please dig the CIPSGA
+> site and try to find some emails and start asking them to contact
+> me _PLEASE_! (I tried kov, hmh, dvalois, macan several times with
+> no success, and now I'm 100% on dpi implementation).
+
+If nothing helps, maybe just call them by phone?
+
+miernik@tarnica:~$ whois cipsga.org.br
+
+[...]
+
+domain: CIPSGA.ORG.BR
+owner: Comite Incentivo Prod. S. Gratuito Alternativo
+ownerid: 003.179.614/0001-70
+responsible: Djalma Valois Filho
+address: Rua Alice, 151, 102
+address: 22241-020 - Rio de Janeiro - RJ
+phone: (021) 92237832 []
+
+[...]
+
+nic-hdl-br: DVF5
+person: Djalma Valois Filho
+e-mail: dvalois@CI...
+address: Rua Alice, 151, 102
+address: 22241-020 - Rio de Janeiro - RJ
+phone: (021) 92237832 []
+created: 19991120
+changed: 20020708
+
+A call to +552192237832 should solve the problem. 
+
+-- 
+Miernik _____________________________________
+/ /
+tel.: +48603070983 / / mailto:miernik@ct...
+__________________/___/ ICQ UIN: 4004001 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Jamin W. Collins <jcollins@as...> - 2002-09-13 19:29
+
+On Fri, 13 Sep 2002 14:24:29 -0400 (CLT) Jorge Arellano Cid
+<jcid@so...> wrote:
+
+> - The Web server is not a problem because we have accounts with
+> all the required priviledges there.
+> 
+> - CVS is working at CIPSGA but only for me and Sebastian, and
+> the point is to find a CIPSGA sysadmin to enable the pserver.
+> That's why the SF CVS server look dead.
+
+If these two items are working. Why not do a periodic CVS snapshot and
+make it available on the new web site. Works around the CVS problems for
+right now.
+
+-- 
+Jamin W. Collins 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-09-13 18:30
+
+On Fri, 13 Sep 2002, Sebastian Geerken wrote:
+
+Hi Sebastian, is nice to hear from you!
+
+> On Wed, Sep 11, 2002 at 08:52:14PM +0200, Nicola Girardi wrote:
+> > If he's not going to keep up with it, I'll try to start from his
+> > patch and add anti-aliasing, but first I want to ask another
+> > question: is there any hope that the GTK2 patch goes into CVS or
+> > would I be going to maintain a separate patch all life long?
+>
+> I will review it soon, what may take some while, since I'm currently
+> horribly overworked. Dillo will be ported to Gtk+, this has already
+> been discussed some time ago on this list.
+
+Well, I tend not to answer things that have been discussed
+several times in the past, but as I've been pretty silent trying
+to finish the dpi framework (those who read my posts know the
+whole picture), I'll refresh some ideas here:
+
+- GTK2 port was discussed a long time ago (BTW it's also listed
+in the future goals), and the plan is to incorporate it into CVS
+when the main distros start to ship GTK2.
+
+- Some time ago (maybe Pekka IIRC) assembled a GTK2 patch from
+several other efforts, and I thought it'd be good to open a CVS
+branch for it a CIPSGA, but, as you may have noticed in the front
+page of our sites, we've been trying to contact CIPSGA sysadmins
+for months with Livio!!!
+
+- Since nothing has helped to find them, please dig the CIPSGA
+site and try to find some emails and start asking them to contact
+me _PLEASE_! (I tried kov, hmh, dvalois, macan several times with
+no success, and now I'm 100% on dpi implementation).
+
+- The Web server is not a problem because we have accounts with
+all the required priviledges there.
+
+- CVS is working at CIPSGA but only for me and Sebastian, and
+the point is to find a CIPSGA sysadmin to enable the pserver.
+That's why the SF CVS server look dead.
+
+- As I pointed before, you can find the whole picture reading
+my posts at the mailing list archive.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-09-13 15:50
+
+On Wed, Sep 11, 2002 at 08:52:14PM +0200, Nicola Girardi wrote:
+> If he's not going to keep up with it, I'll try to start from his
+> patch and add anti-aliasing, but first I want to ask another
+> question: is there any hope that the GTK2 patch goes into CVS or
+> would I be going to maintain a separate patch all life long?
+
+I will review it soon, what may take some while, since I'm currently
+horribly overworked. Dillo will be ported to Gtk+, this has already
+been discussed some time ago on this list.
+
+Sebastian 
+
+
+
+[Dillo-dev]New about:splash?
+
+From: MadProf <ralphtheraccoon@uk...> - 2002-09-13 12:17
+
+Hi,
+
+As with the new dillo website having the brown colour scheme, should the
+about:splash page also be updated? I have made the changes here, and 
+have a screenshot (CVS+ximian.pixmaps.h+gtk2(cool!):
+
+http://www.madprof.net/working/dillo.png
+
+I can make a patch too if anyone is interested.
+
+Dan 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Miernik <miernik@ct...> - 2002-09-13 07:49
+
+On Fri, 13 Sep 2002, Nicola Girardi wrote:
+
+> Pekka Lampila wrote:
+>
+> > Hi,
+> >
+> > My previous message doesn't seem to get through to the list. (Or it's
+> > just slow). So I'm repeating myself, and have added Nicola to CC.
+
+I didn't get Pekka's message too.
+
+> > Anyway I'm the author of the GTK2 patch. I have received additional
+> > patch from Jorgen Viksell, which implements Pango support (including
+> > AA-text) and other nice stuff.
+> >
+> > I just ported these patches against current CVS.
+>
+> I had done that meanwhile too, it's a pity that your message didn't
+> hit the dillo-dev list in time. Well it was just a few changes that
+> didn't take me long anyway...
+>
+> > Get yours from:
+> > http://kirjasto.org/medar/dillo/dillo_gtk2_2002-09-12.diff.gz
+
+So, will we have Dillo 0.6.7 for GTK2?
+
+Does Dillo correctly render Unicode with this patch (that's what Pango is
+for)?
+
+-- 
+Miernik _____________________________________
+/ /
+tel.: +48603070983 / / mailto:miernik@ct...
+__________________/___/ ICQ UIN: 4004001 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Nicola Girardi <nicola@g-...> - 2002-09-13 04:37
+
+Pekka Lampila wrote:
+
+> Hi,
+> 
+> My previous message doesn't seem to get through to the list. (Or it's
+> just slow). So I'm repeating myself, and have added Nicola to CC.
+> 
+> Anyway I'm the author of the GTK2 patch. I have received additional
+> patch from Jorgen Viksell, which implements Pango support (including
+> AA-text) and other nice stuff.
+> 
+> I just ported these patches against current CVS.
+
+I had done that meanwhile too, it's a pity that your message didn't
+hit the dillo-dev list in time. Well it was just a few changes that
+didn't take me long anyway...
+
+> Get yours from:
+> http://kirjasto.org/medar/dillo/dillo_gtk2_2002-09-12.diff.gz
+> 
+> There are surely many things left to do with GTK2-stuff. And I would
+> be pleased if someone did them :)
+
+I'm not familiar with GTK2 but these days I was seeking info about
+AA, which was, as I said, the primary aim in my GTK2 effort. Thanks
+to the guy who did it for me and to you merging his work with yours.
+
+> One cool thing would be implementing dynamical keybindings for menus,
+> with gtk_accel_map_load() etc.
+> 
+> Any questions? Just ask.
+> 
+> 
+> PS. Nicola: If this mail doesn't make it to the mailing list, could
+> you forward this to dillo-dev?
+
+I'm quoting the entire mail, just to be sure. :-) 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: <jbradford@di...> - 2002-09-12 14:21
+
+> FYI, you don't need to bother to CC me as I'm subscribed to this
+> list; thanks anyway.
+
+Sorry about that, it's a bad habbit picked up from the linux kernel dev list, where you tend to get CC'ed in on an entire thread once you've posted about it once :-)
+
+> > > > > If it's OK and nobody's working on it, I may try to do it myself;
+> > > > > with much emphasis on *try*.
+> > > > 
+> > > > Have a look at this thread on the mailing list:
+> > > > 
+> > > > http://www.geocrawler.com/archives/3/702/2002/6/0/8944485/
+> > > 
+> > > I got the patch, I'm browsing through it. The screenshot lets me
+> > > see that anti aliased fonts weren't used actually. I'd like to know
+> > > if the author of the patch is going to keep working on it.
+> > 
+> > It doesn't seem to have been updated for a few months.
+> 
+> I just updated it to work with the CVS version (still without AA),
+> but you're telling me (below) that the CVS version is outdated(?).
+
+Well, I'm not sure what is happening. The CVS server hasn't had anything updated on it for months, and there have been loads of patches sent to the mailing list, so maybe whoever is actually in charge of maintaining the CVS tree doesn't think the patches are ready yet. However, since there are quite a few trivial patches, I don't think that's the case, but when I enquired about it on this list, I got a message back that seemed to imply that the CVS server *was* up to date.
+
+So, does what will eventually become Dillo 0.6.7 exist in CVS already, or just as patches scattered around the mailing list archives? Is there a CVS server somewhere that is up to date, and we are just not seeing that at:
+
+http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/dillo/
+
+I personally think that it's time to commit the known working patches to CVS, and release version 0.6.7, but what do others think?
+
+By the way, I've found a bug in the view source dialogue, where occasionally text doesn't wrap on to new lines properly. I'm just trying to work out how to re-produce it reliably.
+
+John.
+
+> > > If he's not going to keep up with it, I'll try to start from his
+> > > patch and add anti-aliasing, but first I want to ask another
+> > > question: is there any hope that the GTK2 patch goes into CVS or
+> > > would I be going to maintain a separate patch all life long?
+> > 
+> > What is going on with the CVS server anyway?
+> > 
+> > I asked about it last month:
+> > 
+> > http://www.geocrawler.com/archives/3/702/2002/8/0/9397536/
+> > 
+> > but nothing here:
+> > 
+> > http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/dillo/
+> > 
+> > has been updated for months. 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Nicola Girardi <nicola@g-...> - 2002-09-12 13:31
+
+FYI, you don't need to bother to CC me as I'm subscribed to this
+list; thanks anyway.
+
+> > > > If it's OK and nobody's working on it, I may try to do it myself;
+> > > > with much emphasis on *try*.
+> > > 
+> > > Have a look at this thread on the mailing list:
+> > > 
+> > > http://www.geocrawler.com/archives/3/702/2002/6/0/8944485/
+> > 
+> > I got the patch, I'm browsing through it. The screenshot lets me
+> > see that anti aliased fonts weren't used actually. I'd like to know
+> > if the author of the patch is going to keep working on it.
+> 
+> It doesn't seem to have been updated for a few months.
+
+I just updated it to work with the CVS version (still without AA),
+but you're telling me (below) that the CVS version is outdated(?).
+
+> > If he's not going to keep up with it, I'll try to start from his
+> > patch and add anti-aliasing, but first I want to ask another
+> > question: is there any hope that the GTK2 patch goes into CVS or
+> > would I be going to maintain a separate patch all life long?
+> 
+> What is going on with the CVS server anyway?
+> 
+> I asked about it last month:
+> 
+> http://www.geocrawler.com/archives/3/702/2002/8/0/9397536/
+> 
+> but nothing here:
+> 
+> http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/dillo/
+> 
+> has been updated for months. 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Nicola Girardi <nicola@g-...> - 2002-09-11 20:05
+
+jbradford@di... wrote:
+
+> > If it's OK and nobody's working on it, I may try to do it myself;
+> > with much emphasis on *try*.
+> 
+> Have a look at this thread on the mailing list:
+> 
+> http://www.geocrawler.com/archives/3/702/2002/6/0/8944485/
+
+I got the patch, I'm browsing through it. The screenshot lets me
+see that anti aliased fonts weren't used actually. I'd like to know
+if the author of the patch is going to keep working on it.
+
+If he's not going to keep up with it, I'll try to start from his
+patch and add anti-aliasing, but first I want to ask another
+question: is there any hope that the GTK2 patch goes into CVS or
+would I be going to maintain a separate patch all life long?
+
+Thanks for the quick responses anyway. :-) 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: <jbradford@di...> - 2002-09-11 17:28
+
+> I'd just like to ask you if a switch to GTK 2 is planned; the only
+> reason why I'm asking this is because of anti aliased fonts, which
+> seem to me quite important.
+
+Plus, you get PANGO capabilities. I.E. Eastern fonts can be made to work easily.
+
+> If it's OK and nobody's working on it, I may try to do it myself;
+> with much emphasis on *try*.
+
+Have a look at this thread on the mailing list:
+
+http://www.geocrawler.com/archives/3/702/2002/6/0/8944485/
+
+it might be a good place to start.
+
+John. 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Chris Wareham <cwareham@bt...> - 2002-09-11 16:54
+
+Nicola Girardi wrote:
+> I'd just like to ask you if a switch to GTK 2 is planned; the only
+> reason why I'm asking this is because of anti aliased fonts, which
+> seem to me quite important.
+> 
+> If it's OK and nobody's working on it, I may try to do it myself;
+> with much emphasis on *try*.
+> 
+
+Someone posted a patch, or a link to a patch, which ported Dillo
+to GTK2. It was against the CVS version sometime after the last
+release, and doesn't apply cleanly to the current CVS version.
+If you poke through the mailing list archive, then you should
+be able to find the relevant post. I'm keeping my fingers crossed
+that the patch author might sort out the conflicts and post a
+new patch against the next stable release ...
+
+Chris 
+
+
+
+Re: [Dillo-dev]GTK 2
+
+From: Tomas Guemes <tomas@pa...> - 2002-09-11 16:42
+
+Hi Nicola,
+
+On Wed, 11 Sep 2002 16:49:21 +0200
+Nicola Girardi <nicola@g-...> wrote:
+
+> I'd just like to ask you if a switch to GTK 2 is planned; the only
+> reason why I'm asking this is because of anti aliased fonts, which
+> seem to me quite important.
+>
+> If it's OK and nobody's working on it, I may try to do it myself;
+> with much emphasis on *try*.
+> 
+> Thanks.
+> 
+
+There is a patch for GTK 2, i can't remember where you can get it but if
+you look into the list archive you will find the address.
+
+greetings 
+
+Tomas 
+
+
+
+[Dillo-dev]GTK 2
+
+From: Nicola Girardi <nicola@g-...> - 2002-09-11 16:29
+
+I'd just like to ask you if a switch to GTK 2 is planned; the only
+reason why I'm asking this is because of anti aliased fonts, which
+seem to me quite important.
+
+If it's OK and nobody's working on it, I may try to do it myself;
+with much emphasis on *try*.
+
+Thanks. 
+
+
+
+[Dillo-dev]dillo plugins ...
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-09-11 13:11
+
+Why not use dynamic loading ?
+
+fx. like octave functions written in c ?
+
+( dynamic binding is perhaps a better word .-) )
+
+One could still do the fork, but it would be much easier since it 
+would be possible to map callbacks and such fairly easily.
+
+Is this a 'dumb' idea or am I missing something ?
+
+I did some small tests and they seemed to work quite easily ?
+
+I was thinking of the problem of race conditions and such that was 
+mentioned previously, this should pretty much take care of that no ?
+
+/ Lars Segerlund. 
+
+
+
+[Dillo-dev]accessing yahoo/rediff/hotmail.
+
+From: Anish Somi <anishsomi@re...> - 2002-09-11 06:35
+
+Dillo is really a wonderful web browser. However I cannot access 
+emails from the following sites:
+rediff.com/yahoo.com/hotmail.com
+Is it because they use javascript and https? Any other wy to get 
+around it?
+-Regards Anurag 
+
+
+
+[Dillo-dev]Problem saving search on eBay
+
+From: Miernik <miernik@ct...> - 2002-09-09 08:33
+
+When I want to save a search on eBay, I get a page to input username &
+password. Whe I do that I get a page with URL:
+
+http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?AddSavedSearch&amp;savedsearch=http%3A%2F%2Fsearch.ebay.com%2Fsearch%2Fsearch.dll%3FGetResult%26st%3D2%26SortProperty%3DMetaEndSort%26query%3Dpci%2Bdvb%26srchdesc%3Dy%26ebaytag1%3Debayreg%26ht%3D1%26combine%3Dy&amp;domainname=&amp;attributestring=&amp;myfavlogin=0&amp;pass=ojSjnGog1aeA7Ef.li4T7/&amp;userid=miernikus
+
+(I've changed some characters in the encoded password before posting it
+here, as not to disclose my password).
+
+This page says:
+
+One of the parameters received was invalid for this function. This
+probably means that your browser had problems with the form or you invoked
+the function incorrectly.
+
+The tethereal log of this request is:
+
+Hypertext Transfer Protocol
+GET /aw-cgi/eBayISAPI.dll?AddSavedSearch&amp;savedsearch=http%3A%2F%2Fsearch.ebay.com%2Fsearch%2Fsearch.dll%3FGetResult%26st%3D2%26SortProperty%3DMetaEndSort%26query%3Dpci%2Bdvb%26srchdesc%3Dy%26ebaytag1%3Debayreg%26ht%3D1%26combine%3Dy&am
+Cache-Control: no-cache\r\n
+Pragma: no-cache\r\n
+Host: cgi1.ebay.com\r\n
+User-Agent: Dillo/0.6.6\r\n
+Cookie2: $Version="1"\r\n
+Cookie: keepmesignin=in; $Path=/; $Domain=.ebay.com; ebaysignin=in; $Path=/; $Domain=.ebay.com; nonsession=AQAAAAQAAAAIAAAAVAAAADkvfD05vKM9MDEwMzE1NDg3Mjl4NjFodHRwOi8vY2dpLmViYXkuY29tL3dzL2VCYXlJU0FQSS5kbGw/Vmlld0l0ZW0maXRlbT0xMzc5NTUwMTMy
+
+
+(The GET request got turncated here, probably by tethereal display, or my
+terminal).
+
+-- 
+Miernik _____________________________________
+/ /
+tel.: +48603070983 / / mailto:miernik@ct...
+__________________/___/ ICQ UIN: 4004001 
+
+
+
+Re: [Dillo-dev]Bug: sometimes adding spaces between parameters on eBay
+
+From: <jbradford@di...> - 2002-09-08 15:37
+
+> > Dillo works mostly OK on eBay, but sometimes I get a nasty bug, when it
+> > adds spaces between parameters when I click a link, like this:
+> > 
+> > http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?MakeTrack&item= 1379550132
+> 
+> The problem is that the source of the page looks like this :
+> 
+> http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?MakeTrack&item=
+> 1379550132
+> 
+> i.e. there is a RETURN and the RETURN gets translated into
+> a space. I haven't looked for why this happens, I only
+> noticed that, too, and found that reason. Maybe it helps
+> somebody to fix it :-)
+
+The solution is to ask the maintainer of the webpage to fix their incorrect HTML :-).
+
+I pointed a similar problem out to the people at http://www.hlj.com, and they fixed it within about a day, and thanked me for pointing it out! It is possible that other webmasters might not be as helpful, though.
+
+John. 
+
+
+
+Re: [Dillo-dev]Bug: sometimes adding spaces between parameters on eBay
+
+From: Andreas Schweitzer <Andreas.Schweitzer@hs...> - 2002-09-08 15:12
+
+Hi,
+
+> Dillo works mostly OK on eBay, but sometimes I get a nasty bug, when it
+> adds spaces between parameters when I click a link, like this:
+> 
+> http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?MakeTrack&item= 1379550132
+
+The problem is that the source of the page looks like this :
+
+http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?MakeTrack&item=
+1379550132
+
+i.e. there is a RETURN and the RETURN gets translated into
+a space. I haven't looked for why this happens, I only
+noticed that, too, and found that reason. Maybe it helps
+somebody to fix it :-)
+
+Cheers,
+Andreas
+
+-- 
+**************************** NEW ADDRESS ******************************
+Hamburger Sternwarte Universitaet Hamburg
+Gojenbergsweg 112 Tel. ++49 40 42891 4016
+D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 
+
+
+
+[Dillo-dev]Bug: sometimes adding spaces between parameters on eBay
+
+From: Miernik <miernik@ct...> - 2002-09-08 00:19
+
+Hi,
+
+Dillo works mostly OK on eBay, but sometimes I get a nasty bug, when it
+adds spaces between parameters when I click a link, like this:
+
+http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?MakeTrack&item= 1379550132
+
+There shouldn't be a space in the request between item= and 1379550132
+
+P.S. Is the work on frames support getting anything forward?
+
+-- 
+Miernik _____________________________________
+/ /
+tel.: +48603070983 / / mailto:miernik@ct...
+__________________/___/ ICQ UIN: 4004001 
+
+
+
+[Dillo-dev]plugins.
+
+From: Kyle Schmitt <azephrahel@ya...> - 2002-09-07 21:54
+
+Hi,
+From reading the posts to the mailing list, I get
+the
+idea that a plugin interface exists (well from you get
+the idea there must be at least 3 unfinished
+attempts),
+but that it hasn't been released in any way
+whatsoever.
+...but from the web pages I get the idea the plugin
+interface IS in there right now, but not being used...
+
+Soooo, is it there? Is it partiall there? Can a
+patch
+to enable at least simple simple plugins be
+downloaded?
+
+I don't particularly care if it changes so much that a
+plugin written for 6.6 wont' work with 6.7, I just
+wanna
+try writing some plugins.
+
+Thanks -- Kyle
+
+__________________________________________________
+Do You Yahoo!?
+Yahoo! Finance - Get real-time stock quotes
+http://finance.yahoo.com 
+
+
+
+[Dillo-dev]dillo (fwd)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-09-03 23:36
+
+---------- Forwarded message ----------
+Date: Thu, 29 Aug 2002 22:35:09 -0700
+From: David Tarsi <dtarsi@pr...>
+To: jcid@ma...
+Subject: dillo
+
+Hello ;
+My name is Dave. I have downloaded and installed Dillo on my Red Hat 7.3
+system running on a Compaq 2700T laptop. Wonderful!!!!!!!!!!
+Thank you!!!!!!! It's fast , it's simple , it's easy to install. Thank
+you so much for your efforts!!!!!.
+
+
+Sincerely , Dave T. 
+
diff --git a/old/oldmail/200210.txt b/old/oldmail/200210.txt
new file mode 100644
index 0000000..a2f12f6
--- /dev/null
+++ b/old/oldmail/200210.txt
@@ -0,0 +1,1951 @@
+Re: [Dillo-dev]dillo website problems
+
+From: Livio Baldini Soares <livio@im...> - 2002-10-28 22:04
+
+Hi all!
+
+Jorge Arellano Cid writes:
+> 
+> 
+> On Mon, 28 Oct 2002, Marc E. Fiuczynski wrote:
+> 
+> > The dillo website seems to be down. It's been down since the weekend (Sat?).
+> 
+> Yes, I can't access it either.
+
+It's back on-line now. 
+
+> I though it was something related to the presidential elections
+> and hope it starts working again soon.
+> 
+> Any clues?
+
+Most probably the server crashed during the weekend and it took them
+a while to get it up again (considering, I think, most of us were more
+interested in the election results than going to work :-P).
+
+> BTW (Livio): I sent you two emails, and saw your posting to the
+> list. Did you receive them?
+
+Yes. I didn't answer yet because I'm going to make the contacts you
+asked tonight (or possibly tomorrow), so I still don't have anything
+useful to report ;)
+
+best regards to all!
+
+-- 
+Livio <livio@im...> 
+
+
+
+Re: [Dillo-dev]dillo website problems
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-28 19:50
+
+On Mon, 28 Oct 2002, Marc E. Fiuczynski wrote:
+
+> The dillo website seems to be down. It's been down since the weekend (Sat?).
+
+Yes, I can't access it either.
+
+I though it was something related to the presidential elections
+and hope it starts working again soon.
+
+Any clues?
+
+BTW (Livio): I sent you two emails, and saw your posting to the
+list. Did you receive them?
+
+Something weird is happening and I don't know what it is...
+
+
+puzzled
+Jorge.- 
+
+
+
+Re: [Dillo-dev]memory leak?
+
+From: Livio Baldini Soares <livio@im...> - 2002-10-28 19:32
+
+Hello Marc,
+
+Marc E. Fiuczynski writes:
+> Hi,
+> 
+> I am using dillo as a rendering engine for my digital picture frame
+> project --- converting an old laptop into an asthetic looking picture frame.
+> Lacking client-side scripting support, I am using http-equiv="refresh" to
+> cycle through a set of pictures being served via WiFi from my thttpd server.
+> 
+> After running this for 24 hours, I noticed that the dillo memory footprint
+> slowly grows. The footprint seems to grow at 4K increments. My conjecture is
+> that dillo's cache or history is slowly growing.
+> 
+> Is there a convinient way to disable the cache and history support?
+
+Humm, I don't know about history support, it shouldn't be too hard
+to do, but I think that would be the "wrong" way to fix your problem.
+But about the infinite growing cache, I made a patch to control the
+size of Dillo's cache (even set it to zero - which in practise will
+disable it):
+
+http://www.ime.usp.br/~livio/dillo/patches/cache-size-limit.diff
+
+The patch _should_ apply to current release/CVS. Some files might
+shift a bit, but I think it still works. The option you'll be looking
+for in you dillorc is `cache_size`.
+
+But I'm not sure your memory increase is cache related. If you apply
+my patch it will enable an `about:cache` page where you can see what
+files are currently cached, and much of cache they are occupying
+(never forget to reload it to update the info! ;). Maybe what you see
+is just a memory leak in the code... There is a rather complete e-mail
+I've sent about this patch, back in June. It's here:
+http://so....net/mailarchive/message.php?msg_id=1642897
+
+good luck!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]dillo website problems
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-28 18:56
+
+The dillo website seems to be down. It's been down since the weekend (Sat?). 
+
+
+
+[Dillo-dev]memory leak?
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-28 18:53
+
+Hi,
+
+I am using dillo as a rendering engine for my digital picture frame
+project --- converting an old laptop into an asthetic looking picture frame.
+Lacking client-side scripting support, I am using http-equiv="refresh" to
+cycle through a set of pictures being served via WiFi from my thttpd server.
+
+After running this for 24 hours, I noticed that the dillo memory footprint
+slowly grows. The footprint seems to grow at 4K increments. My conjecture is
+that dillo's cache or history is slowly growing.
+
+Is there a convinient way to disable the cache and history support?
+
+Thanks,
+Marc 
+
+
+
+Re: [Dillo-dev]Hello!
+
+From: Carlos Daniel Ruvalcaba Valenzuela <clsdaniel@ya...> - 2002-10-28 01:15
+
+Great!, i was looking at some cached pages at google and it says the
+there is not much done on DPI, but now knowing that the framework is
+complete and working is a great advance, i'm very interested to see it,
+and do some testings.
+
+Also don't spect that i passed 2 years learning lazy C, no way i'm a
+serious programmer (or a freak it's much the same) in whatever the
+languaje is, specially C/C++, also these 2 years are with pure C apps, i
+have worked more with C libraries doing the heavy work for some VB
+programs, and mixed with some x86 and mmx assembly.
+
+Ok, i'll wait to see the tarball posted, and then i'll start coding with
+it.
+
+Anyway, anyone working on downloads?, i whould like to know if there is
+something already instead of trying to start from scratch some basic
+stuff for a download plugin.
+
+
+_________________________________________________________
+Do You Yahoo!?
+La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx 
+
+
+
+Re: [Dillo-dev]Hello!
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-27 23:20
+
+Carlos,
+
+> I would like to help to the dillo project, i want to work over the
+> current DPI1 plans, i coded a little implementation witch i'm testing
+> right now.
+
+Talking about DPI1, I just "finished" a dpi-program for
+bookmarks: 1690 lines that need some polishing, but that make an
+excellent example.
+
+The code is well commented but there's still a small doc to
+write before sharing it and starting coding dpis!
+
+I was waiting for someone from CIPSGA to write back to one of
+our multiple attempts to contact them :(, but if things continue
+this way I'll pack a tarball with it and put it on the HTTP
+server next week.
+
+If some more time passes by and we still have no answers, we'll
+have to search for another CVS server...
+
+
+Cheers
+Jorge.-
+
+PS: If somebody wrote me this weekend, please resend, I didn't
+receive but one email and that's rare. 
+
+
+
+[Dillo-dev]Hello!
+
+From: Carlos Daniel Ruvalcaba Valenzuela <clsdaniel@ya...> - 2002-10-27 20:51
+
+I would like to help to the dillo project, i want to work over the
+current DPI1 plans, i coded a little implementation witch i'm testing
+right now.
+
+_________________________________________________________
+Do You Yahoo!?
+La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx 
+
+
+
+Re: [Dillo-dev]CSS
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-10-24 19:30
+
+tor 2002-10-24 klockan 18.50 skrev Sebastian Geerken:
+> Hi!
+>=20
+> I haven't yet read the whole thread, but just want to give some hints:
+> I've written some notes to the list, they can be found at
+> <http://www.geocrawler.com/archives/3/702/2002/4/0/8538786/>. Furthermore=
+,
+> there are documentations on Dw within the tarball.
+>=20
+> Some more notes:
+>=20
+> * How a particular attribute is rendered, is mainly the task of Dw,
+> e.g. DwPage (most likely) must handle floats, fixed positions
+> etc. They are not covered by the posting mentioned above, and may be
+> implemented bit by bit.
+>=20
+> * Another complex task is CSS parsing and evaluation, handling
+> document elements, and synchronizing the whole thing. (On the other
+> hand, some extensions of Dw may also have an impact on this,
+> especially the document tree.)
+
+FWIW, I'm interested in writing the cascade and parsing parts. But it
+would help to know more about how the document tree will look like and
+how it interact with the cascade.
+
+Cheers,
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-10-24 17:02
+
+On Wed, Oct 23, 2002 at 12:58:52PM -0300, Jorge Arellano Cid wrote:
+> > [...]
+> > Yes, and probably on the content of the stream as well.
+> >
+> > Personally, I think that that is not something that should be added to
+> > Dillo, because the real solution is to fix the server.
+> 
+> That's the point.
+> 
+> Also, beacuase being as tolerant as IE or Mozilla or $* to
+> HTML, HTTP or .*P mistakes/errors/extensions/faults, only polutes
+> the web space rising the entry barriers for other SW to deal with
+> it.
+> 
+> Enough said.
+
+Sorry for adding this: This would not just extend HTTP, but *break*
+it. If the server does send a Content-Type, the browser MUST adhere to
+it. Any solution to "solve" this "problem" would make dillo's behavior
+simply incorrect, not only more tolerant. (Adding detection code for
+the case that no Content-Type is sent, would OTOH ok, see the HTTP
+specs.)
+
+Sebastian 
+
+
+
+[Dillo-dev]CSS
+
+From: Sebastian Geerken <sgeerken@st...> - 2002-10-24 16:50
+
+Hi!
+
+I haven't yet read the whole thread, but just want to give some hints:
+I've written some notes to the list, they can be found at
+<http://www.geocrawler.com/archives/3/702/2002/4/0/8538786/>. Furthermore,
+there are documentations on Dw within the tarball.
+
+Some more notes:
+
+* How a particular attribute is rendered, is mainly the task of Dw,
+e.g. DwPage (most likely) must handle floats, fixed positions
+etc. They are not covered by the posting mentioned above, and may be
+implemented bit by bit.
+
+* Another complex task is CSS parsing and evaluation, handling
+document elements, and synchronizing the whole thing. (On the other
+hand, some extensions of Dw may also have an impact on this,
+especially the document tree.)
+
+Floats are something mainly affecting DwPage, but also will probably
+make the document tree more complicated. I've until now collected some
+ideas; who is interested in an implementation, may ask me to write
+them down. Of course, be warned that it is no simple task.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]CSS: HTMLParser question - update
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-24 16:48
+
+Tony,
+
+You may like to read the "CSS Spec" link (I just added it to
+the home site). It has a lot of information about CSS and dillo
+internals.
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]CSS: HTMLParser question - update
+
+From: Lars Clausen <lrclause@cs...> - 2002-10-24 15:41
+
+On Wed, 23 Oct 2002, tony@we... wrote:
+> Sorry, small correction....
+>=20
+> absolute-positioned elements do not affect the normal text flow (text
+> simply flows under/over such elements) so the question about text
+> rendering as it's parsed is irrelevant as float:left and float:right (and
+> img align=3Dright) have to appear before the text that will subsequently
+> flow around them.
+>=20
+> OK first hurdle down, but there is still the problem of images in floated
+> elements being of undetermined dimensions (as they are being retrieved by
+> a separate thread at this point). So the problem is this...
+>=20
+> A piece of HTML is encountered like this... <img src=3D'wherever.png'
+> align=3Dright>loads of text goes here that now needs to flow around the
+> image that has just been loaded...
+>=20
+> The IMG tag will get pushed to the parsing stack, but are the image's
+> dimensions retrieved before the following words are rendered?
+>=20
+> There is no problem with <DIV> elements floated that include only text,
+> as the CSS2 spec says that the element's width should be provided in the
+> css and if not is left up to the browser to decide.
+>=20
+> Could someone give me a quick pointer as to wether the images dimensions
+> are loaded before subsequent text rendering, or if not, can it be?
+
+Dillo is heavily threaded, so you can't depend on the dimensions being
+loaded at any specific point. You should just assume a zero-width picture
+until you know the dimensions, at which point you'll need to re-render.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]CSS: HTMLParser question - update
+
+From: Tony <dillo@we...> - 2002-10-24 07:54
+
+Sorry, small correction....
+
+absolute-positioned elements do not affect the normal text flow (text simply flows under/over such elements) so the question about text rendering as it's parsed is irrelevant as float:left and float:right (and img align=right) have to appear before the text that will subsequently flow around them.
+
+OK first hurdle down, but there is still the problem of images in floated elements being of undetermined dimensions (as they are being retrieved by a separate thread at this point). So the problem is this...
+
+A piece of HTML is encountered like this...
+<img src='wherever.png' align=right>loads of text goes here that now needs to flow around the image that has just been loaded...
+
+The IMG tag will get pushed to the parsing stack, but are the image's dimensions retrieved before the following words are rendered?
+
+There is no problem with <DIV> elements floated that include only text, as the CSS2 spec says that the element's width should be provided in the css and if not is left up to the browser to decide.
+
+Could someone give me a quick pointer as to wether the images dimensions are loaded before subsequent text rendering, or if not, can it be?
+
+
+thanks 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: Geoff Lane <zzassgl@tw...> - 2002-10-24 07:38
+
+> In fact, this is not a simple case. Dillo has code for autodetecting 
+> content type when content-type header is missing. This does not seem
+> to be a case here - application/octet-stream is valid content type and 
+> means something for what browser may prompt to download but should not 
+> try to show it by itself. Mozilla and IE probably looked file extension, 
+> but this kind of behavior is imho problematic - if you really want user 
+> to be prompted for download and configure web server to send 
+> application/octet-stream content-type but web browser tries to show it 
+> anyway because file extension, then this is not a wanted behavior. It is 
+> just guessing.
+
+While developing a web application for downloading data to client PCs I had
+to investigate the behaviour of various browsers to discover a common method
+to download the data (which happened to be comma seperated values.) For
+all but IE the browser accepted application/octet-stream and displayed the
+usually SaveFile dialog. IE ignored application/octet-stream and started up
+a spread sheet to display the data. In the end I had to create a new x-
+MIME type to ensure that IE never assumed it knew better than the server.
+
+From experimentation and some info I found on microsoft's web site I would
+say that IE will ignore both MIME and name suffix if it sees data it
+_thinks_ it can display or execute.
+
+This kind of policy, of course, just perpetuates bad server configurations.
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+A single fact can spoil a good argument. 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: Geoff Lane <zzassgl@tw...> - 2002-10-24 07:22
+
+> 
+> > So is the problem with thttpd? Why is it that mozilla and IE have no problem
+> > with this? Do they "guess" what the content type is based on the filename?
+> 
+> Yes, and probably on the content of the stream as well.
+> 
+> Personally, I think that that is not something that should be added to
+> Dillo, because the real solution is to fix the server.
+> 
+
+Recently I had reason to actually check the true contents of a large number
+of GIF files obtained from the web (and no, they were not porn :-)) Around
+80% were in fact JPG files. All the mainstream browsers seem to check the
+file contents signatures (similar to the file command.) IE will agressively
+search for content that it conciders displayable and/or executable no matter
+what MIME information is supplied (which led to the famous security problem
+cause by JavaScript hidden in the GIF comment field.)
+
+It's a sad state of affairs.
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\ 
+
+
+
+Re: [Dillo-dev]CSS: HTMLParser question
+
+From: Paul Chamberlain <tif@ti...> - 2002-10-24 03:08
+
+Tony wrote:
+> If the page text is being rendered as it is encountered
+> (as suspected) then I doubt CSS (or for that matter,
+> even an align=right img tag) can be implemented in the
+> code's current form. For example, the ending paragraph
+> may contain a <DIV class that positions it at the top...
+
+For an example of a truly whacked page which dillo
+doesn't handle well at all, go to:
+
+http://www.apaaustin.com/rost204r.htm
+
+Whatever was used to create this page went out of it's
+way to be as confusing as possible.
+--
+Paul Chamberlain, tif@ti... 
+
+
+
+Re: [Dillo-dev]CSS: HTMLParser question
+
+From: <livio@im...> - 2002-10-23 20:37
+
+Hi Tony,
+
+Tony writes:
+> Hi,
+> 
+> Could someone answer me a quick question about the HTML parsing process please....
+> 
+> It appears from the docs that the style info for text that is to be rendered is held in a parsing stack, which is pushed each time a new tag arrives and subsequently popped when the tag is closed. From this, can I infer that html page text is being rendered as it is being received? or is rendering delayed until the complete page has been read and the parsing stack built?
+
+The page is rendered during download.
+
+> If the page text is being rendered as it is encountered (as suspected) then I doubt CSS (or for that matter, even an align=right img tag) can be implemented in the code's current form. For example, the ending paragraph may contain a <DIV class that positions it at the top of the page, and it's width/height may be dependant on an image that hasn't been loaded by the time the first few paragraphs have been rendered.
+
+Hummm, so? The page is just re-rendered, like it is today. If info
+about an image is not downloaded yet the page is rendered in a certain
+way, and after the info (width and height) is received it is
+re-rendered. Same goes for tables and other stuff.. 
+
+Try using a slow connection on a slow site. Watch Dillo (or even
+Mozilla, Opera or Konqueror for that matter) and see how the rendering
+"evolves" during download. Of course the objects are pushed about the
+page until you download the entire page (and info about other
+elements, like images).
+
+The only other way I see of doing this is to do what Netscape 4
+did. Download enough info to determine what the page layout will be
+and only then render it. In my opinion that's just horrible for the
+user. I _really_ want to see the page during download, _even_ if the
+layout keeps "shifting" about.
+
+To sum it up, I think rendering at download-time is very adequate
+and imposes no barrier to implementing CSS.
+
+Cheers!
+
+-- 
+Livio <livio@im...> 
+
+
+
+[Dillo-dev]CSS: HTMLParser question - update
+
+From: Tony <tony@we...> - 2002-10-23 20:33
+
+Sorry, small correction....
+
+absolute-positioned elements do not affect the normal text flow (text simply flows under/over such elements) so the question about text rendering as it's parsed is irrelevant as float:left and float:right (and img align=right) have to appear before the text that will subsequently flow around them.
+
+OK first hurdle down, but there is still the problem of images in floated elements being of undetermined dimensions (as they are being retrieved by a separate thread at this point). So the problem is this...
+
+A piece of HTML is encountered like this...
+<img src='wherever.png' align=right>loads of text goes here that now needs to flow around the image that has just been loaded...
+
+The IMG tag will get pushed to the parsing stack, but are the image's dimensions retrieved before the following words are rendered?
+
+There is no problem with <DIV> elements floated that include only text, as the CSS2 spec says that the element's width should be provided in the css and if not is left up to the browser to decide.
+
+Could someone give me a quick pointer as to wether the images dimensions are loaded before subsequent text rendering, or if not, can it be?
+
+
+thanks 
+
+
+
+[Dillo-dev]CSS: HTMLParser question
+
+From: Tony <tony@we...> - 2002-10-23 20:17
+
+Hi,
+
+Could someone answer me a quick question about the HTML parsing process please....
+
+It appears from the docs that the style info for text that is to be rendered is held in a parsing stack, which is pushed each time a new tag arrives and subsequently popped when the tag is closed. From this, can I infer that html page text is being rendered as it is being received? or is rendering delayed until the complete page has been read and the parsing stack built?
+
+If the page text is being rendered as it is encountered (as suspected) then I doubt CSS (or for that matter, even an align=right img tag) can be implemented in the code's current form. For example, the ending paragraph may contain a <DIV class that positions it at the top of the page, and it's width/height may be dependant on an image that hasn't been loaded by the time the first few paragraphs have been rendered.
+
+Could someone verify wether the text rendering is done during page content parsing or deferred please?
+
+thanks 
+
+
+
+RE: [Dillo-dev]Silly problem
+
+From: madis <madis@cy...> - 2002-10-23 18:17
+
+On Wed, 23 Oct 2002, Marc E. Fiuczynski wrote:
+
+> While I agree that the fix should be at the server side, I don't think it is
+> prudent for dillo to not work in simple cases. I doubt that dillo's
+> following is so huge that by not being so tollerant as other web browsers it
+> will change the implementation of today's web servers.
+
+In fact, this is not a simple case. Dillo has code for autodetecting 
+content type when content-type header is missing. This does not seem
+to be a case here - application/octet-stream is valid content type and 
+means something for what browser may prompt to download but should not 
+try to show it by itself. Mozilla and IE probably looked file extension, 
+but this kind of behavior is imho problematic - if you really want user 
+to be prompted for download and configure web server to send 
+application/octet-stream content-type but web browser tries to show it 
+anyway because file extension, then this is not a wanted behavior. It is 
+just guessing.
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]plans for CSS support?
+
+From: Tony <dillo@we...> - 2002-10-23 16:56
+
+I don't know how feasable it will be to retro-fit CSS to the code. Certainly if I was starting from scratch then i'd make sure every HTML 'object' (be it an image, table, H1 or body piece of text, etc) had css properties (padding, margin, colour, etc) and then alter those default CSS properties with any stylesheet information that was encountered. Certainly the img align=right html tag is really a CSS property. I will have a look at the code and see if I can get my head around it. In the meantime if anyone else is interested in helping please say so.
+
+Tony
+
+> There have been mumblings of CSS, but I don't think anybody took it upon
+> themselves. One thing that I'd particularly like to see, that is (I
+> believe) part of CSS, is image (object) align, i.e. text flowing around
+> images. Many pages depend on this, either as CSS or in the deprecated <img
+> align=left> form. 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: <Juergen.Daubert@t-...> - 2002-10-23 16:56
+
+On Wed, 23 Oct 2002 08:38:15 -0700 "Marc E. Fiuczynski"
+<mef@cs.washington.edu> wrote:
+
+[...] 
+
+> So is the problem with thttpd? 
+
+Maybe you should upgrade thttpd to 2.21 or even 2.23beta1. I've no problems 
+viewing your test page with both of versions of thttpd.
+
+regards
+Jürgen 
+
+-- 
+juergen.daubert@t-... 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: <jbradford@di...> - 2002-10-23 16:50
+
+> While I agree that the fix should be at the server side, I don't think it is
+> prudent for dillo to not work in simple cases. I doubt that dillo's
+> following is so huge that by not being so tollerant as other web browsers it
+> will change the implementation of today's web servers.
+
+My reasons for not wanting it in Dillo are that it will bloat the
+code, and also it means looking at each stream to decide what it is,
+instead of just looking at the content type. This would harm it's use
+in embedded systems.
+
+There is always the option of using a separate proxy application to
+re-write the content type headers.
+
+> My "primary" interest in using dillo is the fact that it is small. This is
+> because I have a need for a free small memory footprint browser for my
+> application (converting an old pentium laptop to a digital picture
+> frame).
+
+There was an article on Slashdot about that a while ago - if you
+haven't seen it, it might be worth searching for it.
+
+> To be totally honest (and risking to alienate people on this list), I'd
+> switch to another web browser in a heart beat if it worked with more of
+> today's web servers and html content (e.g., supporting client side
+> scripting, style sheets, etc.).
+
+Hmmm, why are you using a web browser in the picture frame
+application, anyway? Why not just use a framebuffer picture viewer?
+
+John. 
+
+
+
+RE: [Dillo-dev]Silly problem
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-23 16:22
+
+Jorge & John,
+
+While I agree that the fix should be at the server side, I don't think it is
+prudent for dillo to not work in simple cases. I doubt that dillo's
+following is so huge that by not being so tollerant as other web browsers it
+will change the implementation of today's web servers.
+
+My "primary" interest in using dillo is the fact that it is small. This is
+because I have a need for a free small memory footprint browser for my
+application (converting an old pentium laptop to a digital picture frame).
+To be totally honest (and risking to alienate people on this list), I'd
+switch to another web browser in a heart beat if it worked with more of
+today's web servers and html content (e.g., supporting client side
+scripting, style sheets, etc.).
+
+Cheers,
+Marc
+
+-----Original Message-----
+From: dillo-dev-admin@li...
+[mailto:dillo-dev-admin@li...]On Behalf Of Jorge
+Arellano Cid
+Sent: Wednesday, October 23, 2002 8:59 AM
+To: Dillo mailing list
+Subject: Re: [Dillo-dev]Silly problem
+
+
+
+
+On Wed, 23 Oct 2002 jbradford@di... wrote:
+
+> > So is the problem with thttpd? Why is it that mozilla and IE have no
+problem
+> > with this? Do they "guess" what the content type is based on the
+filename?
+>
+> Yes, and probably on the content of the stream as well.
+>
+> Personally, I think that that is not something that should be added to
+> Dillo, because the real solution is to fix the server.
+
+That's the point.
+
+Also, beacuase being as tolerant as IE or Mozilla or $* to
+HTML, HTTP or .*P mistakes/errors/extensions/faults, only polutes
+the web space rising the entry barriers for other SW to deal with
+it.
+
+Enough said.
+
+Cheers
+Jorge.-
+
+
+
+
+-------------------------------------------------------
+This s...net email is sponsored by: Influence the future
+of Java(TM) technology. Join the Java Community
+Process(SM) (JCP(SM)) program now.
+http://ads.so....net/cgi-bin/redirect.pl?sunm0002en
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-23 16:05
+
+On Wed, 23 Oct 2002 jbradford@di... wrote:
+
+> > So is the problem with thttpd? Why is it that mozilla and IE have no problem
+> > with this? Do they "guess" what the content type is based on the filename?
+>
+> Yes, and probably on the content of the stream as well.
+>
+> Personally, I think that that is not something that should be added to
+> Dillo, because the real solution is to fix the server.
+
+That's the point.
+
+Also, beacuase being as tolerant as IE or Mozilla or $* to
+HTML, HTTP or .*P mistakes/errors/extensions/faults, only polutes
+the web space rising the entry barriers for other SW to deal with
+it.
+
+Enough said.
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: <jbradford@di...> - 2002-10-23 15:43
+
+> So is the problem with thttpd? Why is it that mozilla and IE have no problem
+> with this? Do they "guess" what the content type is based on the filename?
+
+Yes, and probably on the content of the stream as well.
+
+Personally, I think that that is not something that should be added to
+Dillo, because the real solution is to fix the server.
+
+John. 
+
+
+
+RE: [Dillo-dev]nanoGTK ?
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-23 15:36
+
+I've forgotten about TinyX on the iPaq. Saw a demonstration of dillo on ipaq
+(as part of the "familiar" linux distribution).
+
+-----Original Message-----
+From: dillo-dev-admin@li...
+[mailto:dillo-dev-admin@li...]On Behalf Of Jorge
+Arellano Cid
+Sent: Wednesday, October 23, 2002 6:09 AM
+To: Dillo mailing list
+Subject: Re: [Dillo-dev]nanoGTK ?
+
+
+
+Hi!
+
+On Tue, 22 Oct 2002, Ross J. Reedstrom wrote:
+
+> I use dillo on my ipaq (with linux installed), which uses the tinyX build
+> (AFAIK). Works fine.
+
+Can anyone confirm that please?
+(Dillo working on tinyX)
+
+
+Cheers
+Jorge.-
+
+
+
+-------------------------------------------------------
+This s...net email is sponsored by: Influence the future
+of Java(TM) technology. Join the Java Community
+Process(SM) (JCP(SM)) program now.
+http://ads.so....net/cgi-bin/redirect.pl?sunm0002en
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+RE: [Dillo-dev]Silly problem
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-23 15:35
+
+Hi Jorge,
+
+So is the problem with thttpd? Why is it that mozilla and IE have no problem
+with this? Do they "guess" what the content type is based on the filename?
+
+Marc
+
+-----Original Message-----
+From: dillo-dev-admin@li...
+[mailto:dillo-dev-admin@li...]On Behalf Of Jorge
+Arellano Cid
+Sent: Wednesday, October 23, 2002 6:44 AM
+To: Dillo mailing list
+Subject: Re: [Dillo-dev]Silly problem
+
+
+
+Marc,
+
+> Hi,
+>
+> When I open an HTML page with a JPEG image source, dillo says that it
+cannot
+> open up the application/octet-stream MIME type. Well, I should send you
+the
+> exact error message in a later message.
+>
+> The html page is simply contains and is being served from a thttpd version
+> 2.1 server:
+>
+> <HTML>
+> <HEAD>
+> </HEAD>
+> <BODY>
+> <IMG src="pics/foo.jpg">
+> </BODY>
+> </HTML>
+>
+> There is no problem in opening this page from Internet Explorer or Mozilla
+> from the thttpd server.
+>
+> Any insights?
+
+Yes, the content/type should have been either:
+
+- image/jpeg
+- image/jpg
+- image/pjpeg
+
+not "application/octet-stream".
+
+You can read the HTTP RFCs for details...
+
+Cheers
+Jorge.-
+
+
+
+
+
+-------------------------------------------------------
+This s...net email is sponsored by: Influence the future
+of Java(TM) technology. Join the Java Community
+Process(SM) (JCP(SM)) program now.
+http://ads.so....net/cgi-bin/redirect.pl?sunm0002en
+
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+Re: [Dillo-dev]Silly problem
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-23 13:46
+
+Marc,
+
+> Hi,
+>
+> When I open an HTML page with a JPEG image source, dillo says that it cannot
+> open up the application/octet-stream MIME type. Well, I should send you the
+> exact error message in a later message.
+>
+> The html page is simply contains and is being served from a thttpd version
+> 2.1 server:
+>
+> <HTML>
+> <HEAD>
+> </HEAD>
+> <BODY>
+> <IMG src="pics/foo.jpg">
+> </BODY>
+> </HTML>
+>
+> There is no problem in opening this page from Internet Explorer or Mozilla
+> from the thttpd server.
+>
+> Any insights?
+
+Yes, the content/type should have been either:
+
+- image/jpeg
+- image/jpg
+- image/pjpeg
+
+not "application/octet-stream".
+
+You can read the HTTP RFCs for details...
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]plans for CSS support?
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-23 13:44
+
+Tony,
+
+> Firstly, respect for creating a very useful lightweight browser...
+
+Thanks.
+
+> Do you have any plans for adding CSS support?
+
+Yes, Sebastian developed a nice document on how a possible
+implementation could go. As he is very busy now, it's waiting for
+some "man-months" to push it forward.
+
+> If not it is something i would consider contributing to myself,
+> but im so pushed for time i don't know what i can dedicate towards it.
+
+Hmmm, this is not a trivial task. If you have a suitable amount
+of time (this depends on your understanding of GTK+ and Dw),
+please ask me back and I'll send you the doc.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]nanoGTK ?
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-23 13:44
+
+Hi!
+
+On Tue, 22 Oct 2002, Ross J. Reedstrom wrote:
+
+> I use dillo on my ipaq (with linux installed), which uses the tinyX build
+> (AFAIK). Works fine.
+
+Can anyone confirm that please?
+(Dillo working on tinyX)
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]Re: Dillo-dev -- confirmation of subscription -- request 259643
+
+From: Thomas White <taw27@ca...> - 2002-10-23 10:21
+
+On Wed, 23 Oct 2002 03:20:47 -0700
+dillo-dev-request@li... wrote:
+
+> Dillo-dev -- confirmation of subscription -- request 259643
+> 
+> We have received a request from 131.111.195.177 for subscription of
+> your email address, <taw27@ca...>, to the
+> dillo-dev@li... mailing list. To confirm the request,
+> please send a message to dillo-dev-request@li..., and
+> either:
+> 
+> - maintain the subject line as is (the reply's additional "Re:" is
+> ok),
+> 
+> - or include the following line - and only the following line - in the
+> message body: 
+> 
+> confirm 259643
+> 
+> (Simply sending a 'reply' to this message should work from most email
+> interfaces, since that usually leaves the subject line in the right
+> form.)
+> 
+> If you do not wish to subscribe to this list, please simply disregard
+> this message. Send questions to
+> dillo-dev-admin@li....
+
+
+______________________
+Thomas White
+Downing College
+Cambridge 
+
+
+
+Re: [Dillo-dev]nanoGTK ?
+
+From: Ross J. Reedstrom <reedstrm@ri...> - 2002-10-23 03:05
+
+On Tue, Oct 22, 2002 at 07:06:06PM -0700, Marc E. Fiuczynski wrote:
+> Hi,
+> 
+> I am interested in this, too, or any graphics platform that has a small
+> footprint. For example, has anyone used dilly with TinyX (or SmallX), which
+> is a small footprint version of the XFree86 Server? Alternatively, has
+> anyone run dillo ontop of gtk+fb, which is a version of GTK+ that uses the
+> framebuffer directly?
+
+I use dillo on my ipaq (with linux installed), which uses the tinyX build
+(AFAIK). Works fine.
+
+Ross
+-- 
+Ross Reedstrom, Ph.D. reedstrm@ri...
+Executive Director phone: 713-348-6166
+Gulf Coast Consortium for Bioinformatics fax: 713-348-6182
+Rice University MS-39
+Houston, TX 77005 
+
+
+
+[Dillo-dev]portuguese dillo man page
+
+From: <joaopaulo99@te...> - 2002-10-23 02:56
+
+i translate dillo man page, but i just translate the doc, doesn't create 
+the man page.
+i can study how to do it, it's necessary ?
+the transleted file is here:
+
+http://www.rootshell.be/~blackbox/dillo/man-page_dillo 
+
+
+
+Re: [Dillo-dev]plans for CSS support?
+
+From: Lars Clausen <lrclause@cs...> - 2002-10-23 02:28
+
+On Wed, 23 Oct 2002, dillo@we... wrote:
+> Hi,
+>=20
+> Firstly, respect for creating a very useful lightweight browser...
+> Do you have any plans for adding CSS support?
+>=20
+> If not it is something i would consider contributing to myself, but im so
+> pushed for time i don't know what i can dedicate towards it.
+
+There have been mumblings of CSS, but I don't think anybody took it upon
+themselves. One thing that I'd particularly like to see, that is (I
+believe) part of CSS, is image (object) align, i.e. text flowing around
+images. Many pages depend on this, either as CSS or in the deprecated <img
+align=3Dleft> form.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]plans for CSS support?
+
+From: Tony <dillo@we...> - 2002-10-23 02:13
+
+Hi,
+
+Firstly, respect for creating a very useful lightweight browser...
+Do you have any plans for adding CSS support?
+
+If not it is something i would consider contributing to myself, but im so pushed for time i don't know what i can dedicate towards it.
+
+regards,
+Tony 
+
+
+
+[Dillo-dev]Re: Dillo-dev -- confirmation of subscription -- request 185009
+
+From: Tony <dillo@we...> - 2002-10-23 02:10
+
+On Tue, 22 Oct 2002 19:08:18 -0700
+dillo-dev-request@li... wrote:
+
+> Dillo-dev -- confirmation of subscription -- request 185009
+> 
+> We have received a request from 80.193.224.154 for subscription of
+> your email address, <dillo@we...>, to the
+> dillo-dev@li... mailing list. To confirm the request,
+> please send a message to dillo-dev-request@li..., and
+> either:
+> 
+> - maintain the subject line as is (the reply's additional "Re:" is
+> ok),
+> 
+> - or include the following line - and only the following line - in the
+> message body: 
+> 
+> confirm 185009
+> 
+> (Simply sending a 'reply' to this message should work from most email
+> interfaces, since that usually leaves the subject line in the right
+> form.)
+> 
+> If you do not wish to subscribe to this list, please simply disregard
+> this message. Send questions to
+> dillo-dev-admin@li....
+> 
+> 
+
+
+
+RE: [Dillo-dev]nanoGTK ?
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-23 02:03
+
+Hi,
+
+I am interested in this, too, or any graphics platform that has a small
+footprint. For example, has anyone used dilly with TinyX (or SmallX), which
+is a small footprint version of the XFree86 Server? Alternatively, has
+anyone run dillo ontop of gtk+fb, which is a version of GTK+ that uses the
+framebuffer directly?
+
+Thanks,
+Marc
+
+-----Original Message-----
+From: dillo-dev-admin@li...
+[mailto:dillo-dev-admin@li...]On Behalf Of Daniel
+Stenberg
+Sent: Thursday, October 17, 2002 5:39 AM
+To: Dillo-dev@li...
+Subject: [Dillo-dev]nanoGTK ?
+
+
+Hey Dillo'ers
+
+Anyone tried Dillo on nanoGTK/Microwindows ? If so, care to share some
+experiences?
+
+nanoGTK is here: http://www.emsoftltd.com/index.php?action=nanogtk
+
+--
+Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
+ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
+
+
+
+-------------------------------------------------------
+This s...net email is sponsored by: viaVerio will pay you up to
+$1,000 for every account that you consolidate with us.
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]Silly problem
+
+From: Marc E. Fiuczynski <mef@cs...> - 2002-10-23 02:03
+
+Hi,
+
+When I open an HTML page with a JPEG image source, dillo says that it cannot
+open up the application/octet-stream MIME type. Well, I should send you the
+exact error message in a later message.
+
+The html page is simply contains and is being served from a thttpd version
+2.1 server:
+
+<HTML>
+<HEAD>
+</HEAD>
+<BODY>
+<IMG src="pics/foo.jpg">
+</BODY>
+</HTML>
+
+There is no problem in opening this page from Internet Explorer or Mozilla
+from the thttpd server.
+
+Any insights?
+
+Thanks,
+Marc 
+
+
+
+Re: [Dillo-dev]what's happening?
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-22 21:13
+
+Melvin,
+
+> > Ah, last but not the least, Dillo is applying at linuxfund for
+> > some funds, so you may help the project by visiting:
+> >
+> > http://www.linuxfund.org
+> >
+> > and _voting_ some pesos from there.
+>
+> Done. The site does not explain all the rules on how to vote (maximum pesos,
+> etc). How much is the maximum amount we can give for one project? (2000 did not
+> work, 1000 worked, then I could add 500 more. Is 1500 the maximum?)
+
+I've read the site a couple of times, and still have a bunch of
+doubts (as when does this funding round end?).
+
+But yes, 1500 is the current maximum amount.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]what's happening?
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-10-22 16:48
+
+Hi Jorge,
+
+on Sun, 20 Oct 2002 23:50:58 -0300 (CLST)
+Jorge Arellano Cid <jcid@so...> wrote:
+
+> Ah, last but not the least, Dillo is applying at linuxfund for
+> some funds, so you may help the project by visiting:
+> 
+> http://www.linuxfund.org
+> 
+> and _voting_ some pesos from there.
+
+Done. The site does not explain all the rules on how to vote (maximum pesos,
+etc). How much is the maximum amount we can give for one project? (2000 did not
+work, 1000 worked, then I could add 500 more. Is 1500 the maximum?)
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]what's happening?
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-10-21 02:55
+
+Madis,
+
+>
+> ... with the dpi1 and are there any release expected to come any time
+> soon?
+
+Things are quiet mainly because Sebastian is under a heavy work
+load, Livio is very busy too, and I'm still trying to settle
+to keep things rolling.
+
+Anyway, in the mean time, I've managed to develop 1400 lines of
+a dpi server (to illustrate how the whole thing works), what it
+can do, and what it does now.
+
+This is certainly good news!
+
+BTW, has someone started making a dpi-server?
+
+I'm trying hard to get the CIPSGA CVS set, but if it doesn't
+happen soon, I'll fall back to the tarball scheme, at least until
+I find a good solution.
+
+As for the release, once the dpi updates go to CVS, it will be
+a matter of polishing, integrating some patches, getting sure it
+works solid, and 0.7.0 will be ready.
+
+Ah, last but not the least, Dillo is applying at linuxfund for
+some funds, so you may help the project by visiting:
+
+http://www.linuxfund.org
+
+and _voting_ some pesos from there.
+
+Note: this is not a real money transfer, but virtual money
+that's assigned to the project. When the round ends, the internal
+"board" considers the highest voted projects and decides how much
+real money to grant.
+
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]patched dillo sourceforge cvs version
+
+From: madis <madis@cy...> - 2002-10-21 00:24
+
+http://www.zone.ee/myzz/dillo/dillo-x.html
+
+should be fairly stable, at least it haven't crashed couple of month's and 
+i use this as my main web browser...
+
+-- 
+mzz 
+
+
+
+[Dillo-dev]what's happening?
+
+From: madis <madis@cy...> - 2002-10-20 11:52
+
+... with the dpi1 and are there any release expected to come any time 
+soon?
+
+-- 
+mzz 
+
+
+
+[Dillo-dev]nanoGTK ?
+
+From: Daniel Stenberg <daniel@ha...> - 2002-10-17 12:39
+
+Hey Dillo'ers
+
+Anyone tried Dillo on nanoGTK/Microwindows ? If so, care to share some
+experiences?
+
+nanoGTK is here: http://www.emsoftltd.com/index.php?action=nanogtk
+
+-- 
+Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
+ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol 
+
+
+
+Re: [Dillo-dev]Re: local browsing (offline) patch updated
+
+From: Grigory Bakunov <black@as...> - 2002-10-16 11:05
+
+On Tue, 15 Oct 2002 19:36:32 -0700
+Kelson Vibber <kelson@po...> wrote:
+
+KV> Seems to work okay here. I've updated the RedHat 7.3 Dillo 0.6.6 RPM
+KV> to 
+KV> include the new all-in-one patch.
+
+KV> I do intend at some point to try out Tor's Xft patch, but the one time
+KV> I tried 
+KV> building it I was in too much of a hurry to do more than see if it
+KV> compiled. 
+KV> Eventually I'll set aside the time to mess with it.
+
+KV> http://www.hyperborea.org/software/
+
+
+Hmm. most of RedHat packages include localization patches.
+Why you don't include my localization patches for dillo ? :)
+http://bobuk.ipost.ru/packages/dillo/index.html
+
+
+
+
+
+........................................................................
+IRC: irc.openprojects.net #asplinux Grigory Bakunov
+EMAIL: black@as... ASPLinux Support Team
+ICQ: 51369901 http://www.asplinux.ru
+-----BEGIN GEEK CODE BLOCK-----
+GCS/MU d-(--) s:- a- C+++>++$ UBLAVSX+++$ P+ L++++$ E++$ W++ N+>- o? K?
+w-- O- M V-(--) PS+ PE+ !Y PGP+>++++ t+ 5++ X+++ R+++ tv+>-- b+++ ?DI D+
+G++ e>++$ h- r++ y+ z++(+++)
+------END GEEK CODE BLOCK------ 
+
+
+
+[Dillo-dev]Re: local browsing (offline) patch updated
+
+From: Kelson Vibber <kelson@po...> - 2002-10-16 02:36
+
+Seems to work okay here. I've updated the RedHat 7.3 Dillo 0.6.6 RPM to=20
+include the new all-in-one patch.
+
+I do intend at some point to try out Tor's Xft patch, but the one time I =
+tried=20
+building it I was in too much of a hurry to do more than see if it compil=
+ed. =20
+Eventually I'll set aside the time to mess with it.
+
+http://www.hyperborea.org/software/
+
+--=20
+Kelson Vibber
+kelson@po...
+http://www.hyperborea.org/
+Creative Writing - Photography - The Flash 
+
+
+
+[Dillo-dev]local browsing (offline) patch updated
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-10-14 22:12
+
+Hi,
+
+I updated my localhost-only browsing (aka offline mode) such it is now possible
+to switch the offline mode on and off while browsing (menu File->Work offline
+can be toggled). It is still possible to start directly in offline mode with
+the "-l" command line option. The patch (6k) is at
+
+http://melvin.hadasht.free.fr/home/dillo/local/
+
+The patch adds two new files (offline.[ch]) and modifies src/Makefile.am, so you
+may need to run automake etc.
+
+The objective of this patch is primarily to make the mail client Sylpheed-Claws
+render HTML mails in a secure way while providing the possibility to switch to
+online mode when the user wants it (patches for Sylpheed-Claws are on the same
+site).
+
+From the technical point of view, this patch works a bit differently than the
+last one. Instead of storing a 0 (null) IP in the cache to disallow
+non-localhost browsing, it now stores the correct IP but returns 0 (null) to the
+caller only when offline browsing is on. This saves a DNS lookup when offline
+mode is switched off and seems to be more logical (even if that means two places
+to patch instead of only one).
+
+Another difference is that the offline state is no more stored in dns.[ch]
+but in new files called offline.[ch]. These files are also responsible for
+setting the mode and for updating the menus of the different browser window
+(so the state offline on/off is consistent across windows.). 
+
+(With this scheme, it could be also possible to create a blacklist of hosts
+that should never be accessed. But that would need more work...)
+
+PS: IIRC, I read on the ML that the developers are continuing developing on a
+CVS repository that is not open to the public because of problems with CVS
+hosting. Is it possible to have a newer cvs snapshot (tar ball) downloadable
+from the web site so contributers can work on more uptodate versions? I hope
+the Dillo project is still alive.
+
+As always, any comments are welcome.
+
+Cheers
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]hello world
+
+From: madis <madis@cy...> - 2002-10-09 21:52
+
+On Wed, 9 Oct 2002, "Jo=E3o P. G. Vanzuita" wrote:
+
+> i want to help the project, but .. where are the people ?
+
+put this man page to the web and send link to the list and to jorge
+
+--=20
+mzz 
+
+
+
+[Dillo-dev]hello world
+
+From: <joaopaulo99@te...> - 2002-10-09 21:28
+
+i want to help the project, but .. where are the people ? 
+
+
+
+[Dillo-dev]translation
+
+From: <joaopaulo99@te...> - 2002-10-08 16:42
+
+i have translated the little man page of dillo, English to Portuguese,
+the project wants ? 
+
+
+
+[Dillo-dev]Re: Dillo-dev -- confirmation of subscription -- request 142884
+
+From: Hans-Dieter Stich <hdstich@hd...> - 2002-10-07 17:37
+
+Attachments: Message as HTML      
+
+Dillo-dev -- confirmation of subscription -- request 142884 
+
+
+
+[Dillo-dev]Dillo 0.6.6 RPM for Red Hat 7.3
+
+From: Kelson Vibber <kelson@po...> - 2002-10-04 20:00
+
+I'm not sure if this is the right place to send this, but I never heard 
+back from the address I tried earlier.
+
+I've started packaging a Dillo 0.6.6 RPM for Red Hat 7.3. I've added a 
+menu entry in the /etc/X11/applnk area (which should be shared by Gnome and 
+KDE, but isn't always), using one of the icons from the Dillo home page, 
+and I've included a couple of patches: Melvin Hadasht's combined 
+command-line/embeddable/fullwindow/local browsing patch 
+(http://melvin.hadasht.free.fr/home/index.html) and the remote access patch 
+from Sean's XEmacs Stuff (http://xemacs.seanm.ca/). It's compiled with 
+cookies enabled.
+
+If anyone's interested, it's at http://www.hyperborea.org/software/
+
+
+Kelson Vibber
+kelson@po...
+http://www.hyperborea.org/
+Creative Writing - Photography - The Flash 
+
+
+
+Re: [Dillo-dev]Problems and questions on Dillo 0.6.6
+
+From: <jbradford@di...> - 2002-10-04 15:47
+
+> The sourceforge CVS version have been unmodified for some months now and
+> as far as i know from reading this list, main dillo developers use cvs in 
+> cipsga.org.br now, but they have not been able to make it publicly 
+> readable because they couldn't contact this server's administrator.
+
+Can't we just get it working, and release 0.6.7? :-)
+
+John. 
+
+
+
+Re: [Dillo-dev]Problems and questions on Dillo 0.6.6
+
+From: madis <madis@cy...> - 2002-10-04 15:36
+
+On Fri, 4 Oct 2002, Daniel Stenberg wrote:
+
+> > This is caused by dillo cache, which believes that a cached document is
+> > valid forever. Since the url is same as it was, dillo will show the
+> > document from cache. I have patch for solving this, but it is against
+> > sourceforge cvs version and i am waiting new dillo release to update it.
+> > Older 0.6.6 patch (which is avaible in mix which some other modifications
+> > at http://www.zone.ee/myzz/dillo/dillo-0.6.6-mzz.diff) checks only 307
+> > redirect and cache: headers, but not 302 redirect.
+> 
+> Seems a bit restrictive to me.
+> 
+i can backport these changes to the 0.6.6, but the modified cvs version 
+seems more reliable to me since i have used it long time without 
+problems and mistakes can happen doing the backport.
+
+> Is the CVS version much improved since the 0.6.6? Is it better to switch over
+> to that for some bleeding edge tests?
+
+Changelog:
+http://cvs.so....net/cgi-bin/viewcvs.cgi/dillo/dillo/ChangeLog?rev=1.214&content-type=text/vnd.viewcvs-markup
+
+The sourceforge CVS version have been unmodified for some months now and
+as far as i know from reading this list, main dillo developers use cvs in 
+cipsga.org.br now, but they have not been able to make it publicly 
+readable because they couldn't contact this server's administrator.
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]Problems and questions on Dillo 0.6.6
+
+From: Daniel Stenberg <daniel@ha...> - 2002-10-04 14:39
+
+On Fri, 4 Oct 2002, Madis Janson wrote:
+
+Thanks for your quick response.
+
+> This is caused by dillo cache, which believes that a cached document is
+> valid forever. Since the url is same as it was, dillo will show the
+> document from cache. I have patch for solving this, but it is against
+> sourceforge cvs version and i am waiting new dillo release to update it.
+> Older 0.6.6 patch (which is avaible in mix which some other modifications
+> at http://www.zone.ee/myzz/dillo/dillo-0.6.6-mzz.diff) checks only 307
+> redirect and cache: headers, but not 302 redirect.
+
+Seems a bit restrictive to me.
+
+Is the CVS version much improved since the 0.6.6? Is it better to switch over
+to that for some bleeding edge tests?
+
+> As a side note, RFC 2616 is a bit confusing about what 302 redirect should
+> do for POST request:
+
+Right, but the key to this problem is this section:
+
+> Note: RFC 1945 and RFC 2068 specify that the client is not allowed
+> to change the method on the redirected request. However, most
+> existing user agent implementations treat 302 as if it were a 303
+> response, performing a GET on the Location field-value regardless
+> of the original request method.
+
+This is what all browsers do now. Doing something else is would possibly be
+following the RFC better, but it would then behave differently from the
+others.
+
+-- 
+Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
+ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol 
+
+
+
+Re: [Dillo-dev]Problems and questions on Dillo 0.6.6
+
+From: Madis Janson <madis@cy...> - 2002-10-04 14:29
+
+On Fri, 4 Oct 2002, Daniel Stenberg wrote:
+
+> I recently discovered Dillo and have plans on using it for an embedded
+> project. However, my first tests with dillo 0.6.6 on my Linux browser on
+> some sample pages left me a bit disapppointed, but this may very well be due
+> to my own ignorance or stupidity. Hence my mail here.
+> 
+> I tried a login-page. It is a plain HTML form querying for user and password.
+> I entered them both and pressed 'login'. It sent them off fine in a POST.
+> 
+> The remote site sends back a 302 with a Location: back to the exactly same
+> URL I was already browsing (the one with the form). Oh, right, and I got a
+> Cookie-Set back.
+> 
+> Dillon does not do anything on this response, it just shows the same login
+> screen again (while a working browser would send back a GET and as that new
+> cookie is used, get something entirely different back). I assume this is a
+> bad caching issue since it might believe that it already has the page cached
+> and thus shows that.
+
+This is caused by dillo cache, which believes that a cached document is 
+valid forever. Since the url is same as it was, dillo will show the 
+document from cache. I have patch for solving this, but it is against 
+sourceforge cvs version and i am waiting new dillo release to update it.
+Older 0.6.6 patch (which is avaible in mix which some other modifications 
+at http://www.zone.ee/myzz/dillo/dillo-0.6.6-mzz.diff) checks only 307 
+redirect and cache: headers, but not 302 redirect.
+
+As a side note, RFC 2616 is a bit confusing about what 302 redirect should 
+do for POST request:
+
+10.3.3 302 Found
+
+The requested resource resides temporarily under a different URI.
+Since the redirection might be altered on occasion, the client SHOULD
+continue to use the Request-URI for future requests. This response
+is only cacheable if indicated by a Cache-Control or Expires header
+field.
+
+The temporary URI SHOULD be given by the Location field in the
+response. Unless the request method was HEAD, the entity of the
+response SHOULD contain a short hypertext note with a hyperlink to
+the new URI(s).
+If the 302 status code is received in response to a request other
+than GET or HEAD, the user agent MUST NOT automatically redirect the
+request unless it can be confirmed by the user, since this might
+change the conditions under which the request was issued.
+
+Note: RFC 1945 and RFC 2068 specify that the client is not allowed
+to change the method on the redirected request. However, most
+existing user agent implementations treat 302 as if it were a 303
+response, performing a GET on the Location field-value regardless
+of the original request method. The status codes 303 and 307 have
+been added for servers that wish to make unambiguously clear which
+kind of reaction is expected of the client.
+
+--
+mzz 
+
+
+
+[Dillo-dev]Problems and questions on Dillo 0.6.6
+
+From: Daniel Stenberg <daniel@ha...> - 2002-10-04 13:43
+
+Hey Dillo developers.
+
+I recently discovered Dillo and have plans on using it for an embedded
+project. However, my first tests with dillo 0.6.6 on my Linux browser on
+some sample pages left me a bit disapppointed, but this may very well be due
+to my own ignorance or stupidity. Hence my mail here.
+
+I tried a login-page. It is a plain HTML form querying for user and password.
+I entered them both and pressed 'login'. It sent them off fine in a POST.
+
+The remote site sends back a 302 with a Location: back to the exactly same
+URL I was already browsing (the one with the form). Oh, right, and I got a
+Cookie-Set back.
+
+Dillon does not do anything on this response, it just shows the same login
+screen again (while a working browser would send back a GET and as that new
+cookie is used, get something entirely different back). I assume this is a
+bad caching issue since it might believe that it already has the page cached
+and thus shows that.
+
+Now, it is supposed to have received a cookie. My .dillo/cookierc looks like
+this:
+
+--- start ---
+DEFAULT DENY
+.domain.tld ACCEPT
+--- end ----
+[.domain.tld is something else in real life]
+
+Isn't this the way it is supposed to work?
+
+Now, if I reload the page, Dillo does perform a GET for the page, but it does
+not send along the cookie "correctly". Etherealing on the HTTP traffic
+clearly shows that the request doesn't include the cookie the correct way in
+the request (but it does send a Cookie2: header that puzzles me) and thus
+this doesn't help and yes, I get back that same login page again.
+
+Anyone recognize this?
+
+Another issue, is there anyone who has any experience on running Dillo on
+GTKfb? If all I want to do in an embedded Linux system is running Dillo, it
+does seem like a cool way to avoid X all together.
+
+I'm sorry if this is all just RTFM, but I've actually tried to find the
+answers to these questions. I'd be glad to read more if you can just point to
+which docs I should study!
+
+-- 
+Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
+ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: Tor Andersson <tor.andersson@ds...> - 2002-10-02 20:19
+
+Matias Aguirre <yo_soy@fa...> wrote:
+
+> I have a problem whan compile dillo with xft patch..
+> I use cvs version, and I patch manualy because the patch return a few errors.
+>
+> dw_page.c: In function `Dw_page_draw_line':
+> dw_page.c:1021: warning: implicit declaration of function `XftDrawDrawable'
+> dw_page.c:1048: structure has no member named `text'
+> dw_page.c:1049: structure has no member named `text'
+> make[3]: *** [dw_page.o] Error 1
+
+The CVS version of dillo has changed some data structures. Try replacing
+word->content.text with word->content.data.text and you should be fine.
+
+/tor 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: Nicola Girardi <nicola@g-...> - 2002-10-02 17:37
+
+On Tue, Oct 01, 2002 at 09:52:17PM +0200, Nicola Girardi wrote:
+> > dw_page.c: In function `Dw_page_draw_line':
+> > dw_page.c:1021: warning: implicit declaration of function `XftDrawDrawable'
+
+I (thought I had) said, that this error disappeared for me when I
+updated the Xft/Xrender/fontconfig libraries available from
+fontconfig.org. 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: Nicola Girardi <nicola@g-...> - 2002-10-01 21:24
+
+> dw_page.c: In function `Dw_page_draw_line':
+> dw_page.c:1021: warning: implicit declaration of function `XftDrawDrawable' 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: Nicola Girardi <nicola@g-...> - 2002-10-01 21:24
+
+> I'm currently trying to port the Xft patch to the GTK2 stuff. That would
+> fix the layout problems and bring it up to an acceptable performance
+> level too. Pango just doesn't seem to cut it for this kind of job.
+
+It's a pity, Pango has other features that are nice to have. I
+wouldn't know how to display pages properly with Pango anyway... 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: <jbradford@di...> - 2002-10-01 19:31
+
+> > Today I tried Tor's Xft patch which was posted on this list. You
+> > need to add -lXft and -lfontconfig to make it work. The result, as
+> > far as antialiasing is concerned, is much better than with the GTK2
+> > patch; in the latter, Dillo's layout was partially ruined by large
+> > gaps between lines and images not positioned correctly (at least
+> > when images happen in text like ``something in <img src="this.jpg">
+> > line'').
+> 
+> I'm currently trying to port the Xft patch to the GTK2 stuff. That would
+> fix the layout problems and bring it up to an acceptable performance
+> level too. Pango just doesn't seem to cut it for this kind of job.
+
+Ah, but the beauty of Pango is that we get support for loads of different character sets, E.G. Japanese.
+
+John. 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: Jorgen Viksell <jorgen.viksell@te...> - 2002-10-01 19:19
+
+Hi,
+
+> Today I tried Tor's Xft patch which was posted on this list. You
+> need to add -lXft and -lfontconfig to make it work. The result, as
+> far as antialiasing is concerned, is much better than with the GTK2
+> patch; in the latter, Dillo's layout was partially ruined by large
+> gaps between lines and images not positioned correctly (at least
+> when images happen in text like ``something in <img src=3D"this.jpg">
+> line'').
+
+I'm currently trying to port the Xft patch to the GTK2 stuff. That would
+fix the layout problems and bring it up to an acceptable performance
+level too. Pango just doesn't seem to cut it for this kind of job.
+
+J=F6rgen 
+
+
+
+Re: [Dillo-dev]Tor's Xft patch
+
+From: Matias Aguirre <yo_soy@fa...> - 2002-10-01 17:10
+
+On Mon, 30 Sep 2002 19:33:06 +0200
+Nicola Girardi <nicola@g-...> wrote:
+
+> Today I tried Tor's Xft patch which was posted on this list. You
+> need to add -lXft and -lfontconfig to make it work. The result, as
+> far as antialiasing is concerned, is much better than with the GTK2
+> patch; in the latter, Dillo's layout was partially ruined by large
+> gaps between lines and images not positioned correctly (at least
+> when images happen in text like ``something in <img src="this.jpg">
+> line'').
+> 
+> At least this happens with my configuration.
+> 
+> I'd really suggest you try that nice Xft patch.
+> 
+I have a problem whan compile dillo with xft patch..
+I use cvs version, and I patch manualy because the patch return a few errors.
+
+dw_page.c: In function `Dw_page_draw_line':
+dw_page.c:1021: warning: implicit declaration of function `XftDrawDrawable'
+dw_page.c:1048: structure has no member named `text'
+dw_page.c:1049: structure has no member named `text'
+make[3]: *** [dw_page.o] Error 1
+
+Greetings
+
+-- 
+Matias Aguirre
+Software Engineer
+Sinatec S.A.
+Linux User #: 78193
+
+Buenos Aires, Argentina 
+
+
+
+[Dillo-dev]Tor's Xft patch
+
+From: Nicola Girardi <nicola@g-...> - 2002-10-01 15:26
+
+Today I tried Tor's Xft patch which was posted on this list. You
+need to add -lXft and -lfontconfig to make it work. The result, as
+far as antialiasing is concerned, is much better than with the GTK2
+patch; in the latter, Dillo's layout was partially ruined by large
+gaps between lines and images not positioned correctly (at least
+when images happen in text like ``something in <img src="this.jpg">
+line'').
+
+At least this happens with my configuration.
+
+I'd really suggest you try that nice Xft patch. 
+
diff --git a/old/oldmail/200211.txt b/old/oldmail/200211.txt
new file mode 100644
index 0000000..76ef57b
--- /dev/null
+++ b/old/oldmail/200211.txt
@@ -0,0 +1,1659 @@
+Re: [Dillo-dev]dpi on NetBSD
+
+From: Bjoern Weber <foxbow@we...> - 2002-11-29 08:46
+
+[.. dpi problem of empty requests ..]=20
+> Try a telnet to the dpi:
+> telnet localhost 8000
+> and send this:
+> <dpi cmd=3D'open=5Furl' url=3D'dpi:/bm/'>
+> It should send the full answer back.
+That works great.
+
+> If that works, check pthreads to be working; messages are sent
+> from a pthread.
+I'm afraid that it's the GNU pth pthreads emulation that's breeding the
+problem here since I had to disable multithreading in dns.c as well.
+
+[...]
+--=A0
+()=A0ascii=A0ribbon=A0campaign
+/\=A0against=A0HTML=A0in=A0email/postings 
+
+
+
+Re: [Dillo-dev]dpi on NetBSD
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-28 22:21
+
+Bjoern,
+
+> Hello,
+>
+> finally I managed to take a look at the new beta, pulled the sources from the CVS,
+> compiled everything, got the dpi tarball as well and started some testing but it
+> won't work for me. Some tests with the helloworld dpi showed that no requests
+> are sent until the browser is closed. Then there will be exectly as many empty
+> requests ("") as there should have been original requests.
+>
+> Anyone any clue, or even seen that before?
+
+Try a telnet to the dpi:
+
+telnet localhost 8000
+
+and send this:
+
+<dpi cmd='open_url' url='dpi:/bm/'>
+
+It should send the full answer back.
+
+
+If that works, check pthreads to be working; messages are sent
+from a pthread.
+
+Double check port 8000 is not already in use.
+
+
+> Or is it just some quirk in the current CVS version?
+
+Nope.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo on NanoGtk
+
+From: Sebastian Geerken <s.geerken@pi...> - 2002-11-28 19:47
+
+Hi,
+
+perhaps these notes may help:
+
+On Thu, Nov 28, ???? wrote:
+> Our team just ported Dillo from x86/X/Gtk+ to
+> mips/NanoX/NanoGtk, everything went fine except scrolling, that is,
+> when we browse a large page, we got scrollbars, but once I drag and
+> drop the scrollbar, the page turns into chaos immediately. However, if
+> I scrolled the page by using PageUP and PageDown buttons, everything
+> is Ok.
+>
+> It looks like something goes wrong with the screen refreshment,
+> which is to say, if you post too many screen-updating request by
+> scrolling the page with scrollbar, the underlying refresh-request
+> queue handler (NanoGDK?) just cannot fulfil its responsibilities,
+> while if the request is moderate, the handler can manage it.
+
+Dillo uses GtkLayout (base class DwGtkViewport) with GTK_APP_PAINTABLE
+set. I do not know how it works exactly, but before
+gtk_layout_adjustment_changed (which is called when adjustments are
+changed, e.g. scrollers are moved), I found the comment:
+
+/* [...]
+* Real expose event compression, as in the XFE, could be added
+* here. It would help opaque drags over the region, and the
+* obscured case.
+* [...]
+*/
+
+While I do not know exactly what this may refer to. Furthermore, key
+press events are indeed compressed, that may be the reason, why you
+don't have any problems with them. OTOH, too many events without
+compression cause rather a lock for some time, not a messy rendering.
+
+Another idea: GtkLayout was written for handling scrolled areas with
+more that 32k pixels, so that is used in dillo to display the embedded
+GtkWidgets (for form elements) correctly. It may be that this does not
+work the same for NanoGtk as for Gtk.
+
+> So, based on the observation and my conjecture, I dived into
+> NanoGtk and tried to resolve this problem:
+> 
+> 1.Scrolling request is sent by gtk_scrolled_window_set_vadjustment
+> function
+> 2.gtk_scrolled_window_adjustment_changed is the scrolling signal
+> handler, and it adds the window need to scrolling, scrolled_win, to
+> resize queue by calling gtk_widget_queue_resize
+> 3.For a Container (Gtkscrolledwindow is a container)??the resizing
+> handler is gtk_container_clear_resize_widgets
+> 5.BUT, this function just mark the container with
+> GTK_PRIVATE_UNSET_FLAG (widget, GTK_RESIZE_NEEDED); and do nothing more!
+
+Scrolling is done from the GtkScroller's via the GtkAdjustment's,
+which send signals to all widgets they are connected to (in Dillo
+GtkDwScrolledWindow, GtkDwScrolledFrame, and GtkDwViewport twice,
+gtk_layout_adjustment_changed and Dw_gtk_viewport_adj_changed).
+Dw_gtk_viewport_adj_changed just handles "relative" mouse movements
+(at fixed absolte pointer position, but moved viewport), the point you
+should continue is gtk_layout_adjustment_changed.
+
+On Wed, Nov 27, Lars Clausen wrote:
+> Maybe this can help: In Dia, we used to have problems with really slow
+> updates when scrolling. We changed it so that if more than one
+> update-request was present by the time processing started, only the last
+> one would be handled. It helped a lot. However that would translate into
+> Dillo I'm not sure.
+
+The functionality of GtkLayout is absolutely neccessary for dillo, and
+a reimplementation would be quite difficult. (Look at the code for
+event filtering! BTW, in the very beginning, I tried this, but gave it
+up very soon.) It would quite tricky to insert event compression
+there, and OTOH it seems (for what ever reason, I have no idea why)
+only neccessary for key press events, since I never had problems with
+the scollbars, but had them (on my old computer) with key presses.
+
+Sebastian 
+
+
+
+Re: [Dillo-dev]0.7.0pre crash and patch
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-28 15:30
+
+Madis,
+
+>
+> Efence found something that seems like using freed memory. This patch
+> solved it.
+>
+> [patch]
+
+Done!
+
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo on NanoGtk
+
+From: Lars Clausen <lrclause@cs...> - 2002-11-28 05:34
+
+On Thu, 28 Nov 2002, mabo@in... wrote:
+> Hi, all
+>=20
+> Our team just ported Dillo from x86/X/Gtk+ to mips/NanoX/NanoGtk,
+> everything went fine except scrolling, that is, when we browse a
+> large page, we got scrollbars, but once I drag and drop the
+> scrollbar, the page turns into chaos immediately. However, if I
+> scrolled the page by using PageUP and PageDown buttons, everything is
+> Ok. It looks like something goes wrong with the screen refreshment,
+> which is to say, if you post too many screen-updating request by
+> scrolling the page with scrollbar, the underlying refresh-request
+> queue handler (NanoGDK?) just cannot fulfil its responsibilities,
+> while if the request is moderate, the handler can manage it.=20=20
+
+Maybe this can help: In Dia, we used to have problems with really slow
+updates when scrolling. We changed it so that if more than one
+update-request was present by the time processing started, only the last
+one would be handled. It helped a lot. However that would translate into
+Dillo I'm not sure.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Dillo on NanoGtk
+
+From: <mabo@in...> - 2002-11-28 02:45
+
+Hi, all
+
+=09Our team just ported Dillo from x86/X/Gtk+ to=
+mips/NanoX/NanoGtk, everything went fine except scrolling, that=
+is, when we browse a large page, we got scrollbars, but once I=
+drag and drop the scrollbar, the page turns into chaos=
+immediately. However, if I scrolled the page by using PageUP and=
+PageDown buttons, everything is Ok. 
+It looks like something goes wrong with the screen=
+refreshment, which is to say, if you post too many=
+screen-updating request by scrolling the page with scrollbar,=
+the underlying refresh-request queue handler (NanoGDK?) just=
+cannot fulfil its responsibilities, while if the request is=
+moderate, the handler can manage it.
+=09So, based on the observation and my conjecture, I dived into=
+NanoGtk and tried to resolve this problem:
+
+1.Scrolling request is sent by=
+gtk_scrolled_window_set_vadjustment function
+2.gtk_scrolled_window_adjustment_changed is the scrolling signal=
+handler, and it adds the window need to scrolling, scrolled_win,=
+to resize queue by calling gtk_widget_queue_resize
+3.For a Container (Gtkscrolledwindow is a container)=A3=ACthe=
+resizing handler is gtk_container_clear_resize_widgets
+5.BUT, this function just mark the container with=
+GTK_PRIVATE_UNSET_FLAG (widget, GTK_RESIZE_NEEDED); and do=
+nothing more!
+
+I was lost!!
+
+So, I came up with the second solution: Change the=
+Adjustment->step_increment to Adjustment->page_increment, but it=
+seems doesn't work also!
+
+Who can help me!
+
+mabo 
+
+
+
+[Dillo-dev]0.7.0pre crash and patch
+
+From: Madis Janson <madis@at...> - 2002-11-27 23:24
+
+Efence found something that seems like using freed memory. This patch
+solved it.
+
+@@ -445,8 +451,8 @@ void a_Http_ccc(int Op, int Branch, int 
+if (S) {
+a_Chain_del_link(Info, BCK);
+a_Chain_fcb(OpEnd, Info, (void *)S->SockFD, (void
+*)S->Url);
+- Http_socket_free(SKey);
+BW_MSG(S->web, 1, "Query sent, waiting for reply...");
++ Http_socket_free(SKey);
+}
+break;
+case OpAbort: 
+
+
+
+[Dillo-dev]dpi on NetBSD
+
+From: Bjoern Weber <foxbow@we...> - 2002-11-27 09:12
+
+Hello,
+
+finally I managed to take a look at the new beta, pulled the sources from =
+the CVS,
+compiled everything, got the dpi tarball as well and started some testing =
+but it
+won't work for me. Some tests with the helloworld dpi showed that no reque=
+sts
+are sent until the browser is closed. Then there will be exectly as many e=
+mpty
+requests ("") as there should have been original requests.
+
+Anyone any clue, or even seen that before=3F Or is it just some quirk in the=
+current
+CVS version=3F
+
+Greetings,
+
+Bjoern
+--=A0
+()=A0ascii=A0ribbon=A0campaign
+/\=A0against=A0HTML=A0in=A0email/postings 
+
+
+
+[Dillo-dev]dpi bookmarks plugin
+
+From: Ben Woolley <ben@ta...> - 2002-11-27 00:31
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Hello Jorge,
+
+I just tried out the dpi1 bookmarks plugin, and I really like the concept.
+But I started wondering if someone could take advantage of a dpi URL to do
+something improper.
+
+<html>
+<body>
+<a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.">test</a>
+<img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." alt="test image">
+</body>
+</html>
+
+When I load that page, not only does the image alter my bookmarks, when I
+click on the link the window closes (after altering my bookmarks). This
+seems to be an issue similar to what is discussed in the HTTP 1.1 spec
+section 15.1.3.
+
+Can POST data be sent instead? Section 9.5 says that POST should be used
+for "extending a database through an append operation", which is what the
+plugin actually does.
+
+Perhaps the plugin should check for a proper referral from
+dpi:/bm/modify?operation=add_url&submit=submit. before modifying
+anything.
+
+Perhaps change:
+<dpi
+cmd='open_url'
+url='dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+>
+to:
+<dpi
+cmd='open_url'
+url='dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+ref='dpi:/bm/modify?operation=add_url&submit=submit.'
+>
+or:
+<dpi
+cmd='open_url'
+url='dpi:/bm/modify'
+post='operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+>
+or even:
+<dpi
+cmd='open_url'
+url='dpi:/bm/modify'
+ref='dpi:/bm/modify?operation=add_url&submit=submit.'
+post='operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+>
+
+Do you already have some sort of plan for this issue?
+
+Ben Woolley
+http://ben.tautology.org
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.2.0 (FreeBSD)
+
+iD8DBQE95BJU88ChLVDxFsIRAjlbAJ9vM812QF4lxFfKgp/XfhfMwQh0bQCfTZ+C
+rek9st6hTc3gxc8HbQQYMyE=
+=MQbx
+-----END PGP SIGNATURE----- 
+
+
+
+Re: [Dillo-dev]Dillo on OpenBSD [Sparc64]
+
+From: Ben Woolley <ben@ta...> - 2002-11-26 18:54
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Hello Damien and list,
+
+It seems to work on i386.
+
+I have run 0.6.6 on 3.1 and 3.2 and a CVS build of Dillo from October 4th
+on 3.2 and two recent -current branches. Everything seems fine to me.
+
+Ben Woolley
+http://ben.tautology.org
+
+On Mon, 25 Nov 2002 dbastie@le... wrote:
+
+> Hello,
+>
+> I'm trying to use Dillo on OpenBSD 3.2 with my Ultra 5.
+> But when i launch it and i go on http://www.openbsd.org for example, i've
+> 1 word per line ............ (it's same on all web site)
+>
+> This problem is known ?
+>
+> --
+> Damien Basti=E9
+>
+
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.2.0 (FreeBSD)
+
+iD8DBQE948NX88ChLVDxFsIRAnAcAJ4nSBeV/s2fkjEnDl4DGl8muLkkTgCfYJqB
+SXNMpPBX431Rhkfgb9mVawc=3D
+=3DbjrU
+-----END PGP SIGNATURE----- 
+
+
+
+[Dillo-dev]CIPSGA CVS
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-26 14:19
+
+Hi guys!
+
+The CIPSGA CVS server is running. Just follow the [CVS] link!
+
+I'm also considering to move our mailing list to CIPSGA. BTW
+there're two lists for us already set. The only fact that makes
+me hesitate is that contacting a sysadmin there is hard as hell.
+For instance, our site statistics are down for more than a month,
+and ASFAIK it's a matter of restarting the http server, but
+that requires a sysadmin...
+
+The main gain in moving the mailing list is to get another
+web interface for it (more easily searchable/browseable), and we
+need it.
+
+The other alternative is to wait some meetings I'm having with
+the "Universidad de Chile" to prosper, and set the lists from
+there in a server I can see&touch with my hands!
+
+What do you think of it?
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]MIME types
+
+From: Madis Janson <madis@at...> - 2002-11-26 11:49
+
+On Tue, 26 Nov 2002, Tomas Guemes wrote:
+
+> On Tue, Nov 26, 2002 at 03:57:14AM +0200, Madis Janson wrote:
+> > 
+> i was also thinking to do some work with the bookmarks menu but i still
+> didn't read the dpi code probably i can start next week to read and do
+> something.
+> 
+> Few mounths ago i looked for a standar format for the bookmark file and found
+> xbel, is the XML format used by konqueror and galeon can also manage it, there
+> is some tools to convert to others browser formats like netscape, lynx and
+> opera. I just take a quick look and seems that mozilla is using the same
+> format as netscape. (see http://pyxml.so....net/topics/xbel/)
+> 
+> did you already think something about it?
+>
+a bit - imho some command have to be added to the dpi interface for
+modifing dillo menu (easy thing, i basically did it for a try), then some
+code is needed to make this menu command actually modify the menu and
+then bm_srv needs to be modified so it would add bookmarks into the menu.
+
+XML format - it could be nice, current bm_srv uses a plain-text file, but
+i really haven't thought about this. It should be possible to do it
+entirely in the bookmark plugin. 
+
+
+
+Re: [Dillo-dev]MIME types
+
+From: Tomas Guemes <tomas@as...> - 2002-11-26 03:05
+
+On Tue, Nov 26, 2002 at 03:57:14AM +0200, Madis Janson wrote:
+> 
+> On Mon, 25 Nov 2002, Thomas Heute wrote:
+> 
+> > I don't know how stupid is that question... I am really novice.
+> > 
+> > I would like to know how to handle a MIME type with Dillo, i would like to 
+> > use a software of my own to handle JAR files, i guess i should handle this 
+> > type: <application/x-java>
+> > 
+> > Any way to do that without touching the code of Dillo ?
+> > 
+> > (for information, it is to use on an iPaq)
+> > 
+> You mean 'how to make the browser execute external program for 
+> viewing documents having some certain mime type' ?
+> Short answer is not yet.
+> 
+> This is possible using the plugins api, but first a plugin have to be 
+> written, which would do the actual program execution (one common plugin 
+> should be enough). Currently (in 0.70pre) the dpi1 framework is not fully 
+> finished, but most of necessery code seems to exist. So writing the 
+> plugin should be possible now, when you add some missing bits (i just 
+> read the dillo dpi code in attempt to recreate bookmarks menu into 
+> 0.70pre :)).
+
+i was also thinking to do some work with the bookmarks menu but i still
+didn't read the dpi code probably i can start next week to read and do
+something.
+
+Few mounths ago i looked for a standar format for the bookmark file and found
+xbel, is the XML format used by konqueror and galeon can also manage it, there
+is some tools to convert to others browser formats like netscape, lynx and
+opera. I just take a quick look and seems that mozilla is using the same
+format as netscape. (see http://pyxml.so....net/topics/xbel/)
+
+did you already think something about it?
+
+gretings
+
+Tomas
+
+
+> 
+> --
+> mzz
+> 
+> 
+> 
+> -------------------------------------------------------
+> This S...net email is sponsored by: Get the new Palm Tungsten T 
+> handheld. Power & Color in a compact size! 
+> http://ads.so....net/cgi-bin/redirect.pl?palm0002en
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+> 
+
+-- 
+
+Tomas Guemes <tomas@as...> 
+
+
+
+Re: [Dillo-dev]MIME types
+
+From: Madis Janson <madis@at...> - 2002-11-26 01:58
+
+On Mon, 25 Nov 2002, Thomas Heute wrote:
+
+> I don't know how stupid is that question... I am really novice.
+> 
+> I would like to know how to handle a MIME type with Dillo, i would like to 
+> use a software of my own to handle JAR files, i guess i should handle this 
+> type: <application/x-java>
+> 
+> Any way to do that without touching the code of Dillo ?
+> 
+> (for information, it is to use on an iPaq)
+> 
+You mean 'how to make the browser execute external program for 
+viewing documents having some certain mime type' ?
+Short answer is not yet.
+
+This is possible using the plugins api, but first a plugin have to be 
+written, which would do the actual program execution (one common plugin 
+should be enough). Currently (in 0.70pre) the dpi1 framework is not fully 
+finished, but most of necessery code seems to exist. So writing the 
+plugin should be possible now, when you add some missing bits (i just 
+read the dillo dpi code in attempt to recreate bookmarks menu into 
+0.70pre :)).
+
+--
+mzz 
+
+
+
+[Dillo-dev]Dillo RPM (Red Hat 7.x) Updated
+
+From: Kelson Vibber <kelson@po...> - 2002-11-25 20:47
+
+Over the weekend I updated my RPM of Dillo 0.6.6 to include the localization 
+patch from http://bobuk.ipost.ru/packages/dillo/
+
+I had to modify it slightly in order to merge that patch with the 
+cli-local2-fullwindow-xid patch (in some places they modified the same areas 
+of a file).
+
+I also wrote a patch that extends its functionality to copy a default list of 
+encodings to the user's home directory if it does not already exist. This 
+was what held me back from releasing it when it was suggested, since without 
+it the user would end up with an empty menu unless he/she manually copied a 
+file over. Then I didn't have a chance to work on it for about a month.
+
+The RPM, source RPM and .spec file are at 
+http://www.hyperborea.org/software/dillo.html
+
+Here's the patch. Keep in mind that it's been several years since I've done 
+any C programming, so there may be a better way to do this, but it seems to 
+work (at least on my own system):
+
+diff -rU 2 dillo-0.6.6.old/src/encodings.c dillo-0.6.6/src/encodings.c
+--- dillo-0.6.6.old/src/encodings.c Fri Nov 22 10:56:43 2002
++++ dillo-0.6.6/src/encodings.c Fri Nov 22 11:48:35 2002
+@@ -26,4 +26,5 @@
+#include <stdlib.h>
+#include <string.h>
++#include <unistd.h>
+
+#include "list.h"
+@@ -87,7 +88,26 @@
+{
+gchar *file;
++ char buf[4096];
++ static FILE *fp;
++ static FILE *fpw;
+
+/* Here we load and set the encodings */
+file = a_Misc_prepend_user_home(".dillo/encodings");
++ if (access(file, F_OK)) {
++ if ((fp = fopen("/etc/dillo.encodings", "r")) == NULL)
++ if ((fp = fopen("/usr/local/etc/dillo.encodings", "r")) == NULL)
++ g_print("dillo: copying default encoding file: %s\n",
++ strerror(errno));
++ if (fpw = fopen(file, "a")) {
++ while (1) {
++ /* Read a whole line from the file */
++ if ((fgets(buf, 4096, fp)) == NULL)
++ break;
++ fputs(buf, fpw);
++ }
++ fclose(fpw);
++ }
++ fclose(fp);
++ }
+Encodings_file_op(LOAD_ENCODINGS, file, NULL);
+g_free(file);
+
+
+-- 
+Kelson Vibber
+http://www.hyperborea.org/ 
+
+
+
+[Dillo-dev]MIME types
+
+From: Thomas Heute <thomas.heute@ni...> - 2002-11-25 17:40
+
+I don't know how stupid is that question... I am really novice.
+
+I would like to know how to handle a MIME type with Dillo, i would like to 
+use a software of my own to handle JAR files, i guess i should handle this 
+type: <application/x-java>
+
+Any way to do that without touching the code of Dillo ?
+
+(for information, it is to use on an iPaq)
+
+Thanks,
+
+Thomas. 
+
+
+
+[Dillo-dev]Dillo on OpenBSD [Sparc64]
+
+From: <dbastie@le...> - 2002-11-25 10:44
+
+Attachments: Message as HTML      
+
+Hello,
+
+I'm trying to use Dillo on OpenBSD 3.2 with my Ultra 5.
+But when i launch it and i go on http://www.openbsd.org for example, i've
+1 word per line ............ (it's same on all web site)
+
+This problem is known ?
+
+--
+Damien Basti=E9 
+
+
+
+[Dillo-dev]cygwin
+
+From: TANAKA Keishiro <ksr@lp...> - 2002-11-21 08:29
+
+Hi.
+
+Have anyone tried dill on cygwin ?
+I tried to compile it then succeeded but it did not work.
+It looks that async io (glib library) does not work well..
+
+Best Regards 
+
+
+
+Re: [Dillo-dev]dpi and starting servers ....
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-11-20 11:52
+
+Hi Lars,
+
+on Wed, 06 Nov 2002 06:54:44 +0100
+Lars Segerlund <lars.segerlund@co...> wrote:
+
+> Also it would be nice with two types of dpi processes, one global ( 
+> perhaps running in /tmp/.dillo/<unix socket by dpi name> such as the 
+> cache ? and a second kind running on ~/.dillo/<bla bal>/<unix socket by 
+> dpi name> .
+
+Maybe a global socket can be handy but maybe it will bring some security
+questions (permissions etc).
+
+Perhaps providing the flexibility by using a per user plugin_paths preference
+(plugin_paths=~/.dillo:/tmp/dillo) can be a solution.
+
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]ghelp dillo support
+
+From: higuita <higuita7@ya...> - 2002-11-10 08:21
+
+Attachments: Message as HTML      
+
+Hi
+
+i was testing a gnome program, gtt, and i hit in the help
+dillo open as i setup it up
+
+but it dont open, complain about unknown protocol
+i would be good if you add the ghelp as a "alias" to the 
+file protocol, AFAIK its the same thing
+
+from the console i have:
+Url=>ghelp:/usr/share/gnome/help/gtt/C/index.html
+
+if i change the ghelp: to file in dillo is open just fine
+
+thanks for dillo
+
+higuita
+ps: dillo 0.7.0-pre1 is working fine in linux sparc, the last one crashed
+in that old sun ultra1 machine (suse 7.3)... thanks again for that 8)
+-- 
+There is hardly a thing in the world that some man can
+not make a little worse and sell a little cheaper.
+Galeao.casa@Portugal:
+03:11:00 up 10:24, 1 user, load average: 0.06, 0.05, 0.01 
+
+
+
+[Dillo-dev]Encoding and charset selection patch
+
+From: Grigory Bakunov <black@as...> - 2002-11-08 14:55
+
+Hello all.
+I need to say what i update my i18n patches for dillo-0.7.0 - you can
+find this patches here :
+
+http://stuphead.asplinux.ru/dillo/index.html.en#toc6
+
+Thanks Jorge and others project developers for great work!
+
+
+........................................................................
+IRC: irc.openprojects.net #asplinux Grigory Bakunov
+EMAIL: black@as... ASPLinux Support Team
+ICQ: 51369901 http://www.asplinux.ru
+-----BEGIN GEEK CODE BLOCK-----
+GCS/MU d-(--) s:- a- C+++>++$ UBLAVSX+++$ P+ L++++$ E++$ W++ N+>- o? K?
+w-- O- M V-(--) PS+ PE+ !Y PGP+>++++ t+ 5++ X+++ R+++ tv+>-- b+++ ?DI D+
+G++ e>++$ h- r++ y+ z++(+++)
+------END GEEK CODE BLOCK------ 
+
+
+
+[Dillo-dev]dpi menu (for bookmarks)
+
+From: madis <madis@cy...> - 2002-11-07 20:33
+
+how should dpi1 plugins create menu items (for example for bookmarks 
+menu)? it seems to be missing from dpi specification.
+could it be something like this (just a example for generating better 
+ideas ;) )?
+
+<dpi cmd='menu' name='bm' cnt='3' i1='first' i2='@submenu1' i3='last'>
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-06 23:59
+
+Melvin,
+
+> For the moment the only thing I found that is not working correctly is adding a
+> URL in another section than the first one. I made sure to select "Add URL", then
+> check the section I want the new URL to go in and then "submit". After filling
+> the URL, it is added to the first section. That reminds me that if there is no
+> section, the URL is added but it is not displayed until a first section is
+> displayed.
+
+A I said in my previous post, this was not implemented, but I
+added a few lines to the patch at CVS page to make it work.
+
+Note: the patch at http://dillo.cipsga.org.br/cvs.html is not
+incremental. i.e. apply it to the original tarball.
+
+HTH
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-06 15:22
+
+Melvin,
+
+> > Here's a tiny patch that solves the problem:
+> >
+> > http://dillo.cipsga.org.br/cvs.html
+> >
+> > Please let me know how the whole thing works. I haven't got any
+> > feedback yet.
+>
+> For the moment the only thing I found that is not working correctly is adding a
+> URL in another section than the first one. I made sure to select "Add URL", then
+> check the section I want the new URL to go in and then "submit". After filling
+> the URL, it is added to the first section. That reminds me that if there is no
+> section, the URL is added but it is not displayed until a first section is
+> displayed.
+
+Yes, I haven't implemented it yet!
+
+I know that is the expected behaviour, and that it should work.
+It's just a matter of coding the missing bits...
+
+BTW, I was about to leave the "add url" as an excercise to the
+reader :) when I decided to make it as a last minute addition.
+
+My main concern is about grasping the generic mechanisms, the
+potentiality, the way to code PI, etc. Maybe it'll take some more
+time to study the docs, the bm PI, and start coding a custom PI
+before this can be answered. If this is the case, please take
+your time.
+
+Thanks for your quick reply.
+
+
+Cheers
+Jorge.-
+
+
+BTW: one of the interesting points is the possibility of coding
+another, absolutely different bookmarks plugin. The one I coded
+is just an example, that I hope to be useful. DPI1 allows for a
+very flexible way of extending dillo. Every user can chose
+different PIs with the same dillo core! 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-11-06 14:11
+
+Jorge,
+
+on Wed, 6 Nov 2002 10:04:21 -0300 (CLST)
+Jorge Arellano Cid <jcid@so...> wrote:
+
+> 
+> Hi there!
+> 
+> > > [I wrote:]
+> > > It works for me all the time.
+> > > Has anyone had trouble making it work?
+> > > (AFAIK it worked for Melvin)
+> > >
+> >
+> > On line 56, in bm_srv10.c:
+> > static char *BmFile = "/home/jcid/.dillo/bm.txt";
+> >
+> > After changing that path, it seems to work OK for me ;)
+> 
+> Gotcha! So that was it!
+> 
+> Here's a tiny patch that solves the problem:
+> 
+> http://dillo.cipsga.org.br/cvs.html
+> 
+> Please let me know how the whole thing works. I haven't got any
+> feedback yet.
+
+For the moment the only thing I found that is not working correctly is adding a
+URL in another section than the first one. I made sure to select "Add URL", then
+check the section I want the new URL to go in and then "submit". After filling
+the URL, it is added to the first section. That reminds me that if there is no
+section, the URL is added but it is not displayed until a first section is
+displayed.
+
+Tavvauvusi [Tah-vow-voo-see] (Inuit: Good bye to you all)
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-06 13:51
+
+Hi there!
+
+> > [I wrote:]
+> > It works for me all the time.
+> > Has anyone had trouble making it work?
+> > (AFAIK it worked for Melvin)
+> >
+>
+> On line 56, in bm_srv10.c:
+> static char *BmFile = "/home/jcid/.dillo/bm.txt";
+>
+> After changing that path, it seems to work OK for me ;)
+
+Gotcha! So that was it!
+
+Here's a tiny patch that solves the problem:
+
+http://dillo.cipsga.org.br/cvs.html
+
+Please let me know how the whole thing works. I haven't got any
+feedback yet.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Stephen Lewis <slewis@pa...> - 2002-11-06 09:36
+
+On Tue, 5 Nov 2002 22:51:18 -0300 (CLST)
+Jorge Arellano Cid <jcid@so...> wrote:
+
+> On 5 Nov 2002, Carlos Daniel Ruvalcaba Valenzuela wrote:
+> 
+> > Yes, i think Unix sockets will suit well for the plugin
+> > communication, also the bookmark plugin dosen't works! (yea sure, it
+> > dosen't have to really work, just work a sample plugin :-) )
+> 
+> It works for me all the time.
+> Has anyone had trouble making it work?
+> (AFAIK it worked for Melvin)
+> 
+
+On line 56, in bm_srv10.c:
+static char *BmFile = "/home/jcid/.dillo/bm.txt";
+
+After changing that path, it seems to work OK for me ;)
+
+-- 
+Stephen Lewis
+slewis@pa... 
+
+
+
+[Dillo-dev]another +ve dillo review
+
+From: Geoff Lane <zzassgl@tw...> - 2002-11-06 08:50
+
+This months' issue (Nov 2002) of the UK magazine Linux Format
+(www.linuxformat.co.uk - but it's currently off the net because of /.
+effect) contains a generally favourable review of Dillo 0.6.6.
+
+They really like the small memory use and high speed page loads.
+
+Their main complaints
+
+1 dillo is _too_ strict in following web standards
+(If _nobody_ enforces standards they are pointless)
+2 no highlighting of strings found using the find dialog
+3 no builtin SSL support (nor Java/JavaScript)
+(SSL patches are available, but maybe it's time to integrate
+into base code? Working out a plan to add JavaScript without
+increasing the memory footprint too much would be an
+interesting project for someone.)
+4 HTTP only down-loads
+(Hopefully recent dpi developments solve this.)
+
+
+-- 
+/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
+
+Discoveries are made by not following instructions. 
+
+
+
+[Dillo-dev]dpi and starting servers ....
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-11-06 05:54
+
+Hi folks,
+
+I think the browser should start the different dpi's depending on 
+tags ( URL ), so what in that case would be needed is some configuration 
+of tag -> dpi .
+
+Also it would be nice with two types of dpi processes, one global ( 
+perhaps running in /tmp/.dillo/<unix socket by dpi name> such as the 
+cache ? and a second kind running on ~/.dillo/<bla bal>/<unix socket by 
+dpi name> .
+
+Does anybody agree/disagree ?
+
+/ regards, Lars Segerlund. 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Carlos Daniel Ruvalcaba Valenzuela <clsdaniel@ya...> - 2002-11-06 04:11
+
+On Tue, 2002-11-05 at 18:51, Jorge Arellano Cid wrote:
+
+> Thanks, but how can you tell without running the bookmarks PI?
+
+Well, i was talking about the Dillo part, but the bm dpi does work at
+certain rate, it dosen't shows any bookmark at all, nor does adds
+bookmarks or other functionality related the Bookmark stuff, but it
+shows everything well, the communication between dillo and the bmserver
+is OK.
+
+--> Carlos Daniel Ruvalcaba
+
+_________________________________________________________
+Do You Yahoo!?
+La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-06 01:54
+
+On 5 Nov 2002, Carlos Daniel Ruvalcaba Valenzuela wrote:
+
+> Yes, i think Unix sockets will suit well for the plugin communication,
+> also the bookmark plugin dosen't works! (yea sure, it dosen't have to
+> really work, just work a sample plugin :-) )
+
+It works for me all the time.
+Has anyone had trouble making it work?
+(AFAIK it worked for Melvin)
+
+>, about the DPI protocol,
+> why do you choosed Tag based communication instead of binary struct?, or
+> binary structures will be supported as well?, Tags have to be
+> intepreted, binary structures only readed, there is a great diference on
+> speed on that.
+
+Think twice.
+
+> Remember the structure for communications?
+> cmd
+> id
+> d1
+> d2
+> lenght
+> data
+
+Yes, I've written/reviewed eight drafts about it.
+
+> Plus, dillo will be able to automatically load plugins? (On-Demand),
+> like a rtf pharser, or any other like that?
+
+Please read the included documentation.
+
+> Also for the creation of new plugins, i think that the implementation is
+> well and easy to work with, but it can be a little problematic while
+> handling tags, to communicate to the browser you use plain sockets.
+> There may be people out there that don't like to handle strings, or is
+> careless writing the sockets code, etc.
+>
+> Resume: Not for anybody, just programmers with handy knowledge on
+> sockets and a bit of creativity to parse out the tags.
+>
+> PS:
+> Jorge, good work with the dpi, cheers!
+
+Thanks, but how can you tell without running the bookmarks PI?
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Carlos Daniel Ruvalcaba Valenzuela <clsdaniel@ya...> - 2002-11-06 01:18
+
+Yes, i think Unix sockets will suit well for the plugin communication,
+also the bookmark plugin dosen't works! (yea sure, it dosen't have to
+really work, just work a sample plugin :-) ), about the DPI protocol,
+why do you choosed Tag based communication instead of binary struct?, or
+binary structures will be supported as well?, Tags have to be
+intepreted, binary structures only readed, there is a great diference on
+speed on that.
+
+Remember the structure for communications?
+cmd
+id
+d1
+d2
+lenght
+data
+
+Plus, dillo will be able to automatically load plugins? (On-Demand),
+like a rtf pharser, or any other like that?
+
+Also for the creation of new plugins, i think that the implementation is
+well and easy to work with, but it can be a little problematic while
+handling tags, to communicate to the browser you use plain sockets.
+There may be people out there that don't like to handle strings, or is
+careless writing the sockets code, etc. 
+
+Resume: Not for anybody, just programmers with handy knowledge on
+sockets and a bit of creativity to parse out the tags.
+
+PS: 
+Jorge, good work with the dpi, cheers!
+
+-> Carlos Daniel Ruvalcaba
+
+_________________________________________________________
+Do You Yahoo!?
+La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx 
+
+
+
+Re: [Dillo-dev]Dillo and memory leak
+
+From: higuita <higuita@GM...> - 2002-11-05 09:16
+
+Attachments: Message as HTML      
+
+On Fri, 01 Nov 2002 08:33:25 +0100, Lars Segerlund
+<lars.segerlund@co...> wrote:
+> It seems that after running for a long time dillo uses up quite a lot 
+> of memory, I had two dillo sessions running for about three to five days
+> and both used about 130 MB , they were only displaying static pages on 
+
+isnt this the cache?
+i think that right now there is not memory cache limit so it
+keeps in the memory every page you open...
+
+i think there is a patch that enable the cache age and limit
+
+higuita
+-- 
+One Unix to rule them all, One Resolver to find them,
+One IP to bring them all and in the zone bind them. 
+
+
+
+Re: [Dillo-dev]BUG#382
+
+From: Jamin W. Collins <jcollins@as...> - 2002-11-03 22:39
+
+On Sun, 3 Nov 2002 17:25:19 -0300 (CLST) Jorge Arellano Cid
+<jcid@so...> wrote:
+
+> Bug #382 says that dillo crashes with:
+> 
+> http://deadly.org/article.php3?sid=20020914154658
+> 
+> I can't reproduce it. Can someone reproduce it?
+
+Doesn't happen here.
+
+-- 
+Jamin W. Collins 
+
+
+
+[Dillo-dev]BUG#382
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-03 20:51
+
+Hi!
+
+
+Bug #382 says that dillo crashes with:
+
+http://deadly.org/article.php3?sid=20020914154658
+
+I can't reproduce it. Can someone reproduce it?
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: madis <madis@cy...> - 2002-11-03 18:46
+
+using unix domain sockets seems to be better for these plugins - no 
+potential port number conflicts with other users/services.
+
+On Sat, 2 Nov 2002, Jorge Arellano Cid wrote:
+
+> 
+> Melvin,
+> 
+> > Jorge Arellano Cid <jcid@so...> wrote:
+> >
+> > > Finally, I'm pleased to present the first prototype of dillo
+> > > plugins: both, the dpi enabled browser and the bookmarks PI.
+> >
+> > I tried to run the bookmark server, but it says that the address is already in
+> > use. I have a http server running on port 8000, it seems that's the problem.
+> > That would also mean that two plugins servers can't be run on the same time?
+> > What can I do to solve this?
+> 
+> C'mon Melvin, just change the port number in:
+> 
+> dpi.c:351
+> bm_srv10.c:57
+> 
+> > That would also mean that two plugins servers can't be run on the same time?
+> 
+> Yes they can, at different ports.
+> Ah, and most probably they'll end using unix domain sockets.
+> 
+> I hope this gets you started.
+> 
+> Regards
+> Jorge.-
+> 
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]CPPFLAGS and /usr/local/include (Bug #349)
+
+From: Philip Blundell <pb@ne...> - 2002-11-03 16:53
+
+On Sun, 2002-11-03 at 13:49, Jorge Arellano Cid wrote:
+> Maybe not making a default inclusion of /usr/local/ stuff and
+> letting the user add it in the environment vars before running
+> ./configure is the right way?
+
+Yes, this seems like the right answer. As far as I know, there is no
+reason for dillo to be doing anything special with /usr/local by
+default.
+
+p. 
+
+
+
+[Dillo-dev]CPPFLAGS and /usr/local/include (Bug #349)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-03 13:54
+
+Hi,
+
+There's a problem with having:
+
+CPPFLAGS=3D"$CPPFLAGS -I/usr/local/include"
+LDFLAGS=3D"$LDFLAGS -L/usr/local/lib"
+
+in configure.in.
+
+It'd be good to try to fix it now because the problem arises
+with the gcc 3.1 (cpp 3.1).
+
+If you know about cpp, gcc & autoconf please read on:
+
+(NOTE: cpp <=3D> C pre-processor)
+
+
+On Sun, 29 Sep 2002, Manuel Menal wrote:
+
+> Hey,
+>
+> While porting Dillo to the new implementation of POSIX threads for
+> GNU/Hurd (code name: "Rubbish, I asked for mine with Minced Garlic,
+> Please Take this back"), I found some minor =AB bugs =BB in the Dillo
+> "installation system". The first bug I found out was a bug that was
+> already reported as #349 in the Dillo bug report system. It seems a
+> quite simple and not so annoying bug, but in fact it is quite pervert,
+> as it makes the configure misdetect what is installed in the system:
+> when it checks for jpeglib.h (& others), it tries to preprocess a simple
+> C file which only includes jpeglib.h, and check if there is some
+> output. If there is some output, then it assumes there is no
+> jpeglib.h. Which is not true in this case: the output is just warning
+> of cpp, which complains about the =AB -I/usr/local/include =BB (cpp 3.1
+> already has /usr/local/include it its system directories).
+>
+> There is a simple way to fix it, though. And Here is a patch:
+>
+> diff -pru old/dillo-0.6.6/configure dillo-0.6.6/configure
+> --- old/dillo-0.6.6/configure 2002-09-29 12:41:20.000000000 +0200
+> +++ dillo-0.6.6/configure 2002-09-29 12:40:57.000000000 +0200
+> @@ -1494,8 +1494,8 @@ ac_config_headers=3D"$ac_config_headers co
+> ac_config_commands=3D"$ac_config_commands default-1"
+>
+>
+> -CPPFLAGS=3D"$CPPFLAGS -I/usr/local/include"
+> -LDFLAGS=3D"$LDFLAGS -L/usr/local/lib"
+> +CPPFLAGS=3D"$CPPFLAGS -idirafter=3D/usr/local/include"
+> +LDFLAGS=3D"$LDFLAGS -idirafter=3D/usr/local/lib"
+>
+> idirafter makes cpp check /usr/local/include AFTER its system
+> directories (and the other -I'ed directories), so it doesn't complain
+> any more, and though it does include /usr/local/include on systems where
+> cpp doesn't have it in its system directories. This seems to fix my bug
+> and #349's reporter one.
+>
+> HTH,
+>
+> --
+> Manuel Menal
+
+
+This seems to solve the problem, but it has been reported that
+"idirafter" breaks things for non-gcc compilers, and I wonder
+what's the _right_ way to fix this.
+
+Maybe not making a default inclusion of /usr/local/ stuff and
+letting the user add it in the environment vars before running
+=2E/configure is the right way?
+
+I hesitate because if /usr/local is not already included in the
+system's directories, it means it's not installed.
+
+That is: if you have package "foo" in /usr/lib with includes in
+/usr/include, and you want to test a newest version of it, and
+you build it under /usr/local, ./configure should detect the
+the old one (the system's one).
+
+If you want to use the newest one, you can specify -I/usr/local
+(which changes the search order so now it's found first). Finally
+if you want every application to use the newest package, the
+system's includes&libs paths should be updated.
+
+Does anyone know better?
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-11-02 13:33
+
+Hi Jorge,
+
+on Sat, 2 Nov 2002 09:06:10 -0300 (CLST)
+Jorge Arellano Cid <jcid@so...> wrote:
+
+> C'mon Melvin, just change the port number in:
+>=20
+> dpi.c:351
+> bm_srv10.c:57
+
+That's what I ended to do... But if plugins will use INET sockets, then t=
+here
+should be a defined list of ports.
+
+In fact, it was a NAS server that listened at 8000, not the HTTP server.
+
+> Yes they can, at different ports.
+> Ah, and most probably they'll end using unix domain sockets.
+>=20
+> I hope this gets you started.
+
+It's OK, but I thought I report this, because this is currently a limitat=
+ion
+(unless a list that maps plugins to TCP/IP ports is created).
+
+BTW, I like the idea that plugins do not have to be started by the browse=
+r.=20
+
+Thanks for your work.
+
+Tsch=FC=DF (German: Bye)
+
+
+--=20
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]patches updated
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-02 12:55
+
+On Sat, 2 Nov 2002, Melvin Hadasht wrote:
+
+> Hi,
+>
+> The following patches were updated so they apply cleanly on Dillo 0.7.0pre-v1.
+>
+> - local browsing patch. Please note: this patch blocks accesses to a remote
+> host but still does DNS lookup for that host. I read somewhere that spammers can
+> look at their DNS server log to see if they got a hit for 123456.the.spam.com,
+> for example, thus allowing tracking of mail reading. If someone knows a way to
+> check if an address resolves to a localhost (local network?) address without
+> using DNS, please tell me.
+>
+> - fullwindow startup
+>
+> - embeddable Dillo (in another GTK+ application).
+>
+> The all-in-one patch was also updated. The command line support patch was not
+> updated because the last version still applies cleanly.
+>
+> Gentoo distribution is currently allowing the user to automatically fetch these
+> patches to permit HTML mail to be viewed from within Sylpheed-Claws mail user
+> agent, so I hope they will be officially implemented in Dillo.
+>
+> The patches are to be found at http://melvin.hadasht.free.fr/home/
+
+Thanks for the update Melvin.
+
+Yes, those patches will make into the official dillo. BTW I
+have a lot of pending patches to review; as I've said before,
+they were procrastinated because the top priority was on dpi.
+
+I apologize to all the people that haven't had answers in a
+long time. Please be aware that even working full time I don't
+have the time to cope with the huge loads of work here. BTW, just
+answering all the email I receive would eat almost all of my
+time!
+
+Now the priorities are:
+
+* Funding initiative
+* dpi
+* integrating some procrastinated patches
+* next release
+
+
+Please note that the funding initiative is critical, as I know
+that working on spare time won't work for a web browser.
+
+Ah, as I've pointed out somewhere, the current funding
+presentation haven't rised a single dolar, so I'm trying to
+expand the horizon and ask in other channels, and it certainly
+takes a lot of time...
+
+[more on this later]
+
+Best
+Jorge.-
+
+
+PS: Have you voted at http://www.linuxfund.org ? 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-02 12:55
+
+Melvin,
+
+> Jorge Arellano Cid <jcid@so...> wrote:
+>
+> > Finally, I'm pleased to present the first prototype of dillo
+> > plugins: both, the dpi enabled browser and the bookmarks PI.
+>
+> I tried to run the bookmark server, but it says that the address is already in
+> use. I have a http server running on port 8000, it seems that's the problem.
+> That would also mean that two plugins servers can't be run on the same time?
+> What can I do to solve this?
+
+C'mon Melvin, just change the port number in:
+
+dpi.c:351
+bm_srv10.c:57
+
+> That would also mean that two plugins servers can't be run on the same time?
+
+Yes they can, at different ports.
+Ah, and most probably they'll end using unix domain sockets.
+
+I hope this gets you started.
+
+Regards
+Jorge.- 
+
+
+
+[Dillo-dev]Re: broken link on dillo website
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-02 12:55
+
+Jolan,
+
+> http://dillo.cipsga.org.br/Icons/
+>
+> You don't have permission to access /Icons/ on this server.
+>
+> Can you please change the permissions as appropriate so I can grab
+> an icon?
+
+Sorry about that.
+
+The real problem is that the web server was somehow "updated"
+and the settings didn't remain. BTW, thepermissions are right,
+the problem is they don't allow symbolic links any more, so the:
+
+index.html -> icons.html
+
+doesn't work anymore.
+
+I had to made a file copy of it (now it works).
+
+Thanks for the tip, and please don't hesitate to report any
+problem you may find.
+
+
+Cheers
+Jorge.- 
+
+
+
+[Dillo-dev]patches updated
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-11-02 10:19
+
+Hi,
+
+The following patches were updated so they apply cleanly on Dillo 0.7.0pre-v1.
+
+- local browsing patch. Please note: this patch blocks accesses to a remote
+host but still does DNS lookup for that host. I read somewhere that spammers can
+look at their DNS server log to see if they got a hit for 123456.the.spam.com,
+for example, thus allowing tracking of mail reading. If someone knows a way to
+check if an address resolves to a localhost (local network?) address without
+using DNS, please tell me.
+
+- fullwindow startup
+
+- embeddable Dillo (in another GTK+ application).
+
+The all-in-one patch was also updated. The command line support patch was not
+updated because the last version still applies cleanly.
+
+Gentoo distribution is currently allowing the user to automatically fetch these
+patches to permit HTML mail to be viewed from within Sylpheed-Claws mail user
+agent, so I hope they will be officially implemented in Dillo.
+
+The patches are to be found at http://melvin.hadasht.free.fr/home/
+
+
+-- 
+Melvin Hadasht 
+
+
+
+Re: [Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-11-01 20:47
+
+Hi Jorge,
+
+on Fri, 1 Nov 2002 15:52:25 -0300 (CLST)
+Jorge Arellano Cid <jcid@so...> wrote:
+
+> Finally, I'm pleased to present the first prototype of dillo
+> plugins: both, the dpi enabled browser and the bookmarks PI.
+
+I tried to run the bookmark server, but it says that the address is already in
+use. I have a http server running on port 8000, it seems that's the problem.
+That would also mean that two plugins servers can't be run on the same time?
+What can I do to solve this?
+
+Cheers
+
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]Dillo 0.7.0-pre-v1 (dpi enabled)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-11-01 18:54
+
+Hi there!
+
+
+A lot of time has passed, but also a lot of work has been done.
+
+Finally, I'm pleased to present the first prototype of dillo
+plugins: both, the dpi enabled browser and the bookmarks PI.
+
+This is a work in progress and there's still some work to do
+before making a release of it, but I hope you enjoy this version
+and start working with it ASAP.
+
+I've prepared a tarball with all the necessary stuff, just get:
+
+http://dillo.cipsga.org.br/070pre/070pre-v1.tgz
+
+... read the docs and you'll be started.
+
+
+Enjoy
+Jorge.-
+
+
+PD: If you haven't voted some pesos for dillo at
+http://www.linuxfund.org, please do so. We need
+the money and it'll cost you nothing.
+Remember, the max amount is 1500. 
+
+
+
+[Dillo-dev]Dillo and memory leak
+
+From: Lars Segerlund <lars.segerlund@co...> - 2002-11-01 07:33
+
+It seems that after running for a long time dillo uses up quite a lot 
+of memory, I had two dillo sessions running for about three to five days 
+and both used about 130 MB , they were only displaying static pages on 
+the local filesystem, in other words no reloads and sych, also they 
+seemed to have allocated about the same amount of memory during this 
+time. This could indicate a leak that is propotional with time so to 
+speak. I will try to pin it down.
+
+/ Lars Segerlund. 
+
diff --git a/old/oldmail/200212.txt b/old/oldmail/200212.txt
new file mode 100644
index 0000000..f291e40
--- /dev/null
+++ b/old/oldmail/200212.txt
@@ -0,0 +1,769 @@
+Re: [Dillo-dev]BR taking extra space and problem with spaces in table
+
+From: Sebastian Geerken <s.geerken@pi...> - 2002-12-30 10:25
+
+A happy outcome is worth waiting for :-)
+
+On Fri, Jun 28, Pekka Lampila wrote:
+> On Tue, 25 Jun 2002 14:13:23 +0200
+> Sebastian Geerken <sgeerken@st...> wrote:
+> > In this case, multiple <br>'s would not be rendered properly. A
+> > solution may be to examine if this is the first <br> in series (by
+> > looking if there are DW_CONTENT_BREAK's before), but for my taste,
+> > this is somehow too hackish. (Other opinions?)
+> 
+> It's should work and is certainly better than the current situation.
+> So in my opinion, that kind of fix should be committed.
+
+Since most browsers do so, and it is rather simple, and does not break
+anything (AFAIK), I've comitted it.
+
+Sebastian 
+
+
+
+[Dillo-dev]*** IMPORTANT ***
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-19 22:35
+
+***************************
+* *
+* I M P O R T A N T ! *
+* *
+***************************
+
+
+Hi there,
+
+Don't let this pass or you'll miss the boat!
+
+After thoughtful considerations about our site's facilities,
+I've decided to move dillo project to the wearlab in Germany.
+
+That is:
+- web site
+- bug track
+- downloads
+- CVS
+- mailing lists
+
+i.e. everything.
+
+The good news is that everything is already set and working!
+
+Well, except for the mailing lists. I lost control of the
+current one a long long time ago when James administered it. So,
+please go to the new site and SUBSCRIBE YOURSELVES into the new
+mailing list (follow the links).
+
+(You may also want to unsubscribe from the current one.)
+
+We'll be running from there tomorrow, so please do it now and
+report any troubles you may find.
+
+I've updated several things. Most notably, the project Notes
+and the HTML versions for CSS and Dpi.
+
+The site is:
+
+http://dillo.auriga.wearlab.de
+
+
+Good luck!
+Jorge.-
+
+PS: Update your bookmarks. 
+
+
+
+[Dillo-dev]Dillo website statistics
+
+From: Eduardo Marcel Macan <macan@co...> - 2002-12-19 11:53
+
+Hello! The folks that take care of the particular machine where dillo
+was hosted just told me that the website stats are up again.
+
+Cipsga hosts many free software sites and projects, a lot of them
+projects from the CIPSGA group themselves. Many of these services=20
+and sites were changing servers due to administrative issues,=20
+that included the dillo website, although they tried to make this=20
+change transparent it seems that some little corners were yet to=20
+be rounded :D
+
+It is (i think) completely operational now.
+
+Regards :)
+
+--=20
+Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager
+macan@co... Col=E9gio Bandeirantes 
+
+
+
+Re: [Dillo-dev]CIPSGA CVS
+
+From: Eduardo Marcel Macan <macan@co...> - 2002-12-17 19:10
+
+Well, it is not *that* difficult, now that my personal life is
+kind of stable again, I have root access in some CIPSGA
+machines and know who to poke when I don't :) Feel free to mail me
+personally, since I do not follow this list daily.
+
+I'll take a look at it.
+
+Em Ter, 2002-11-26 =E0s 12:16, Jorge Arellano Cid escreveu:
+>=20
+> Hi guys!
+>=20
+> The CIPSGA CVS server is running. Just follow the [CVS] link!
+>=20
+> I'm also considering to move our mailing list to CIPSGA. BTW
+> there're two lists for us already set. The only fact that makes
+> me hesitate is that contacting a sysadmin there is hard as hell.
+> For instance, our site statistics are down for more than a month,
+> and ASFAIK it's a matter of restarting the http server, but
+> that requires a sysadmin...
+>=20
+> The main gain in moving the mailing list is to get another
+> web interface for it (more easily searchable/browseable), and we
+> need it.
+>=20
+> The other alternative is to wait some meetings I'm having with
+> the "Universidad de Chile" to prosper, and set the lists from
+> there in a server I can see&touch with my hands!
+>=20
+> What do you think of it?
+>=20
+>=20
+> Cheers
+> Jorge.-
+>=20
+>=20
+>=20
+>=20
+> -------------------------------------------------------
+> This S...net email is sponsored by: Get the new Palm Tungsten T
+> handheld. Power & Color in a compact size!
+> http://ads.so....net/cgi-bin/redirect.pl?palm0002en
+> _______________________________________________
+> Dillo-dev mailing list
+> Dillo-dev@li...
+> https://lists.so....net/lists/listinfo/dillo-dev
+>=20
+--=20
+Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager
+macan@co... Col=E9gio Bandeirantes 
+
+
+
+[Dillo-dev]Re: Dillo
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:37
+
+Martin,
+
+
+> Just mailing to say thanks for working on Dillo - it's great :-)
+> Recently upgraded to a machine with 256Mb RAM running Debian and was
+> rather shocked at quite how much memory Mozilla used - it's pretty but
+> I'm not sure that it's worth the memory and dillo runs _much_ faster
+> <vbg>.
+
+Thanks for the recognition!
+
+IMHO, dillo makes a different browsing experience. It lets you
+grab information so quickly, that making quick online research is
+possible (you may like to read the project objectives).
+
+
+> Given one of my next tasks is to resurrect a pair of Sun SLCs to
+> work as simple web browsers I think Dillo is my only realistic choice.
+> One little question (and if I wasn't buried alive under coursework I'd
+> try it myself) are you going to support several pages within the same
+> window - I found the tabs feature in Opera and then Mozilla really handy
+> for fast browsing - is it likely to appear in Dillo?
+
+Very likely.
+
+Arvind already has a prototype patch for tabs, and we're
+working on the details. We don't want to hurry it, but at least
+now you know that somewhere in the world, in a certain machine
+dillo has tabs!
+
+> Keep up the good work :-)
+
+We are trying as hard as we can.
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]BUG#339
+
+From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-12-17 13:34
+
+Hi Jorge,
+
+on Tue, 17 Dec 2002 10:00:27 -0300 (CLST)
+Jorge Arellano Cid <jcid@so...> wrote:
+
+> 
+> Hi there!
+> 
+> Can anyone reproduce BUG#339?
+> 
+> Jorge.-
+
+
+This bug could *not* be triggered in cvs 0.7.0pre from 14 Dec 2002
+Linux 2.4.19
+gcc 2.95.4
+libc 2.2.5
+gtk 1.2.10
+
+Bye
+
+
+-- 
+Melvin Hadasht 
+
+
+
+[Dillo-dev]BUG#339
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:04
+
+Hi there!
+
+Can anyone reproduce BUG#339?
+
+Jorge.- 
+
+
+
+[Dillo-dev]Dillo is great! (fwd)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:04
+
+---------- Forwarded message ----------
+Date: Mon, 9 Dec 2002 08:03:49 +0100
+From: Michael Mayer <michael-mayer@gm...>
+To: jcid@so...
+Subject: Dillo is great!
+
+Hello out there!
+
+This morning I read a short note about dillo and I'am really enthusiastic
+about it. I like compact coding and am really impressed by its speed: Very
+good work, thank you!
+
+I will use it as much as possible and I hope that I will find some time to
+have a look inside it. The most important thing I'am missing are more
+keyboard shortcuts. But even without this feature: I like it very much.
+
+Michael 
+
+
+
+[Dillo-dev]Dillo (fwd)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:04
+
+---------- Forwarded message ----------
+Date: Thu, 5 Dec 2002 20:23:27 +0000
+From: *** <stu@sp...>
+To: jcid@so...
+Subject: Dillo
+
+Hello
+
+First of all, wow really a neat browser!
+
+And it works just fine!! I'm using Vector Linux 2.0
+with 16 megs of RAM, and an old Cirrus Logic
+video card, and it does just fine!
+
+I tried Netscape.....I could retire if I had to load more than
+one graphic per page (turtle slow), I tried the Lynx Browser
+I can do it, but I would have to RElearn how to do stuff, and
+I did do it and can if need be.
+
+However, by chance I came across your website and browser
+and just had to give it a try! And it is eXactly what I needed!!
+
+thanks a bunch!!
+
+Stu Wilcox
+Madisonville, KY 
+
+
+
+Re: [Dillo-dev]Dillo and MIME types (2)
+
+From: Lars Clausen <lrclause@cs...> - 2002-12-10 18:13
+
+On Tue, 10 Dec 2002, Thomas Heute wrote:
+>=20
+> Sorry to bother,
+>=20
+> i still didn't fix my problem, what i'd like to do is to be able to click
+> on a jar file in Dillo and open an external file with that Jar file as
+> parameter.
+>=20
+> Or click on a PDF and launch any specified external PDF reader.
+>=20
+> Is there actually a way to do that, i don't think PI is my solution.
+
+I made a patch a while ago that uses the /etc/mailcap file to find
+readers. It's not the best way to do it, for several reasons, but it kinda
+works. See http://shasta.cs.uiuc.edu/~lrclause/dillo-patchomatic (which is
+in severe need of updating).
+
+Eventually there should be a chooser thing that reads the mailcap file
+(lazily) and remembers choices, and the actual handling should prolly be
+done via DPI.
+
+-Lars
+
+--=20
+Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
+"I do not agree with a word that you say, but I |------------------------=
+----
+will defend to the death your right to say it." | Where are we going, and
+--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas=
+ket? 
+
+
+
+[Dillo-dev]Dillo and MIME types (2)
+
+From: Thomas Heute <thomas.heute@ni...> - 2002-12-10 17:03
+
+Sorry to bother,
+
+i still didn't fix my problem, what i'd like to do is to be able to click on 
+a jar file in Dillo and open an external file with that Jar file as parameter.
+
+Or click on a PDF and launch any specified external PDF reader.
+
+Is there actually a way to do that, i don't think PI is my solution.
+
+Thanks for your work.
+
+Thomas. 
+
+
+
+Re: [Dillo-dev]dpi bookmarks plugin
+
+From: Ben Woolley <ben@ta...> - 2002-12-08 13:27
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Jorge,
+
+> > I just tried out the dpi1 bookmarks plugin, and I really like the concept.
+>
+> Thanks!
+>
+> I've only received a couple of tiny comments that kept me
+> somewhat clueless about how it was understood/received.
+>
+> I know it's not easy to grasp and certainly studying it
+> requires some time, but as for your comments, it looks as though
+> you've got it right!
+>
+
+It seems like a graceful method, and quite powerful (especially when
+listening on tcp). Just for fun, my brother and I wrote a shell script
+that used netcat to alter our bookmarks from remote computers (I know,
+you already have a solution for that, which is why I didn't bring it up
+before)
+
+By the way, what is your IP? ;)
+
+>
+> > But I started wondering if someone could take advantage of a dpi URL to do
+> > something improper.
+> >
+> > <html>
+> > <body>
+> > <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.">test</a>
+> > <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." alt="test image">
+> > </body>
+> > </html>
+> >
+> > When I load that page, not only does the image alter my bookmarks, when I
+> > click on the link the window closes (after altering my bookmarks). This
+> > seems to be an issue similar to what is discussed in the HTTP 1.1 spec
+> > section 15.1.3.
+>
+> Yes, I understand the issue.
+>
+
+I knew that you would. I am sure that developing a web browser makes one
+familiar with the spec. I just posted the numbers for reference, and
+more to prove that _I_ understood the issue. :)
+
+> > Can POST data be sent instead? Section 9.5 says that POST should be used
+> > for "extending a database through an append operation", which is what the
+> > plugin actually does.
+> >
+> > Perhaps the plugin should check for a proper referral from
+> > dpi:/bm/modify?operation=add_url&submit=submit. before modifying
+> > anything.
+>
+> Yes, POST could eventually be added...
+>
+
+I actually really like the idea of borrowing the distinction between GET
+and POST from HTTP. Web developers are already familiar with it. You could
+also have configuration options that restrict dpi executions, but that may
+just end up being bloat.
+
+> > [snip]
+
+> >
+> > Do you already have some sort of plan for this issue?
+>
+> I recognize that when designing it, I thought that having the
+> dpis running locally would cut "in gross" all of those problems.
+>
+> After reading your email, I kept thinking about it, and two
+> ideas remained:
+>
+> 1.- Only allow a dpi url from dpi-generated pages.
+> 2.- Add a dpi command that asks the dpi-server for a key, and
+> then use it to acknowledge permissions.
+>
+> The first is the easiest to implement, it just requires a check
+> before allowing the dpi command to be issued. Is not even
+> necessary to modify the protocol! (and in the event of a user
+> longing to make a custom page, accessed as file, that uses dpi
+> url references, it may then be served from an elementary dpi
+> program).
+>
+> The second option is more cumbersome, and requires two actions,
+> the key request, and including it in the dpi tag.
+>
+
+#1 had crossed my mind. Perhaps you could specify a standard URL argument
+that would tell the plugin that the request was referred from an outside
+source, and that the plugin should treat it like a typical GET request and
+not do anything special. Dillo would only allow those URLs to execute
+plugins from outside. For example:
+<a href="dpi:/mb/?submit=outside">Check your Dillo bookmarks</a>
+
+You could also just limit dpi execution to URLs with _no_ arguments, and
+specify that plugins should be written to expect that.
+
+Anyway, I want to let you know that my brother and I test all of our web
+work in Dillo. I use it regularly, even on fast computers.
+
+Laters,
+
+Ben Woolley
+http://ben.tautology.org
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.2.0 (FreeBSD)
+
+iD8DBQE980iv88ChLVDxFsIRAgLcAJwNhv+MSnLG2H0dSjM8sP2MHHbqTwCeJoLu
+gCpa56QHiw+udAsHUKP4hK4=
+=TEj+
+-----END PGP SIGNATURE----- 
+
+
+
+Re: [Dillo-dev]dpi bookmarks plugin
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-07 13:59
+
+Madis,
+
+> On Fri, 6 Dec 2002, Jorge Arellano Cid wrote:
+>
+> > I recognize that when designing it, I thought that having the
+> > dpis running locally would cut "in gross" all of those problems.
+> >
+> > After reading your email, I kept thinking about it, and two
+> > ideas remained:
+> >
+> > 1.- Only allow a dpi url from dpi-generated pages.
+> > 2.- Add a dpi command that asks the dpi-server for a key, and
+> > then use it to acknowledge permissions.
+> >
+> > The first is the easiest to implement, it just requires a check
+> > before allowing the dpi command to be issued. Is not even
+> > necessary to modify the protocol! (and in the event of a user
+> > longing to make a custom page, accessed as file, that uses dpi
+> > url references, it may then be served from an elementary dpi
+> > program).
+> >
+> > The second option is more cumbersome, and requires two actions,
+> > the key request, and including it in the dpi tag.
+>
+> keep it stupid, simple ;)
+
+BTW, I use Slackware!!!
+
+>
+> As i have understand, there are two types of dpi plugins -
+> protocol/mime handler plugins (like ftp://, https://, downloader) and
+> "feature" plugins (like bookmarks plugin). The second type uses dpi://
+> protocol in url. Is there any good reason, why links from non-dpi pages
+> to dpi:// pages should be allowed?
+
+The only one I've thought of was described above, and as the
+solution is quite simple, I don't see any good reason to allow
+links from non-dpi pages to dpi:// urls anymore.
+
+Does anyone see another reason?
+
+
+Cheers
+Jorge.- 
+
+
+
+Re: [Dillo-dev]dpi bookmarks plugin
+
+From: madis <madis@cy...> - 2002-12-07 13:01
+
+On Fri, 6 Dec 2002, Jorge Arellano Cid wrote:
+
+> I recognize that when designing it, I thought that having the
+> dpis running locally would cut "in gross" all of those problems.
+> 
+> After reading your email, I kept thinking about it, and two
+> ideas remained:
+> 
+> 1.- Only allow a dpi url from dpi-generated pages.
+> 2.- Add a dpi command that asks the dpi-server for a key, and
+> then use it to acknowledge permissions.
+> 
+> The first is the easiest to implement, it just requires a check
+> before allowing the dpi command to be issued. Is not even
+> necessary to modify the protocol! (and in the event of a user
+> longing to make a custom page, accessed as file, that uses dpi
+> url references, it may then be served from an elementary dpi
+> program).
+> 
+> The second option is more cumbersome, and requires two actions,
+> the key request, and including it in the dpi tag.
+
+keep it stupid, simple ;)
+
+As i have understand, there are two types of dpi plugins - 
+protocol/mime handler plugins (like ftp://, https://, downloader) and 
+"feature" plugins (like bookmarks plugin). The second type uses dpi:// 
+protocol in url. Is there any good reason, why links from non-dpi pages 
+to dpi:// pages should be allowed?
+
+-- 
+mzz 
+
+
+
+Re: [Dillo-dev]Dillo on NanoGtk
+
+From: Richard Tseng <rtseng@em...> - 2002-12-07 07:40
+
+Attachments: Message as HTML      
+
+Hi Mabo,
+We are developer of NanoGtk. Could you post your dillo port, so that we can
+have a look at it ? Great job on porting Dillo to NanoGTK/mips !!
+Richard Tseng
+Emsoft Limited
+http://www.emsoftltd.com
+----- Original Message -----
+From: 马波
+To: dillo-dev@li...
+Sent: Thursday, November 28, 2002 10:44 AM
+Subject: [Dillo-dev]Dillo on NanoGtk
+
+
+Hi, all
+
+Our team just ported Dillo from x86/X/Gtk+ to mips/NanoX/NanoGtk,
+everything went fine except scrolling, that is, when we browse a large page,
+we got scrollbars, but once I drag and drop the scrollbar, the page turns
+into chaos immediately. However, if I scrolled the page by using PageUP and
+PageDown buttons, everything is Ok.
+It looks like something goes wrong with the screen refreshment, which
+is to say, if you post too many screen-updating request by scrolling the
+page with scrollbar, the underlying refresh-request queue handler (NanoGDK?)
+just cannot fulfil its responsibilities, while if the request is moderate,
+the handler can manage it.
+So, based on the observation and my conjecture, I dived into NanoGtk and
+tried to resolve this problem:
+
+1.Scrolling request is sent by gtk_scrolled_window_set_vadjustment
+function
+2.gtk_scrolled_window_adjustment_changed is the scrolling signal handler,
+and it adds the window need to scrolling, scrolled_win, to resize queue by
+calling gtk_widget_queue_resize
+3.For a Container (Gtkscrolledwindow is a container)，the resizing handler
+is gtk_container_clear_resize_widgets
+5.BUT, this function just mark the container with GTK_PRIVATE_UNSET_FLAG
+(widget, GTK_RESIZE_NEEDED); and do nothing more!
+
+I was lost!!
+
+So, I came up with the second solution: Change the
+Adjustment->step_increment to Adjustment->page_increment, but it seems
+doesn't work also!
+
+Who can help me!
+
+mabo
+
+
+
+
+
+-------------------------------------------------------
+This S...net email is sponsored by: Get the new Palm Tungsten T
+handheld. Power & Color in a compact size!
+http://ads.so....net/cgi-bin/redirect.pl?palm0002en
+_______________________________________________
+Dillo-dev mailing list
+Dillo-dev@li...
+https://lists.so....net/lists/listinfo/dillo-dev 
+
+
+
+[Dillo-dev]Dillo (fwd)
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-06 23:56
+
+---------- Forwarded message ----------
+Date: Thu, 5 Dec 2002 20:23:27 +0000
+From: *** <stu@sp...>
+To: jcid@so...
+Subject: Dillo
+
+Hello
+
+First of all, wow really a neat browser!
+
+And it works just fine!! I'm using Vector Linux 2.0
+with 16 megs of RAM, and an old Cirrus Logic
+video card, and it does just fine!
+
+I tried Netscape.....I could retire if I had to load more than
+one graphic per page (turtle slow), I tried the Lynx Browser
+I can do it, but I would have to RElearn how to do stuff, and
+I did do it and can if need be.
+
+However, by chance I came across your website and browser
+and just had to give it a try! And it is eXactly what I needed!!
+
+thanks a bunch!!
+
+Stu Wilcox
+Madisonville, KY 
+
+
+
+Re: [Dillo-dev]dpi bookmarks plugin
+
+From: Jorge Arellano Cid <jcid@so...> - 2002-12-06 23:56
+
+Ben,
+
+> I just tried out the dpi1 bookmarks plugin, and I really like the concept.
+
+Thanks!
+
+I've only received a couple of tiny comments that kept me
+somewhat clueless about how it was understood/received.
+
+I know it's not easy to grasp and certainly studying it
+requires some time, but as for your comments, it looks as though
+you've got it right!
+
+
+> But I started wondering if someone could take advantage of a dpi URL to do
+> something improper.
+>
+> <html>
+> <body>
+> <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.">test</a>
+> <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." alt="test image">
+> </body>
+> </html>
+>
+> When I load that page, not only does the image alter my bookmarks, when I
+> click on the link the window closes (after altering my bookmarks). This
+> seems to be an issue similar to what is discussed in the HTTP 1.1 spec
+> section 15.1.3.
+
+Yes, I understand the issue.
+
+> Can POST data be sent instead? Section 9.5 says that POST should be used
+> for "extending a database through an append operation", which is what the
+> plugin actually does.
+>
+> Perhaps the plugin should check for a proper referral from
+> dpi:/bm/modify?operation=add_url&submit=submit. before modifying
+> anything.
+
+Yes, POST could eventually be added...
+
+
+> Perhaps change:
+> <dpi
+> cmd='open_url'
+> url='dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+> >
+> to:
+> <dpi
+> cmd='open_url'
+> url='dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+> ref='dpi:/bm/modify?operation=add_url&submit=submit.'
+> >
+> or:
+> <dpi
+> cmd='open_url'
+> url='dpi:/bm/modify'
+> post='operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+> >
+> or even:
+> <dpi
+> cmd='open_url'
+> url='dpi:/bm/modify'
+> ref='dpi:/bm/modify?operation=add_url&submit=submit.'
+> post='operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.'
+> >
+>
+> Do you already have some sort of plan for this issue?
+
+I recognize that when designing it, I thought that having the
+dpis running locally would cut "in gross" all of those problems.
+
+After reading your email, I kept thinking about it, and two
+ideas remained:
+
+1.- Only allow a dpi url from dpi-generated pages.
+2.- Add a dpi command that asks the dpi-server for a key, and
+then use it to acknowledge permissions.
+
+The first is the easiest to implement, it just requires a check
+before allowing the dpi command to be issued. Is not even
+necessary to modify the protocol! (and in the event of a user
+longing to make a custom page, accessed as file, that uses dpi
+url references, it may then be served from an elementary dpi
+program).
+
+The second option is more cumbersome, and requires two actions,
+the key request, and including it in the dpi tag.
+
+HTH.
+
+Cheers
+Jorge.- 
+
diff --git a/old/oldmail/index.html b/old/oldmail/index.html
new file mode 100644
index 0000000..7af82a6
--- /dev/null
+++ b/old/oldmail/index.html
@@ -0,0 +1,49 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Ancient dillo-dev mail</title>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8">
+</head>
+<body>
+Here are the early Dillo-dev archives as awkward flat text files.
+<table>
+<tr><td align="right">  53087 <td> <a href="199912.txt"> 199912 </a>
+<tr><td align="right">   8436 <td> <a href="200001.txt"> 200001 </a>
+<tr><td align="right">   7933 <td> <a href="200002.txt"> 200002 </a>
+<tr><td align="right">   5929 <td> <a href="200003.txt"> 200003 </a>
+<tr><td align="right">  25450 <td> <a href="200004.txt"> 200004 </a>
+<tr><td align="right">  12251 <td> <a href="200005.txt"> 200005 </a>
+<tr><td align="right">   8861 <td> <a href="200006.txt"> 200006 </a>
+<tr><td align="right">  45272 <td> <a href="200007.txt"> 200007 </a>
+<tr><td align="right"> 108568 <td> <a href="200008.txt"> 200008 </a>
+<tr><td align="right">  82194 <td> <a href="200009.txt"> 200009 </a>
+<tr><td align="right"> 124068 <td> <a href="200010.txt"> 200010 </a>
+<tr><td align="right">  63479 <td> <a href="200011.txt"> 200011 </a>
+<tr><td align="right">  92621 <td> <a href="200012.txt"> 200012 </a>
+<tr><td align="right">   9374 <td> <a href="200101.txt"> 200101 </a>
+<tr><td align="right">  40623 <td> <a href="200102.txt"> 200102 </a>
+<tr><td align="right">  49081 <td> <a href="200103.txt"> 200103 </a>
+<tr><td align="right">  43904 <td> <a href="200104.txt"> 200104 </a>
+<tr><td align="right">  77332 <td> <a href="200105.txt"> 200105 </a>
+<tr><td align="right">  40086 <td> <a href="200106.txt"> 200106 </a>
+<tr><td align="right">  17338 <td> <a href="200107.txt"> 200107 </a>
+<tr><td align="right">  89762 <td> <a href="200108.txt"> 200108 </a>
+<tr><td align="right">  91635 <td> <a href="200109.txt"> 200109 </a>
+<tr><td align="right"> 116977 <td> <a href="200110.txt"> 200110 </a>
+<tr><td align="right"> 120558 <td> <a href="200111.txt"> 200111 </a>
+<tr><td align="right"> 115068 <td> <a href="200112.txt"> 200112 </a>
+<tr><td align="right"> 113846 <td> <a href="200201.txt"> 200201 </a>
+<tr><td align="right"> 159307 <td> <a href="200202.txt"> 200202 </a>
+<tr><td align="right">  98349 <td> <a href="200203.txt"> 200203 </a>
+<tr><td align="right"> 128370 <td> <a href="200204.txt"> 200204 </a>
+<tr><td align="right"> 154186 <td> <a href="200205.txt"> 200205 </a>
+<tr><td align="right"> 178390 <td> <a href="200206.txt"> 200206 </a>
+<tr><td align="right">  59061 <td> <a href="200207.txt"> 200207 </a>
+<tr><td align="right">  57599 <td> <a href="200208.txt"> 200208 </a>
+<tr><td align="right">  37615 <td> <a href="200209.txt"> 200209 </a>
+<tr><td align="right">  61769 <td> <a href="200210.txt"> 200210 </a>
+<tr><td align="right">  47866 <td> <a href="200211.txt"> 200211 </a>
+<tr><td align="right">  22391 <td> <a href="200212.txt"> 200212 </a>
+</table>
+</body>
+</html>