Re: Rise of the Plugins

["Christophe Dehais" <christophe dehais gmail com>]

I'd like to add that imho an application having a plugin architecture
is a little less scary for the would-be contributor. At least I was
myself wrt rhythmbox.
The user may not care but eventually the more contributions the better
the application, so ...

cheers,
Christophe


On 5/17/07, Nickolay V. Shmyrev <nshmyrev yandex ru> wrote:
> В Чтв, 17/05/2007 в 18:26 +0200, Vincent Untz пишет:
> > Hey,
> >
> > It's great to see more and more applications creating a plugin
> > architecture. However, I think it's worth discussing a bit some of the
> > issues we're facing wrt plugins. I'm just raising three points to start
> > the discussion, but there are probably other interesting items that are
> > worth discussing.
> >
> >
> > Naming
> > ======
> > Plugin vs extension? It has already been raised on the list [1], but
> > there wasn't a lot of replies there. Using the same term everywhere is
> > really the only way to go.
> >
> > My €0.02: I think that people are getting used to the Extension term,
> > and it sounds less geeky.
> >
> >
> > UI and code sharing
> > ===================
> > Every time a new module is getting the plugin love, I'm seeing this: "I
> > stole the gedit/epiphany code and integrated it". Wow. Copy and paste?
> > Would it be possible to share all this code in a library? (maybe it's
> > not, I don't know: I didn't look at that code)
> >
> > Also, each module is having its own plugin/extension manager dialog, and
> > they are all looking the same, but with small variations. Wouldn't it
> > make sense to standardize this? Again, maybe a library could help.
> >
> > (And in the future, we might want to get some "update the extensions
> > from the internet" feature, and we don't want to implement this ten
> > times, do we?)
> >
> >
> > Moving features to plugins/extensions
> > =====================================
> > (thanks to Baptiste for having raised this specific issue)
> >
> > One of the first thing people are doing with plugins/extensions is
> > moving some of the current features there. It often makes sense from the
> > code point of view, since things will be cleaner. But it doesn't always
> > make sense for the user.
> >
> > Some of the features implemented in plugins/extensions should just
> > always be there, and it's useless to disable the plugin/extension. The
> > handling of multimedia keys come to my mind (I believe RB is already
> > doing the right thing in this specific case and always uses this
> > plugin). Plugins/extensions about integration with the rest of the
> > desktop are another example.
> > There could also be some way to automatically enable a plugin/extension
> > when it makes sense.
> >
> > It's probably worth considering global settings for various types of
> > plugins/extensions. Many applications may want to ship a
> > plugin/extension changing the status in galago. Maybe it's worth
> > considering the option of having only one place where we say "Enable
> > galago" instead of having all the applications expose the
> > plugin/extension. Or they could all expose the plugin/extension, but
> > only to override the global setting.
> >
> >
> > All this needs to be discussed, and we can probably determine what makes
> > sense, and what we can do to make this kind of feature work better in
> > GNOME.
> >
> > Thanks,
> >
> > Vincent
>
> Although problem with GUI library with widgets for GNOME desktop is
> important it's probably a subject for another discussion. Yes, we need a
> library with quickly maintained but not probably stable widgets. Without
> extensive testing it's hard to write a stable interface for GTK. But
> here I think the third issue is more important - is plugin framework
> really required?
>
> A few bad properties of plugins:
>
> 1. They are badly tested. So called Evolution plugins distributed with
> Evolution aren't translated properly even now. As with every GUI option
> we create a lot of cases to test and make our system very complicated.
> With current overcomplicated systems stability and safety became much
> more important. We can't guarantee stability in plugins and user doesn't
> care is it flash plugin or epiphany itself crashed and thus a hour of
> his work is lost.
>
> 2. They duplicate package-management system. It's really not so good we
> don't have a package management application and use distro-oriented
> tools, but is it a reason to introduce an application or UI to manage
> installed functionality? Why not just use package manager for this task?
> Package manager has almost all required functions - signature checks,
> search, meta-information, dependency tracking and so on.
>
> 3. They are hard to find out. When user installs application it should
> just work as expected nothing more. I remember I spent several hours
> trying to find out they way to export certificate from epiphany. Of
> course the first thing you might do is to search menu item for plugins.
> Also you can try to adjust dozen option in your app? Isn't it easier to
> move to another desktop environment.
>
> 4. As noted before they require too complicated interface to work with
> application. Signing and searching is the minor things. What about
> safety for cooperation and dependency issues? Dynamic linking is not a
> solution here, it should be some sort of IPC with mandatory error
> checking, dbus probably. Applications can define extension points
> through dbus and others can use them but it's very different from
> plugins. Don't forget about required documentation for plugin-writers.
>
> 5. Usually people say that plugins make code modular. I don't see how.
> You can make your code modular just by separating a library or a file
> and defining interface.
>
> Probably someone will add more, it would be appreciated. I haven't seen
> eog-ng yet and probably it's not my domain but I can't imagine what can
> be implemented there with plugins.
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list