- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Jorge Arellano Cid

On Thu, 21 Aug 2003, Joerg Sonnenberger wrote: > On Wed, Aug 20, 2003 at 01:02:40PM -0400, Jorge Arellano Cid wrote: > [snip] > > Don't panic! > > > > The mkdtemp() issue needs to be solved. Thanks for reporting > > the problem. > > > > If configure has a way to deal with it, we'd need to find it > > out how. If not, just to think of something else (as implementing > > a custom function as you did, or see if there's a wrapper in glib > > etc.) > > > > I'm open to suggestions. > > Well, you could add a portable implementation e.g. from the *BSD libc > to dillo and a AC_CHECK_FUNCS to autoconf to conditionally include > that code. This is the way coreutils and other GNU packages work. > > I'll send you a working copy if you want. Of course! It'd be of great help. Cheers Jorge.-

Aug. 23, 2003

Re: [Dillo-dev] [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

Sorry, it looks the attachment was truncated. Here it is again, gzipped.

Aug. 22, 2003

[PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

[Henning, you may be interested: the patch implements a --reload option] Hi, To implement the server and remote commands feature in Dillo, I'm going to go step by step. First, I'll implement commands to control Dillo at startup time, then I'll implement the server mode (where a Dillo instance can send the aforementioned commands to another Dillo instance). This is because I may try two differents approaches for the server mode part and because the commands are just a generalization of the command line options and can be implemented separately. Here is my first step: implement commands (like -c "open(URL)"). Patch is attached and is against CVS version. This is a generalization of the command line interface, and in fact, most of the old command line options are translated to a Dillo -c command. The advantage of such approach is that the commands can take optional parameters, like in: dillo -c "open(URL newwindow reload=10 fullwindow=yes)" which is approximately equivalent to: dillo -f -r 10 URL The commands are passed to Dillo as arguments to the -c, --command command line option: dillo -c "open(http://www.google.com)" 1. Command Syntax The argument to the -c command line option is of the form: CMD([STRING][ PARAM=VALUE]...) CMD: command name STRING: first and generic argument: in general a URL or yes|no PARAM: name of optional parameter VALUE: value of optional parameter. Currently, only booleans (yes|no) and integer values are supported. Boolean value can be omitted, in which case the value is considered to be "yes". Integer value cannot be omitted. Parameters are separated with a single space (no commas, to simplify the parser) Commands can be divided into two groups: actions commands, and options commands 2. Action Commands: They do some action: currently implemented commands: open(URL [ fullwindow[=yes|no]] [ reload=SECONDS] [ spamsafe[=yes|no]] [ xid=XID]) parameters speak for themselves. The "reload" parameter is a new feature: it allows to reload the URL each SECONDS seconds. The reload is halted when the page is not viewed and restarted if the user comes back to it. exit() exit the instance. This will be useful when passed to another Dillo instance running as a server. Other commands can be added. The framework is quite flexible and extensible. 3. Options Commands These commands set some options that will affect the following commands. For example, the parameters used in the open() command act only on that particular URL. But it can be useful to be able to set some defaults values. The currently implemented commands that influence these defaults are: fullwindow([yes|no]) reload(SECONDS) spamsafe([yes|no]) xid(XID) all open() commands that come after these options commands will have these default values, unless explicitly overridden. 4. Examples: dillo -c "open(http://www.google.com)" -c "open(file:///home/mhadasht/test.html newwindow spamsafe)" will open two windows: the first with google, and the second with the local file opened in spamsafe mode. dillo -c "reload(10)" -c "open(http://www.freshmeat.net)" -c "open(http://news.google.com newwindow)" will open 2 windows and will reload both URLs each 10s. This is equivalent to: dillo --reload 10 http://www.freshmeat.net http://news.google.com 5. Implementation details: 5.1. Command Line Parsing Command line options other than the help/version options are translated into a -c command and stored in a list. The list of commands is then executed (or, when the server mode will is implemented, sent to another Dillo instance) 5.2. Reload Function a URL can be set to auto-reload itself if it is currently viewed. For that, a new member (reload_interval [milliseconds]) to DilloUrl is added and set with a_Url_set_reload(). Each BrowserWindow can trigger a timer function if the viewed URL (Nav_open_url()) has a non-zero reload_interval. (As soon as another URL is viewed, or when the BrowserWindow is destroyed, the eventually pending timeout function is removed.) The timer is of the one-shot type: when it is triggered, it requests its BrowserWindow to reload the URL, then it stops itself. There is currently no UI to start/stop an auto-reload of a URL, but it is just a matter of using a_Url_set_reload() to a non-zero or a zero reload interval. 6. Remark The -c command and the normal command line options can be seen as two ways of doing the same thing: passing commands to Dillo. But the -c command is more generic and flexible and has a more powerful syntax. 7. Future Plans I plan to implement the server mode. After reading the dpi doc and source, I found that it cannot be used to make Dillo act as a plugin unless we accept to have only one Dillo server. This is because the socket names are tightly linked to the service name. Each service has only one socket. Whereas Dillo servers must have a distinct socket. If the we add another argument to the "start_plugin" cmd: <dpi cmd="start_plugin" msg="dillo" param="SERVER_NAME"> and if we modify the socket naming scheme, then it could be possible. I have to think about that again. But I may still use the communication infrastructure of the dpi. If I find this overkill, I'll revert to the straightforward approach I used before, that is, I won't use the dpi framework. OK, it's late, I hope I managed to be somewhat clear... Cheers. -- Melvin Hadasht

Aug. 22, 2003

finger plugin

by Andreas Schweitzer

Hi, as promised in a previous mail. Here is the still quite rough finger dpi intended for interested developers : http://www.hs.uni-hamburg.de/~stcd102/dillo/ http://www.hs.uni-hamburg.de/~stcd102/dillo/adpi-0.1.tar.gz It's configure.in is essentially dillo's configure.in :-) you could actually just put finger.c in the ./dpi/ subdirectory of dillo and adjust Makefile.am accordingly. but now I have an actual distribution :-) In the tarball is also what I call so far a library ... well, or at least the routines that have been re-used over and over. Lastly, there is also an experiment : a term plugin, which lets you call arbitrary programs from within dillo (read the source, though !) Installation: just copy the created .dpi files to ~/.dillo/ and edit ~/.dillo/dpidrc (as long as this file exists), then go to dpi:/finger/ If you want dillo to actually recognize the finger URL you will have to edit src/IO/Url.c and sr/capi.c. Search for the string "ftp" inside these two files and duplicate the relevant part for the finger protocol. Or await how dillo evolves :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 22, 2003

Re: [Dillo-dev] [PATCH] version 9 of tab+frame patch, frame support 'complete' (?)

by Andreas Schweitzer

Hi, > http://www.geocities.com/ikbenfrank/ > > More specifically for both versions: > > Dillo 0.8.0-pre (CVS) > ===================== > http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz > size: 66661 bytes (gzipped, as downloaded) > 281416 bytes (uncompressed) > md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) > c3b6ee3095d4b230a78cf836516e0023 (uncompressed) > > Dillo 0.7.3 (release) > ===================== > http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz > size: 93929 bytes (gzipped, as downloaded) > 399156 bytes (uncompressed) > md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) > 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) or again from my mirror. This time : http://www.hs.uni-hamburg.de/~stcd102/dillo/ Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 22, 2003

Re: [Dillo-dev] Some points about the dpi's

by Andreas Schweitzer

Hi, This e-mail account was cut off the net (literally ...) for 2 days, hence the delay in answering. > > > However, this brings me to my questions : > > > 1) will there be a generic URL->dpi mapping ? > > > I could imagine that dpid could actually handle that. > > Yes, but I think you mean URL->SERVICE, a dpi is just an implementation > > of a service. > > Ditto!. I understand. I think my original wording was not the best. But in the end, if the user can easily manage and configure URL->(via services)->dpi-program w/o compiling dillo, (s)he will be happy :-) > > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > > > or "fallback handler" or "univeral URL handler" or the like. > > > It will give the user the possibility to start an external > > > program for handling certain URL's. > > > In fact, with my current dpi, this is quite easy > > > to do :-). > > OK, but I think we should hold off on 1 and 1b until I make the next > > dpid patch available. > > Me too. I'll put it on hold :-) > > > 3) About configuration (and I think I read comments about this > > > in the code), shouldn't there be only one config file ? > > > and not dpidrc and possibly different configs for all the dpis ? > > > maybe even merge cookiesrc with dillorc ? > > Yes, my next dpid patch gets rid of dpidrc. > > This is the only point I have some doubts. > > I've always thought that it is a good idea to keep separate > configuration files for dillo, and its dpis (and dpid). > > One file with a lengthy collection of not tightly-related > configuration directives sounds to me as low-cohesion and > high-coupling (I'm not sure about what are the words in english > for those technical terms. In spanish it is: cohesión y > acoplamiento). OTOH, for a user (like myself) who likes editing configuration files by hand, it is more convenient to have it in one place ... just an opinion though :-) ... but ... as you say : > The idea of having a preferences plugin providing an HTML GUI > for: dillo, dpid, and each dpi, is what I picture in the long > term. Something like: > > .-------. > | Dillo | Dpid | ftp | https | .... > | ---------------------------------------------------. ^^^^^ should be named "Plugin Management" or the like :-) this is of course also acceptable. Thinking a bit longer ... I think Mozilla is very much like that. You can configure Mozilla from within and it puts its config files scattered thorugh ~/.mozilla/ within a maze of directories. Every time I look inside that directory trying to fix things by hand, I am completely lost ... hence my desire for a one stop config file :-) > > > P.S.: I also have some ideas about improving the ftp plugin. There > > > is a pretty simple ftp library, > > Which one? http://nbpfaus.net/~pfau/ftplib/ seems to be relatively old, but the ftp protocol hasn't really changed that much :-) I *think* it is also used in some other applications. > > > and I think it does make sense to > > > actually log in an ftp server and stay logged in for all the operations. > > > (unlike wget which logs in and out for every file). This is not only > > > faster but helps with busy ftp sites, too ! > > Developing the ftp plugin is a high priority and your help here would be > > appreciated. > > Just as hinted in the comments inside ftp.c! > > Note that you only need to provide the HTML output for > FTP directories. and for files the user clicks on, like text files, images and even html files that exist in the ftp directory. > Downloads are to be bounced back to dillo for it > to forward them to the downloads plugin (that way the whole > downloading is centralized in a single place, stats can be > provided etc.). I have been thinking back and forth about that point. I think what I will end up doing is at least implementing the actual download from within the ftp plugin. Weather it will be included in the "official" one, or if I make 2 versions (a basic one and a fancy one), or whatever, remains to be seen. I guess one could also think about sending the data from the ftp plugin directly to the download plugin w/o relaying it via dillo. > I left some code inside ftp.c that shows a beautiful trick to > tell whether an FTP URL is a directory when using wget (it > probably can be re-used). I saw it, and this is indeed a problem. I checked the ftp rfc and there is no command that will tell me if something is a regular file or a directory. Also, after checking the ftp rfc and the url syntax rfc (rfc 1738) especially, section 3.2.4 and 3.2.5 makes the logging into ftp sites somewhat problematic. Essentially, it says, unless you actually travel an ftp site like within an interactive client, there is no way of telling how to get from ftp://site.com/foo/bar/ (which could be one link in an html page) to ftp://site.com/foo2/bar2/ (which could be a 2nd link in an html page) > The most time consuming task with this approach is to parse the > ASCII from the ftp server into HTML (easy in theory but you'll > find different layouts). In fact that's what I did with and > ancient FTP plugin I wrote. > > If the library you think of using writes HTML itself, great! If > not, just tell me to dig in for my old FTP code, and to send it > to you. I think either way it could be useful to look at :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 22, 2003

