Plugins

[Evan Dandrea]

Thanks for laying the groundwork for this with your oem-config merge and taking
on this long overdue task.

Is there any reason to not make the core pages plugins as well?  The document
does not specify one way or the other.

My first thought is that we'll want to add support for dependencies to this, so
we have a way of ensuring that the language selection is present and run before
the timezone selection is done.  This dependency has bugged me for a while as
it prevents us from jumping back to arbitrary pages from the summary page and
then going straight back to the summary page without having to hit next through
every page between.  However, I don't believe there's a way around that at
present.

With respect to hiding pages, are there any pages we can get away with not
showing?  The summary page is the only one that comes to mind.

> We could additionally dumb down the python a plugin needs to provide by
> having them be 'filter lites' custom classes that didn't do everything a
> filter does. But the filter parent classes already provide good default
> methods. We should probably have a plugin parent class that sits between the
> debconf filter and the plugin, just to provide further default methods and
> any special configuration we need.

Indeed, I think this needs to be a requirement as we shouldn't expect very
simple plugins like an EULA to add boilerplate shell code.

> It can install the UI files (.glade, .ui) anywhere it wants.

Why wouldn't we restrict the files to a specific location like we would do with
filters going into the plugins.d directory?

> What about the apply() method and progress? Do we want to expose a string to
> show to user while Ubiquity is apply'ing the plugins? And allow progress
> reporting? Or do we just say 'plugins should apply quickly'?

I think we should incorporate progress reporting.