An important issue is that those are actions plugins, not action plugins. This means that one plugin may (and usually do) contain more than one action. For consistency they should be grouped by purpose (this may have exceptions : if plugins are really specific to an app, they could belong to a special plugin for this app).
Important: There are no ways for the user or the writer of a desc. file to know which functions are in your plug-ins so you must document your plug-in. This could be done in DocBook format so I can easily put it in this documentation.
Gaby needs to know what it should perform when an user choose "Mail to this guy" in the "Actions" menu. On the other side I already said that Gaby has no way to know the list of functions you export. So, how does it work ?
The user choose "Mail to";
Gaby know that this command is "mail" in a plug-in called "net" thanks to the desc file;
With this information, Gaby can load your plug-in but it doesn't know (yet) where to find "mail";
Gaby calls a function get_function_by_name which you have defined in your plug-in;
Now that Gaby has all the informations, it can call the right function and the user is happy ...
In the next sections, I'll write (a little) about get_function_by_name and (a lot) about the other functions.
void get_function_by_name(gchar* name, action* a);This is a simple question whose job is to map functions names to functions. Ususally it will be something like :
Example 13-1. get_function_by_name
void get_function_by_name (gchar *name, action *a)
{
a->function = NULL;
if ( strcmp(name, "mail") == 0 )
a->function = mail;
if ( strcmp(name, "phone") == 0 )
a->function = phone;
} |
Simple enough to skip comments ...