[Svn] Plugin API development

till klimpong at gmail.com
Thu Feb 12 14:52:24 CET 2009

Hey Thomas,

sweet news! :-)

On Wed, Feb 11, 2009 at 11:58 PM, Thomas Bruederli <roundcube at gmail.com> wrote:
> Hi Devs
> I recently committed some more code for the upcoming plugin API and
> also some sample plugins to demonstrate and test the API. To describe
> the API I also started some documentation in the wiki:
> http://trac.roundcube.net/wiki/Doc_Plugins but it's still far from
> being complete.
> Now we can go on with adding more hooks in the RoundCube core and
> refine the current functionality of the plugin API. Kris, Ziba: you
> once told me that you're working on some plugins and hooks. Are you
> ready to commit these to the devel-api branch? All the others are
> kindly requested to have a look at the current state of the API and
> submit your concerns and suggestions.
> However, there's one thing I'm not sure how to design/implement: The
> cooperation of plugins and the skin.
> Some plugins will want to add UI elements and complete screens/steps
> to the application and now the question is how these should be built
> and styled. Should the plugin put the button into place and style it
> (with an icon perhaps)? This makes it easy to install plugins because
> the skin doesn't need to be changed. On the other hand, a plugin can
> completely mess-up the UI with ugly icons and misplaced elements. But
> this requires one to alter the skins when installing a new plugin. And
> what about custom screens (e.g. for the legendary RSS reader or a
> filter plugin)? Do they bring their own skin templates or will they
> even have the HTML output hard-coded?

Could we offer DOM "hooks" (e.g. IDs) and use jQuery to populate them
"onload" ($('#hook').ready()). I'm guessing the styling is up to the
author of the plugin but we should recommend that they use CSS so
people can override styles.

jQuery would also load a default.css from the plugin. All CSS should
be prefixed within the namespace of the plugin to avoid duplicate
mess, e.g. .plugin-fancyemoticons-foobar {}. Obviously DOM IDs used by
the plugin should follow.

RE: CSS and customization, I'm thinking something like this:


"default.css" contains the default CSS styling provided by the plugin author.

If a user wants to override it, they can do that in local.css.
local.css is obviously loaded after the default.css.

If we come up with a plugin install/update function, the changes in
local.css shouldn't be touched and therefor be preserved.

> I'm really unable to decide between those different approaches and I
> hope you can help me out. What do you think or expect? Have you seen
> other systems solving this problem in one or another way?
> Best regards,
> Thomas


More information about the Svn mailing list