Branch: refs/heads/master Author: elextr elextr@gmail.com Committer: elextr elextr@gmail.com Date: Sun, 10 Apr 2016 23:21:17 UTC Commit: f74fdd8d1ce0f1c18071d9d963fc45683f67c817 https://github.com/geany/geany/commit/f74fdd8d1ce0f1c18071d9d963fc45683f67c8...

Log Message: ----------- Merge pull request #991 from philippwiesemann/fix-plugin-doc-typos

Fix typos in plugin documentation

Modified Paths: -------------- doc/plugins.dox doc/pluginsignals.c doc/pluginsymbols.c

Modified: doc/plugins.dox 22 lines changed, 11 insertions(+), 11 deletions(-) =================================================================== @@ -95,10 +95,10 @@ All information about this project you can find at http://plugins.geany.org/ To add a new plugin to this project, get in touch with the people on the geany-devel-mailing list and create a fork of the geany-plugins project at https://github.com/geany/geany-plugins. -Beside of adding a new plugin, geany-devel-mailing list is also the place where +Beside of adding a new plugin, geany-devel-mailing list is also the place to discuss development related questions. However, once you have done your fork of geany-plugins you can develop -your plugin until you think its the right time to publish it. At this point, +your plugin until you think it is the right time to publish it. At this point, create a pull request for adding your patch set into the master branch of the main geany-plugins repository.

@@ -170,7 +170,7 @@ distributions, the package names and commands to use may differ. Basically, you are done at this point and could continue with writing the plugin code.

[1] For Windows, it is basically the same but you might have some more work on setting up -the general build environment(compiler, GTK development files, ...). This is described on +the general build environment (compiler, GTK development files, ...). This is described on Geany's website at http://www.geany.org/Support/BuildingOnWin32.

@section helloworld "Hello World" @@ -207,7 +207,7 @@ that helps supporting GTK+2 and GTK+3 in the same source.

Now you can go on and write your first lines for your new plugin. As mentioned before, you will need to implement a couple of functions. The first mandatory one is @a geany_load_module(). Geany -uses the presence fo this function to identify a library as a plugin. When Geany scans the +uses the presence of this function to identify a library as a plugin. When Geany scans the pre-defined and user-configured plugin directories, it will take a look at each shared library (or DLL on Windows) to see if it exports a @a geany_load_module() symbol. Files lacking these will be ignored. The second mandatory one is an initialization function that is only called when the plugin @@ -577,7 +577,7 @@ static gboolean hello_init(GeanyPlugin *plugin, gpointer pdata) This page briefly describes the deprecated, legacy plugin entry points. These have been in place prior to Geany 1.26 and are still loadable and working for the time being. However, do not create new plugins against these. For this reason, the actual description here is rather minimalistic and -concentrates on porting legacy plugins to the new interface. Basically it's main purpose +concentrates on porting legacy plugins to the new interface. Basically its main purpose is to give newcomers an idea of what they are looking at if they come across a legacy plugin.

@section overview Overview @@ -595,10 +595,10 @@ plugin_configure_single(GtkWidget *) are optional, however Geany prints a warnin plugin_cleanup() is missing and only one of plugin_configure(GtkDialog *) and plugin_configure_single(GtkWidget *) is used for any single plugin.

-By convention, plugin_version_check() is implicitely defined through the use of PLUGIN_VERSION_CHECK(), +By convention, plugin_version_check() is implicitly defined through the use of PLUGIN_VERSION_CHECK(), and similarly plugin_info is defined through PLUGIN_SET_INFO() or PLUGIN_SET_TRANSLATABLE_INFO().

-The functions should generally perform the same tasks as their eqivalents in GeanyPlugin::funcs. +The functions should generally perform the same tasks as their equivalents in GeanyPlugin::funcs.

Geany also recognized numerous variable fields if the plugin exported them globally, and actually set a few of them inside the plugins data section. @@ -759,7 +759,7 @@ sub-plugin plugins in an abstract manner: - Unloading simply reverses the effect of loading.

For providing these methods, GeanyPlugin has a field GeanyProxyFuncs which contains three function -pointers which must be initialized proir to calling geany_plugin_register_proxy(). This should be +pointers which must be initialized prior to calling geany_plugin_register_proxy(). This should be done in the GeanyPluginFuncs::init function of the proxy plugin.

