libkdeprint

[Kurt Pfeifle]

Alex Merry wrote:
> I'd like to remove kdelibs/kdeprint and kdebase/runtime/kdeprint (ie: 
> libkdeprint and associated utils and kcm) to playground on Monday 23rd 
> October.
> 
> As of now, there are no dependencies on libkdeprint (except 
> kdebase/runtime/kdeprint) in trunk/KDE, although the porting has caused 
> printing to break with programs that used KPrinter::printFiles, such as 
> Okular.  This is a major problem.  One suggested solution is that these 
> programs talk to Cups or lpr directly 


I don't get this (bear with me, I'm "only" a user). So you're asking
all no-longer supported applications to craft their own individual
solutions? "Talk to CUPS", meaning to implement a (complete)/(partial)
CUPS/IPP client functionality within themselves?

> (printFiles() is inherently 
> non-portable to non-UNIX systems), 

And this means that we can't support a "special", non-portable solution
for Unix systems (which are, after all, the favorite ones for most of
the KDE community)? I'm not asking to not drop support for portability,
or drop support for Windows and Mac -- I'm just asking to *not* drop
support for some of our best showpiece applications on that platfrom
that is our home turf.

> although they should ideally draw to 
> a QPainter.

I don't understand that either; but it seems a technicality I can't
understand without becoming a coder.

How much effort does that "ideal" solution mean for the apps that need
to implement it? How many man days of work, how much delay in releasing
KDE 4.0? Is there a workaround possible with less effort, and still add
that "ideal" solution in 4.1?


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