Similar to "save-settings", but for projects. Highly recommended for Scope. Can be used to create non-dialog project settings, which is currently impossible.
Discussion
Anonymous
-
2012-12-09
You forgot Doxygen comments for the new signal in pluginsignals.c, which is the whole point of that file. Otherwise, it looks fine to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-08-31
What about the changes in the attached 0001-Always-emit-project-save-when-writing-project-file.patch instead of a new signal?
Maybe I misunderstood the reason for not emitting project-save when the project was closing but I don't see any obvious harm in emitting two separate signals, since they have different purposes. This seems to be the commit that added the special case:
Looking at scope.c it should just be a matter of s/project-before-save/project-save/ in the scope_callbacks array IIUC. Would it also be useful to add the private/internal "save-settings" signal that Scope uses to the plugin API?
What about the changes in the attached 0001-Always-emit-project-save-when-writing-project-file.patch instead of a new signal?
Maybe I misunderstood the reason for not emitting project-save when the project was closing but I don't see any obvious harm in emitting two separate signals, since they have different purposes.
I thought project-save is emited only on OK so that the plugins (geany
modules?) can remove any extra pages they have added to the project
dialog... though there is "project-dialog-close" for that. Don't know,
really, it's unsuitable for Scope anyway - see below.
Looking at scope.c it should just be a matter of s/project-before-save/project-save/ in the scope_callbacks array IIUC.
Scope locks any source files while debugging. When the global settings
and session are being saved, it temporarily unlocks them (if locked by
scope, of course) on "save-settings" - that is, before save - so they
aren't saved in the session as "Read only", and schedules a re-lock on
idle (which may never happen if quitting Geany).
And that's why the project settings and session save signal used by
Scope must be before the actual save takes place. Attaching after the
session is saved will do nothing.
Would it also be useful to add the private/internal "save-settings"
signal that Scope uses to the plugin API?
Add to the documentation perhaps? The signal is fully accessible, I'm
using it since Geany 0.19 in the extra selection plugin.
--
E-gards: Jimmy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-09-01
I replied by email but it seems not show up so I'm just pasting from my Sent folder:
On 13-09-01 12:03 PM, Dimitar Zhekov wrote:
On Sat, 31 Aug 2013 22:14:13 +0000
"Matthew Brush" address@hidden wrote:
What about the changes in the attached 0001-Always-emit-project-save-when-writing-project-file.patch instead of a new signal?
Maybe I misunderstood the reason for not emitting project-save when the project was closing but I don't see any obvious harm in emitting two separate signals, since they have different purposes.
I thought project-save is emited only on OK so that the plugins (geany
modules?) can remove any extra pages they have added to the project
dialog... though there is "project-dialog-close" for that. Don't know,
really, it's unsuitable for Scope anyway - see below.
It's emitted from the function that Geany uses to write the project config to disk (project.c:write_config). So it's emitted when a new project is created after the new project dialog is accepted and when the project properties dialog accepted, but for whatever reason there's currently a special case that prevents it being called when a project is closed and it saves the settings.
Looking at scope.c it should just be a matter of s/project-before-save/project-save/ in the scope_callbacks array IIUC.
Scope locks any source files while debugging. When the global settings
and session are being saved, it temporarily unlocks them (if locked by
scope, of course) on "save-settings" - that is, before save - so they
aren't saved in the session as "Read only", and schedules a re-lock on
idle (which may never happen if quitting Geany).
And that's why the project settings and session save signal used by
Scope must be before the actual save takes place. Attaching after the
session is saved will do nothing.
If the g_signal_emit_by_name(geany_object, "project-save", config) call was moved up a few lines, it would fire before the session files are saved to the keyfile. Might not be good to change it though in case other plugins are expecting the session files to be in the keyfile before they use it.
Out of curiosity, why does Scope require the documents to be read-only during debugging?
Would it also be useful to add the private/internal "save-settings"
signal that Scope uses to the plugin API?
Add to the documentation perhaps? The signal is fully accessible, I'm
using it since Geany 0.19 in the extra selection plugin.
I think you can also access any of Geany's non-static global variables and non-static functions even if not documented, but it doesn't mean you should It seems like a useful signal, IMO, it should be added to the plugin API (ie. docs).
Last edit: Anonymous 2013-09-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe I misunderstood the reason for not emitting project-save when the project was closing but I don't see any obvious harm in emitting two separate signals, since they have different purposes.
I thought project-save is emited only on OK so that the plugins (geany
modules?) can remove any extra pages they have added to the project
dialog... though there is "project-dialog-close" for that. [...]
It's emitted from the function that Geany uses to write the project
config to disk (plugins.c:write_config). So it's emitted when a new
project is created after the new project dialog is accepted and when the
project properties dialog accepted, but for whatever reason there's
currently a special case that prevents it being called when a project is
closed and it saves the settings.
From another angle, it's emitted if, and only if, the project dialog
OK button is pressed. May have been for the plugins which add extra
project dialog pages to know when to fetch the dialog data and write
it into project config, but there is "project-dialog-confirmed"...
Looking at scope.c it should just be a matter of s/project-before-save/project-save/ in the scope_callbacks array IIUC.
Scope locks any source files while debugging. When the global settings
and session are being saved, it temporarily unlocks them (if locked by
scope, of course) on "save-settings" - that is, before save - so they
aren't saved in the session as "Read only" [...]
If the g_signal_emit_by_name(geany_object, "project-save", config)
call was moved up a few lines, it would fire before the session files
are saved to the keyfile. Might not be good to change it though in case
other plugins are expecting the session files to be in the keyfile
before they use it.
From a quick check, gproject uses the signal to detect when a new
project is created, and I don't see a replacement...
Out of curiosity, why does Scope require the documents to be read-only
during debugging?
Locking them is a common practice, because if you start editing while
debugging, your execution point(s), breakpoints and source code
may become inadequate. Scope does not require it, and will let you
unlock any file with Document -> Read Only, if you want to.
Would it also be useful to add the private/internal "save-settings"
signal that Scope uses to the plugin API?
Add to the documentation perhaps? The signal is fully accessible, I'm
using it since Geany 0.19 in the extra selection plugin.
I think you can also access any of Geany's non-static global variables
and non-static functions even if not documented, but it doesn't mean you
should :)
That depends on whether the functions are compiled as exportable, and
accessing the global variables is asking for trouble. The GLib signals,
OTOH, will work from a purely technical standpoint...
It seems like a useful signal, IMO, it should be added to the
plugin API (ie. docs).
...but it'll be better to make "save-settings" official, and I can't
imagine any problems or disadvantages.
--
E-gards: Jimmy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You forgot Doxygen comments for the new signal in pluginsignals.c, which is the whole point of that file. Otherwise, it looks fine to me.
Note to committer, needs to bump the API version when its committed.
0002: Added doxygen comment, increased API version to 217 and moved emission immediately after g_key_file_load_ (was before save_session_).
for 2012-12-17+
What about the changes in the attached
0001-Always-emit-project-save-when-writing-project-file.patchinstead of a new signal?Maybe I misunderstood the reason for not emitting
project-savewhen the project was closing but I don't see any obvious harm in emitting two separate signals, since they have different purposes. This seems to be the commit that added the special case:https://github.com/geany/geany/commit/748d55216874be532570d5fc5a19958cd12129f0
Looking at scope.c it should just be a matter of
s/project-before-save/project-save/in thescope_callbacksarray IIUC. Would it also be useful to add the private/internal "save-settings" signal that Scope uses to the plugin API?On Sat, 31 Aug 2013 22:14:13 +0000
"Matthew Brush" codebrainz@users.sf.net wrote:
I thought project-save is emited only on OK so that the plugins (geany
modules?) can remove any extra pages they have added to the project
dialog... though there is "project-dialog-close" for that. Don't know,
really, it's unsuitable for Scope anyway - see below.
Scope locks any source files while debugging. When the global settings
and session are being saved, it temporarily unlocks them (if locked by
scope, of course) on "save-settings" - that is, before save - so they
aren't saved in the session as "Read only", and schedules a re-lock on
idle (which may never happen if quitting Geany).
And that's why the project settings and session save signal used by
Scope must be before the actual save takes place. Attaching after the
session is saved will do nothing.
Add to the documentation perhaps? The signal is fully accessible, I'm
using it since Geany 0.19 in the extra selection plugin.
--
E-gards: Jimmy
I replied by email but it seems not show up so I'm just pasting from my Sent folder:
On 13-09-01 12:03 PM, Dimitar Zhekov wrote:
It's emitted from the function that Geany uses to write the project config to disk (project.c:write_config). So it's emitted when a new project is created after the new project dialog is accepted and when the project properties dialog accepted, but for whatever reason there's currently a special case that prevents it being called when a project is closed and it saves the settings.
If the
g_signal_emit_by_name(geany_object, "project-save", config)call was moved up a few lines, it would fire before the session files are saved to the keyfile. Might not be good to change it though in case other plugins are expecting the session files to be in the keyfile before they use it.Out of curiosity, why does Scope require the documents to be read-only during debugging?
I think you can also access any of Geany's non-static global variables and non-static functions even if not documented, but it doesn't mean you should It seems like a useful signal, IMO, it should be added to the plugin API (ie. docs).
Last edit: Anonymous 2013-09-01
On Sun, 01 Sep 2013 21:53:23 +0000
"Matthew Brush" codebrainz@users.sf.net wrote:
From another angle, it's emitted if, and only if, the project dialog
OK button is pressed. May have been for the plugins which add extra
project dialog pages to know when to fetch the dialog data and write
it into project config, but there is "project-dialog-confirmed"...
From a quick check, gproject uses the signal to detect when a new
project is created, and I don't see a replacement...
Locking them is a common practice, because if you start editing while
debugging, your execution point(s), breakpoints and source code
may become inadequate. Scope does not require it, and will let you
unlock any file with Document -> Read Only, if you want to.
That depends on whether the functions are compiled as exportable, and
accessing the global variables is asking for trouble. The GLib signals,
OTOH, will work from a purely technical standpoint...
...but it'll be better to make "save-settings" official, and I can't
imagine any problems or disadvantages.
--
E-gards: Jimmy
For Geany 2013-09-26+
For Geany 2015-02-22+