Re: GSCUPS and GNUstep Printing

[Alexander Malmberg]

Adam Fedor wrote:
> On Jun 11, 2004, at 2:11 PM, Chad Hardin wrote:
> > As for handling both type of printing systems, how to handle that?  Is
> > the best was to simply read the users defaults and then use a
> > different combination of NSPrinter/NSPrintInfo/NSPrintPanel.  It looks
> > like NSPrintOperation should be same either way, on UNIX at least.
> >
> Best would be to check automatically in configure if CUPS is present,
> and use the classes if it is. Perhaps we need an LPR class that would
> handle printing otherwise (or perhaps the CUPS classes could be written
> so they can be used with and without CUPS - I don't really know how
> they work).

I suggest using bundles. Add a gui/Printing/ directory with
subdirectories for each printing system (gui/Printing/CUPS/,
gui/Printing/lpr/, maybe later gui/Printing/win32), put concrete
implementations for the printing classes there, and compile them to
bundles. -gui picks the right one to load (default bundle based on
./configure options, but with a user default key to override it), and
creates the right kind of instance when an app asks for a
printing-related class (either by overriding +allocWithZone:, or, if
it's for a shared instance, by overriding the method that creates the
shared instance).

This also solves the packaging issue. If -gui is linked to libcups
itself, but libcups isn't present, the dynamic linker won't let you run
any apps. With bundles, only the CUPS printing bundle is linked to
libcups, so if libcups isn't present, -gui will still run (and it can
automagically detect that the load of the CUPS printing bundle failed
and load the LPR bundle instead).

- Alexander Malmberg