From: Robert L K. <rl...@al...> - 2002-09-11 23:23:12
|
From: Roger Leigh <ro...@wh...> Date: 11 Sep 2002 23:57:04 +0100 1. The GIMP Plugin uses an autoconf macro to determine the plugin directory, so we use the automake framework and forget about gimptool (at least for (un)install. Much cleaner, and it fixes DESTDIR and make uninstall. I'd like to separate this from the genppd issue. I thought we fixed the gimptool stuff pretty well, anyhow. 3. PPDs are no longer created and installed. The user must use cups-genppd(-config) to create them. I think we should keep an option to allow generating PPD files (./configure --enable-install-all-ppd-files or some such). Distributors might well prefer to distribute all available PPD files. Index: src/cups/Makefile.am =================================================================== RCS file: /cvsroot/gimp-print/print/src/cups/Makefile.am,v retrieving revision 1.57 diff -u -r1.57 Makefile.am --- src/cups/Makefile.am 27 Aug 2002 21:12:43 -0000 1.57 +++ src/cups/Makefile.am 11 Sep 2002 22:33:03 -0000 @@ -36,7 +36,7 @@ cupsexec_backenddir = $(pkglibdir)/backend cupsexec_filterdir = $(pkglibdir)/filter -cups_modeldir = $(pkgdatadir)/model +cups_modeldir = $(pkgdatadir)/model/gimp-print Will this even work with all versions of CUPS 1.1 and above? -refresh-data-local: ppd - cd ppd ; \ - files=`find . -name '*.ppd*' -exec basename '{}' \; | sort | uniq` ; \ - for language in . de en es fr it ; do \ - for f in $$files ; do \ - ff="$(DESTDIR)/$(cups_modeldir)/$$language/$$f" ; \ - if [ -f "$$ff" ] ; then \ - echo "Removing $$ff" ; \ - $(RM) "$$ff" ; \ - fi ; \ - if [ -f "$$ff" ] ; then \ - echo "Unable to remove $$ff" 1>&2 ; \ - exit 1 ; \ - fi ; \ - done; \ - done It's probably time for this to come out of 4.3; this is only used for upgrading from 4.0. --=-=-= Content-Disposition: attachment; filename=cups-genppdconfig.in Content-Description: src/cups/cups-genppdconfig.in #! /usr/bin/perl -w Please don't use /usr/bin/perl explicitly; it should be @PERL@ (we already substitute the local copy of perl in some of the foomatic scripts.) Also, does this work in both console and X environments (and preferably on OS X natively also)? -- Robert Krawitz <rl...@al...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Roger L. <ro...@wh...> - 2002-09-12 18:41:35
|
Robert L Krawitz <rl...@al...> writes: > From: Roger Leigh <ro...@wh...> > Date: 11 Sep 2002 23:57:04 +0100 > > 1. The GIMP Plugin uses an autoconf macro to determine the plugin > directory, so we use the automake framework and forget about > gimptool (at least for (un)install. Much cleaner, and it fixes > DESTDIR and make uninstall. > > I'd like to separate this from the genppd issue. I thought we fixed > the gimptool stuff pretty well, anyhow. I'll separate it. This is a trivial fix. make install would always break when DESTDIR was set, since getting libtool to use the "gimptool --just-print" output wouldn't get the install directory set correctly, even though gimptool now understands DESTDIR. The fix uses gimptool to determine the plugin dir at configure time, and then this can be used in the Makefile.am without worrying about the installation details. > 3. PPDs are no longer created and installed. The user must use > cups-genppd(-config) to create them. > > I think we should keep an option to allow generating PPD files > (./configure --enable-install-all-ppd-files or some such). > Distributors might well prefer to distribute all available PPD files. OK. Should translated PPDs still be made available by default, or just English? I don't think anyone will want to distribute every language, and they can always use cups-genppd or cups-genppdconfig to generate them. > -cups_modeldir = $(pkgdatadir)/model > +cups_modeldir = $(pkgdatadir)/model/gimp-print > > Will this even work with all versions of CUPS 1.1 and above? I don't know. I'm using 1.1.14, and it works just fine with that (it seems to do a recursive scan of all the files under $cups_datadir/model). I put everything under there so it could be easily removed without trampling on other stuff. I can't test the earlier CUPS versions myself though. > -refresh-data-local: ppd > - cd ppd ; \ > - files=`find . -name '*.ppd*' -exec basename '{}' \; | sort | uniq` ; \ > - for language in . de en es fr it ; do \ > - for f in $$files ; do \ > - ff="$(DESTDIR)/$(cups_modeldir)/$$language/$$f" ; \ > - if [ -f "$$ff" ] ; then \ > - echo "Removing $$ff" ; \ > - $(RM) "$$ff" ; \ > - fi ; \ > - if [ -f "$$ff" ] ; then \ > - echo "Unable to remove $$ff" 1>&2 ; \ > - exit 1 ; \ > - fi ; \ > - done; \ > - done > > It's probably time for this to come out of 4.3; this is only used for > upgrading from 4.0. OK. Is it worth keeping the replacement target "refresh-data"? This runs update-cups-genppd, but just running the program is easier. > #! /usr/bin/perl -w > > Please don't use /usr/bin/perl explicitly; it should be @PERL@ (we > already substitute the local copy of perl in some of the foomatic > scripts.) I've changed this. > Also, does this work in both console and X environments (and > preferably on OS X natively also)? It's a console program. I have had it working on the Linux console, and various X terminal emulators. There are some variations of dialog, xdialog and gdialog, which use Xlib and GTK+ respectively. I have not had success getting these to work though. I can always dump dialog (I don't know how widespread its use is, but it should work with any curses library) and use a better solution, such as libcdk (Curses Development Kit) which has a Perl interface. What would you prefer? I could always try to write a GTK+ interface, but I want to be able to use it from a terminal, too. Even if the program does not work, users can still use cups-genppd. This is just a wrapper around that. -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers |
From: Robert L K. <rl...@al...> - 2002-09-13 04:32:31
|
From: Roger Leigh <ro...@wh...> Date: 12 Sep 2002 19:30:38 +0100 Robert L Krawitz <rl...@al...> writes: > From: Roger Leigh <ro...@wh...> > Date: 11 Sep 2002 23:57:04 +0100 > > 1. The GIMP Plugin uses an autoconf macro to determine the plugin > directory, so we use the automake framework and forget about > gimptool (at least for (un)install. Much cleaner, and it fixes > DESTDIR and make uninstall. > > I'd like to separate this from the genppd issue. I thought we fixed > the gimptool stuff pretty well, anyhow. I'll separate it. This is a trivial fix. make install would always break when DESTDIR was set, since getting libtool to use the "gimptool --just-print" output wouldn't get the install directory set correctly, even though gimptool now understands DESTDIR. The fix uses gimptool to determine the plugin dir at configure time, and then this can be used in the Makefile.am without worrying about the installation details. If gimptool --just-print does the right thing, why do we need to change this? > 3. PPDs are no longer created and installed. The user must use > cups-genppd(-config) to create them. > > I think we should keep an option to allow generating PPD files > (./configure --enable-install-all-ppd-files or some such). > Distributors might well prefer to distribute all available PPD files. OK. Should translated PPDs still be made available by default, or just English? I don't think anyone will want to distribute every language, and they can always use cups-genppd or cups-genppdconfig to generate them. I don't have a good feel for what the default should be, but it should be possible to do both. > -cups_modeldir = $(pkgdatadir)/model > +cups_modeldir = $(pkgdatadir)/model/gimp-print > > Will this even work with all versions of CUPS 1.1 and above? I don't know. I'm using 1.1.14, and it works just fine with that (it seems to do a recursive scan of all the files under $cups_datadir/model). I put everything under there so it could be easily removed without trampling on other stuff. I can't test the earlier CUPS versions myself though. Mike, when he gets back, can answer this. > It's probably time for this to come out of 4.3; this is only used for > upgrading from 4.0. OK. Is it worth keeping the replacement target "refresh-data"? This runs update-cups-genppd, but just running the program is easier. I'd say toss it; that was a 4.0-specific hack. > Also, does this work in both console and X environments (and > preferably on OS X natively also)? It's a console program. I have had it working on the Linux console, and various X terminal emulators. There are some variations of dialog, xdialog and gdialog, which use Xlib and GTK+ respectively. I have not had success getting these to work though. Is dialog a common program in all modern Unices? -- Robert Krawitz <rl...@al...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Roger L. <ro...@wh...> - 2002-09-13 23:43:35
|
Robert L Krawitz <rl...@al...> writes: > From: Roger Leigh <ro...@wh...> > Date: 12 Sep 2002 19:30:38 +0100 > > Robert L Krawitz <rl...@al...> writes: > > > From: Roger Leigh <ro...@wh...> > > Date: 11 Sep 2002 23:57:04 +0100 > > > > 1. The GIMP Plugin uses an autoconf macro to determine the plugin > > directory, so we use the automake framework and forget about > > gimptool (at least for (un)install. Much cleaner, and it fixes > > DESTDIR and make uninstall. > > > > I'd like to separate this from the genppd issue. I thought we fixed > > the gimptool stuff pretty well, anyhow. > > I'll separate it. This is a trivial fix. make install would > always break when DESTDIR was set, since getting libtool to use the > "gimptool --just-print" output wouldn't get the install directory > set correctly, even though gimptool now understands DESTDIR. The > fix uses gimptool to determine the plugin dir at configure time, > and then this can be used in the Makefile.am without worrying about > the installation details. > > If gimptool --just-print does the right thing, why do we need to > change this? Because libtool could not use the data correctly. To get it to work properly, I needed to parse it with sed (to strip everything but the install path). After that, it was easiest to move this into configure, as a simple check, which cleaned up the Makefile by letting us use much simpler rules, which just work (i.e. automake-generated ones; we don't need any custom rules now). roger@whinlatter:/tmp$ touch print roger@whinlatter:/tmp$ chmod +x print roger@whinlatter:/tmp$ gimptool --dry-run --install-admin-bin print /usr/bin/install -c print /usr/lib/gimp/1.2/plug-ins/print roger@whinlatter:/tmp$ DESTDIR=staging gimptool --dry-run --install-admin-bin print /usr/bin/install -c print staging/usr/lib/gimp/1.2/plug-ins/print I don't think that libtool likes the "-c" flag. --mode=install just wants "cp" or "install", the file and destination. It ignored DESTDIR (though I don't know the exact reason). Possibly it wanted a directory as the last argument, and not <path>/print. libtool does some mangling of the options, and somewhere gets it wrong. > > 3. PPDs are no longer created and installed. The user must use > > cups-genppd(-config) to create them. > > > > I think we should keep an option to allow generating PPD files > > (./configure --enable-install-all-ppd-files or some such). > > Distributors might well prefer to distribute all available PPD files. > > OK. Should translated PPDs still be made available by default, or > just English? I don't think anyone will want to distribute every > language, and they can always use cups-genppd or cups-genppdconfig to > generate them. > > I don't have a good feel for what the default should be, but it should > be possible to do both. OK. I'll keep all the old rules, but make their use dependent on enabling via configure options. > > Also, does this work in both console and X environments (and > > preferably on OS X natively also)? > > It's a console program. I have had it working on the Linux > console, and various X terminal emulators. There are some > variations of dialog, xdialog and gdialog, which use Xlib and GTK+ > respectively. I have not had success getting these to work though. > > Is dialog a common program in all modern Unices? It's in FreeBSD, and Debian (and I assume all Linux distributions, since it's used in interactive shell scripts, typically configuration). I only have FreeBSD and Debian to hand though. Does anyone on the list /not/ have dialog available with their OS? I don't like dialog much, since it's a bit of a hack using it through a pipe. Does anyone /not/ have libcdk available--I can use this instead, if it's common. This is also in FreeBSD and Debian. This would be more flexible, and not require a separate process forking for each dialogue box. This is a wiget-based toolkit for curses. -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers |
From: Brian A. P. <li...@th...> - 2002-09-14 00:07:26
|
I am trying to get Gimp-Print to work with a DesignJet 5000 (NON PS version) and since there is no file for it in the HP list, I am wondering if someone could write one. I tried the 2500 driver before I realized it was for a DeskJet 2500, but it DID output a print to the 5000. It was the wrong scale and the color was off, but it did output. I could test the DJ 5000 if someone would write the driver file. I don't think it would be THAT hard for a programmer as there is already a PS file for it, and the NON-PS DeskJet drivers can talk to it now. Thanks, Brian A. Peat ____________________________________________________________________________ The Peat Group Member, Apple Consultants Network Mobile: (614) 946-8989 E-mail: Br...@th... Office: (614) 891-1618 Web: http://www.thepeatgroup.com -- The Peat Group Offers Macintosh based Consulting, Repair, Web Design, Digital Video Editing, and Conference Management. |
From: Till K. <til...@gm...> - 2002-09-14 11:48:11
|
The DesignJet probably only accepts raster data in RGB format and not in CMYK as GIMP-Print produces. So you should try the HPIJS driver from HP. And as this is not a GIMP-Print issue any more I am cross-posting to the HP list on linuxprinting.org. Make sure that your follow-ups will also appear on that list. Can you do the following: Download and install HPIJS from http://hpinkjet.sf.net/, install also a recent GhostScript (ESP GhostScript 7.05.5 from http://www.cups.org/ghostscript.html, not only for CUPS, use it also when you use LPRng or another spooler). Now go to the HPIJS driver page of linuxprinting.org http://www.linuxprinting.org/show_driver.cgi?driver=hpijs In the section "Printing system interfaces" go to the subsection for your spooler, choose the HP Color Inkjet Printer CP1700 and then click the button to generate the configuration file. After the file being completely downloaded and displayed, choose "File"/"Save as..." in your browser's menues to save the file. Then click the "Back" button of your browser. Now click the "documentation" link to see how to set up a print queue with the downloaded file. Set up the queue to point to your DesignJet 5000. Now you should be able to print on paper sizes up to A3/SuperB. Please report whether it works. Till Brian A. Peat wrote: > I am trying to get Gimp-Print to work with a DesignJet 5000 (NON PS version) > and since there is no file for it in the HP list, I am wondering if someone > could write one. > > I tried the 2500 driver before I realized it was for a DeskJet 2500, but it > DID output a print to the 5000. It was the wrong scale and the color was > off, but it did output. > > I could test the DJ 5000 if someone would write the driver file. I don't > think it would be THAT hard for a programmer as there is already a PS file > for it, and the NON-PS DeskJet drivers can talk to it now. > > Thanks, > > Brian A. Peat > ____________________________________________________________________________ > The Peat Group Member, Apple Consultants Network > Mobile: (614) 946-8989 E-mail: Br...@th... > Office: (614) 891-1618 Web: http://www.thepeatgroup.com > -- > The Peat Group Offers Macintosh based Consulting, Repair, Web Design, > Digital Video Editing, and Conference Management. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > |
From: Robert L K. <rl...@al...> - 2002-09-14 12:36:53
|
From: Till Kamppeter <til...@gm...> Date: Sat, 14 Sep 2002 13:47:52 +0200 The DesignJet probably only accepts raster data in RGB format and not in CMYK as GIMP-Print produces. So you should try the HPIJS driver from HP. And as this is not a GIMP-Print issue any more I am cross-posting to the HP list on linuxprinting.org. Make sure that your follow-ups will also appear on that list. Gimp-print's perfectly capable of producing RGB output; it's just a matter of how the driver's written. If the real issue is that this printer expects 8-bit data and does its own dithering, then Gimp-print may simply not be the best driver for this purpose. However, I don't really know anything about HP printers, so I can't usefully say much more. -- Robert Krawitz <rl...@al...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Till K. <til...@gm...> - 2002-09-14 13:52:48
|
Do you know which drivers of GIMP-Print produce RGB data? Are there also drivers for HP inkjets doing so? Till Robert L Krawitz wrote: > From: Till Kamppeter <til...@gm...> > Date: Sat, 14 Sep 2002 13:47:52 +0200 > > The DesignJet probably only accepts raster data in RGB format and > not in CMYK as GIMP-Print produces. So you should try the HPIJS > driver from HP. And as this is not a GIMP-Print issue any more I > am cross-posting to the HP list on linuxprinting.org. Make sure > that your follow-ups will also appear on that list. > > Gimp-print's perfectly capable of producing RGB output; it's just a > matter of how the driver's written. If the real issue is that this > printer expects 8-bit data and does its own dithering, then Gimp-print > may simply not be the best driver for this purpose. However, I don't > really know anything about HP printers, so I can't usefully say much > more. > |
From: Robert L K. <rl...@al...> - 2002-09-14 14:00:47
|
From: Till Kamppeter <til...@gm...> Date: Sat, 14 Sep 2002 15:51:33 +0200 Do you know which drivers of GIMP-Print produce RGB data? Are there also drivers for HP inkjets doing so? The Postscript drivers produce RGB data. I think that all of the existing HP drivers produce CMYK data, though. -- Robert Krawitz <rl...@al...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Brian A. P. <br...@th...> - 2002-09-14 14:39:42
|
In the first message I posted on this I mentioned I am using OS X 10.2, I forgot to put that in this recent message. Will I have trouble with these Linix drivers, I mean, will someone have to compile them for OS X first? Thanks, Brian A. Peat ____________________________________________________________________________ The Peat Group Member, Apple Consultants Network Mobile: (614) 946-8989 E-mail: Br...@th... Office: (614) 891-1618 Web: http://www.thepeatgroup.com -- The Peat Group Offers Macintosh based Consulting, Repair, Web Design, Digital Video Editing, and Conference Management. > From: Till Kamppeter <til...@gm...> > Newsgroups: linuxprinting.hp.general > Date: Sat, 14 Sep 2002 13:47:52 +0200 > To: "Brian A. Peat" <li...@th...> > Cc: gim...@li... > Subject: Re: [Gimp-print-devel] Help with DesignJet 5000 > > The DesignJet probably only accepts raster data in RGB format and not in > CMYK as GIMP-Print produces. So you should try the HPIJS driver from HP. > And as this is not a GIMP-Print issue any more I am cross-posting to the > HP list on linuxprinting.org. Make sure that your follow-ups will also > appear on that list. > > Can you do the following: > > Download and install HPIJS from http://hpinkjet.sf.net/, install also a > recent GhostScript (ESP GhostScript 7.05.5 from > http://www.cups.org/ghostscript.html, not only for CUPS, use it also > when you use LPRng or another spooler). > > Now go to the HPIJS driver page of linuxprinting.org > > http://www.linuxprinting.org/show_driver.cgi?driver=hpijs > > In the section "Printing system interfaces" go to the subsection for > your spooler, choose the HP Color Inkjet Printer CP1700 and then click > the button to generate the configuration file. After the file being > completely downloaded and displayed, choose "File"/"Save as..." in your > browser's menues to save the file. Then click the "Back" button of your > browser. Now click the "documentation" link to see how to set up a print > queue with the downloaded file. Set up the queue to point to your > DesignJet 5000. > > Now you should be able to print on paper sizes up to A3/SuperB. Please > report whether it works. > > Till > > > Brian A. Peat wrote: >> I am trying to get Gimp-Print to work with a DesignJet 5000 (NON PS version) >> and since there is no file for it in the HP list, I am wondering if someone >> could write one. >> >> I tried the 2500 driver before I realized it was for a DeskJet 2500, but it >> DID output a print to the 5000. It was the wrong scale and the color was >> off, but it did output. >> >> I could test the DJ 5000 if someone would write the driver file. I don't >> think it would be THAT hard for a programmer as there is already a PS file >> for it, and the NON-PS DeskJet drivers can talk to it now. >> >> Thanks, >> >> Brian A. Peat >> ____________________________________________________________________________ >> The Peat Group Member, Apple Consultants Network >> Mobile: (614) 946-8989 E-mail: Br...@th... >> Office: (614) 891-1618 Web: http://www.thepeatgroup.com >> -- >> The Peat Group Offers Macintosh based Consulting, Repair, Web Design, >> Digital Video Editing, and Conference Management. >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Gimp-print-devel mailing list >> Gim...@li... >> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel >> >> > > > |
From: Robert L K. <rl...@al...> - 2002-09-14 00:31:48
|
From: Roger Leigh <ro...@wh...> Date: 14 Sep 2002 00:25:47 +0100 Robert L Krawitz <rl...@al...> writes: > If gimptool --just-print does the right thing, why do we need to > change this? Because libtool could not use the data correctly. To get it to work properly, I needed to parse it with sed (to strip everything but the install path). After that, it was easiest to move this into configure, as a simple check, which cleaned up the Makefile by letting us use much simpler rules, which just work (i.e. automake-generated ones; we don't need any custom rules now). OK. > Is dialog a common program in all modern Unices? It's in FreeBSD, and Debian (and I assume all Linux distributions, since it's used in interactive shell scripts, typically configuration). I only have FreeBSD and Debian to hand though. Does anyone on the list /not/ have dialog available with their OS? We should check Solaris, HP-UX, etc. to be safe. -- Robert Krawitz <rl...@al...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Tyler B. <ty...@us...> - 2002-09-14 00:44:22
|
On Friday, Sep 13, 2002, at 18:25 US/Central, Roger Leigh wrote: > >>> 3. PPDs are no longer created and installed. The user must use >>> cups-genppd(-config) to create them. >>> >>> I think we should keep an option to allow generating PPD files >>> (./configure --enable-install-all-ppd-files or some such). >>> Distributors might well prefer to distribute all available PPD files. >> >> OK. Should translated PPDs still be made available by default, or >> just English? I don't think anyone will want to distribute every >> language, and they can always use cups-genppd or cups-genppdconfig >> to >> generate them. >> >> I don't have a good feel for what the default should be, but it should >> be possible to do both. > > OK. I'll keep all the old rules, but make their use dependent on > enabling via configure options. > >>> Also, does this work in both console and X environments (and >>> preferably on OS X natively also)? >> >> It's a console program. I have had it working on the Linux >> console, and various X terminal emulators. There are some >> variations of dialog, xdialog and gdialog, which use Xlib and GTK+ >> respectively. I have not had success getting these to work though. >> >> Is dialog a common program in all modern Unices? > > It's in FreeBSD, and Debian (and I assume all Linux distributions, > since it's used in interactive shell scripts, typically > configuration). I only have FreeBSD and Debian to hand though. Does > anyone on the list /not/ have dialog available with their OS? > > I don't like dialog much, since it's a bit of a hack using it through > a pipe. Does anyone /not/ have libcdk available--I can use this > instead, if it's common. This is also in FreeBSD and Debian. This > would be more flexible, and not require a separate process forking for > each dialogue box. This is a wiget-based toolkit for curses. > I don't see either of these on OS X, but neither interface would be appropriate for users anyway. As long as a configure option remains available for including them all it shouldn't be a problem. Generating them on the fly seems like a good idea, but how to implement it on OS X is a question for Jim or Richard. |