[Kde-imaging] About ImagesGallery plugin
ach at mpe.mpg.de
Wed Feb 8 00:31:21 CET 2006
On Tuesday 07 February 2006 23:53, Aurelien Gateau wrote:
> Le Mardi 7 Février 2006 20:32, Achim Bohnet a écrit :
> > I'm still not sure if I like the the config like page(s).
> > A wizard that displays the 4 pages after each other is
> > a better concept IMHO. Current design needs of course less
> > clicks _if_ one is knows that the chosen values in the other
> > pages are correct.
> I agree, a design similar to the print wizard would be nicer. I can do this.
> > Before putting too _much_ efford in imagesgallery additions,
> > time is IMHO better spend to find a way to interact with one (several?) of
> > the existing gallery programs. Many of the missing features, e.g., CSS,
> > are already implemented there. Generating an input/config file for a tool
> > and fire it up from kipi, is much easier to maintain than developing a full
> > featured gallery plugin. Maybe gallery upstream author even takes
> > over/helps to maintain such a plugin (I'm dreaming ;).
> This would be nice, but then we should support several of them, otherwise we
> would tie the plugin to one gallery generator. We should also provide a very
> simple gallery generator, so that users do not need to install an additional
One powerful generator as a start would be good ;)
> > Mhmm, a general (sort of a base class plugin) that take list of files
> > and start app xy with the files in arguments may also be helpful to
> > incorporate e.g., external slideview programs, fire up kommander
> > scripts wrapper around imagemagick or other tools.
> Well... this was one of my original ideas for KIPI: creating standalone
> programs instead of plugins. This way everyone can use them, not only KIPI
> enabled applications.
Mhmm, my idea here was a bit different. Use kipi as a sort of adaptor that
encapsulates the detail how the application is started.
Your idea is like the (not existing) kipirun application
I mentioned in another thread, as a kim-ng, replacement.
> There is a problem with this design though: obtaining application specific
> metadata. A standalone program would not be able to access image comments and
> tags from Digikam or KPhotoAlbum for example.
Obtaining meta data is also a problem for kipi plugins themself. This
needs to be address in API V2 of kipi IMHO.
> I thought about a possible solution for this, but I don't know if it's
> feasible at all: provide a way for standalone programs to access image
> metadata through a DCOP service: Instead of implementing the current KIPI
> interface, KIPI apps would implement a DCOP service which would provide the
> metadata information. A tool like a gallery generation program could then
> query the service for album list, image metadata...
I don't feel qualified to comment on this.
> Kde-imaging mailing list
> Kde-imaging at kde.org
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.
-- reddy at lion.austin.ibm.com
More information about the Kde-imaging