Re: Extensions manager ideas

[Justin Wake <jwake iinet net au>]

(oops, sorry, Adam, you'll get two copies of this, I clicked 'Reply' instead of 'Reply to All'..)

On Sun, 2004-09-05 at 23:24 -0400, Adam Hooper wrote:
> Before coding I'll post my planned code for the Epiphany extensions 
> manager (both UI and backend). If anybody has any comments about these 
> ideas, please let me know.
> 
> First of all, the UI: a dialog with a GtkTreeView and some text 
> underneath. The GtkTreeView will be a simple table, each row containing 
> two elements: a checkbox (loaded/unloaded) and the extension name. The 
> text underneath will show metadata about the selected extension in the 
> treeview -- description, author(s), relevant URLs, etc. This is somewhat 
> inspired by Gaim's "Plugins" config section, but of course there's 
> simply Less Useless Stuff.

I'll certainly agree that Gaim's UI could be a little better in this
regard, though I'm not too fond of Gaim's plugin UI.

Perhaps we could clone (well, not quite) the Add To Panel dialog from
gnome-panel, to have the name / summary appear as a bold header/plain
text sort of thing? It could be interesting to add icon support as well,
but I'm not sure that creating icons that neatly represent the
functionality of all the extensions would be a particularly easy job;
the Gestures extension would be fairly straightforward, for example, but
not necessarily so for the toolbar-extras extension.

You could even go so far as to include the version, author, and URL in
each cell, perhaps behind a little 'More Information' link below the
extension name, thus leaving the dialog as a whole empty except for the
list of extensions, the button row, and the 'Select extensions you want
loaded' descriptive text. 

Also, the 'OK' button should probably be replaced with 'Help' and
'Close' buttons.

> 
> I've attached a mockup.
> 
> Next... the backend.
> 
> Epiphany's extensions manager will scan a hard-coded set of directories 
> -- $PREFIX/lib/epiphany/extensions and $EPHY_DOT_DIR/extensions -- for 
> XML files which contain metadata about extensions. An example XML file:
> 
> -----
> error-viewer-extension.xml
> -----
> <?xml version="1.0" encoding="UTF-8"?>
> <extension-list>
>          <extension>
>                  <filename>errorviewer</filename>
>                  <name>Error Viewer</name>
>                  <description>Provides a dialog which displays web page 
> errors.</description>
>                  <version>1.1.3</version>
>                  <author>
>                          <name>Adam Hooper</name>
>                          <email>adamh densi com</email>
>                  </author>
>  
> <url>http://www.gnome.org/projects/epiphany/extensions</url>
>          </extension>
> </extension-list>
> -----
> 
> The extensions manager will parse all these XML files and store them in 
> an internal GList. Maybe at some point we can even monitor the 
> directories and update the internal GList as new extensions are added.
> 
> The extensions manager will also monitor a GConf value -- 
> /apps/epiphany/general/loaded_extensions (a List) -- to determine which 
> extensions to load. The list will be a list of the desired <filename> 
> values from the above XML file. The extensions which appear in that 
> GConf list will be loaded; the ones which don't won't. Extensions which 
> appear in GConf but have no matching XML file will be silently ignored.
> 
> To clarify: the extensions manager UI will *only* use these XML 
> definition files. The actual backend will *only* use the GConf value.
> 
> To load an extension with filename $filename, the extensions manager 
> will look for $EPHY_DOT_DIR/lib${filename}extension.so or 
> $PREFIX/lib/epiphany/extensions/lib${filename}extension.so. If a match 
> is found, that extension will be loaded (as it is in current Epiphany). 
> If not, a WARNING will be printed to the console.
> 
> For both the XML files and the .so's, $EPHY_DOT_DIR/extensions will take 
> precedence over $PREFIX/lib/epiphany/extensions.

This all seems quite fine to me. I might suggest that rescanning of the
extension directories probably only needs to happen upon opening the
Select Extensions dialog, since there are (currently) no other ways of
causing an extension to be loaded.

> So, the big questions: is there anything I'm forgetting? Any comments? 
> Is this system overkill? Any ideas on how to make this system better? etc.

Sounds quite reasonable to me. :)

-- 
Justin Wake