kde3 kde4 coinstallability take two

[Kurt Pfeifle]

Thiago Macieira wrote:
> Em Monday 22 October 2007 14:29:25 Kurt Pfeifle escreveu:
>>> In any case, CUPS isn't the only backend we support.
>> It is a pretty save guess that more than 90% of *nix-based users have
>> CUPS.
> 
> No doubt about that. In fact, I'd go as far as to say that CUPS is the only 
> printing system we should support on Unix. This is my *personal* opinion.
> 
> The problem is that we're no longer Unix-only. Here's where problems arise.
> 
>> This in turn means we should be very careful with what we change for
>> them, especially if we remove features.
> 
> I understand.
> 
>> And for Win32/64 of course, never existed at all up to now.
> 
> Now it does. And it doesn't accept PostScript.

I dare not accept this statement by its face value. (And in the
past, I already hinted [more than once] at things that should
be looked at in order to get access to that missed PostScript
support).

>>> Therefore, we cannot rely
>>> on CUPS features, like accepting those formats.
>> Where there is CUPS underneath, *of course* you should rely on and offer
>> to use those features! What else?!
> 
> Agreed, but it has to be done only where it makes sense.

It makes *always* sense. Because I said: "where there is CUPS underneath..."
There it makes always sense.

If we agree that we don't take away features from *nix users and CUPS
users, just because we can't support the same features for Win32/64,
I'm already much less concerned.

> If we provide a "print a PNG" feature, we have to provide it everywhere (or 
> come up with a really good and convincing reason why it doesn't work in 
> certain circumstances). 

In KDE3, when you load one or more PNG files into kprinter, if you then
switch the print subsystem away from CUPS, you don't see the "Image" tab
any more. That is because only CUPS supports it, and because kprinter3
already came up with a really good and convincing way to handle these
changed conditions.

> Which in turn means we must not depend on a CUPS feature only: it has to 
> be "emulated" in our printing system if the feature isn't available in the 
> backend.

Why?

(And do we also "emulate" other features that way if the real feature pro-
viding backend is not available?)

> Printing image formats is rather easy, because we have image loaders. 

I don't understand what you mean with "image loaders". (Probably you are
again talking about stuff on the low level C++/classes/code area...)

> We don't 
> have a PostScript loader though: so implementing a light-weight equivalent 
> of "kprinter *.ps" is close to impossible. Enter, therefore, the heavy-weight 
> all-purpose document viewer.
> 
> I have no problems with providing "kprinter" in KDE Workspace: we can easily 
> say we support CUPS only in the KDE Workspace (see above). And this is also 
> not a co-installability issue, because KDE Workspace 4 cannot be installed at 
> the same time as KDE 3's.

What is "KDE {3,4} Workspace" exactly?

>>> That is not a KDE3-vs-KDE4 co-installability issue.
>> Right, But it is something to keep in mind whenever "printing" is dis-
>> cussed.
> 
> No. You're hijacking every single thread that has "print" mentioned to 
> reiterate again and again your arguments. We have understood them.

I still see too many misconceptions about *kprinter3* popping up in
order to be convinced of that. A *lot* of people (of *core* people)
do not know/understand fully what/how kprinter and KDEPrint in KDE3
did things, but they nevertheless base their arguments on this par-
tial knowledge when discussing kprinting4.

> Now let's stick to the topic at hand: installing KDE 3 and 4 at the same time.

OK. (But I keep watching for "print" mentions... :-)   )

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