Hi Jim, My question was from a user's point of view: how can a Shotwell user discover new plugins? E.g. how does a user know that if he goes to foo.com, I'll find a publishing plugin for barpics.net? This subject was actually discussed in the context of LibreOffice at FOSDEM a week ago: there are lots of extensions for OpenOffice/LibreOffice but users don't know about them so they believe that the software can't do what they want it to do. Same for Shotwell: you could have tons of plugins available, if there is no easy way for users to find them, they won't use them and this will potentially reflect on the software itself. One simple way to solve this could be to have a plugin directory in the Shotwell wiki.
In terms of packaging, what could be of tremendous help is if there was some simple plugin packaging how-to on the wiki: for instance, I'd have no problem coding a plugin but I would not know where to start in order to package it in a .deb that actually works. The there's the aspect of getting the plugins in the distros. I agree that this is distro specific but having pointers along the packaging info would be of great help. For instance, do we know what it would take for a plugin to appear as an add-on to Shotwell in the Ubuntu Software Center (see GnuCash for an example)? Ideally, when you find Shotwell in the software centre, the plugins that are available in the distro should appear as add-ons (which would in turn make them more discoverable by the users). I'm conscious that none of the above has an easy answer and is probably not trivial to do but making sure that the whole plugin ecosystem works beyond the coding and API aspects can greatly enhance the feature. Cheers, Bruno On 14 February 2011 21:08, Jim Nelson <[email protected]> wrote: > Hi Bruno, > > Regarding the error, two things happened: (a) we changed the API slightly > and (b) we removed one of the built-in plugins (which was there just for > testing; it's essentially been moved to the samples directory). Shotwell is > attempting to load an old .so. If you remove that spitter.so file, Shotwell > should start. > > To answer your questions: > > 1. At this point we envision developers distributing their own plug-ins. If > a contributor offers us a plugin that we think belongs in the Shotwell core, > then we would accept it and move it into our source tree. But Yorba does > not want to become the central repository of all Shotwell plugins. > > 2. We plan on bundling our core plugins with Shotwell. Other plugins will > (most likely) be packaged separately. Note that packagers and/or distros > may bundle a number of those plugins together and offer them as a single > separate download. That's beyond our purview. > > 3. Today Shotwell discovers plugins only when they've been installed in one > of two locations: > > /usr/lib/shotwell/plugins > ~/.gnome2/shotwell/plugins > > The first is for plugins available system-wide, the second for plugins only > available to that user. (Shotwell will search their subdirectories as > well.) > > Hope that answers your questions, > > -- Jim > > On Sat, Feb 12, 2011 at 12:21 PM, Bruno Girin <[email protected]> wrote: >> >> Hi Jim, >> >> Interesting! That brings a number of questions: >> * When it comes to distributing plug-ins, what is your preferred >> way of doing it? Developers distribute them on independent sites >> or contribute them to the Shotwell repo? Personally, I'd prefer >> the latter as I'm confortable writing code but I would struggle >> to work out sensible build and packaging code. >> * If the latter, would you rather offer a single package that >> includes Shotwell + plugins or several packages, one for >> Shotwell core and others for the various plugins? >> * And if plugins are distributed separately, what is the plan to >> make them discoverable? >> >> By the way, I get the following error when starting Shotwell with the >> current trunk: >> >> shotwell: symbol lookup >> error: /usr/local/lib/shotwell/plugins/builtin/spitter.so: undefined >> symbol: spit_wad_get_type >> >> Cheers, >> >> Bruno >> >> >> On Tue, 2011-02-08 at 19:29 -0800, Jim Nelson wrote: >> > Hi Rodney, >> > >> > To jump in here, there's still some work to be done to support plug-in >> > writers. We wanted to make sure our own plug-ins worked first so we >> > weren't >> > putting untested interfaces out into the world. >> > >> > One ticket you should be aware of: http://trac.yorba.org/ticket/3160 >> > This >> > is to have Shotwell install the .h and VAPI files in a "make install". >> > This >> > will only happen if a switch is enabled with the configure script. >> > >> > As part of this work we'll also produce and install a .pc file. >> > >> > Until then, you'll need to copy the generated .h, .vapi, and .dep files >> > to >> > your project and include them in your build (the valac --vapidir option >> > is >> > useful here). Because the .vapi files wants to look for the .h files in >> > a >> > plugins/ subdirectory, they should be placed there, i.e. >> > my_project/plugins. >> > >> > Once Shotwell is capable of installing the header and VAPIs, you won't >> > need >> > to include them in your project directory. >> > >> > -- Jim >> > >> > On Tue, Feb 8, 2011 at 5:53 PM, Lucas Beeler <[email protected]> wrote: >> > >> > > Hi Rodney, >> > > >> > > Sorry for not answering your questions! Admittedly, my previous email >> > > was probably more of an introduction to the state of the Shotwell >> > > plug-in system than it was a specific response to your points. Once >> > > again, I apologize. I'll hit your questions one-by-one this time: >> > > >> > > > Is there a shared library that the plug-ins link >> > > > to for the Spit.* API/Interfaces? >> > > >> > > No. The plug-ins link directly with the Shotwell executable. There's >> > > no stub library or developer package that needs to be installed or >> > > that appears in Synaptic or as a pkg-config module. All of the >> > > references to the word "package" in the Shotwell make files refer to >> > > Vala packages. As you noted, a Vala package isn't a "package" in the >> > > sense of Synaptic or pkg-config. It's just a .vapi file and a .deps >> > > file. >> > > >> > > > is there also a .gir being generated for them? >> > > >> > > No. Shotwell doesn't use GObject introspection to discover interfaces. >> > > Interface specification is all done directly through .vapi and .deps >> > > files. >> > > >> > > > If so, is there a .vapi/.deps being built for those? >> > > >> > > Yes. The .vapi and .deps files for the plug-in interfaces are >> > > generated automatically by the Shotwell build system. Simply running >> > > "./configure ; make" will cause the files shotwell-spit-1.0.vapi, >> > > shotwell-spit-1.0.deps, shotwell-publishing-1.0.vapi, and >> > > shotwell-publishing-1.0.deps to appear in the >> > > ${SHOTWELL_ROOT}/plugins/ directory. These should be sufficient for >> > > interface specification, at least as far as the Vala compiler is >> > > concerned. If you're curious, the make rules that generate these files >> > > are located in the file ${SHOTWELL_ROOT}/src/plugins/mk/interfaces.mk. >> > > >> > > > If so, is there a .pc file to specify CFLAGS/LDFLAGS for linking? >> > > >> > > No. The Vala compiler will specify the CFLAGS and LDFLAGS variables >> > > automatically when it invokes gcc as a child process. Right now, if >> > > you want to develop plug-ins in C instead of Vala, you'll need to set >> > > these up manually. >> > > >> > > Cheers, >> > > Lucas >> > > _______________________________________________ >> > > Shotwell mailing list >> > > [email protected] >> > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > > >> > _______________________________________________ >> > Shotwell mailing list >> > [email protected] >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> >> _______________________________________________ >> Shotwell mailing list >> [email protected] >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > -- Bruno Visit my weblog: http://brunogirin.blogspot.com _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
