[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KImageIO replacement
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2003-09-28 21:39:21
[Download RAW message or body]

> > Problem with this is, each application who wish to use an QImageIO
filter
> > has to link them explicitly.
> > KImageIO provides a KDE wide mechanism with central registration.
> > The Qt filter mechanisms would be fine for stand-alone applications, but
> > less than optimal for desktop applications. Imagine
> > that Konqueror could read TIFFs (as an example), while Kicker could not
do
> > it...

> Well, it is already the case, if your application forgets to call the
KImageIO
> registration method.

Sorry, I meant that Konqueror could read TIFF, but no EPS, while Kicker
could read both...
Currently KImageIO it is a one-or-nothing solution.


> >
> > I am interested in this problem because I have implemented a KImageIO
> > filter for SVG files (using KSVG), which I would like to test.

> Add it to the registration method. Then you can test with KView. (I found
that
> KView was the best program to test when I added MS-DOS EPS files to the
EPS
> KImageIO.)

So I have to explictly register it in a kdelibs registration method in
kdecore?
This would be unfortunate. I would really like prefer dynamic registration
by providing a service desktop file.
So my SVG QImageIO could be packaged with KSVG, because it uses its
functionality.

Otherwise their would be some nasty dependencies, not to mention the unclear
linking...

Regards
Dirk




 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]