[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSCUPS and GNUstep Printing
From: |
Chad Hardin |
Subject: |
Re: GSCUPS and GNUstep Printing |
Date: |
Fri, 11 Jun 2004 12:37:00 -1000 |
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.
- GSCUPS and GNUstep Printing, Chad Hardin, 2004/06/10
- Re: GSCUPS and GNUstep Printing, Riccardo Mottola, 2004/06/11
- Re: GSCUPS and GNUstep Printing, Pete French, 2004/06/11
- Re: GSCUPS and GNUstep Printing, Chad Hardin, 2004/06/11
- Re: GSCUPS and GNUstep Printing, Adam Fedor, 2004/06/11
- Re: GSCUPS and GNUstep Printing,
Chad Hardin <=
- Re: GSCUPS and GNUstep Printing, Adam Fedor, 2004/06/11
- Re: GSCUPS and GNUstep Printing, Chad Hardin, 2004/06/11
- Re: GSCUPS and GNUstep Printing, Chad Hardin, 2004/06/11
- Re: GSCUPS and GNUstep Printing, Adam Fedor, 2004/06/14
- Re: GSCUPS and GNUstep Printing, Chad Hardin, 2004/06/15
- Re: GSCUPS and GNUstep Printing, Adam Fedor, 2004/06/16
- Re: GSCUPS and GNUstep Printing, Alex Perez, 2004/06/16
- Re: GSCUPS and GNUstep Printing, Alexander Malmberg, 2004/06/12