Regarding kpdf

[Frans Englich]

On Thursday 01 January 2004 01:56, Scott Wheeler wrote:
> On Tuesday 30 December 2003 22:05, George Staikos wrote:
> >   I agree that it needs to be removed.  I have already asked for it
> > (along with other dead code) to be moved to kdenonbeta but I did not
> > receive a reply.
>
> For what it's worth I've had a lot of problems with it too.  It's difficult
> to get it to build on an older distro -- much less work.  There are a lot
> of code paths that aren't hit because of ifdef's that don't seem to have
> been tested much that cause problems if you're missing some of the soft
> dependencies.  I'd also prefer to see it moved back to kdenonbeta for 3.2
> and if it's in better shape in a few months discuss bringing it back for
> 3.3...

I can't comment on the technical merits of kpdf/ghostview but there clearly is 
a usability disadvantage in including more than one.

I find the discussion whether to include kpdf a little bit ridiculus. We, the 
developers, knows that there's a difference between kpdf and ghostview. 
Somehow, we got this idea that a typical KDE user also knows the differences, 
and in case not, will be able to tell from the descriptive texts "PDF Viewer 
(KPDF)" and "PS/PDF Viewer (KGhostView)". Someone tell me: How do a user know 
which pdf to open with kpdf and which one with kghostview? When do the 
user /know/ when stability respective speed is most suitable?
Including both hurts usability: Except from the confusing texts in the 
KMenu(above) it means 1) two GUIs for the same thing 2) a even further 
bloated KMenu.
Including both promotes only a *very* small usergroup - those who know the 
difference between them(or have a preference..). I would say we make 
things /much/ simpler and include one, which is the Right Thing. Those who 
like kghostview or kpdf can install it afterwards(KDE does not have to 
include every possible app outhere.. ;-). There's not many who knows the 
difference and thus will not get hurt. (And those who don't know, will not 
suffer from the usability problems)

One solution which I first thought of (which tries to make everyone happy, how 
coward..) is doing a NoDisplay on kpdf - it solves the usability problems and 
those who can tell the difference can use the minicli or bind it to the 
mimetype in KControl. But again, this would only be done to please the tiny 
usergroup who finds kpdf better and make us get rid of the hard task of 
deciding which one to reject. It's not worth it. I think we can take the 
decision, further it's not worth including an app for such a small userbase.
This is my suggestion to solve this:
If kpdf is acceptable stable, /replace/ kghostview with it. Furtermore, 
stability got higher priority than speed. If it is not stable enough, throw 
it out.
If kpdf does not replace ghostview and the idea is to in the long run 
substitute kghostview(which is my understanding) I suggest directly after 3.2 
it replaces kghostview, so kpdf gets thoroughly shaken before 3.3.

I don't care which one is chosen, and can for that matter not comment on them 
either - I am equally happy with either one of them. Please just 
choose /one/.

Cheers,

			Frans