[Kde-imaging] ksaneplugin (and libksane)

[Aaron J. Seigo]

On Tuesday 06 May 2008, Gilles Caulier wrote:
> 2008/5/6 Angelo Naselli <anaselli at linux.it>:
> > lunedì 5 maggio 2008 alle 19:35, Aaron J. Seigo ha scritto:
> > > On Monday 05 May 2008, Gilles Caulier wrote:

> >  But let's see it in another way, gwenview needs a stable version of
> > libkipi, that means it can only rely on a release version of libkipi,
> > even if this time we haven't released it yet though.... and that should
> > not need to build against svn version of extragear. And that may be the
> > starting point for any other host applications, imo. If Koffice wants to
> > enjoy kipi-plugins and if any other kde-core applications do, we should
> > consider to move.

yes, that's really sort of the direction i can see things moving: it's a 
victim of it's own success ;)

> > But as it is by now, Gilles is the main libkxxxx 
> > (kipi/kexiv2/kdcraw) developer (we can say almost the only one) and if he
> > does not feel ready to move, we must take that in account.

of course; it's also useful to spread information around the project so people 
know what's going on as well as to probe issues to discover ideas that one 
person or another may not have thought of yet.

> >  I, as far as I'm concerned, am ready to help all of them need to use our
> > libkipi & co. to have them released as much stable (and quicker) as they
> > need.

cool =)

> >  Note that libksane maybe needs to be moved anyway.... imo better to have
> > a new and maintained library instead of an old and almost unmaintained
> > one (as it is libkscan) available for all.

it's not only maintenance, it's also features like 16 bit/channel.

> Yes Angelo, you have resume very well the situation. libkipi for KDE4
> (and also libkexiv2 and libkdcraw) still in devel stage. Me and
> Marcel, we have work hard to provide faster a suitable library.

note that from my perspective, it's completely fine to have a "not perfect" 
situation for 4.1/4.2 as far build and dependencies go (e.g. gwenview 
depending on extragear-libs for certain features). but it would be good to 
work towards a better solution, and having a time frame would be good, even 
if that's "we'd like to make it happen for KDE 4.5" ;)

> It's time to stabilize and finalize, code everywhere, and this include
> digiKam and kipi-plugins. For this last one, it still 40% of plugins
> to port under KDE4. This is the first jobs to do before to move
> something libkipi in another place... because the _goal_ of libkipi is
> to use plugins in hosts applications. Why to share plugins with the
> rest of KDE world if plugins list provided is a reduced one...

consider, however, that increased usage means increased # of hackers as well.

even if all the plugins aren't ported, the library itself can move to a place 
that application developers can start using it. they can add support for it 
to their apps while others work on plugins, and that increases the chance 
that others will help with the plugins.

the plugins don't have to move from where they are, of course .. just the 
library, to satisfy build and runtime dependencies. i would expect, with 
time, some plugins to naturally migrate closer to the library, but that's not 
an immediate concern.

of greater concern to me than the plugins is whether the library itself has 
had an API review recently?

and of course, this is all up to the maintainers of the kipi framework in the 
end =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-imaging/attachments/20080506/0e01a242/attachment.pgp