[PATCH] version 9 of tab+frame patch, frame support 'complete' (?)

by Frank de Lange

Hi'all, The next version (9) of my tab patch is ready (see bottom of this message for download instructions). Frameset support is now almost complete, manual resize has been added, targeted link functionality has been improved, most frame-related attributes actually work, try it I'd say... Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. Other new features (since the last version): - CTRL-U pops up the view source window - CTRL-B bookmarks the current page - CTRL-S pops up save page window New preferences frame_blank_in_tab=([NO]/YES): show frames with "_blank" target in new tab (instead of new window) (read the Browser_Frames.txt and Browser_Tabs.txt documents (in the doc/ directory) and the dillorc file for more info on tab- and frame-related preferences (after applying the patch, of course...)) Of course, the patch also fixes some bugs (and possibly introduces new ones). More on frame/iframe support ============================ Frameset support is based on a new widget (GtkFrameset) which implements <frameset> as specified in xhtml-dtd-frameset. This widget is not Dillo-specific, so it can in theory be used in any GTK program. It is a pure GTK widget, not rooted in Dw. It does not provide any special support for Dw-specific features (eg. the full-screen-off-button is not displayed in the widget). I might make a special version for Dillo after the GTK-version has been debugged sufficiently. What works: - loading (nested) framesets, displaying frames at their appropriate location and appropriate size, including margin width/height and scrolling. - loading (nested) iframes, displaying iframes at their appropriate location and with (mostly) appropriate size and alignment. - manual frame resize (row, column or both at the same time (drag border crossing - this does not work between nested framesets) - all frame-related menu options (in the popup menu). Frame menus can be accessed using the 'This Frame...' button in the popup menu, nested framesets have their own 'This Frameset...' menu. This way, Dillo allows you to limit actions to a subset of a framed document, eg. you can search for text in just one frame/iframe/frameset. Top-level menu options usually refer to the whole document (the frameset). An exception to this is the 'Jump To' option, which refers to the frame in which the menu was opened (question: should this contain the anchors for all frames?). Use the 'Show only this Frame' option in the Frame Options menu to get a full-page view of a frame. Same for 'Show only this Frameset'. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - the frameborder attribute works, but dw_gtk_scrolled_frame always draws a (focus) shadow around itself - even with the border size is set to 0. This makes it impossible to draw frames seamlessly. Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20030821-tabs.patch.gz unpatched: 285536 bytes patched, no tabs, no frames: 290444 bytes patched, with tabs, no frames: 298092 bytes patched, no tabs, with frames: 307116 bytes patched, with tabs, with frames: 314892 bytes version: 0.7.3 patch: dillo-0.7.3-20030821-tabs.patch.gz unpatched: 284416 bytes patched, no tabs, no frames: 289708 bytes patched, with tabs, no frames: 297324 bytes patched, no tabs, with frames: 305708 bytes patched, with tabs, with frames: 313452 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Judge for yourself if the features are worth their weight in bytes... Download instructions ===================== There are now two versions of the patch, one for Dillo 0.7.3 (release) and one for Dillo 0.8.0-pre (CVS). Make sure to download the correct version for the Dillo source you want to patch! If you patch the CVS source, do not forget to run ./autogen.sh after applying the patch. The CVS patch is made against 20030820 CVS, while the 0.7.3 patch is made against Dillo-0.7.3.tar.bz2 (the source tarball on the main Dillo website). Both versions of the patch can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically for both versions: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz size: 66661 bytes (gzipped, as downloaded) 281416 bytes (uncompressed) md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) c3b6ee3095d4b230a78cf836516e0023 (uncompressed) Dillo 0.7.3 (release) ===================== http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz size: 93929 bytes (gzipped, as downloaded) 399156 bytes (uncompressed) md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) As always, check the site for the most recent version: That's all for now, Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 21, 2003

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Joerg Sonnenberger

