From kde-devel Sun Sep 28 21:39:21 2003 From: =?iso-8859-2?Q?Dirk_Sch=F6nberger?= Date: Sun, 28 Sep 2003 21:39:21 +0000 To: kde-devel Subject: Re: KImageIO replacement X-MARC-Message: https://marc.info/?l=kde-devel&m=106478539527097 > > 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 <<