- In the call to geany_plugin_register_proxy() the proxy plugin passes a list of file extensions. @@ -769,7 +769,7 @@ done in the GeanyPluginFuncs::init function of the proxy plugin. provided file extensions) is actually a plugin. This may depend on the plugin file itself in case of ambiguity or availability of runtime dependencies or even configuration. @ref PROXY_IGNORED or @ref PROXY_MATCHED should be returned, possibly in combination - with the @ref PROXY_NOLOAD flag. Not implementing GeanyProxyFuncs::probe at all is eqivalent to + with the @ref PROXY_NOLOAD flag. Not implementing GeanyProxyFuncs::probe at all is equivalent to always returning @ref PROXY_MATCHED. - GeanyProxyFuncs::load must be implemented to actually load the plugin. It is called by Geany when the user enables the sub-plugin. What "loading" means is entirely up to the proxy plugin and @@ -843,7 +843,7 @@ syntactic problems or other errors. There are two basic classes:

1) Runtime errors that can be determined at load time. For example, the shebang of a script -indicates a specific interpeter version but that version is not installed on the system. Your proxy +indicates a specific interpreter version but that version is not installed on the system. Your proxy should respond the same way as for version-incompatible plugins: don't register the plugin at all, but leave a message the user suggesting what has to be installed in order to work. Handle syntax errors in the scripts of sub-plugins the same way if possible. @@ -973,7 +973,7 @@ static gint demoproxy_probe(GeanyPlugin *proxy, const gchar *filename, gpointer

GeanyProxyFuncs::load is a bit more complex. It reads the file, fills the sub-plugin's PluginInfo fields and calls GEANY_PLUGIN_REGISTER_FULL(). Additionally, it creates a per-plugin context that -holds GKeyFile instance (a poor man's interpeter context). You can also see that it does not call +holds GKeyFile instance (a poor man's interpreter context). You can also see that it does not call GEANY_PLUGIN_REGISTER_FULL() if g_key_file_load_from_file() found an error (probably a syntax problem) which means the sub-plugin cannot be enabled.

Modified: doc/pluginsignals.c 8 lines changed, 4 insertions(+), 4 deletions(-) =================================================================== @@ -135,18 +135,18 @@ signal void (*document_close)(GObject *obj, GeanyDocument *doc, gpointer user_da /** Sent after a project is opened but before session files are loaded. * * @param obj a GeanyObject instance, should be ignored. - * @param config an exising GKeyFile object which can be used to read and write data. + * @param config an existing GKeyFile object which can be used to read and write data. * It must not be closed or freed. * @param user_data user data. */ signal void (*project_open)(GObject *obj, GKeyFile *config, gpointer user_data);

-/** Sent when a project is saved(happens when the project is created, the properties +/** Sent when a project is saved (happens when the project is created, the properties * dialog is closed or Geany is exited). This signal is emitted shortly before Geany * will write the contents of the GKeyFile to the disc. * * @param obj a GeanyObject instance, should be ignored. - * @param config an exising GKeyFile object which can be used to read and write data. + * @param config an existing GKeyFile object which can be used to read and write data. * It must not be closed or freed. * @param user_data user data. */ @@ -242,7 +242,7 @@ signal void (*update_editor_menu)(GObject *obj, const gchar *word, gint pos, Gea * The signal can be sent after Geany's default handler has been run when you set * PluginCallback::after field to TRUE. * - * An example callback implemention of this signal can be found in the Demo plugin. + * An example callback implementation of this signal can be found in the Demo plugin. * * @warning This signal has much power and should be used carefully. You should especially * care about the return value; make sure to return TRUE only if it is necessary

Modified: doc/pluginsymbols.c 2 lines changed, 1 insertions(+), 1 deletions(-) =================================================================== @@ -111,7 +111,7 @@ void plugin_init(GeanyData *data); void plugin_cleanup();

/** Called whenever the plugin should show its documentation (if any). This may open a dialog, - * a browser with a website or a local installed HTML help file(see utils_open_browser()) + * a browser with a website or a local installed HTML help file (see utils_open_browser()) * or something else. * Can be omitted when not needed. */ void plugin_help();

-------------- This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).