[Kde-imaging] About ImagesGallery plugin

[Achim Bohnet]

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

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.

Achim
> 
> Aurélien
> 
> _______________________________________________
> Kde-imaging mailing list
> Kde-imaging at kde.org
> https://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.
                                      -- reddy at lion.austin.ibm.com