Adam, That sounds like a great plan :-)
Bruno On Tue, 2011-02-15 at 18:13 -0800, Adam Dingle wrote: > Bruno, > > today at Yorba we met to discuss plugin packaging/distribution more. > Here's our tentative plan. > > The core Shotwell publishing plugins (Facebook, Flickr, Picasa Web, > YouTube) will continue to live in the Shotwell trunk. Starting in > Shotwell 0.9, they will build into a shared library separate from the > main Shotwell executable. > > Other existing plugins (Yandex, Piwigo) will stay in the Shotwell trunk > for 0.9, but will build into an extra shared library which is separate > from the core plugin shared library. In the Shotwell 0.10 time frame, > we plan to move these plugins to a separate shotwell-plugins source > tarball which will be hosted in version control at Yorba. Other authors > may contribute plugins to shotwell-plugins as long as they seem to be of > good quality. The bar for getting into Shotwell core is very high > (major services only, all code carefully reviewed at Yorba). For > shotwell-plugins it will not be as high, but we will certainly reject > plugins that contain crashing bugs, for example. It will be up to > distributions to decide whether to install and/or enable the > shotwell-plugins package by default. I think they will probably not, but > users will be able to install this package easily if they want it. > > Finally, we'll have a Shotwell wiki page which lists all existing > plugins (including core plugins, those in the extra shotwell-plugins > tarball, and those hosted by third parties). Hopefully there will also > be some helpful tutorials helping plugin authors get started. > > All of this echoes common practice in the GNOME world. For example, > gedit includes some core plugins in its source package, but there is a > gedit-plugins source package containing additional plugins and then a > wiki page listing zillions of third-party plugins. > > adam > > On 02/15/2011 11:45 AM, Bruno Girin wrote: > > 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 > >> > > > > > > _______________________________________________ > 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
