Re: GSCUPS and GNUstep Printing

[Chad Hardin]

On Jun 11, 2004, at 11:28 AM, Adam Fedor wrote:

> On Jun 11, 2004, at 2:11 PM, Chad Hardin wrote:
> > Personally, I would prefer to add the objective-c wrappers I have 
> > already written and put those directly in GNUstep.  Whatever is *not* 
> > transferred over would remain behind in the GSCUPS framework.
> >
> > If I did this, the classes to be added to GNUstep would be:
> > GSCUPS.h/m
> > GSCUPSDestination.h/m       #This is an abstraction of either one 
> > printer or a pool of printers...along with the options associated 
> > with instances of those.
> [...]
>
> Probably these should go in a separate subdirectory under Source.
Ok, under GSCUPS, I suppose?

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

There would be a problem with software packaging if the default 
printing method was determined solely by ./configure flags.  It's very 
likely the package maintainers will want their gnustep-gui package to 
have the capability to use CUPS, but not mandate it.  That is why I am 
thinking there should be both compile time selection (via ./configure 
--with-cups, etc) AND a run-time selection.

What I'm thinking is something along what you are saying with the LPR 
class.  Make subclasses of NSPrinter, NSPrintInfo, and NSPrintPanel for 
both LPR and CUPS.  I suppose you could name them GSCUPSPrinter, 
GSCUPSPrintInfo, GSCUPSPrintPanel and GSLPRPrinter, GSLPRPrintInfo, 
GSLPRPrintPanel.  The *LPR* subclasses would basically be what the 
NSPrinter, NSPrintInfo, and NsPrintPanel currently are, hardly anything 
would have to be written for them.

At this time I must admit a bit of ignorance and I must ask for some 
pointers.  How would I be able to seamlessly allow for this type of 
behavior of the NsPrint* classes?  The Applicatiions will explicitly 
ask for and load an instance of NSPrinter, for example, but I want to 
give them an instance of GSCUPSPrinter instead.  I suppose it would not 
be too difficult, maybe this pseudocode is on the right track?:

@implementation NSPrinter

+(id) alloc
{
        id printer;
        NSString *userDefault;

	//find out what we are actually going to allocate, is it a 
GSLPRPrinter or a GSCUPSPrinter (maybe even a GSWindowsPrinter?)
        userDefault = //whatever the default is

        if( [userDefault isEqualToString: @"GSCUPS"])
        {
                return [GSCUPSPrinter alloc];
        }

        if( [userDefault isEqualToString: @"GSLPR"])
        {
                return [GSCUPSLPR alloc];
        }
        ....
}

+(id) allocWithZone:(NSZone*) zone
{
.......
}

//The rest of the implementation would be basically empty.


@end



Am I on the right track here?


> It would be nice then if NSPrinter/etc was rewritten to use whichever 
> class was available.