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
