Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa01520; 26 Dec 96 22:47 PST To: jay@JIMI.CS.UNLV.EDU Subject: bug-chimera may 95 Date: Thu, 26 Dec 1996 22:47:56 -0800 From: Jay Nietling ------- Forwarded Messages Received: from tango.rahul.net by JIMI.CS.UNLV.EDU id aa25879; 1 May 95 12:23 PDT Received: from dandelion.com by tango.rahul.net with SMTP id AA10617 (5.67b8/IDA-1.5 for ); Mon, 1 May 1995 12:23:24 -0700 Received: (from lnz@localhost) by dandelion.com (8.6.12/8.6.12) id MAA08770; Mon, 1 May 1995 12:23:22 -0700 Date: Mon, 1 May 1995 12:23:22 -0700 From: "Leonard N. Zubkoff" Message-Id: <199505011923.MAA08770@dandelion.com> To: bug-chimera@cs.unlv.edu Subject: Chimera 1.65 bug There is a bug in libhtmlw where large documents will not be scrolled properly. The problem is that the scroll height is typed Dimension in some places, and that is only an unsigned short. The following change fixes the problems I've actually detected, but this entire file should probably be checked over carefully for use of data types that are too small. Leonard - --- HTML.c- Fri Mar 24 22:43:21 1995 +++ HTML.c Mon May 1 12:19:09 1995 @@ -693,8 +693,8 @@ static void setScrollBar (sb, topPosition, totalLength, currentLength) Widget sb; - -Position topPosition; - -Dimension totalLength, currentLength; +int topPosition; +int totalLength, currentLength; { float top = (float) topPosition / (float) (totalLength); float shown = (float) currentLength / (float) (totalLength); @@ -949,7 +949,7 @@ float scrollDir = (int) call_data < 0 ? -0.3 : 0.3; HTMLWidget hw = (HTMLWidget) client_data; int value, maxv; - - Dimension totalLength, currentLength; + int totalLength, currentLength; if (w == hw->html.vbar) { ------- Message 2 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa07813; 1 May 95 17:03 PDT To: "Leonard N. Zubkoff" cc: bug-chimera@cs.unlv.edu Subject: Re: Chimera 1.65 bug In-reply-to: Your message of "Mon, 01 May 1995 12:23:22 PDT." <199505011923.MAA08770@dandelion.com> Date: Mon, 01 May 1995 17:03:47 -0700 From: John Kilburg Thanks for the patch. Just as a note to you and to everyone on the list: I am incorporating the NCSA 2.6b1 HTML widget into the next chimera. It has support for tables. -john >There is a bug in libhtmlw where large documents will not be scrolled properly . >The problem is that the scroll height is typed Dimension in some places, and >that is only an unsigned short. The following change fixes the problems I've >actually detected, but this entire file should probably be checked over >carefully for use of data types that are too small. ------- Message 3 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa15876; 1 May 95 21:10 PDT Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Tue, 02 May 95 00:09:41 -0400 From: Jim Rees To: Chimera Lovers Date: Tue, 02 May 1995 00:09:40 -0400 Subject: unneeded page redisplays Sender: rees@citi.umich.edu If you click on a link that uses an external viewer, chimera redisplays the current page even though it hasn't changed. This can be annoying if it's a big page with lots of inline images on a slow machine. Has anyone noticed this? Does anyone have a fix? ------- Message 4 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa16198; 1 May 95 21:19 PDT To: Jim Rees cc: Chimera Lovers Subject: Re: unneeded page redisplays In-reply-to: Your message of "Tue, 02 May 1995 00:09:40 EDT." Date: Mon, 01 May 1995 21:19:43 -0700 From: John Kilburg >If you click on a link that uses an external viewer, chimera redisplays the >current page even though it hasn't changed. This can be annoying if it's a >big page with lots of inline images on a slow machine. Has anyone noticed >this? Does anyone have a fix? This is intentional. If I remember correctly, the reason this is done is because the external viewer can mess with the colors so the inline images have to be redisplayed. Doing a redisplay was a quick fix. If you don't care about the colors then you can move DisplayCurrent() in HandleDoc() to get only called only when the document is "text/html". If the colors get messed up then you can fix them by clicking on "source" and "back". -john ------- Message 5 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id ab16272; 1 May 95 21:28 PDT Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Tue, 02 May 95 00:27:58 -0400 From: Jim Rees To: Chimera Lovers Date: Tue, 02 May 1995 00:27:57 -0400 Subject: fix for unneeded redisplay Sender: rees@citi.umich.edu Please try this fix for the unneeded page redisplay after starting an external viewer. It looks right and seems to work, but I haven't tested it extensively. I'm including two diffs here, since my main.c is already patched. The first has just my change, and the second includes Roman's fixes. % diff -cb main.c~ main.c *** main.c~ Thu Apr 13 19:28:23 1995 - --- main.c Tue May 2 00:21:41 1995 *************** *** 1000,1006 **** else { DestroyDocument(d); ! d = NULL; } } else - --- 1000,1006 ---- else { DestroyDocument(d); ! return; } } else % diff -cb main.c- main.c *** main.c- Fri Mar 31 20:45:19 1995 - --- main.c Tue May 2 00:21:41 1995 *************** *** 121,126 **** - --- 121,128 ---- offset(showURL), XtRImmediate, (XtPointer)True }, { "showTitle", XtCBoolean, XtRBoolean, sizeof(Boolean), offset(showTitle), XtRImmediate, (XtPointer)True }, + { "anchorDisplay", XtCBoolean, XtRBoolean, sizeof(Boolean), + offset(anchorDisplay), XtRImmediate, (XtPointer)False }, { "button1Box", "BoxList", XtRString, sizeof(char *), offset(button1Box), XtRString, (XtPointer)BUTTON_LIST }, { "button2Box", "BoxList", XtRString, sizeof(char *), *************** *** 918,927 **** } /* ! * Convert needs to be called in case there is a transfer or content ! * encoding. */ ! if (d->ptext == NULL) { /* * This frightens me. I know it is bad but I can't think of anything - --- 920,929 ---- } /* ! * Convert needs to be called in case there is a content transfer or content ! * encoding. But not for downloads, says Roman. */ ! if (d->ptext == NULL && ! download) { /* * This frightens me. I know it is bad but I can't think of anything *************** *** 949,955 **** if (d->status == DS_OK && (download || (d->content == NULL && d->pcontent == NULL))) { ! CreateStrReq("filename", root.savestr, False, SaveOCallback, SaveDCallback, (XtPointer)d); } else if ((d->content != NULL && strcasecmp(d->content, "text/html") == 0) || - --- 951,976 ---- if (d->status == DS_OK && (download || (d->content == NULL && d->pcontent == NULL))) { ! ! /* Let's offer the save the downloaded file under the same name. ! Roman Czyborra, 1995-04-13 */ ! ! char *filename=NULL, *basename; int length; ! ! if (d->up) if (filename= d->up->filename) if (length = strlen(filename)) ! { ! if (filename[length-1]=='/') ! { ! filename[length-1]='\0'; ! } ! if (basename = strrchr (filename, '/')) ! { ! filename = basename + 1; ! } ! } ! if (! filename) filename=""; ! ! CreateStrReq("filename", filename, False, SaveOCallback, SaveDCallback, (XtPointer)d); } else if ((d->content != NULL && strcasecmp(d->content, "text/html") == 0) || *************** *** 979,985 **** else { DestroyDocument(d); ! d = NULL; } } else - --- 1000,1006 ---- else { DestroyDocument(d); ! return; } } else *************** *** 1064,1069 **** - --- 1085,1107 ---- } return; + } + + /* rwmcm */ + /* + * AnchorURLDisplay + * + * Called when the mouse moves over an anchor + */ + void + AnchorURLDisplay(w, c) + Widget w; + char *c; + { + Arg args[5]; + + XtSetArg(args[0], XtNlabel, c); + XtSetValues(root.anchordisplay,args,1); } /* ------- Message 6 Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa29191; 2 May 95 6:56 PDT Received: from titanic.cs.tu-berlin.de (czyborra@titanic.cs.tu-berlin.de [130.149.18.9]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id PAA27923; Tue, 2 May 1995 15:55:08 +0200 Received: (czyborra@localhost) by titanic.cs.tu-berlin.de (8.6.10/8.6.6) id PAA25249; Tue, 2 May 1995 15:55:02 +0200 From: Roman Czyborra To: bug-chimera@cs.unlv.edu Cc: mosaic-x@ncsa.uiuc.edu Subject: HTML 3 tables In-Reply-To: <199505020026.CAA18033@opal.cs.tu-berlin.de> by john@cephas.isri.unlv.edu dated 1995-5- 1 17:03:47 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 02 May 1995 15:55:01 +0200 Message-ID: John Kilburg wrote: > I am incorporating the NCSA 2.6b1 HTML widget into the next chimera. > It has support for tables. This is certainly a nice thing to hear although it seems to me like the libhtmlw/2.6b1 table support is still broken. If you look at https://www.cs.tu-berlin.de/fb13/studiengebiete.html Mosaic 2.5 and 2.6b1 display only the first word of each table entry. Hence this page is even more readable with Chimera 1.65. Arena 0.96 and Netscape 1.1 get the table right, so I doubt it's our fault. ------- Message 7 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa18801; 3 May 95 23:42 PDT To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: 2.0 inline images Date: Wed, 03 May 1995 23:42:32 -0700 From: John Kilburg Inline image handling in 2.0 will be different than what you're used to. The I/O is event driven so the old way of doing image rendering won't work. In 2.0, it works like this: - - if the dimensions of the inline image is included in the HTML then the image is rendered as soon as it is downloaded. This works really well so far. - - if the dimensions are not included then the image is downloaded but the rendering is deferred for some number of seconds (currently 10 but it will be configurable) and all images that do not have the dimensions specified will be rendered. This causes the entire page to be reformatted. - - if the dimensions are incorrect then the images are treated as if they weren't specified. I will eventually change it to figure out the image size from the image itself but that might be work. Comments? I will probably release an alpha version this weekend to let the curious to check it out. -john ------- Message 8 Received: from rosebud.turing.toronto.edu by JIMI.CS.UNLV.EDU id aa27836; 4 May 95 5:07 PDT Received: by turing.toronto.edu id <5379>; Thu, 4 May 1995 08:06:55 -0400 From: Smarasderagd To: bug-chimera@cephas.ISRI.UNLV.EDU, john@cephas.ISRI.UNLV.EDU Subject: Re: 2.0 inline images Message-Id: <95May4.080655edt.5379@turing.toronto.edu> Date: Thu, 4 May 1995 08:06:47 -0400 I've been thinking about colour allocation. Does the HTML widget reallocate colours for the inline images in view as the page is scrolled? If it doesn't, it might be good to quantize/dither the inline images in a page to a common colormap before displaying. I haven't looked at the code for this so I may be talking nonsense. Another approach to colour handling would be to slam everything to N shades of gray. With jpegs this is easy enough, but can the internal GIF converter do this? Finally, there's the possibility of supporting PNG, the new image format cooked up to avoid compression patents, and fill some gaps in existing image formats. The latest draft is at https://sunsite.unc.edu/boutell/png.html. Among many nice features this format has is an optional gamma correction chunk, to guide conversion of image data for different displays -- the draft has a nice explanation of this. Just some random ideas, feel free to ignore. ------- Message 9 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa01512; 4 May 95 7:39 PDT Received: from citi.umich.edu by citi.umich.edu for smarry@turing.toronto.edu bug-chimera@cs.unlv.edu with SMTP; Thu, 04 May 95 10:38:42 -0400 From: Jim Rees To: Smarasderagd Cc: Chimera Lovers Date: Thu, 04 May 1995 10:38:41 -0400 Subject: Re: 2.0 inline images Sender: rees@citi.umich.edu In-Reply-To: Smarasderagd, Thu, 04 May 1995 08:06:47 EDT I've been thinking about colour allocation. Does the HTML widget reallocate colours for the inline images in view as the page is scrolled? No, it does not. There is certainly room for improvement in the way color cells are allocated. It's been a while since I looked at this, but here is roughly how it works. First, each inline image is reduced to some number of colors, specified by the maxColors resource (default 256). Then each of the remaining colors is allocated. If all the cells are taken, then the closest available color is used instead. Notice that if the first image uses all 256 colors, then the next image won't get any colors at all, but will have to make do with the colors that the first image allocated. For this reason, I set maxColors to 48. So I get about 5 inline images before running out of colors. Ideally, one would examine all the images and reduce to the best set of colors for the page. This is hard. Somewhat easier would be to count the number of images, and reduce each image to maxColors/nImages. This might be a bit too aggressive, since it wouldn't take advantage of shared colors. It would help a lot if web page authors would reduce the number of colors in their inline images, and use a shared color map for all the images on a page, but most don't bother. I don't think re-allocating colors as the page is scrolled is a good solution, although it might be worth a try. ------- Message 10 Received: from toad.lake.cs.wwu.EDU by JIMI.CS.UNLV.EDU id aa06161; 4 May 95 9:57 PDT Received: by toad.lake.cs.wwu.edu (5.0/SMI-SVR4) id AA22475; Thu, 4 May 1995 09:55:22 -0700 Date: Thu, 4 May 1995 09:55:15 -0700 (PDT) From: KESINGER To: John Kilburg Cc: bug-chimera@cephas.ISRI.UNLV.EDU Subject: Re: 2.0 inline images In-Reply-To: <9505040710.AA05511@egg.lake.cs.wwu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 1248 On Wed, 3 May 1995, John Kilburg wrote: > - if the dimensions of the inline image is included in the HTML then > the image is rendered as soon as it is downloaded. This works > really well so far. You mean like Netscape's HEIGHT="" WIDTH=""? > > - if the dimensions are not included then the image is downloaded but > the rendering is deferred for some number of seconds (currently 10 > but it will be configurable) and all images that do not have > the dimensions specified will be rendered. This causes the entire > page to be reformatted. Do you mean the text is displayed first then the images? Woo-hoo! Will links still be active? > > I will eventually change it to figure out the image size from the image > itself but that might be work. > It seems like about 98% of the images on the net are .gifs which have the size in bytes 7-10. I think. Maybe I'll take a look at the code one of these days (are they making time go by faster? it sure seems like it). I notice the p?m files have the size early in the file, and I'm sure JPG does as well. This way you could read in the first however many bytes, get the size, format the page, then continue reading the image. --Jake ------- Message 11 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa16932; 4 May 95 14:45 PDT To: KESINGER cc: bug-chimera@cephas.ISRI.UNLV.EDU Subject: Re: 2.0 inline images In-reply-to: Your message of "Thu, 04 May 1995 09:55:15 PDT." Date: Thu, 04 May 1995 14:45:01 -0700 From: John Kilburg >On Wed, 3 May 1995, John Kilburg wrote: > >> - if the dimensions of the inline image is included in the HTML then >> the image is rendered as soon as it is downloaded. This works >> really well so far. > >You mean like Netscape's HEIGHT="" WIDTH=""? Yes. Works well. Netscape's site comes up real fast with chimera :) >> - if the dimensions are not included then the image is downloaded but >> the rendering is deferred for some number of seconds (currently 10 >> but it will be configurable) and all images that do not have >> the dimensions specified will be rendered. This causes the entire >> page to be reformatted. >Do you mean the text is displayed first then the images? >Woo-hoo! Will links still be active? Yes. Works. >> itself but that might be work. >> >It seems like about 98% of the images on the net are .gifs which have the >size in bytes 7-10. I think. Maybe I'll take a look at the code >one of these days (are they making time go by faster? it sure seems >like it). I notice the p?m files have the size early in the file, and I'm >sure JPG does as well. This way you could read in the first >however many bytes, get the size, format the page, then continue reading >the image. Right. However, it will take quite a bit of rearranging of the widget code to make it work. I don't want to be too optimistic. There will be some very annoying problems with this weekend's release. -john ------- Message 12 Received: from rosebud.turing.toronto.edu by JIMI.CS.UNLV.EDU id aa04487; 5 May 95 23:44 PDT Received: by turing.toronto.edu id <5380>; Sat, 6 May 1995 02:44:20 -0400 From: Smarasderagd To: bug-chimera@cephas.ISRI.UNLV.EDU, john@cephas.ISRI.UNLV.EDU Subject: Re: 2.0 inline images Message-Id: <95May6.024420edt.5380@turing.toronto.edu> Date: Sat, 6 May 1995 02:44:07 -0400 In my initial ramblings I forgot something rather obvious. Can chimera allocate a private colormap? This would help quite a bit when running other applications making significant use of colour. ------- Message 13 Received: from little-charlie.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa24633; 7 May 95 23:35 PDT To: bug-chimera@little-charlie.ISRI.UNLV.EDU Subject: chimera 2.0alpha Date: Sun, 07 May 1995 23:35:01 -0700 From: John Kilburg I just put an alpha version of 2.0 out for FTP: ftp://ftp.cs.unlv.edu/pub/chimera-misc/john/nc7-2.0.tar.gz I am releasing this so that if you are curious you can take a look at what I am doing and how 2.0 is evolving. When I say that this is an alpha version, I REALLY mean it. It WILL dump core...even more than usual. There is a whole bunch of stuff missing. For example, it will not display text/plain which means browsing FTP and gopher sites is a pain. This also means that "source" doesn't work. Other things that don't work: - - convert - - external protocol - - forms stuff was messed up the last time i tried to submit a form - - there is no download progress indicator - - it leaks huge amounts of memory - - a bunch of other stuff i don't remember right now I have compiled it on: Sun Sparc SunOS 4.1.3_U1 DEC Alpha OSF/1 3.0 DECstation Ultrix 4.4 My linux box is not available right now. What does work: - - event driven I/O - HTML is displayed immediately - can do multiple inline image downloads at once - user interface is active during downloads - can click on a link during a download - - width and height attributes in IMG tags - - HTTP, FTP, Gopher, local file downloads - - screen refreshes should work better - - the cancel button seems to work really well There are a couple of new X resources that you might find useful: Chimera.refreshDelay This is used to tell chimera how many seconds to wait before refreshing images that don't have width and height specified. Instead of waiting for all images to get downloaded it will display whatever is ready after refreshDelay seconds. Or something like that. Chimera.maxDownloads This is used to tell chimera how many simultaneous inline images downloads can be running at one time. The default is 2. I have no idea if this works or not, yet. Once I get the convert code reincorporated I will personally use it for all of my browsing. I already use it unless I absolutely cannot download something with it. To me, it feels much faster. Also, note that I am still doing a lot of modifications so if you decide to make a patch then be aware that the code may change completely and make your patch unusable. Good luck. -john p.s. Oops. Just found a problem in ftp.c. Probable quick fix: comment out all of the free_mem()'s in ftp_destroy_info(). :) ------- Message 14 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa28858; 8 May 95 1:26 PDT To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: 2.0 ftp bug fix Date: Mon, 08 May 1995 01:26:34 -0700 From: John Kilburg In ftp_destroy_info() change for (i = 0; i < fi->sasize; i++) to for (i = 0; i < fi->sacount; i++) -john ------- Message 15 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa09696; 8 May 95 9:25 PDT Received: from bls5.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id BAA03137; Tue, 9 May 1995 01:25:48 +0900 Return-Path: Received: from localhost by bls5.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA17073; Tue, 9 May 95 01:25:47 GMT+0900 Message-Id: <9505081625.AA17073@bls5.aist-nara.ac.jp> To: bug-chimera@little-charlie.isri.unlv.edu Subject: Re: chimera 2.0alpha Reply-To: k-chinen@is.aist-nara.ac.jp In-Reply-To: Your message of "Sun, 07 May 1995 23:35:01 -0700" References: <199505080708.QAA10115@mailgate.aist-nara.ac.jp> X-Mailer: Mew beta version 0.89 on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 09 May 1995 01:25:47 +0900 From: Kenichi Chinen Dear John. I am glad about your new release. Chimera 2.0 is very fast and smart. Any way, I try to compile nc7-2.0 in OSF V2.0 with cc. And I got log of warnings and errors. I found problems and way to solve. please read report at end of this mail. Then, I can compile chimera. I will try to install :-) Thank you. ========== * www cache.o and local.o were not compiled. There are 2 problems, I think. First, OSF/1 is not BSD and SYSV. {cache,local}.o include headers about directory (dirent.h, dir.h and types.h). But OSF/1 is not usual. You must include sys/types.h and dirent.h Second, current implementation is hard to recogize OS. Now, DEFINES in Imakefile is definded to... DEFINES = $(CEXTRA_DEFINES) If you want to recognize OSF/1 easy, you should define to DEFINES = $(DEPENDFLAGS) $(CEXTRA_DEFINES) and you should switch by MACRO __osf__ or __alpha . * common util.c use wait3(). If you want to use wait3(), you must include sys/resource.h. Good Luck !!! ------- Message 16 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa07027; 15 May 95 18:03 PDT To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: title field Date: Mon, 15 May 1995 18:03:21 -0700 From: John Kilburg Here is an idea that I have been kicking around: I am going to remove the title field and replace it with a general purpose message area to display - - URLs when the mouse moves over an anchor - - download status at the appropriate times. The title seems worthless to me because most documents usually have leading H1 marked text or a leading GIF anyways. The title is good for the bookmark name but that is about it, in my opinion, so I might as well replace it to save screen space. Opinions? -john ------- Message 17 Received: from ldgo.columbia.edu by JIMI.CS.UNLV.EDU id aa22039; 16 May 95 4:53 PDT Received: from rosie.ldgo.columbia.edu ([129.236.21.205]) by lamont.ldgo.columbia.edu (4.1/SMI-3.2) id AA18758; Tue, 16 May 95 07:39:52 EDT Received: by rosie.ldgo.columbia.edu (931110.SGI/930416.SGI.AUTO) for @lamont.ldgo.columbia.edu:bug-chimera@cephas.ISRI.UNLV.EDU id AA18353; Tue, 16 May 95 07:38:04 -0400 Date: Tue, 16 May 95 07:38:04 -0400 From: Benno Blumenthal Message-Id: <9505161138.AA18353@rosie.ldgo.columbia.edu> To: bug-chimera@cephas.ISRI.UNLV.EDU In-Reply-To: <9505160126.AA00515@lamont.ldgo.columbia.edu> (message from John Kilburg on Mon, 15 May 1995 18:03:21 -0700) Subject: Re: title field My hope would be that the title would get more use rather than less: if it were always clearly displayed then people would not redundantly put it in a header field. But I think as long as you change the title of the window to be the title of the document, you have done enough. - -- -- Benno Benno Blumenthal Lamont-Doherty Earth Observatory of Columbia University Palisades NY 10964 (914) 365-8350 internet: benno@lamont.ldeo.columbia.edu ------- Message 18 Received: from trout.nosc.mil by JIMI.CS.UNLV.EDU id aa24948; 16 May 95 7:34 PDT Received: from Np.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA26386; Tue, 16 May 95 07:34:28 PDT Received: by Np.nosc.mil (4.1/SMI-4.1) id AA10131; Tue, 16 May 95 07:25:44 PDT Date: Tue, 16 May 95 07:25:44 PDT From: Vincent Broman Message-Id: <9505161425.AA10131@Np.nosc.mil> To: john@cephas.ISRI.UNLV.EDU Cc: bug-chimera@cephas.ISRI.UNLV.EDU In-Reply-To: <9505160127.AA23455@trout.nosc.mil> (message from John Kilburg on Mon, 15 May 1995 18:03:21 -0700) Subject: Re: title field Reply-To: broman@nosc.mil Something like "Title: here is the title" could be the default seen in the message area when no URL under the mouse or download status needs to be displayed. Vincent Broman, code 572 Bayside Email: broman@nosc.mil Naval Command Control and Ocean Surveillance Center, RDT&E Div. San Diego, CA 92152-6147, USA Phone: +1 619 553 1641 ------- Message 19 Received: from convex.convex.com by JIMI.CS.UNLV.EDU id aa26748; 16 May 95 8:43 PDT Received: from mikey.convex.com by convex.convex.com (8.6.4.2/1.35) id KAA09197; Tue, 16 May 1995 10:43:41 -0500 Received: by mikey.convex.com (8.6.10/1.28) id KAA20459; Tue, 16 May 1995 10:43:40 -0500 From: David DeSimone Message-Id: <199505161543.KAA20459@mikey.convex.com> Subject: Re: title field To: John Kilburg Date: Tue, 16 May 1995 10:43:39 -0500 (CDT) Cc: bug-chimera@cephas.ISRI.UNLV.EDU In-Reply-To: <199505160120.UAA05081@convex.convex.com> from "John Kilburg" at May 15, 95 06:03:21 pm Reply-To: David DeSimone X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 516 John Kilburg wrote: > > I am going to remove the title field and replace it with a general > purpose message area I don't know, I still like the title field, even if it is sometimes redundant. Perhaps you could do what that "Big N" browser does, and put the title into the window-managed title bar. - -- David DeSimone | "The doctrine of human equality reposes on this: fox@convex.com | that there is no man really clever who has not Convex Computers | found that he is stupid." -- Gilbert K. Chesterson ------- Message 20 Received: from toad.lake.cs.wwu.EDU by JIMI.CS.UNLV.EDU id aa27039; 16 May 95 8:56 PDT Received: from bear.lake.cs.wwu.edu by toad.lake.cs.wwu.edu (5.0/SMI-SVR4) id AA08027; Tue, 16 May 1995 08:54:06 -0700 Received: by bear.lake.cs.wwu.edu (5.0/SMI-SVR4) id AA15653; Tue, 16 May 1995 08:54:07 -0700 Date: Tue, 16 May 1995 15:54:00 +0000 (GMT) From: KESINGER To: John Kilburg Cc: bug-chimera@cephas.ISRI.UNLV.EDU Subject: Re: title field In-Reply-To: <9505160121.AA25645@egg.lake.cs.wwu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1150 On Mon, 15 May 1995, John Kilburg wrote: > Here is an idea that I have been kicking around: > > I am going to remove the title field and replace it with a general > purpose message area to display > > - URLs when the mouse moves over an anchor > - download status > > at the appropriate times. > > The title seems worthless to me because most documents usually have > leading H1 marked text or a leading GIF anyways. The title is good > for the bookmark name but that is about it, in my opinion, so I might > as well replace it to save screen space. > > Opinions? Have you considered putting the title in the window bar, like Arena and Netscape? You could have something like ``Chimera: '' or just ``<title of document>''. I personally like the title, and would miss it. I do like the idea of displaying the URL on mouse move, though. By download status I presume you mean something like ``x bytes out of y''? Good idea. BTW, has anyone got v2.0a to display inline images on NetBSD? I found one image that worked, no others did. 2.0 and 1.65 are using the same files, the 2.0 version I believe. --Jake ------- Message 21 Received: from enst.enst.fr by JIMI.CS.UNLV.EDU id aa03126; 16 May 95 11:52 PDT Received: from email.enst.fr (root@email.enst.fr [137.194.160.46]) by enst.enst.fr (8.6.10/8.6.10) with ESMTP id UAA11204 for <bug-chimera@cephas.ISRI.UNLV.EDU>; Tue, 16 May 1995 20:51:56 +0200 Received: from mistral.enst.fr (mistral.enst.fr [137.194.160.11]) by email.enst.fr (8.6.10/8.6.10) with ESMTP id UAA11366; Tue, 16 May 1995 20:49:23 +0200 From: Nicolas Pioch <pioch@Email.ENST.Fr> Received: (pioch@localhost) by mistral.enst.fr (8.6.10/8.6.10) id UAA24998; Tue, 16 May 1995 20:49:20 +0200 Message-Id: <199505161849.UAA24998@mistral.enst.fr> Subject: Re: title field To: fox@convex.convex.com Date: Tue, 16 May 1995 20:49:19 +0200 (MET DST) Cc: bug-chimera@cephas.ISRI.UNLV.EDU In-Reply-To: <199505161543.KAA20459@mikey.convex.com> from "David DeSimone" at May 16, 95 10:43:39 am Sensitivity: Confidential X-Www: https://sunsite.unc.edu/louvre/ X-Motto: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. X-Pgp-Key: "finger -l pioch@inf.enst.fr | pgp -fka" X-Nap: "The Computer made me do it." X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 423 I don't like that behavior very much because I use twm "SqueezeTitle's" with the Shape extension... Modifying the window title causes a modification of the window title size for each document... Urgh! - -- N. [David DeSimone] | I don't know, I still like the title field, even if it is sometimes | redundant. Perhaps you could do what that "Big N" browser does, and put | the title into the window-managed title bar. ------- Message 22 Received: from snooky.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa09457; 16 May 95 14:58 PDT To: John Kilburg <john@cephas.isri.unlv.edu> cc: bug-chimera@cephas.isri.unlv.edu Subject: Re: title field In-reply-to: Your message of "Mon, 15 May 1995 18:03:21 PDT." Date: Tue, 16 May 1995 14:58:19 -0700 From: "Steve E. Lumos" <slumos@snooky.CS.UNLV.EDU> >Here is an idea that I have been kicking around: > >I am going to remove the title field and replace it with a general >purpose message area to display > >- URLs when the mouse moves over an anchor Yea! >- download status > >at the appropriate times. > >The title seems worthless to me because most documents usually have >leading H1 marked text or a leading GIF anyways. The title is good >for the bookmark name but that is about it, in my opinion, so I might >as well replace it to save screen space. > >Opinions? 1. The title is useful, and not always equal to the H1. I personally like to use each to say different things. 2. You should but the title on the titlebar next to "chimera". TTYL - Steve ------- Message 23 Received: from deacon.cogsci.ed.ac.uk by JIMI.CS.UNLV.EDU id aa28856; 18 May 95 16:36 PDT Received: from burns.cogsci.ed.ac.uk (burns.cogsci.ed.ac.uk [129.215.144.4]) by deacon.cogsci.ed.ac.uk (8.6.10/8.6.9) with SMTP id AAA20348 for <bug-chimera@cs.unlv.edu>; Fri, 19 May 1995 00:36:32 +0100 Date: Fri, 19 May 95 00:36:31 BST Message-Id: <9684.9505182336@burns.cogsci.ed.ac.uk> From: Tim Bradshaw <tfb@ed.ac.uk> To: Chimera doctors <bug-chimera@cs.unlv.edu> Subject: select/option processing wrong 1.65 (I haven't tried 2.0) doesn't understand <option> properly, in particular: <select ...> <option>...</option> <option>...</option> </select> will make a menu with 4 (not 2) entries, 2 of them empty. OPTION's end tag is omissable and most people seem to do that, but it is allowed on the other hand... - --tim ------- Message 24 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa00234; 18 May 95 17:25 PDT To: Tim Bradshaw <tfb@ed.ac.uk> cc: Chimera doctors <bug-chimera@cs.unlv.edu> Subject: Re: select/option processing wrong In-reply-to: Your message of "Fri, 19 May 1995 00:36:31 -0000." <9684.9505182336@burns.cogsci.ed.ac.uk> Date: Thu, 18 May 1995 17:25:44 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> >1.65 (I haven't tried 2.0) doesn't understand <option> properly, in >particular: > ><select ...> > <option>...</option> > <option>...</option> ></select> > >will make a menu with 4 (not 2) entries, 2 of them empty. OPTION's >end tag is omissable and most people seem to do that, but it is >allowed on the other hand... I'll take a look but it will be a while before I can do anything about it. Avoid 2.0. -john ------- Message 25 Received: from elixir.e.kth.se by JIMI.CS.UNLV.EDU id aa19998; 19 May 95 12:06 PDT Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id VAA27200 for <bug-chimera@cs.unlv.edu>; Fri, 19 May 1995 21:05:22 +0200 From: Juha Sarlin <juha@elixir.e.kth.se> Received: (juha@localhost) by zafir.e.kth.se (8.6.8.1/8.6.6) id VAA06112; Fri, 19 May 1995 21:05:22 +0200 Date: Fri, 19 May 1995 21:05:22 +0200 Message-Id: <199505191905.VAA06112@zafir.e.kth.se> To: bug-chimera@cs.unlv.edu Subject: Fixes for ParseExpiresDate Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Here are some fixes to ParseExpiresDate in Chimera 1.65: Really use the month number after calculating it from the month name. Use timegm instead of mktime. Added handling of the date format "Friday, 19-May-95 18:00:00 GMT". *** 1.1 1995/05/19 17:47:40 - --- mime.c 1995/05/19 18:21:46 *************** *** 319,324 **** - --- 319,329 ---- return(-1); } + #if defined(HAVE_MKTIME) && !defined(HAVE_TIMEGM) + #define timegm mktime + #define HAVE_TIMEGM + #endif + /* * ParseExpiresDate * *************** *** 328,354 **** ParseExpiresDate(s) char *s; { ! #ifdef HAVE_MKTIME int i; ! time_t expires; struct tm tm; char buffer[BUFSIZ]; ! char month[4], zone[4]; static char *ms[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; memset(&tm, 0, sizeof(tm)); ! if (sscanf(s, "%s %d %s %d %d:%d:%d %s", ! buffer, &tm.tm_mday, month, &tm.tm_year, ! &tm.tm_hour, &tm.tm_min, &tm.tm_sec, zone) == 8) { if (tm.tm_year > 1900) tm.tm_year -= 1900; for (i = 0; i < sizeof(ms) / sizeof(ms[0]); i++) { if (strcmp(month, ms[i]) == 0) { ! expires = mktime(&tm); break; } } - --- 333,376 ---- ParseExpiresDate(s) char *s; { ! #ifdef HAVE_TIMEGM int i; ! time_t expires = 0; ! int ok = 0; struct tm tm; char buffer[BUFSIZ]; ! char month[4]; static char *ms[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; memset(&tm, 0, sizeof(tm)); ! if (sscanf(s, "%s %d %s %d %d:%d:%d", ! buffer, &tm.tm_mday, buffer, &tm.tm_year, ! &tm.tm_hour, &tm.tm_min, &tm.tm_sec) == 7) ! { ! strncpy(month, buffer, 4); ! ok = 1; ! } ! else if (sscanf(s, "%s %s %d:%d:%d", ! buffer, buffer, &tm.tm_hour, &tm.tm_min, &tm.tm_sec) == 5 ! && buffer[2] == '-' && buffer[6] == '-') ! { ! tm.tm_mday = atoi(buffer); ! tm.tm_year = atoi(buffer+7); ! strncpy(month, buffer+3, 4); ! ok = 1; ! } ! if (ok) { if (tm.tm_year > 1900) tm.tm_year -= 1900; + if (tm.tm_year < 70) tm.tm_year += 100; for (i = 0; i < sizeof(ms) / sizeof(ms[0]); i++) { if (strcmp(month, ms[i]) == 0) { ! tm.tm_mon = i; ! expires = timegm(&tm); break; } } - -- Juha Sarlin <juha@elixir.e.kth.se> ------- Message 26 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa00135; 22 May 95 19:40 PDT To: Juha Sarlin <juha@elixir.e.kth.se> cc: bug-chimera@cs.unlv.edu Subject: Re: Fixes for ParseExpiresDate In-reply-to: Your message of "Fri, 19 May 1995 21:05:22 +0200." <199505191905.VAA06112@zafir.e.kth.se> Date: Mon, 22 May 1995 19:40:42 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> Thanks, I'll look at it and try to work it into the next release. -john >Here are some fixes to ParseExpiresDate in Chimera 1.65: > >Really use the month number after calculating it from the month name. >Use timegm instead of mktime. >Added handling of the date format "Friday, 19-May-95 18:00:00 GMT". > >*** 1.1 1995/05/19 17:47:40 >--- mime.c 1995/05/19 18:21:46 >*************** >*** 319,324 **** >--- 319,329 ---- > return(-1); > } > >+ #if defined(HAVE_MKTIME) && !defined(HAVE_TIMEGM) >+ #define timegm mktime >+ #define HAVE_TIMEGM >+ #endif >+ > /* > * ParseExpiresDate > * >*************** >*** 328,354 **** > ParseExpiresDate(s) > char *s; > { >! #ifdef HAVE_MKTIME > int i; >! time_t expires; > struct tm tm; > char buffer[BUFSIZ]; >! char month[4], zone[4]; > static char *ms[] = > { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", > "Nov", "Dec" }; > > memset(&tm, 0, sizeof(tm)); >! if (sscanf(s, "%s %d %s %d %d:%d:%d %s", >! buffer, &tm.tm_mday, month, &tm.tm_year, >! &tm.tm_hour, &tm.tm_min, &tm.tm_sec, zone) == 8) > { > if (tm.tm_year > 1900) tm.tm_year -= 1900; > for (i = 0; i < sizeof(ms) / sizeof(ms[0]); i++) > { > if (strcmp(month, ms[i]) == 0) > { >! expires = mktime(&tm); > break; > } > } >--- 333,376 ---- > ParseExpiresDate(s) > char *s; > { >! #ifdef HAVE_TIMEGM > int i; >! time_t expires = 0; >! int ok = 0; > struct tm tm; > char buffer[BUFSIZ]; >! char month[4]; > static char *ms[] = > { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", > "Nov", "Dec" }; > > memset(&tm, 0, sizeof(tm)); >! if (sscanf(s, "%s %d %s %d %d:%d:%d", >! buffer, &tm.tm_mday, buffer, &tm.tm_year, >! &tm.tm_hour, &tm.tm_min, &tm.tm_sec) == 7) >! { >! strncpy(month, buffer, 4); >! ok = 1; >! } >! else if (sscanf(s, "%s %s %d:%d:%d", >! buffer, buffer, &tm.tm_hour, &tm.tm_min, &tm.tm_sec) == 5 >! && buffer[2] == '-' && buffer[6] == '-') >! { >! tm.tm_mday = atoi(buffer); >! tm.tm_year = atoi(buffer+7); >! strncpy(month, buffer+3, 4); >! ok = 1; >! } >! if (ok) > { > if (tm.tm_year > 1900) tm.tm_year -= 1900; >+ if (tm.tm_year < 70) tm.tm_year += 100; > for (i = 0; i < sizeof(ms) / sizeof(ms[0]); i++) > { > if (strcmp(month, ms[i]) == 0) > { >! tm.tm_mon = i; >! expires = timegm(&tm); > break; > } > } >-- >Juha Sarlin <juha@elixir.e.kth.se> ------- Message 27 Received: from elixir.e.kth.se by JIMI.CS.UNLV.EDU id aa12128; 23 May 95 3:06 PDT Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id MAA04498 for <bug-chimera@cs.unlv.edu>; Tue, 23 May 1995 12:02:16 +0200 From: Juha Sarlin <juha@elixir.e.kth.se> Received: (juha@localhost) by zafir.e.kth.se (8.6.8.1/8.6.6) id MAA11367; Tue, 23 May 1995 12:02:15 +0200 Date: Tue, 23 May 1995 12:02:15 +0200 Message-Id: <199505231002.MAA11367@zafir.e.kth.se> To: bug-chimera@cs.unlv.edu Subject: Fix to my fix for ParseExpiresDate Here is a small change to my previous changes to ParseExpiresDate to make the date format "Friday, 19-May-95 18:00:00 GMT" work. This time I've actually tested it once. :-) *** 1.2 1995/05/19 19:17:43 - --- mime.c 1995/05/23 09:49:30 *************** *** 358,364 **** { tm.tm_mday = atoi(buffer); tm.tm_year = atoi(buffer+7); ! strncpy(month, buffer+3, 4); ok = 1; } if (ok) - --- 358,365 ---- { tm.tm_mday = atoi(buffer); tm.tm_year = atoi(buffer+7); ! buffer[6] = '\0'; ! strcpy(month, buffer+3); ok = 1; } if (ok) - -- Juha Sarlin <juha@elixir.e.kth.se> ------- Message 28 Received: from wn1.sci.kun.nl by JIMI.CS.UNLV.EDU id aa14095; 23 May 95 5:00 PDT Received: from torgelspitter.sci.kun.nl by wn1.sci.kun.nl via torgelspitter.sci.kun.nl [131.174.132.53] with SMTP id OAA22298 (8.6.10/2.11) for <bug-chimera@cs.unlv.edu>; Tue, 23 May 1995 14:00:01 +0200 Message-Id: <199505231200.OAA22298@wn1.sci.kun.nl> To: bug-chimera@cs.unlv.edu Subject: Stupid omission from libhtml/Imakefile Date: Tue, 23 May 95 13:59:59 +0200 From: Michiel Boland <boland@sci.kun.nl> Please add -D_NO_PROTO to libhtml/Imakefile in the original chimera-1.65 distribution. While you're at it, please add 'static' to SearchCallBack in src/main.c. This silly bug has been mentioned twice on this mailing list but is still not fixed. Thanks :) Michiel Boland <boland@sci.kun.nl> University of Nijmegen The Netherlands ------- Message 29 Received: from wn1.sci.kun.nl by JIMI.CS.UNLV.EDU id aa15396; 23 May 95 6:12 PDT Received: from torgelspitter.sci.kun.nl by wn1.sci.kun.nl via torgelspitter.sci.kun.nl [131.174.132.53] with SMTP id PAA25319 (8.6.10/2.11) for <bug-chimera@cs.unlv.edu>; Tue, 23 May 1995 15:12:06 +0200 Message-Id: <199505231312.PAA25319@wn1.sci.kun.nl> To: bug-chimera@cs.unlv.edu Subject: Re: Stupid omission from libhtml/Imakefile Date: Tue, 23 May 95 15:12:05 +0200 From: Michiel Boland <boland@sci.kun.nl> oops .. sorry to follow up so soon - my apologies for not thinking :) It may be better perhaps to add -D_NO_PROTO to CEXTRA_DEFINES in Common.tmpl. If I do that, everything works fine. Apart from two warning messages: "StrReq.c", line 87: warning: illegal pointer combination "AuthReq.c", line 87: warning: illegal pointer combination I haven't a clue what this means (and how to fix it). It appears to be harmless. Michiel Boland <boland@sci.kun.nl> University of Nijmegen The Netherlands ------- Message 30 Received: from oriole.nmt.edu by JIMI.CS.UNLV.EDU id aa17551; 26 May 95 12:41 PDT Return-Path: <raymond> Message-Id: <m0sF5HA-000EOhC@oriole.nmt.edu> Date: Fri, 26 May 95 13:42 MDT From: "David J. Raymond" <raymond@oriole.nmt.edu> To: bug-chimera@cs.unlv.edu Hi, I notice that chimera 1.63 on Linux leaves off the end of a downloaded file obtained from an ftp directory. The file was a gzipped tar file. Dave Raymond ------- Message 31 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14771; 28 May 95 20:51 PDT Received: from nic.hookup.net by JIMI.CS.UNLV.EDU id aa14676; 28 May 95 20:44 PDT Received: (Ufrop@localhost) by nic.hookup.net (8.6.12/1.350) with UUCP id XAA15685; Sun, 28 May 1995 23:43:56 -0400 Received: (from jack@localhost) by frop.hookup.net (8.6.11/8.6.9) id WAA04188 for chimera-announce@cs.unlv.edu; Sun, 28 May 1995 22:57:13 -0400 From: Jack Kern <jack@frop.hookup.net> Message-Id: <199505290257.WAA04188@frop.hookup.net> To: chimera-announce@cs.unlv.edu Date: Sun, 28 May 1995 22:57:09 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 44 - -- Jack Kern <jack@frop.hookup.net> ------- Message 32 Received: from deacon.cogsci.ed.ac.uk by JIMI.CS.UNLV.EDU id aa07535; 30 May 95 15:28 PDT Received: from burns.cogsci.ed.ac.uk (burns.cogsci.ed.ac.uk [129.215.144.4]) by deacon (8.6.10/8.6.9) with SMTP id XAA04930 for <bug-chimera@cs.unlv.edu>; Tue, 30 May 1995 23:28:30 +0100 Date: Tue, 30 May 95 23:28:13 BST Message-Id: <20270.9505302228@burns.cogsci.ed.ac.uk> From: Tim Bradshaw <tfb@ed.ac.uk> To: Chimera doctors <bug-chimera@cs.unlv.edu> Subject: Feature request It would be nice if chimera would (optionally? after confirmation?) kill any child processes when you ask it to exit. I often have ghostview's &c hanging around from looking at PS files and this makes it hang causing me confusion. - --tim ------- Message 33 Received: from convex.convex.com by JIMI.CS.UNLV.EDU id aa00423; 31 May 95 8:23 PDT Received: from mikey.convex.com by convex.convex.com (8.6.4.2/1.35) id KAA12384; Wed, 31 May 1995 10:23:22 -0500 Received: by mikey.convex.com (8.6.10/1.28) id KAA08368; Wed, 31 May 1995 10:23:21 -0500 From: David DeSimone <fox@mikey.convex.com> Message-Id: <199505311523.KAA08368@mikey.convex.com> Subject: Re: Feature request To: Tim Bradshaw <tfb@ed.ac.uk> Date: Wed, 31 May 1995 10:23:20 -0500 (CDT) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <20270.9505302228@burns.cogsci.ed.ac.uk> from "Tim Bradshaw" at May 30, 95 11:28:13 pm Reply-To: David DeSimone <fox@convex.convex.com> X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 898 Tim Bradshaw wrote: > > It would be nice if chimera would (optionally? after confirmation?) > kill any child processes when you ask it to exit. I often have > ghostview's &c hanging around from looking at PS files and this makes > it hang causing me confusion. Actually, I would rather like it if chimera would simply spawn off children, and then forget about them. Then I could close chimera, and leave the viewer programs running if I choose to do so. Mosaic uses this method to launch viewers: sh -c '<viewer> <temp file> ; rm -f <temp file>' & This allows the viewer to run independently, with a shell process hanging around to clean up the temp file when it finishes. - -- David DeSimone | "The doctrine of human equality reposes on this: fox@convex.com | that there is no man really clever who has not Convex Computers | found that he is stupid." -- Gilbert K. Chesterson ------- End of Forwarded Messages