Galeon2 extensions plan

After some discussion with philip on irc we managed to agree on a
plugin-like plan. Not all the points I'm posting here are agreed
with him, but the general direction is.

DISTRIBUTION

- We will keep distributing a base galeon package following the user
interface lines I posted.
- It will be possible to have additional functionalities and preferences
in a different package. (galeon-powertweaks ?)
- The powertweaks package will contain one or more modules and some
data (xml, icons ...). It will contain also a manifest like file for
fine grain control of the additional functionalities.
- I think it would be good if the package would have a separate
mantainer.

ARCHITECTURE

A GaleonExtensionService object, accessible from galeon-shell, will
provide a way to merge the additional functionalities in the base
ui. It will also parse the manifest file. This will be compiled in
the base galeon package probably in utils/
The modules code and data will reside in a separate galeon/plugins/
direcotry.

1 Menus

galeon_extensions_service_merge_menus will be called in GaleonWindow.
An handle to the the plugin initialization will be retrieved through
gmodule.
Not sure how this should work exactly in practice.
Maybe the manifest contains an extension identifier and that is used
to determine the function name ?
Like [extension identifier]_init ?
The plugin code will look a lot like:
http://tko.ods.org/galeon-tools.diff

2 Preferences

The plugin will have to contain the glade file, the structures
defining the pref name/types and when necessary the code.
PrefsDialog could call
galeon_extensions_service_get_prefs_pages and get a list
of structures like:
char *category;
char *subcategory;
GtkWidget *page;

We need to make a decision about the category/sub category user
interface here. Philip would like to have something like galeon1,
with base galeon like a particular case (just one category).
I personally think putting more tabs inside the current categories
would be a better usability choice. But I leave this up to you
to decide.

3 Mime dialogs

I think it's better to separate the two implementations because:

- They are very different implementation. And the base one is dead
simple.
- It would be unacceptable to bloat galeon base with an unnecessary
mime database and dialog code
- There are some conflicts. 
I dont want predefined mime types in the base (I want to be asked to
save a tgz).
If someone install the plugin and use it, if he goes back to base for
some reason, he will get not editable predefined actions.
- When making changes to content handler philip would need to test
both with the plugin and without.
- The approach is so different that at some point even the two user
interfaces may conflict. (Hiding the two checkbuttons would not be
enough)

I think we should move the user interface out of the mozilla code like
we did for the downloader (and the sidebar). Both implementation would
have to implement an interface like:

run
get_action (open/save/save and open)
get_command
get_use_terminal
....

On the initialization galeon_embed_shell could call

galeon_extensions_service_get_(mime_handler ? I cant think to a sensible
name for the thing).
If an handler is found,
galeon_embed_shell_get_mime_handler will return it, otherwise it will
return the default one.

This is still very rough and I'm absolutely open to improvements. But I
think that in general this is a cleaner approach than having a way to
hide the check buttons. Less mantainance pains and no unnecessary bloat
in the base.

CONCLUSION

Can we get an agreement on this ? :)

Marco





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf