Multiple Modules, Multiple Function, Multifunctions

Often one wants to implement a group of closely related functions that could share quite a bit of code. There are several posibilities how to do it.

The naive approach would be to put the code of all the modules to a one file and share what is shareable. But alas! there can be only one GWY_MODULE_QUERY per file, thus a one file can register only a one module and this approach would not work.

The prefered solution is to register more than function for the module. This is as simple as it sounds. One just has to call gwy_process_func_register() (or other feature registration method) several times with different functions. It is even possible to register functions of different kind in a one module, but usually there is no reason to do this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

static gboolean
module_register(void)
{
    gwy_process_func_register("sobel_horizontal",
                              (GwyProcessFunc)&gradient_sobel_horizontal,
                              N_("/_Presentation/_Gradient/_Sobel (horizontal)"),
                              NULL,
                              GRADIENT_RUN_MODES,
                              GWY_MENU_FLAG_DATA,
                              N_("Horizontal Sobel gradient presentation"));
    gwy_process_func_register("sobel_vertical",
                              (GwyProcessFunc)&gradient_sobel_vertical,
                              N_("/_Presentation/_Gradient/_Sobel (vertical)"),
                              NULL,
                              GRADIENT_RUN_MODES,
                              GWY_MENU_FLAG_DATA,
                              N_("Vertical Sobel gradient presentation"));

    return TRUE;
}

The other posibility is to call gwy_process_func_register() several times with the same func argument. The function can then determine from its last argument (name) what function the caller thinks it is calling. This approach can be used when the differences between the functions are very small. Incidentally, this is also exactly how the plugin-proxy module works.

Settings

The nice thing about Gwyddion module dialog boxes is that they show the same parameter values as when you last opened them, and they remember the settings even across sessions. And you of course want this feature in your modules too.

Saving and restoring settings usually has sense only for modules with a GUI, simple noninteractive modules like value inversion have no settings to remember. We will get to GUI later.

There is a one GwyContainer in Gwyddion containing settings for all modules (and other creatures). The function gwy_app_settings_get() will bring it to you. It is loaded on startup and saved on exit and you don not need to take care about this. So the only thing you have to care about is to read the settings from it when your module starts and store them there on exit. OK, there are in fact two things you have to care about. There are no limitations on who can access what in the settings, so to avoid surprises you should use only keys startings with "/module/my-module-name/".

Loading settings could look (remember they may not always exist, for instance when the function is run the first time):

1
2
3
4
5
6
7
8

GwyContainer *settings;

settings = gwy_app_settings_get();
ratio = 1.61803;
gwy_container_gis_double_by_name(settings,
                                 "/module/my_module/ratio",
                                 &ratio);
ratio = CLAMP(ratio, 1.0, 2.0);

Function gwy_container_gis_double_by_name() function updates its last argument only when there is a corresponding value in the container. The use of CLAMP() is a recommended defensive measure against corrupted settings (for example manually (mis)edited by the user) that could cause troubles later.

Saving settings is equally easy:

1
2
3
4
5
6

GwyContainer *settings;

settings = gwy_app_settings_get();
gwy_container_set_double_by_name(settings,
                                 "/module/my_module/ratio",
                                 ratio);

Modules customarily define a function load_settings() that fills its internal parameter representation on the start of execution and santitizes them. Likewise function save_settings() stores them to back to the global settings upon exit. Note to achieve the typical state preservation of Gwyddion modules parameters have to be saved both after successful execution and cancellation.

Creating New Files, Data Fields and Graphs

Not always one wants to modify the original data instead one prefers to create a new window for the result, or the output is perhaps of diffrent kind than the source: a graph is created from two-dimensional data.

Modules usually do not create new files, if they create new objects, they put them to the same container as the source data. A notable exception are file modules, they however just return the newly created container. New data containers, if one wishes to create them, are put under the control of the data browser with gwy_app_data_browser_add(). If they contain no visible data, they would be inaccessible by the user and present a memory leak. Therefore some data must be added and made visible later (or beforehand).

1
2
3
4
5
6
7

GwyContainer *container;

container = gwy_container_new();
/* Fill data with something meaningful */
...
gwy_app_data_browser_add(container);
g_object_unref(container);

New data fields can be created from scratch with gwy_data_field_new(), in most cases the new data field is strongly related to an existing one and then gwy_data_field_new_alike() or gwy_data_field_duplicate() come handy. The former copies all properties except the data itself, the latter duplicates a data field completely.

When we created the new object and we have to add it to the current file. We could just use one of GwyContainer functions

1
2

gwy_container_set_object_by_name(container, "/12345/data", data_field);
g_object_unref(data_field);

The data browser would notice it and add the data field, but this method is generally very inconvenient – for start, how we came to "/12345/data"?. Therefore we use the high-level interface and obtain the new channel number for free:

1
2
3

new_id = gwy_app_data_browser_add_data_field(container, data_field);
g_object_unref(data_field);
gwy_app_set_data_field_title(container, new_id, _("Bogosity"));

Often the new data field should inherit more properties from the original one than just the dimensions, e.g., the color gradient. This can be easily achieved with gwy_app_sync_data_items()

1
2
3
4
5
6

gwy_app_sync_data_items(container, container,
                        old_id, new_id,
                        FALSE,
                        GWY_DATA_ITEM_GRADIENT,
                        GWY_DATA_ITEM_MASK_COLOR,
                        0);

The id number of the source data field (old_id) was obtained with gwy_app_data_browser_get_current() (normally together with the data field itself, its key and/or other current objects)

1

gwy_app_data_browser_get_current(GWY_APP_DATA_FIELD_ID, &old_id, 0);

Creation and addition of graphs is very similar. We create a new graph model with gwy_graph_model_new() or a similar function, create individual curves with gwy_graph_curve_model_new() and fill the curves with data. Then we add it to the data browser

1
2

new_id = gwy_app_data_browser_add_graph_model(container, graph_model);
g_object_unref(graph_model);

Graphical User Interface (GUI)

You are encouraged to use the Gtk+ graphical toolkit for your module GUI. It has following advantages:

There is an extensive Gtk+ Tutorial and API Reference available on the Gtk+ Web site. You can use existing modules as templates for your module.

A very simple graphical user interface asking for a one value (unimaginatively called Amount) can be implemented in Gtk+ as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

static gboolean
slope_dialog(gdouble *amount)
{
    GtkWidget *dialog, *table, *spin;
    GtkObject *adjust;
    gint response;

    /* Create the dialog */
    dialog = gtk_dialog_new_with_buttons(_("Frobnicate"), NULL, 0,
                                         GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
                                         GTK_STOCK_OK, GTK_RESPONSE_OK,
                                         NULL);
    gtk_dialog_set_has_separator(GTK_DIALOG(dialog), FALSE);
    gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_OK);

    /* Create the parameter controls */
    table = gtk_table_new(1, 3, FALSE);
    gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), table,
                       FALSE, FALSE, 4);

    adjust = gtk_adjustment_new(*amount, 0, 100, 1, 10, 0);
    spin = gwy_table_attach_hscale(table, 0, _("Amount:"), "percent",
                                   adjust, 0);

    /* Run the dialog and respond to user actions */
    gtk_widget_show_all(dialog);
    response = gtk_dialog_run(GTK_DIALOG(dialog));
    switch (response) {
        case GTK_RESPONSE_CANCEL:
        case GTK_RESPONSE_DELETE_EVENT:
        gtk_widget_destroy(dialog);
        case GTK_RESPONSE_NONE:
        break;

        case GTK_RESPONSE_OK:
        *amount = gtk_adjustment_get_value(GTK_ADJUSTMENT(adjust));
        gtk_widget_destroy(dialog);
        break;
    }

    return response == GTK_RESPONSE_OK;
}

There is no rocket science in here: the dialog is created with some standard buttons and settings. Then a table with a value entry with a description is placed there and the range of allowed values is specified. Then the dialog is run and depending on user's action the value of amount is possibly updated, and TRUE or FALSE is returned to the caller to indicate user's action (we take everything as cancellation, except pressing OK).