frans.englich at telia.com
Fri Jan 2 21:19:43 GMT 2004
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
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
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
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
More information about the kde-core-devel