libkdeprint

[Andreas Pakulat]

On 04.11.07 13:22:29, Kurt Pfeifle wrote:
> 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".)

That would mean creating a new project in kdesupport for just that one
utility and remove it again when kde4.1 or 4.2 ships with a proper
solution. IMHO thats just too much work when the solution of a copy is
just soo much simpler  and non-confusing.

Its not even needed that the utility be renamed in each and every app,
or be a real copy (we can use svn:externals to fetch it from one central
place). The installation can be done into something like
<prefix>/lib/<appname>/ and then there's no naming-clash.

Andreas

-- 
You are a fluke of the universe; you have no right to be here.