[Kde-imaging] extragear/libs/kipi-plugins (and common dir)

Angelo Naselli anaselli at linux.it
Sat Oct 7 11:30:19 CEST 2006


Alle 09:51, sabato 7 ottobre 2006, Angelo Naselli ha scritto:
> Alle 14:54, venerdì 6 ottobre 2006, Aurélien Gâteau, @orange.fr ha scritto:
> > On Thu, 5 Oct 2006 09:01:32 +0200, Gilles Caulier <caulier.gilles at kdemail.net> wrote:
> > > Ok, i have found the problem. In kipi-plugins Makefile.am, we using this
> > > line :
> > > 
> > > kipiplugin_rawconverter_la_DEPENDENCIES = $(LIBKIPI_LIBS_DEP)
> > > 
> > > ... witch must be :
> > > 
> > > kipiplugin_rawconverter_la_DEPENDENCIES = $(LIBKIPI_LIBS_DEP) \
> > > 	$(top_builddir)/kipi-plugins/common/exiv2iface/libexiv2iface.la
> > > 
> > > In DigikamImagePlugins, i don't use *_la_DEPENDENCIES with plugins. This
> > > is
> > > why automake check automaticly all depencies properlly.
> > > 
> > > I have fixed in svn all Makefile.am from all kipi-plugins with depend of
> > > libexiv2iface.la
> > 
> > Just a (stupid) question: if it's common to all plugins, then why not keep it 
> > in libkipi?
> Well as far as I can say there is some kipi-plugins stuff that should stay in
> kipi-plugins tree. 
> I mean, for instance,  kipi-plugins version is important, till now the kipi plugins
> version is confusing with libkipi one...
> 
> Even if i don't like the way we're using - static linking means we must
> take care to put all the lib pathes into the plugin makefiles, if we need more
> than one libs from common, the Makefile.am becomes awful (IMO of course) -
> I believe we need a common place, anyway, were to put the common interfaces.
> For instance we can have a class in which we manage a list of filenames
> to have a unique "webbified" name for any of them and a unique relation
> like that:
> list filenames - list Image names
> foo.jpeg         - foo
> foo.png          - foo_1
> foo.mpeg       - foo_2
> and so on.
> Another thing I'm working on, in the spare time (unfortunately very little
> in these days) is to have a common about dialog interface.
> I mean having something like KipipluginsAboutData that
> extends KAboutData and contains all the data that is in common for
> all the plugins, e.g. kipi-plugins web page, version, maybe logo,...
> and that needs data like plugins name, maybe version, description 
> authors and license.
> That should solve the problem that people often do not understand
> they're using kipi-plugins and help us to have the same way to show
> the about dialog. Well maybe we can extend in the same way 
> the help button, or... :)
> In that way I'd prefer a share library instead, something like libkipipluginsstuff.
Ehm, it was an invitation ti a discussion of corse so I should have finished with,
WDYT?

Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-imaging/attachments/20061007/389649d5/attachment.pgp 


More information about the Kde-imaging mailing list