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 <
[EMAIL PROTECTED]> wrote:
> On May 17, 2007 5:26 PM, Vincent Untz <[EMAIL PROTECTED]> 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
> [email protected]
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
