Branch: refs/heads/master
Author: Jiří Techet <techet(a)gmail.com>
Committer: Jiří Techet <techet(a)gmail.com>
Date: Wed, 23 Mar 2016 19:45:47 UTC
Commit: 1c83b18e22c20c29514ba85196022dbb8db74c52
https://github.com/geany/geany/commit/1c83b18e22c20c29514ba85196022dbb8db74…
Log Message:
-----------
osx: force resync menus when changing keybindings
Normally menu items are updated only when adding or removing
them on osx. They are however not redrawn when just changing
keybindings so the old keybinding is displayed after the change.
Force the menu update to show the updated keybindings.
Modified Paths:
--------------
src/prefs.c
Modified: src/prefs.c
5 lines changed, 5 insertions(+), 0 deletions(-)
===================================================================
@@ -56,6 +56,7 @@
#include "ui_utils.h"
#include "utils.h"
#include "vte.h"
+#include "osx.h"
#include "gtkcompat.h"
@@ -1197,6 +1198,10 @@ on_prefs_dialog_response(GtkDialog *dialog, gint response, gpointer user_data)
kb_update(&global_kb_data);
tools_create_insert_custom_command_menu_items();
keybindings_write_to_file();
+#ifdef MAC_INTEGRATION
+ /* Force re-syncing the menubar to update displayed keybindings. */
+ gtkosx_application_sync_menubar(gtkosx_application_get());
+#endif
}
/* Printing */
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).
Branch: refs/heads/master
Author: elextr <elextr(a)gmail.com>
Committer: elextr <elextr(a)gmail.com>
Date: Sun, 10 Apr 2016 23:21:17 UTC
Commit: f74fdd8d1ce0f1c18071d9d963fc45683f67c817
https://github.com/geany/geany/commit/f74fdd8d1ce0f1c18071d9d963fc45683f67c…
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).
Branch: refs/heads/master
Author: Philipp Wiesemann <philipp.wiesemann(a)arcor.de>
Committer: Philipp Wiesemann <philipp.wiesemann(a)arcor.de>
Date: Sun, 10 Apr 2016 19:05:50 UTC
Commit: ad81720d9880c380f38bfcb68bb0403a71430c35
https://github.com/geany/geany/commit/ad81720d9880c380f38bfcb68bb0403a71430…
Log Message:
-----------
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).