From kde-core-devel  Sun Jul 21 02:11:36 2002
From: Andreas Pour <pour () mieterra ! com>
Date: Sun, 21 Jul 2002 02:11:36 +0000
To: kde-core-devel
Subject: Re: KSVG - ready for KDE 3.1?
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=102721770616597


Hi,

> On Saturday 20 July 2002 06:51, Andreas Pour wrote:
> > Is it possible to get an agreement that if any image can be shown to
> > crash KSVG, it will be set not to be installed by default (and, for this
> > commitment, fixing that one crash would not solve the problem, the point
> > is it should not be crashing at all by then)?  So there are no hurt
> > feelings or arguments if it needs to happen - just show one example and
> > that's it?  B/c if there is any crash I do not think it should be
> > shipped, stability is more important right now.
> 
> given the number of SVG images in actual use on the web right now (very, very
> few)

That's an argument against departing from the default, which is that
KSVG is not part of KDE 3.1, isn't it?  But the reality is some users
might have this version installed for quite some time, so that is why I
think it is worth considering.

> and the fact that i don't know of a single other part of KDE that has
> such a "no possible way to crash it or don't release it" policy, this seems a
> little harsh and even unfair.

Actually I think it's a pretty good policy for adding features.  Would
make things much more stable :-).  If KSVG were a standalone app, it
would be less of an issue, the problem I see it it crashes Konqi, which
really needs to be protected against those things, that is what really
makes the whole desktop seem unstable.

There are of course other ways to make sure Konqi does not crash - like
having KSVG run in a separate process (a kio_slave, or a daemon, or a
separate process, maybe an out-of-process KPart, and deliver xpm's or so
to Konqi, or use an approach like Kicker uses to parent "untrusted"
applets).  There was talk of having an image server anyway, perhaps a
convenient reason to implement a prototype.

I just think the stability of Konqi should not be diminished on account
of new features, par. if reasonably avoidable.  I don't know all the KDE
technologies as well as others, but what I suggest is to be creative,
and find ways to add features without diminishing stability.
 
> i agree that if it is highly unstable / easily crashable then it should
> probably not go out, but requiring its critical defect rate to be 0 is a
> little harsh. nsplugins can't say that, kjs hasn't been able to say that ....

KJS is a bit different, it's quite a lot higher on the "necessary"
scale, and it cannot really be separated from KHTML.  Also, b/c of its
interrelationship with KHTML, I presume it's much harder to fail
gracefully.
 
> getting public use and stress on this new component for a very new and only
> recently post-experimental technology would also be invaluable. this is about
> viewing gifs or jpegs. yet. ;-)

I think gifs and jpegs are good examples of things that don't crash
Konqi.
 
> so how about a compromise somewhere in between, such as being able to handle
> w/out crashing the W3C SVG Test Suite: http://www.w3.org/Graphics/SVG/Test/ ?

It's quite easy to avoid a crash on some known examples, probably the
test can be satisfied and crash on a high percentage of all other SVGs.
 
Ciao,

Dre