Gwenview, kdegraphics and libkipi

Hello,

There is a thread on kde-devel-core discussing the inclusion
of Gwenview in 
kdegraphics for KDE4. One important question is what to do
concerning the 
dependency on libkipi. 

The simplest solution is to remove support for libkipi in
Gwenview, but I 
think you will agree it's not the best one 

The other solution is to move libkipi into a new module
named kdegraphicslib, 
so that libkipi is distributed with KDE. This would be nice,
but it would 
require us to be much more strict regarding binary
compatibility. Basically 
it would mean no more binary incompatible changes once
KDE4.0 is out.

To avoid splitting the discussion on two mailing lists, I
invite you to join 
the ongoing discussion on kde-devel-core (use news.gmane.org
if you don't 
want to subscribe).

Aurélien

PS: Note that this change would "only" concerned
libkipi. It would not impose 
any restriction on kipi-plugins.

_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging

Le Mercredi 17 Janvier 2007 07:51, Caulier Gilles a écrit :
> > PS: Note that this change would "only"
concerned libkipi. It would not
> > impose any restriction on kipi-plugins.
>
> This is not true Aurélien. If libkipi is hosted by KDE
4, i t will be
> ported to Qt4 ! Right ?

What I meant is that only libkipi would have been concerned
by a move into 
kdegraphics: kipi-plugins could have stayed in extragear.

Of course all this code will eventually need to be ported to
Qt4. You just 
can't escape it.

Anyway, the problem has been resolved: Stephan Kulow is OK
with Gwenview 
having an optional compile-time dependency on libkipi.

Aurélien

_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging

Le Jeudi 18 Janvier 2007 10:20, Angelo Naselli a écrit :
> Alle 10:14, mercoledì 17 gennaio 2007, Caulier Gilles
ha scritto:
> > Le mercredi 17 janvier 2007 10:03, Angelo Naselli
a écrit :
> > > Alle 08:53, mercoledì 17 gennaio 2007,
Valerio Fuoglio ha scritto:
> > > > Alle 00:07, mercoledì 17 gennaio 2007,
Aurelien Gateau ha scritto:
> > > > > PS: Note that this change would
"only" concerned libkipi. It would
> > > > > not impose any restriction on
kipi-plugins.
> > > >
> > > > IMHO, the best solution for the future
of kipi-plugins, is to be
> > > > included too.
> > > > Can't we do this?
> > >
> > > hmm, if not necessary why?
> > > We're not so good at releasing new plugins,
but something is
> > > changing (new ideas, new developers, new
maintainers and
> > > contributors,...) and i wouldn't like to see
that going backwards again
> > > :(
> > >
> > > Just my 2 €cents
> > > 	Angelo
> >
> > Look my previous mail. if libkipi is moved in
KDE4, it will be ported to
> > Qt4. Only gwenview will use it until all others
host will be ported to
> > Qt4...
> >
> > This sound like a fork of libkipi dedicaced to
gwenview.
> >
> > In fact, I'm not favorable to do it.
>
> But we should evaulate a migration though sooner or
later.....
>

Sure. When i said "> > In fact, I'm not favorable
to do it", i want mean 
"now" (:=)))

Gilles
_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging

Le Jeudi 18 Janvier 2007 10:16, Angelo Naselli a écrit :
> Alle 22:56, mercoledì 17 gennaio 2007, Aurelien Gateau
ha scritto:
> > Anyway, the problem has been resolved: Stephan
Kulow is OK with Gwenview
> > having an optional compile-time dependency on
libkipi.
>
> Yes but that has to be tested first. So I'd expect that
optional dependency
> wouldn't be optional, or that would mean leaving that
packagers/distros
> that aim. And if something goes wrong? who fixes the
problem after the
> release is out?
> I'm afraid that means to have gv without kipi &co.
for the most....

I don't think so. kdegraphics could have an --enable-kipi
option which would 
be set to "auto" by default. The whole thing will
work this way:

- When KDE4.0 is out, Gwenview will be dynamically linked on
libkipi.so.x 
(assuming libkipi.so.x is a KDE4 version of libkipi), a
symlink to 
libkipi.so.x.0.0.

- If a new, binary compatible, version of libkipi is
released the .so file 
will be libkipi.so.x.1.1. libkipi.so.x will point to this
new file and 
Gwenview will make use of the new libkipi.

- If a new, binary incompatible, version of libkipi is
released, the .so file 
will be libkipi.so.x+1.0.0, which can be installed alongside

libkipi.so.x.0.0. Of course Gwenview won't benefit from this
new libkipi but 
it won't block any other KIPI application from using
libkipi.so.x+1.0.0.

Aurélien


_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging

On Friday, 19. January 2007 01:55, Aurelien Gateau wrote:
> Le Jeudi 18 Janvier 2007 10:16, Angelo Naselli a
écrit :
> > Alle 22:56, mercoledì 17 gennaio 2007, Aurelien
Gateau ha scritto:
> > > Anyway, the problem has been resolved:
Stephan Kulow is OK with Gwenview
> > > having an optional compile-time dependency on
libkipi.
> >
> > Yes but that has to be tested first. So I'd expect
that optional dependency
> > wouldn't be optional, or that would mean leaving
that packagers/distros
> > that aim. And if something goes wrong? who fixes
the problem after the
> > release is out?
> > I'm afraid that means to have gv without kipi
&co. for the most....
> 
> I don't think so. kdegraphics could have an
--enable-kipi option which would 
> be set to "auto" by default. The whole thing
will work this way:
> 
> - When KDE4.0 is out, Gwenview will be dynamically
linked on libkipi.so.x 
> (assuming libkipi.so.x is a KDE4 version of libkipi), a
symlink to 
> libkipi.so.x.0.0.
> 
> - If a new, binary compatible, version of libkipi is
released the .so file 
> will be libkipi.so.x.1.1. libkipi.so.x will point to
this new file and 
> Gwenview will make use of the new libkipi.
> 
> - If a new, binary incompatible, version of libkipi is
released, the .so file 
> will be libkipi.so.x+1.0.0, which can be installed
alongside 
> libkipi.so.x.0.0. Of course Gwenview won't benefit from
this new libkipi but 
> it won't block any other KIPI application from using
libkipi.so.x+1.0.0.

Side by side needs a bit adaption e.g. translation files
have right now
no Major version in their name.

But the interesting thing will be kipi-plugins.  When
kipi-plugins is
build against libkipi.so.x+1.0.0  an app linked against the
old 
libkipi.x.0.0 can not find the kipi-plugins.  Of course we
can also
adapt kipi-plugins to stay side by side.

Distros and pkger will surely be not happy to maintain old
and new
kipi-plugins side by side.  I assume that they much perfer a
patch
that adapts gwenview to new kipi-plugins, that they can
apply.

But all this is only a problem when the api changes. It can
always
be extended.

Achim
> 
> Aurélien
> 
> 
> _______________________________________________
> Kde-imaging mailing list
> Kde-imagingkde.org
> htt
ps://mail.kde.org/mailman/listinfo/kde-imaging
> 

-- 
  To me vi is Zen.  To use vi is to practice zen. Every
command is
  a koan. Profound to the user, unintelligible to the
uninitiated.
  You discover truth everytime you use it.
                                      -- reddylion.austin.ibm.com
_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging