Re: Rise of the Plugins

["Dylan McCall" <dylanmccall gmail com>]

I think bumping functionality to plugins is a pointless operation, especially in a desktop environment that tries to follow the idea of having a lot of small programs that each do simple tasks very well. Interfaces like D-Bus let us create top-level applications (for lack of a better term in my dictionary) act like plugins by communicating all sorts of information with applications in an intuitive, generic way. The coolest thing with that sort of functionality is that there is a lot of room for standardization, such that programs can interoperate via D-Bus with other programs that they were not even intended to work with.

This plugins madness, on the other hand, involves every program having its own silly way of doing plugins. In addition, like joined windows handled by individual programs themselves to represent multiiple documents (a ramble I will leave for another day; bottom line: Fluxbox does it right), the extra processes are effectively concealed from lower level systems. I can't say I am hugely knowledgeable about the "lower level systems" that I vaguely mention for fear of sounding like too much of an oaf, but I know there are already systems that handle resource distribution and memory management for processes they know how to handle. These plugin systems tend to do that same thing in their own ways, but those ways happen to be much less carefully crafter and do not have years of attention behind them.

Besides that, those plugin systems rarely offer functionality we cannot get through even a separate program. One unusual example is Epiphany's extensions. Those tend to be very simple plugins that trigger single additions to the core behaviour of the program. Going through the dialog where they are chosen, it feels a lot like regular program preferences, and that is made moreso by the unusual ability for extensions to immediately start working without the need for a browser restart. For example, I can turn on the Tab Sizer extension and have my tab bar immediately sized to always fit on the screen with no need for scrolling.

In theory, Evolution's plugins would offer that same feel, but they don't really. I think a reason for that is they often add /a lot/ of functionality and require configuration; one must peel through two layers of configuration tools to get what he needs. Instead of Epiphany ("Resize tabs to fit window?" "Block ads?" "Scroll with middle mouse?"), Evolution's plugins are a lot of groups of yet more options ("IMAP Features") -- although this isn't always the case, for example with "Block plain text".

Frankly, I think the underlying flaw is in Evolution's core design. It is built to be a very big program, promoting very big plugins; if each plugin there just did a single thing each, we would have not just tens, but hundreds of them!
Clearly, the problem of having an enormous core was observed and acted upon, but the solution just creates a new problem: A lot of plugins, which feels frighteningly similar to KDE. A smoother course of action, and one which fits more with the expected behaviour of GNOME software, would have been (and still would be) to split Evolution into a bunch of individual programs. Not just sub-programs handled by a miniature operating system, but actual individual tools; Mail, Calendar, Notes, etc.
This way they are modular components in a way that other applications can easily work with, and, most importantly, those preferences dialogs shrink to a tiny fraction of their initial size. No need to split Mail, Calendars, etc. via tabs; the options can be easily divided and quickly figured out by the easy idea that these are different programs, with different top-level windows. In the places where plugins do still serve their purpose, they can be much simpler plugins built for each component. Plugins could be nicely aimed at certain components, so instead of being for Evolution as a whole, being for Evolution's mail handling system.

Most importantly, when functionality so significantly unusual that it couldn't fit in the core of Evolution still wants to work within Evolution's systems, it would not have to be implemented as a huge plugin, but as a simple alternative to one of its major components, easily implemented by adhering to some standards so that it "looks" the same as the old component (to Evolution's different programs), and otherwise being a completely normal application visible in the main menu.

Bye,
-Dylan McCall

On Nov 14, 2007 12:50 PM, Baptiste Mille-Mathias <baptiste millemathias gmail com> wrote:

On May 17, 2007 5:26 PM, Vincent Untz <vuntz gnome org> wrote:

> 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.
>

I wanted to bring back to discussion to the list because originallythe
the thread ended in a discussion about licence, but there was no
discussion about the UI / usability of plugins in the GNOME
applications.

I've just open a bug concerning Evolution regarding the way plugins
are handled. (http://bugzilla.gnome.org/show_bug.cgi?id=496839 )

As more and more application comes with their plugin infrastructure,
it would be nice to have a great solution :)

Thank you

--
Baptiste Mille-Mathias
Les gens heureux ne sont pas pressés (merci vuntz)
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list