On Wed, Aug 20, 2003 at 01:02:40PM -0400, Jorge Arellano Cid wrote: [snip] > Don't panic! > > The mkdtemp() issue needs to be solved. Thanks for reporting > the problem. > > If configure has a way to deal with it, we'd need to find it > out how. If not, just to think of something else (as implementing > a custom function as you did, or see if there's a wrapper in glib > etc.) > > I'm open to suggestions. Well, you could add a portable implementation e.g. from the *BSD libc to dillo and a AC_CHECK_FUNCS to autoconf to conditionally include that code. This is the way coreutils and other GNU packages work. I'll send you a working copy if you want. Joerg > > > Cheers > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 21, 2003

Re: [Dillo-dev] Some points about the dpi's

by Jorge Arellano Cid

Andreas, Here go my comments... > On Tue, Aug 19, 2003 at 12:33:53AM +0200, Andreas Schweitzer wrote: > > Hi, > > > > All right, I did it. I made my first dpi ! :-) (heavily > That's great, I hope to make a new patch for dpid available soon. Good! That means it's understandable now! :-) > > > > The second caveat : dillo does not automatically call this plugin > > upon such a URL. It is easy to patch dillo, though. > Creating a new dpi still requires more effort than it should. Eventually there'll be a mechanism for automating the inclusion of new URL-handling plugins. We're working on it with Ferdi. > > > However, this brings me to my questions : > > 1) will there be a generic URL->dpi mapping ? > > I could imagine that dpid could actually handle that. > Yes, but I think you mean URL->SERVICE, a dpi is just an implementation > of a service. Ditto!. The distinction is relevant because there may be several different dpi programs that implement the same service. The user makes a choice and uses _one_ of them. > > > I think, one would need to only modify IO/Url.c and > > capi.c to simply pass through EVERYTHING to the dpi framework. > > However, some "core URL handling dpi's" that will become > > part of the dillo package can probably stay hardcoded in dillo. And attached to a service name... If there's a dpi for handling it, no problem. If not, warn that is not an available service. > > > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > > or "fallback handler" or "univeral URL handler" or the like. > > It will give the user the possibility to start an external > > program for handling certain URL's. > > In fact, with my current dpi, this is quite easy > > to do :-). > OK, but I think we should hold off on 1 and 1b until I make the next > dpid patch available. Me too. > > > 2) Does it make sense to write a library for all the dpi's ? > > I, for myself, did start simply collecting all the functions > > that I found in dpi/ and are used by many dpi's and put them > > in a library. Like the various send_stream functions or the > > get_attr_value function, or the encoding and decoding functions. > Yes, that would be very useful. Your strategy of creating a library > of functions which are actually used by many dpis is a good one. > > > 3) About configuration (and I think I read comments about this > > in the code), shouldn't there be only one config file ? > > and not dpidrc and possibly different configs for all the dpis ? > > maybe even merge cookiesrc with dillorc ? > Yes, my next dpid patch gets rid of dpidrc. This is the only point I have some doubts. I've always thought that it is a good idea to keep separate configuration files for dillo, and its dpis (and dpid). One file with a lengthy collection of not tightly-related configuration directives sounds to me as low-cohesion and high-coupling (I'm not sure about what are the words in english for those technical terms. In spanish it is: cohesión y acoplamiento). The idea of having a preferences plugin providing an HTML GUI for: dillo, dpid, and each dpi, is what I picture in the long term. Something like: .-------. | Dillo | Dpid | ftp | https | .... | ---------------------------------------------------. | | | <dillo's preferences here> | | ... | | '-----------------------------------------------------------' Restore Apply Save I think that is easier and cleaner with separate configuration files. Also, the rc for each dpi would be located in its own dpi directory tree (available in next dpid patch). Note that the task of the preferences dpi is to change the rc file providing a nice GUI, not to make the changes effective. Taking the changes into account is a thing that each program knows better. The preferences dpi will "tell" that program to reread the rc and update its state, probably through dpidc or dpip. > > > I guess some of this (or all of it ?) is being worked on > > by some of you. Maybe this mail helps to avoid duplication :-) Yes it is! > > > > Cheers, > > Andreas > > > > P.S.: I also have some ideas about improving the ftp plugin. There > > is a pretty simple ftp library, Which one? > > and I think it does make sense to > > actually log in an ftp server and stay logged in for all the operations. > > (unlike wget which logs in and out for every file). This is not only > > faster but helps with busy ftp sites, too ! > Developing the ftp plugin is a high priority and your help here would be > appreciated. Just as hinted in the comments inside ftp.c! Note that you only need to provide the HTML output for FTP directories. Downloads are to be bounced back to dillo for it to forward them to the downloads plugin (that way the whole downloading is centralized in a single place, stats can be provided etc.). I left some code inside ftp.c that shows a beautiful trick to tell whether an FTP URL is a directory when using wget (it probably can be re-used). The most time consuming task with this approach is to parse the ASCII from the ftp server into HTML (easy in theory but you'll find different layouts). In fact that's what I did with and ancient FTP plugin I wrote. If the library you think of using writes HTML itself, great! If not, just tell me to dig in for my old FTP code, and to send it to you. Cheers Jorge.-

Aug. 20, 2003

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Jorge Arellano Cid

David, On Tue, 12 Aug 2003, David McKee wrote: > Folks, > Updated my CVS at home (Debian 3.0) to 0.8.0pre the other day, and I > like what I see. When I tried to do the same at work today (Redhat 6.2), I > had problems building. Dpid uses mkdtemp() which was introduced in glibc > 2.1.9. However, ./configure has no problems with my glibc 2.1.3. > > Submitted as bug 487. > > This constitutes a change from the 0.7 days when (according to the > Compatibility web page) any glibc2 would do. > > Introducing (by hand) a definition of mkdtemp() I found on the web solved > all my problems. > > Browsing the source suggests that you are not in the habit of carrying > around lot of little libc bits---and the associated preprocessor code > munging---for systems with variant or insufficient libc's. That is fine. It > keeps the code base small and simple, but perhaps ./configure should look > out for these things. > > So does this mean some previously working libc's are now going to be > excluded, that more conditional compilation stuff will need to go in, or > that dpid needs some work to increase it's universal compatibility? Don't panic! The mkdtemp() issue needs to be solved. Thanks for reporting the problem. If configure has a way to deal with it, we'd need to find it out how. If not, just to think of something else (as implementing a custom function as you did, or see if there's a wrapper in glib etc.) I'm open to suggestions. Cheers Jorge.-

Aug. 20, 2003