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

List:       kde-devel
Subject:    Re: KImageIO replacement
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-09-28 21:20:27
[Download RAW message or body]

On Sunday 28 September 2003 22:36, Dirk Schönberger wrote:
> > I looked in KImageIO and QT's image plugins. I think it would be good to
> > replace KImageIO plugins with pure QT plugins. This way KImageIO can be
> > ripped of from KDE, or can be made more lightweight (no need for the
>
> plugin
>
> > loader). Is this a good idea? If it is I could present some code, too.
>
> 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.

>
> I am not quite sure if KImageIO filters can be layered, so that they can be
> either used separately (QImageIO) or
> as part of KImageIO.

As they are already QImageIO, I doub that it would be complex. (But as always 
I suppose that the problem is in the details.)

>
> 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.)

>
> Regards
> Dirk
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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