History

[Dillo-dev]Skript for keeping a history From: Johannes Hofmann - 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(""" History """) end re = /Nav_open_url: Url=>([^<]+)" + url[1] + "
\n") output.flush end end [Dillo-dev]Compiling 0.6.3 png trouble ? From: Richard - 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 - 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 - 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 - 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 - 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. - 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 - 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 - 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 - 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 - 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

. 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  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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 2001-12-20 17:28

Date |Mon, 17 Dec 2001 21:18:05 -0300 (CLST)
From |Jorge Arellano Cid 

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  - 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


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:  or  



Re: [Dillo-dev]Dillo preferences tool

From: Grigory Bakunov  - 2001-12-20 17:13

Date |Thu, 20 Dec 2001 00:37:15 +0000 (GMT)
From |Robert J Thomson 

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:  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 2001-12-16 08:57

Date |Sun, 16 Dec 2001 10:57:08 +0000
From |Martynas Jocius 

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  - 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  - 2001-12-15 00:27

On 08 Dec 2001 15:37:56 -0600
Lars Clausen  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  - 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  - 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  - 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  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  - 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  - 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  - 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  - 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  - 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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...", "L", bw,
a_Commands_openurl_callback, bw);
- /*
Menu_add(file_menu, "_Preferences", "E", bw,
a_Commands_prefs_callback, bw);=20
- */
Menu_add(file_menu, "Close Window", "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  - 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  - 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  - 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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  - 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  - 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 "\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  - 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  - 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  - 2001-12-07 02:56

Michael Taht  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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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  - 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