libkdeprint

[Kurt Pfeifle]

Alex Merry wrote:
> On Saturday 03 Nov 2007, Kurt Pfeifle wrote:
>> John Layt wrote:
>>> On Saturday 03 November 2007, Alex Merry wrote:
>>>> On Saturday 03 Nov 2007, Kurt Pfeifle wrote:
>>>>> I still think it is better to use something like "cupsdoprint" in
>>>>> KDE3 than directly using the commandline print commands.
>>>> I think you may be right.  It's a single file, and reasonably
>>>> straightforward.  Currently, it uses dcop (which is no more) to
>>>> ask kdeprintd (which is no more) for the CUPS password in case it
>>>> is needed.  Other than that, it's just a simple command line
>>>> utility to send stuff to cups.
>>>>
>>>> playground/base/kdeprint/libkdeprint/cups/cupsdoprint.c
>>>>
>>>> Alex
>>> I had thought about that, but it then adds a compile time
>>> dependency on CUPS for every app that includes it, and each app
>>> would have to name it something different to prevent install
>>> clashes.
>> I don't understand that argument. If you had a "kdedoprint" utility,
>> why would you have to include that in every app?
> 
> Because we're not adding this support in kdelibs (because that would tie 
> us to binary compatibility, and there are issues with this not being 
> cross-platform).  So we have to add it in every application, which 
> means every application would have to provide its own version of 
> kdedoprint.

No, I still don't get it.

You also do not provide the "own version of lp/lpr". You expect the
apps that need a fileprinter to find it installed. Same would apply
for kdedoprint. (To the user it doesn't make a difference if that
kdedoprint utility is part of kdelibs, kdebase, or kdesomething. He
just needs to be told, somehow, "if you want to print from okular,
akular and ekular, you need to install kdedoprint".)

> The only other option would be to have it in kdebase/runtime, I guess.
> 
>>> Besides, we wouldn't get any extra
>>> features over using lp/lpr,
>> I think we would. At least, we wouldn't need to care about "is either
>> 'lp' or 'lpr' installed? and if so, is it the right one for CUPS?"
> 
> We'd still have to do a build-time check and a run-time check, though.

Hmmm...

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany