The application name. Filename extension and section header for PeasPluginInfo files are actually derived from this value. For instance, if app-name is "Gedit", then info files will have the .gedit-plugin extension, and the engine will look for a "Gedit Plugin" section in it to load the plugin data.

The base application directory for binding modules lookup. Each loader module will load its modules from a subdirectory of the base module directory. For instance, the python loader will look for python modules in "${base-module-dir}/python/".

The list of path where to look for plugins. A so-called "search path" actually consists on a couple of both a module directory (where the shared libraries or language modules lie) and a data directory (where the plugin data is). The PeasPlugin will be able to use a correct data dir depending on where it is installed, hence allowing to keep the plugin agnostic installed both in the system path or in the user's home directory, without taking other special care than using egg_plugin_get_data_dir() when looking for its data files. Concretely, this property contains a NULL-terminated array of strings, whose even-indexed strings are module directories, and odd-indexed ones are the associated data directories. Here is an example of such an array: |[ gchar const * const search_paths[] = { // Plugins in ~/.config g_build_filename (g_get_user_config_dir (), "example/plugins", NULL), g_build_filename (g_get_user_config_dir (), "example/plugins", NULL), // System plugins EXAMPLE_PREFIX "/lib/example/plugins/", EXAMPLE_PREFIX "/share/example/plugins/", NULL }; ]|