Plugins

Differences between revisions 1 and 2
Revision 1 as of 2009-07-17 17:34:14
Size: 7996
Editor: bismuth
Comment:
Revision 2 as of 2009-07-17 17:43:54
Size: 8164
Editor: bismuth
Comment:
Deletions are marked like this. Additions are marked like this.
Line 52: Line 52:
I think option 3 above gives us the most flexibility for the least cost. The syntax can be dreadfully simple: only allow one 'after' ''or'' 'before' statement, and it would reference the python module for the page (reducing complexity for things like the partitioner that have 2 UI files, but one module. So, for example: I think option 3 above gives us the most flexibility for the least cost. The syntax can be dreadfully simple: only allow one 'after' ''or'' 'before' statement, and it would use a defined 'name' for the specified page (reducing complexity for things like the partitioner that have 2 UI files, but one module. So, for example:
Line 54: Line 54:
from ubiquity.components import language
AFTER=language.Language
AFTER='language'
Line 60: Line 59:
from ubiquity.components import language, timezone
HIDE=[language.Language, timezone.Timezone]
HIDE=['language', 'timezone']
Line 64: Line 62:
Ties (where two pages specify 'after language' for example) can be broken by file system ordering in plugins.d (ala option 4 above). Thus, Ubiquity just has to read those in in order, and everything just works. The number before the filename can be considered a priority then for ties. i.e. if both 10-mypage and 22-otherpage specify {{{AFTER=language.Language}}}, 22 would be first, then 10. Plugins would have a NAME field that specifies a name to use. The standard pages would have similar values. The recommended NAME for pages would be the module name that defines the page.

Ties (where two pages specify 'after language' for example) can be broken by file system ordering in plugins.d (ala option 4 above). Thus, Ubiquity just has to read those in in order, and everything just works. The number before the filename can be considered a priority then for ties. i.e. if both 10-mypage and 22-otherpage specify {{{AFTER=language}}}, 22 would be first, then 10.
Line 67: Line 67:
 * If both are specified, Ubiquity will just take use AFTER.
 * If AFTER/BEFORE specify a page that isn't being used, the page is ignored (and other plugin options like HIDE are '''not''' used -- it's likely this page is optional, pending installation of some package we don't have or was written for an older Ubiquity).
 * If AFTER or BEFORE is a list, the first component that Ubiquity recognizes is used.
 * If both AFTER and BEFORE are specified, Ubiquity will use AFTER if it recognizes it, else use BEFORE.
 * If U
biquity still can't find a value that it recognizes, the page is ignored (and other plugin options like HIDE are '''not''' used -- it's likely this page is optional, pending installation of some package we don't have or was written for an older Ubiquity).
 * This allows
Line 96: Line 98:
from ubiquity.filteredcommand import Plugin
from ubiquity.components import usersetup
from ubiquity import Plugin
Line 100: Line 101:
BEFORE=usersetup.UserSetup NAME='foo'
BEFORE='usersetup'

Here, I describe a possible system for enabling drop-in plugins for Ubiquity and OEM-config.

Requirements

  • Insert a page: The ability to add a page anywhere in the page sequence
  • Hide a page: The ability to stop a standard page from showing up (the combination of inserting/hiding lets you replace a page)
  • The ability to stop going forward (say, a EULA page that requires an approval checkbox). Might as well through in stopping going back.
  • Let plugins be translatable
  • Let plugins execute code after user is done entering any info, to actually do what user asks
  • Let plugins offer gtk or kde UI (or debconf or noninteractive, etc if desired)

Wants

  • Reduce plugin's exposure to Ubiquity internals, to make them more change-proof.

Design

What a plugin looks like

Bits of a standard gtk page:

  • A glade file
  • A debconf filter
  • Ask and apply scripts

With the above, by providing the above files, we can do everything a normal page can in a plugin. Assuming Ubiquity knows how to find the files.

The asking can be provided by Ubiquity, as long as the plugin gives us a list of debconf questions to ask. And the apply script could just be done by the filter by a special 'apply' method. Then all a plugin needs is a filter and a UI file.

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.

How the plugin will talk to its own UI

It can install the UI files (.glade, .ui) anywhere it wants. The plugin will have UI classes like 'PageGtk' or 'PageKde' or 'PageNoninteractive' which will be instantiated by Ubiquity and passed to the filter class. If the right class for the current frontend isn't find, the plugin is ignored. For GUI frontends, a method get_ui() can be called to get the frontend-specific UI object (for GTK, a tuple of the top-level name and the glade xml object). The GTK frontend will load and connect the glade file itself.

How the plugin is translated

Can use its own debconf template. Ubiquity will do the translation for it, from its template.

How to find the plugin

Plugins can drop the filter in /usr/lib/ubiquity/plugins.d/

How to add/remove pages

There are four major options here:

  1. Require some third party to specify a hard list of pages. This could be done via preseeding the appropriate page list that Ubiquity uses (there's one for Ubiquity and one for OEM-config).
  2. Only allow one plugin (though it could still use multiple pages). This plugin would own the mechanism for specifying a page list (much like the above, but could be via a well-known file like /etc/ubiquity/pages).
  3. Have some syntax for saying a page should be before this page, but after this page. Sort of like how upstart lets your order jobs, but way simpler. Could reference either standard pages or other plugin pages. If Ubiquity can't figure out how to order the plugin, it just won't show it. Additionally would need to allow a plugin to list pages it wants to hide.
  4. Use filesystem ordering, like have plugins use plugins.d/10-mypage and 22-otherpage. The standard pages would need to have standard numbers. Which has all sorts of difficulties if we ever tried to add, remove, or reorder a standard page. All plugins would need to change. Could use a separate directory like plugins.hide.d/mypage to hide pages.

The first two options above are best suited for OEM installs, where one entity is crafting the experience. But the latter two options are slightly better for Ubuntu itself where it's easier for derivatives and packagers to plug into the existing system on a dynamic 'am-I-installed' basis. Seeds would do the rest of the job. Even here though, there is tight control over the experience. The first two options could still work.

I think option 3 above gives us the most flexibility for the least cost. The syntax can be dreadfully simple: only allow one 'after' or 'before' statement, and it would use a defined 'name' for the specified page (reducing complexity for things like the partitioner that have 2 UI files, but one module. So, for example:

AFTER='language'

Pages can be hidden from a HIDE list (a non-list would also work):

HIDE=['language', 'timezone']

Plugins would have a NAME field that specifies a name to use. The standard pages would have similar values. The recommended NAME for pages would be the module name that defines the page.

Ties (where two pages specify 'after language' for example) can be broken by file system ordering in plugins.d (ala option 4 above). Thus, Ubiquity just has to read those in in order, and everything just works. The number before the filename can be considered a priority then for ties. i.e. if both 10-mypage and 22-otherpage specify AFTER=language, 22 would be first, then 10.

  • If neither AFTER or BEFORE are specified, the page will not be used, but may still specify other plugin options, like HIDE.
  • If AFTER or BEFORE is a list, the first component that Ubiquity recognizes is used.
  • If both AFTER and BEFORE are specified, Ubiquity will use AFTER if it recognizes it, else use BEFORE.
  • If Ubiquity still can't find a value that it recognizes, the page is ignored (and other plugin options like HIDE are not used -- it's likely this page is optional, pending installation of some package we don't have or was written for an older Ubiquity).

  • This allows

PageGtk Design

The PageGtk class must provide an init that takes at least one argument. Additional keyword arguments are allowed, but not currently used.

This first argument is a 'controller' class, specified below. This is how PageGtk can provide feedback to the 'real' frontend.

It must provide a method called get_ui(self) that returns a tuple of (string, gtk.glade.XML), where the string specifies the name of the top-level page widget in the glade XML.

Controller Design

The controller object passed to Page frontend classes is a simple mechanism for talking to the main frontend. Right now the only methods allowed are:

allow_go_forward(bool) allow_go_backward(bool)

This may or may not be the main frontend object (which already has these functions), depending on how paranoid we are when implementing it.

Open Questions

  • 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'?

Example

In /usr/lib/ubiquity/plugins.d/30-foo.py

import gtk
import os
from ubiquity import Plugin

# Plugin settings
NAME='foo'
BEFORE='usersetup'

class PageGtk:
    def __init__(self, controller):
        self.controller = controller
        self.gladexml = gtk.glade.XML('/usr/share/ubiquity-foo/foo.glade', 'foo')
    def get_ui(self):
        return ('foo', self.gladexml)

    # Custom foo controls
    def get_bar(self):
        button = self.gladexml.get_widget('bar')
        return button.get_active()
    def set_bar(self, on):
        button = self.gladexml.get_widget('bar')
        button.set_active(on)

class Page(Plugin):
    def prepare(self, unfiltered=False):
        # self.frontend is PageGtk above
        bar = self.db.get('foo/bar')
        self.frontend.set_bar(bar)
        return ([], ['foo/bar'])

    def ok_handler(self):
        bar = self.frontend.get_bar()
        self.preseed_bool('foo/bar', bar)
        Plugin.ok_handler(self)

    def apply(self):
        bar = self.db.get('foo/bar')
        if bar:
            os.system(['touch', '/etc/bar'])
        else:
            os.system(['rm', '/etc/bar'])

Ubiquity/Plugins (last edited 2013-01-16 10:57:22 by fourdollars)