Hi there
So here's a patch tested against r 1767 which adds a single onCharAdded event for plugins that implement onCharAdded().
This is experimental and is really for you to comment on, if it's ok by you I'll add the other events.
So for example my neko plugin looks like this ...
void onCharAdded(ScintillaObject *sci,char c) { printf("nice one %c\n",c); switch(c) { case '(': case '.': executeUtil("process"); break; } }
Cheers
bd.
On 08/01/2007 02:38:53 PM, blackdog wrote:
Hi there
So here's a patch tested against r 1767 which adds a single onCharAdded event for plugins that implement onCharAdded().
This is experimental and is really for you to comment on, if it's ok by you I'll add the other events.
Thanks, but IMO it could be done a bit differently. (I didn't have time to reply to your previous message about this, sorry).
I would prefer it to be done in a way that had less changes to the core - really I think the plugin API should be kept quite lean. Because I think you might want other callbacks besides onCharAdded, perhaps it would be best to have a single on_sci_notify() plugin callback (we don't really use CamelCase for function names, only typenames ;-)).
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn; plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Also, I'm assuming that this notification doesn't slow down Geany (I guess it shouldn't though). I'm also wondering about replacing plugin_list GList with a GPtrArray, which could speed up things if necessary.
Regards, Nick
Hi Nick
Houw about this called from editor.c as per your last email? Haven't compiled it. So all the other events get their own if statement in there or somesuch.
// callback func called by all editors when a signal arises void on_plugin_notification(GtkWidget *editor, gint scn,struct SCNotification *nt, gint idx) { GList *item;
ScintillaObject *sci = doc_list[idx].sci; int event = nt->nmhdr.code; for (item = plugin_list; item != NULL; item = g_list_next(item)) { Plugin *plugin = item->data; if (plugin->on_char_added && event == SCN_CHARADDED) { plugin->on_char_added(sci,ch); } } }
bd
On Wed, 01 Aug 2007 16:28:39 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 08/01/2007 02:38:53 PM, blackdog wrote:
Hi there
So here's a patch tested against r 1767 which adds a single onCharAdded event for plugins that implement onCharAdded().
This is experimental and is really for you to comment on, if it's ok by you I'll add the other events.
Thanks, but IMO it could be done a bit differently. (I didn't have time to reply to your previous message about this, sorry).
I would prefer it to be done in a way that had less changes to the core
- really I think the plugin API should be kept quite lean. Because I
think you might want other callbacks besides onCharAdded, perhaps it would be best to have a single on_sci_notify() plugin callback (we don't really use CamelCase for function names, only typenames ;-)).
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Also, I'm assuming that this notification doesn't slow down Geany (I guess it shouldn't though). I'm also wondering about replacing plugin_list GList with a GPtrArray, which could speed up things if necessary.
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On 08/01/2007 05:18:22 PM, blackdog wrote:
Hi Nick
Houw about this called from editor.c as per your last email? Haven't compiled it. So all the other events get their own if statement in there or somesuch.
No, I mean to save maintenance and a lot of possible symbols to lookup each time a plugin is loaded, just have one symbol, on_sci_notify(). It is passed the SCNotification argument whenever on_editor_notification() receives a notification in editor.c, so it can determine which messages it wants to respond to. This would save a lot of extra code in the plugin API.
---
// callback func called by all editors when a signal arises void on_plugin_notification(GtkWidget *editor, gint scn,struct SCNotification *nt, gint idx) { GList *item;
ScintillaObject *sci = doc_list[idx].sci; int event = nt->nmhdr.code; for (item = plugin_list; item != NULL; item = g_list_next(item)) { Plugin *plugin = item->data; if (plugin->on_char_added && event == SCN_CHARADDED) { plugin->on_char_added(sci,ch); } } }
bd
On Wed, 01 Aug 2007 16:28:39 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 08/01/2007 02:38:53 PM, blackdog wrote:
Hi there
So here's a patch tested against r 1767 which adds a single onCharAdded event for plugins that implement onCharAdded().
This is experimental and is really for you to comment on, if it's
ok
by you I'll add the other events.
Thanks, but IMO it could be done a bit differently. (I didn't have time to reply to your previous message about this, sorry).
I would prefer it to be done in a way that had less changes to the core
- really I think the plugin API should be kept quite lean. Because
I
think you might want other callbacks besides onCharAdded, perhaps
it
would be best to have a single on_sci_notify() plugin callback (we don't really use CamelCase for function names, only typenames ;-)).
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an
on_sci_notify
symbol.
Also, I'm assuming that this notification doesn't slow down Geany
(I
guess it shouldn't though). I'm also wondering about replacing plugin_list GList with a GPtrArray, which could speed up things if necessary.
Regards, Nick
Ah yes, I catch you now, in the plugin you mean, ok, i was one level up.
bd
On Wed, 01 Aug 2007 17:37:19 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 08/01/2007 05:18:22 PM, blackdog wrote:
Hi Nick
Houw about this called from editor.c as per your last email? Haven't compiled it. So all the other events get their own if statement in there or somesuch.
No, I mean to save maintenance and a lot of possible symbols to lookup each time a plugin is loaded, just have one symbol, on_sci_notify(). It is passed the SCNotification argument whenever on_editor_notification() receives a notification in editor.c, so it can determine which messages it wants to respond to. This would save a lot of extra code in the plugin API.
// callback func called by all editors when a signal arises void on_plugin_notification(GtkWidget *editor, gint scn,struct SCNotification *nt, gint idx) { GList *item;
ScintillaObject *sci = doc_list[idx].sci; int event = nt->nmhdr.code; for (item = plugin_list; item != NULL; item = g_list_next(item)) { Plugin *plugin = item->data; if (plugin->on_char_added && event == SCN_CHARADDED) { plugin->on_char_added(sci,ch); } } }
bd
On Wed, 01 Aug 2007 16:28:39 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 08/01/2007 02:38:53 PM, blackdog wrote:
Hi there
So here's a patch tested against r 1767 which adds a single onCharAdded event for plugins that implement onCharAdded().
This is experimental and is really for you to comment on, if it's
ok
by you I'll add the other events.
Thanks, but IMO it could be done a bit differently. (I didn't have time to reply to your previous message about this, sorry).
I would prefer it to be done in a way that had less changes to the core
- really I think the plugin API should be kept quite lean.
Because
I
think you might want other callbacks besides onCharAdded, perhaps
it
would be best to have a single on_sci_notify() plugin callback (we don't really use CamelCase for function names, only typenames ;-)).
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an
on_sci_notify
symbol.
Also, I'm assuming that this notification doesn't slow down Geany
(I
guess it shouldn't though). I'm also wondering about replacing plugin_list GList with a GPtrArray, which could speed up things if necessary.
Regards, Nick
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On Wed, 01 Aug 2007 16:28:39 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Why don't we just use the signal framework from Glib/GTK? My suggestion: Let's define a bunch of available signals like "plugin::sci-notify" "plugin::build-complete" "plugin::show-auto-complete-list" ... Then every plugin can connect to these signals using the g_signal_connect() family. Within the core of Geany, we emit the signal at the appropriate place (e.g. in the signal handler of sci-notify we emit plugin::sci-notify) and so the signal handler within the plugin is called. The only difficult thing probably will be to define the signals.
I came across this way of signal usage while writing a panel plugin for the Xfce panel. There are (at least) these signals for the plugins available: "configure-plugin" "free-data" "save"
configure-plugin is used to tell the plugin it should show its configuration dialog, save is when the plugin settings should be saved and free-data is fired when the panel is about to remove the plugin.
Another possibility could be to let the plugins set function pointers for several pre-defined actions to functions within the plugin. But this would be nothing else than a more simple way of defining signals and connecting handlers to them. So, I suggest we use the existing and working signals framework from GLib/GTK.
What do you think?
Regards, Enrico
I think that's good, I think it would remove the plugin loop that we're thinking of now, so only the plugins who want the event are checked.
Using gobject is probable more flexible in the long run.
Cheers
Ritchie
On Wed, 1 Aug 2007 19:17:37 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 01 Aug 2007 16:28:39 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Why don't we just use the signal framework from Glib/GTK? My suggestion: Let's define a bunch of available signals like "plugin::sci-notify" "plugin::build-complete" "plugin::show-auto-complete-list" ... Then every plugin can connect to these signals using the g_signal_connect() family. Within the core of Geany, we emit the signal at the appropriate place (e.g. in the signal handler of sci-notify we emit plugin::sci-notify) and so the signal handler within the plugin is called. The only difficult thing probably will be to define the signals.
I came across this way of signal usage while writing a panel plugin for the Xfce panel. There are (at least) these signals for the plugins available: "configure-plugin" "free-data" "save"
configure-plugin is used to tell the plugin it should show its configuration dialog, save is when the plugin settings should be saved and free-data is fired when the panel is about to remove the plugin.
Another possibility could be to let the plugins set function pointers for several pre-defined actions to functions within the plugin. But this would be nothing else than a more simple way of defining signals and connecting handlers to them. So, I suggest we use the existing and working signals framework from GLib/GTK.
What do you think?
Regards, Enrico
Hi Enrico
I found this tutorial for defining signals, so I think i'll give it a shot
http://gnomejournal.org/article/36/writing-a-widget-using-cairo-and-gtk28-pa...
bd
On Wed, 1 Aug 2007 19:17:37 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 01 Aug 2007 16:28:39 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Why don't we just use the signal framework from Glib/GTK? My suggestion: Let's define a bunch of available signals like "plugin::sci-notify" "plugin::build-complete" "plugin::show-auto-complete-list" ... Then every plugin can connect to these signals using the g_signal_connect() family. Within the core of Geany, we emit the signal at the appropriate place (e.g. in the signal handler of sci-notify we emit plugin::sci-notify) and so the signal handler within the plugin is called. The only difficult thing probably will be to define the signals.
I came across this way of signal usage while writing a panel plugin for the Xfce panel. There are (at least) these signals for the plugins available: "configure-plugin" "free-data" "save"
configure-plugin is used to tell the plugin it should show its configuration dialog, save is when the plugin settings should be saved and free-data is fired when the panel is about to remove the plugin.
Another possibility could be to let the plugins set function pointers for several pre-defined actions to functions within the plugin. But this would be nothing else than a more simple way of defining signals and connecting handlers to them. So, I suggest we use the existing and working signals framework from GLib/GTK.
What do you think?
Regards, Enrico
Ok, I'm going to leave that for the masters :) It took about 15 mins to decide I didn't know what new kind of GOBject to create to attach the signal to.
Where I have GTK_TYPE_WIDGET (to get it to compile) you need, I think, some kind of custom GObject.
enum { SCI_NOTIFY, LAST_SIGNAL };
static guint plugin_signals[LAST_SIGNAL] = { 0 };
plugin_signals[SCI_NOTIFY] = g_signal_new ( "sci_notify", G_TYPE_FROM_CLASS(gtk_type_class (GTK_TYPE_WIDGET)), G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__INT, G_TYPE_NONE, 1, G_TYPE_INT);
Cheers
bd
On Wed, 1 Aug 2007 15:13:53 -0400 blackdog blackdog@ipowerhouse.com wrote:
Hi Enrico
I found this tutorial for defining signals, so I think i'll give it a shot
http://gnomejournal.org/article/36/writing-a-widget-using-cairo-and-gtk28-pa...
bd
On Wed, 1 Aug 2007 19:17:37 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 01 Aug 2007 16:28:39 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Why don't we just use the signal framework from Glib/GTK? My suggestion: Let's define a bunch of available signals like "plugin::sci-notify" "plugin::build-complete" "plugin::show-auto-complete-list" ... Then every plugin can connect to these signals using the g_signal_connect() family. Within the core of Geany, we emit the signal at the appropriate place (e.g. in the signal handler of sci-notify we emit plugin::sci-notify) and so the signal handler within the plugin is called. The only difficult thing probably will be to define the signals.
I came across this way of signal usage while writing a panel plugin for the Xfce panel. There are (at least) these signals for the plugins available: "configure-plugin" "free-data" "save"
configure-plugin is used to tell the plugin it should show its configuration dialog, save is when the plugin settings should be saved and free-data is fired when the panel is about to remove the plugin.
Another possibility could be to let the plugins set function pointers for several pre-defined actions to functions within the plugin. But this would be nothing else than a more simple way of defining signals and connecting handlers to them. So, I suggest we use the existing and working signals framework from GLib/GTK.
What do you think?
Regards, Enrico
Hi there
I've attached a patch for the last implementation that Nick suggested. This is just in case the signals idea doesn't pan out, or it's not implemented due to time issues etc. If we know that a plugin implements on_sci_notify the geany implementation can be changed later without affecting anything else - so maybe this patch can suffice in the meantime? The one issue in the patch is I'm calling on_plugin_notification from on_editor_notification, maybe it should be a proper callback from g_signal_connect, just like on_editor_notification?
Also, I added a sci_show_autocomplete in this patch too, as it's needed for my plugin.
Cheers.
bd
On Wed, 1 Aug 2007 19:17:37 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 01 Aug 2007 16:28:39 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
Then something like:
// callback func called by all editors when a signal arises void on_editor_notification(GtkWidget *editor, gint scn, gpointer lscn, gpointer user_data) { SCNotification *nt; ScintillaObject *sci; gint idx;
idx = GPOINTER_TO_INT(user_data); sci = doc_list[idx].sci;
nt = lscn;
plugins_sci_notify(editor, scn, nt, idx);
Where plugins_sci_notify() calls any plugin that has an on_sci_notify symbol.
Why don't we just use the signal framework from Glib/GTK? My suggestion: Let's define a bunch of available signals like "plugin::sci-notify" "plugin::build-complete" "plugin::show-auto-complete-list" ... Then every plugin can connect to these signals using the g_signal_connect() family. Within the core of Geany, we emit the signal at the appropriate place (e.g. in the signal handler of sci-notify we emit plugin::sci-notify) and so the signal handler within the plugin is called. The only difficult thing probably will be to define the signals.
I came across this way of signal usage while writing a panel plugin for the Xfce panel. There are (at least) these signals for the plugins available: "configure-plugin" "free-data" "save"
configure-plugin is used to tell the plugin it should show its configuration dialog, save is when the plugin settings should be saved and free-data is fired when the panel is about to remove the plugin.
Another possibility could be to let the plugins set function pointers for several pre-defined actions to functions within the plugin. But this would be nothing else than a more simple way of defining signals and connecting handlers to them. So, I suggest we use the existing and working signals framework from GLib/GTK.
What do you think?
Regards, Enrico
On 08/02/2007 02:25:46 PM, blackdog wrote:
Hi there
I've attached a patch for the last implementation that Nick suggested. This is just in case the signals idea doesn't pan out, or it's not implemented due to time issues etc. If we know that a plugin implements on_sci_notify the geany implementation can be changed later without affecting anything else - so maybe this patch can suffice in the meantime?
Thanks for the patch, I'm not sure about applying it yet but I'll sort something out in the next few days. I think a clean signals implementation would mean that Geany wouldn't lookup on_sci_notify() itself.
The one issue in the patch is I'm calling on_plugin_notification from on_editor_notification, maybe it should be a proper callback from g_signal_connect, just like on_editor_notification?
To me it seems better to do it like that (maybe more efficient).
Also, I added a sci_show_autocomplete in this patch too, as it's needed for my plugin.
I think that because most filetypes don't need special autocompletion I don't think it should be in the plugin API, at least for now. Maybe if several plugins want it then it can be added. But I've added scintilla_send_message to the API, so you can copy the wrapper function or use it unwrapped.
Regards, Nick
Hi Nick
Thanks for checking it out.
The one issue in the patch is I'm calling on_plugin_notification from on_editor_notification, maybe it should be a proper callback from g_signal_connect, just like on_editor_notification?
To me it seems better to do it like that (maybe more efficient).
Something else to consider is whether the plugin get's to nullify further events down the line. I'm not sure if this is applicable or not but you do see sometimes, in other packages, a plugin event returning false to indicate no further action required.
Cheers bd
On Tue, 07 Aug 2007 12:41:09 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 08/02/2007 02:25:46 PM, blackdog wrote:
Hi there
I've attached a patch for the last implementation that Nick suggested. This is just in case the signals idea doesn't pan out, or it's not implemented due to time issues etc. If we know that a plugin implements on_sci_notify the geany implementation can be changed later without affecting anything else - so maybe this patch can suffice in the meantime?
Thanks for the patch, I'm not sure about applying it yet but I'll sort something out in the next few days. I think a clean signals implementation would mean that Geany wouldn't lookup on_sci_notify() itself.
The one issue in the patch is I'm calling on_plugin_notification from on_editor_notification, maybe it should be a proper callback from g_signal_connect, just like on_editor_notification?
To me it seems better to do it like that (maybe more efficient).
Also, I added a sci_show_autocomplete in this patch too, as it's needed for my plugin.
I think that because most filetypes don't need special autocompletion I don't think it should be in the plugin API, at least for now. Maybe if several plugins want it then it can be added. But I've added scintilla_send_message to the API, so you can copy the wrapper function or use it unwrapped.
Regards, Nick
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany