Plugins

[Michael Terry]

On Mon, 2009-07-20 at 13:23 +0100, Evan Dandrea wrote:
> Is there any reason to not make the core pages plugins as well?  The document
> does not specify one way or the other.

This was intentionally not-specified.  I believe it should be possible
(and would make the pages nice and modular -- no more timezone map logic
in the main gtk_ui.py for example), but didn't want to make it a
requirement for this initial pass.

I intended to try porting one or two core pages and updating the spec as
needed if I ran into blocks.  But this version of the spec is largely
comment-fodder.

One place where the core pages get more complicated that expected
plugins is that some have special asking scripts.  I suppose I could
allow a plugin to provide an asking script, but the spec doesn't really
get into that right now.  Core pages would also require a progress
portion of the spec.


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

It's more about replacing.  For example, mythbuntu replaces a couple of
the core pages (including summary).  So you insert yourself where the
other one used to be, and hide it.  Maybe we should add a 'REPLACE'
field.  But HIDE may as well stay even then.  It might become more
useful when you try to hide other pages from the same plugin or whatnot,
if you have complicated plugin logic.


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

Indeed, it was my wish that a plugin need no shell code.  The spec adds
the 'apply' method and automates the asking of debconf so that the
plugin doesn't need an asking script.  So as-is, plugins can happily
just be python.


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

Just because we didn't need to.  I have the plugin loading its own xml
(it needs access to its own xml anyway so it can play with its widgets),
so I figured it would just add complexity to specify UI file locations.
And maybe some plugin would use a different glade file depending on the
system (maybe if a certain python module is available), so we wouldn't
want to make assumptions about the name of the glade file.  If we can't
do that (and thus can't load the files ourselves automatically), we'd
only be specifying a standard dumping directory for glade files, which
isn't too useful.


> I think we should incorporate progress reporting.

Indeed, a requirement if we want to port core pages.

-- 
mterry • Canonical
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-installer/attachments/20090720/05962554/attachment.pgp