Re: Rise of the Plugins



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]