#21 "project-before-save" signal

open
nobody
None
5
2013-10-03
2012-12-08
Dimitar Zhekov
No

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

  • Matthew Brush
    Matthew Brush
    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.

     
  • Lex Trotman
    Lex Trotman
    2012-12-09

    Note to committer, needs to bump the API version when its committed.

     
  • Dimitar Zhekov
    Dimitar Zhekov
    2012-12-09

    0002: Added doxygen comment, increased API version to 217 and moved emission immediately after g_key_file_load_ (was before save_session_).

     
  • Matthew Brush
    Matthew Brush
    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:

    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 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?

     
  • Dimitar Zhekov
    Dimitar Zhekov
    2013-09-01

    On Sat, 31 Aug 2013 22:14:13 +0000
    "Matthew Brush" codebrainz@users.sf.net 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.

    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

     
  • Matthew Brush
    Matthew Brush
    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: Matthew Brush 2013-09-01
  • Dimitar Zhekov
    Dimitar Zhekov
    2013-09-02

    On Sun, 01 Sep 2013 21:53:23 +0000
    "Matthew Brush" codebrainz@users.sf.net wrote:

    On 13-09-01 12:03 PM, Dimitar Zhekov wrote:

    On Sat, 31 Aug 2013 22:14:13 +0000
    "Matthew Brush" codebrainz@users.sf.net wrote:

    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