Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
1. Open project properties dialog. 2. Close it. 3. Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
Cheers, Jiri
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
Ah yes, each time the properties are to be shown it creates a new dialog and adds a bunch of stuff at run-time and then destroys the whole dialog after. With the new GtkBuilder stuff, the dialog shouldn't be destroyed since it's the same one used for the whole run-time now.
I guess the dialog either needs to be hardcoded outside of the glade file so it can be created and destroyed at will or add code to add/remove stuff dynamically without destroying the whole thing after.
Cheers, Matthew Brush
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
Hi,
I haven't yet found a decent way to fix this without re-writing *a lot* of code around the projects dialog, so if anyone has any ideas on a "quick fix" or wants to fix up properly themselves, feel free :)
Cheers, Matthew Brush
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f...
If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great.
Cheers, Matthew Brush
On Mon, Jan 9, 2012 at 01:05, Matthew Brush mbrush@codebrainz.ca wrote:
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f...
If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great.
In general it seems to be fixed.
However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior.
Cheers,
Jiri
On 01/11/2012 04:11 PM, Jiří Techet wrote:
On Mon, Jan 9, 2012 at 01:05, Matthew Brushmbrush@codebrainz.ca wrote:
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f...
If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great.
In general it seems to be fixed.
However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior.
Yeah, I guess that couldn't hurt, although according to the docs, this is how the API version is supposed to be used[1]:
"The Application Programming Interface (API) version, incremented whenever any plugin data types are modified or appended to."
Which is why I never touched the API version, since it's quite clear when to increment it[2].
Cheers, Matthew Brush
[1] Although I personally dislike this in general since it does not give any indication when new functions are added or removed or like this case where behaviour is changed, nor does it give any correlation between API version and the currently running version of Geany. In other words, it seems basically useless, IMO.
[2] Despite the example in the same comment that shows it being used to guard a function, which can't actually be guarded since there's no way to know what API version to check for functions.
On Thu, Jan 12, 2012 at 1:25 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/11/2012 04:11 PM, Jiří Techet wrote:
On Mon, Jan 9, 2012 at 01:05, Matthew Brushmbrush@codebrainz.ca wrote:
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
I fixed this in:
https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f...
If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great.
In general it seems to be fixed.
However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior.
Yeah, I guess that couldn't hurt, although according to the docs, this is how the API version is supposed to be used[1]:
"The Application Programming Interface (API) version, incremented whenever any plugin data types are modified or appended to."
Which is why I never touched the API version, since it's quite clear when to increment it[2].
Cheers, Matthew Brush
[1] Although I personally dislike this in general since it does not give any indication when new functions are added or removed or like this case where behaviour is changed, nor does it give any correlation between API version and the currently running version of Geany. In other words, it seems basically useless, IMO.
[2] Despite the example in the same comment that shows it being used to guard a function, which can't actually be guarded since there's no way to know what API version to check for functions.
Hi Guys,
This should be an ABI and API change unfortunately, current functions do not work the way they did so old plugins (eg old GProjects) won't work.
API without ABI is for adding new stuff that does not prevent current plugins from working.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 01/11/2012 11:10 PM, Lex Trotman wrote:
On Thu, Jan 12, 2012 at 1:25 PM, Matthew Brushmbrush@codebrainz.ca wrote:
On 01/11/2012 04:11 PM, Jiří Techet wrote:
On Mon, Jan 9, 2012 at 01:05, Matthew Brushmbrush@codebrainz.ca wrote:
On 12/26/2011 01:37 PM, Jiří Techet wrote:
Hi,
I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce:
- Open project properties dialog.
- Close it.
- Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong.
I fixed this in:
https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f...
If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great.
In general it seems to be fixed.
However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior.
Yeah, I guess that couldn't hurt, although according to the docs, this is how the API version is supposed to be used[1]:
"The Application Programming Interface (API) version, incremented whenever any plugin data types are modified or appended to."
Which is why I never touched the API version, since it's quite clear when to increment it[2].
Cheers, Matthew Brush
[1] Although I personally dislike this in general since it does not give any indication when new functions are added or removed or like this case where behaviour is changed, nor does it give any correlation between API version and the currently running version of Geany. In other words, it seems basically useless, IMO.
[2] Despite the example in the same comment that shows it being used to guard a function, which can't actually be guarded since there's no way to know what API version to check for functions.
Hi Guys,
This should be an ABI and API change unfortunately, current functions do not work the way they did so old plugins (eg old GProjects) won't work.
API without ABI is for adding new stuff that does not prevent current plugins from working.
There was no change in documented functions, signals or behaviour AFAIK.
Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`?
In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite).
Since we're loading plugins into the Geany process with basically complete access to everything, then we should bump the API version on every commit, since we could potentially be changing undocumented internal behaviour that the plugins can have access to if they really want.
In any case, the docs, especially for `project_dialog_confirmed` should be improved/fixed.
Cheers, Matthew Brush
[...]
There was no change in documented functions, signals or behaviour AFAIK.
Ok, if the functionality used is not *documented* to be in the API then it is not protected, but, as the change in behaviour is going to require a change in the plugin interface an API bump will happen by default.
Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`?
If it was in the interface documentation, yes, else no.
In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite).
Not sure why it needs to depend on internal behaviour, but I havn't studied the details of what it does.
This may a side effect of the ad-hoc inclusion of features in the plugin interface, they are only added when asked for.
Since the project dialog may now be created (and only once) before the plugin is conected to the signal, the plugin interface will need to be changed to still allow current operation to continue since AFAICT the only documented way the plugin can get the notebook is the project create signal. I guess you and Jiri should work out the details of what is needed.
Since we're loading plugins into the Geany process with basically complete access to everything, then we should bump the API version on every commit, since we could potentially be changing undocumented internal behaviour that the plugins can have access to if they really want.
Because C is a crappy language we can't get the compiler to hide stuff it knows about from plugins. That is why the insistence is on only using *documented* API which we will protect by changing API/ABI. If something is visible due to the limitations of C, but not documented, no API/ABI bump is needed.
In any case, the docs, especially for `project_dialog_confirmed` should be improved/fixed.
Probably, but what?
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 01/12/2012 01:44 AM, Lex Trotman wrote:
[...]
There was no change in documented functions, signals or behaviour AFAIK.
Ok, if the functionality used is not *documented* to be in the API then it is not protected, but, as the change in behaviour is going to require a change in the plugin interface an API bump will happen by default.
No, it won't(didn't) require any changes to the API I don't think. It was never documented that you should rely on the Project dialog being destroyed and cleaning up your notebook page for you.
Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`?
If it was in the interface documentation, yes, else no.
In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite).
Not sure why it needs to depend on internal behaviour, but I havn't studied the details of what it does.
This may a side effect of the ad-hoc inclusion of features in the plugin interface, they are only added when asked for.
Since the project dialog may now be created (and only once) before the plugin is conected to the signal, the plugin interface will need to be changed to still allow current operation to continue since AFAICT the only documented way the plugin can get the notebook is the project create signal. I guess you and Jiri should work out the details of what is needed.
Nope, plugins can add their notebook page during the `project_dialog_create` signal and remove it during the `project_dialog_confirmed` signal, nothing changed here I don't think.
Since we're loading plugins into the Geany process with basically complete access to everything, then we should bump the API version on every commit, since we could potentially be changing undocumented internal behaviour that the plugins can have access to if they really want.
Because C is a crappy language we can't get the compiler to hide stuff it knows about from plugins. That is why the insistence is on only using *documented* API which we will protect by changing API/ABI. If something is visible due to the limitations of C, but not documented, no API/ABI bump is needed.
In any case, the docs, especially for `project_dialog_confirmed` should be improved/fixed.
Probably, but what?
Namely removing this from the `project_dialog_confirmed` docs:
"Warning: The dialog will still be running afterwards if the user chose 'Apply'. "
AFAIK there's no Apply button for project dialog and in fact it seems like the ideal place for plugins to remove their notebook page from (I'd need to test to be 100% sure).
Cheers, Matthew Brush
[...]
Nope, plugins can add their notebook page during the `project_dialog_create` signal and remove it during the `project_dialog_confirmed` signal, nothing changed here I don't think.
So the project_dialog_create actually means dialog open, in which case we probably should change the name? If it actually is create then it will only happen once now, won't it? And what happens if the project plugin isn't initialised at that time, it will never get the signal? So the plugin has no official way of getting the notebook to add the page to.
[...]
In any case, the docs, especially for `project_dialog_confirmed` should be improved/fixed.
Probably, but what?
Namely removing this from the `project_dialog_confirmed` docs:
"Warning: The dialog will still be running afterwards if the user chose 'Apply'. "
Ok, its 'ok' :) and IIUC it will still be "running" all the time?
AFAIK there's no Apply button for project dialog and in fact it seems like the ideal place for plugins to remove their notebook page from (I'd need to test to be 100% sure).
Would think so, just not sure when to create it as noted above.
Cheers Lex
On Thu, Jan 12, 2012 at 16:51, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/12/2012 01:44 AM, Lex Trotman wrote:
[...]
There was no change in documented functions, signals or behaviour AFAIK.
Ok, if the functionality used is not *documented* to be in the API then it is not protected, but, as the change in behaviour is going to require a change in the plugin interface an API bump will happen by default.
No, it won't(didn't) require any changes to the API I don't think. It was never documented that you should rely on the Project dialog being destroyed and cleaning up your notebook page for you.
Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`?
If it was in the interface documentation, yes, else no.
In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite).
Not sure why it needs to depend on internal behaviour, but I havn't studied the details of what it does.
This may a side effect of the ad-hoc inclusion of features in the plugin interface, they are only added when asked for.
Since the project dialog may now be created (and only once) before the plugin is conected to the signal, the plugin interface will need to be changed to still allow current operation to continue since AFAICT the only documented way the plugin can get the notebook is the project create signal. I guess you and Jiri should work out the details of what is needed.
Nope, plugins can add their notebook page during the `project_dialog_create` signal and remove it during the `project_dialog_confirmed` signal, nothing changed here I don't think.
Well, not quite - project_dialog_confirmed is only emitted when the dialog is confirmed but not in the case when it's cancelled in which case there's no indication for the plugin that the dialog was closed (and that the tab should be removed). Actually it was me who introduced the signal because there was nothing which would tell you if OK was pressed (and if I should re-read the values from the tab). As far as I know it is only me who adds his own tab to the dialog and I think nobody was thinking much about this possibility before.
OK so what's missing now is the signal when Cancel is pressed. Either we could introduce a new signal for it or change the existing signals which I would prefer because the existing names are confusing now:
* rename project-dialog-create to project-dialog-open * rename project-dialog-confirmed to project-dialog-closed and add a boolean parameter telling whether the dialog was confirmed or cancelled (but this could become a problem if Apply is added to the dialog in the future) * bump the API because it really changes now :-)
Cheers,
Jiri
On 01/12/2012 04:12 PM, Jiří Techet wrote:
On Thu, Jan 12, 2012 at 16:51, Matthew Brushmbrush@codebrainz.ca wrote:
On 01/12/2012 01:44 AM, Lex Trotman wrote:
[...]
There was no change in documented functions, signals or behaviour AFAIK.
Ok, if the functionality used is not *documented* to be in the API then it is not protected, but, as the change in behaviour is going to require a change in the plugin interface an API bump will happen by default.
No, it won't(didn't) require any changes to the API I don't think. It was never documented that you should rely on the Project dialog being destroyed and cleaning up your notebook page for you.
Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`?
If it was in the interface documentation, yes, else no.
In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite).
Not sure why it needs to depend on internal behaviour, but I havn't studied the details of what it does.
This may a side effect of the ad-hoc inclusion of features in the plugin interface, they are only added when asked for.
Since the project dialog may now be created (and only once) before the plugin is conected to the signal, the plugin interface will need to be changed to still allow current operation to continue since AFAICT the only documented way the plugin can get the notebook is the project create signal. I guess you and Jiri should work out the details of what is needed.
Nope, plugins can add their notebook page during the `project_dialog_create` signal and remove it during the `project_dialog_confirmed` signal, nothing changed here I don't think.
Well, not quite - project_dialog_confirmed is only emitted when the dialog is confirmed but not in the case when it's cancelled in which case there's no indication for the plugin that the dialog was closed (and that the tab should be removed). Actually it was me who introduced the signal because there was nothing which would tell you if OK was pressed (and if I should re-read the values from the tab). As far as I know it is only me who adds his own tab to the dialog and I think nobody was thinking much about this possibility before.
OK so what's missing now is the signal when Cancel is pressed. Either we could introduce a new signal for it or change the existing signals which I would prefer because the existing names are confusing now:
- rename project-dialog-create to project-dialog-open
- rename project-dialog-confirmed to project-dialog-closed and add a
boolean parameter telling whether the dialog was confirmed or cancelled (but this could become a problem if Apply is added to the dialog in the future)
- bump the API because it really changes now :-)
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
Cheers, Matthew Brush
[...]
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
But how much of the internal structure of the dialog are you going to document?
Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does).
Cheers Lex
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
But how much of the internal structure of the dialog are you going to document?
Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the "signals on the wrong object" thing like is done for most signals (with the renames Jiri proposed).
Cheers, Matthew Brush
On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
But how much of the internal structure of the dialog are you going to document?
Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the "signals on the wrong object" thing like is done for most signals (with the renames Jiri proposed).
Well I'd say the first or second, but Jiri or others may have a different preference.
Chers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, Jan 13, 2012 at 22:57, Lex Trotman elextr@gmail.com wrote:
On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
But how much of the internal structure of the dialog are you going to document?
Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the "signals on the wrong object" thing like is done for most signals (with the renames Jiri proposed).
Well I'd say the first or second, but Jiri or others may have a different preference.
I don't really care - both versions would work. But I too prefer using the existing GtkDialog signals instead of having custom signals for doing the same.
Jiri
On Sat, Jan 14, 2012 at 21:16, Jiří Techet techet@gmail.com wrote:
On Fri, Jan 13, 2012 at 22:57, Lex Trotman elextr@gmail.com wrote:
On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
But how much of the internal structure of the dialog are you going to document?
Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the "signals on the wrong object" thing like is done for most signals (with the renames Jiri proposed).
Well I'd say the first or second, but Jiri or others may have a different preference.
I don't really care - both versions would work. But I too prefer using
So finally I had some free time to test and listening on the dialog signals doesn't work as I need. The the code for displaying project dialog in Geany looks like this:
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK) { if (update_config(&e, FALSE)) {
Now when I connect to the dialog signals, they get emitted on the line
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
which means that in the signal handler I don't have access to the updated config values from the dialog because these are updated afterwards by
if (update_config(&e, FALSE))
So if there aren't any objections, I'll go back to the implementation I originally suggested and which emits the signal only after the config has been successfully updated.
Cheers, Jiri
On Sun, Feb 19, 2012 at 17:57, Jiří Techet techet@gmail.com wrote:
On Sat, Jan 14, 2012 at 21:16, Jiří Techet techet@gmail.com wrote:
On Fri, Jan 13, 2012 at 22:57, Lex Trotman elextr@gmail.com wrote:
On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the "response", "hide" and "show" signals on it as a normal GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this.
But how much of the internal structure of the dialog are you going to document?
Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the "signals on the wrong object" thing like is done for most signals (with the renames Jiri proposed).
Well I'd say the first or second, but Jiri or others may have a different preference.
I don't really care - both versions would work. But I too prefer using
So finally I had some free time to test and listening on the dialog signals doesn't work as I need. The the code for displaying project dialog in Geany looks like this:
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK) { if (update_config(&e, FALSE)) {
Now when I connect to the dialog signals, they get emitted on the line
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
which means that in the signal handler I don't have access to the updated config values from the dialog because these are updated afterwards by
if (update_config(&e, FALSE))
So if there aren't any objections, I'll go back to the implementation I originally suggested and which emits the signal only after the config has been successfully updated.
I've created new pull request with the changes here:
https://github.com/geany/geany/pull/25
If you are interested, these are the changes made to GProject:
https://github.com/techee/geany-plugins/compare/project_prefs_fix
Jiri
Hi, Jiří,
On Mon, 20 Feb 2012 00:35:24 +0100 Jiří Techet techet@gmail.com wrote:
I've created new pull request with the changes here:
Since you are changing the project signals anyway, can you do me a favor and add an unconditional "project-before-save" signal in write_config, with the same arguments as "project-save"?
Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no "before" signal for the projects settings, and I need one for a plugin of mine.
On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi, Jiří,
On Mon, 20 Feb 2012 00:35:24 +0100 Jiří Techet techet@gmail.com wrote:
I've created new pull request with the changes here:
Since you are changing the project signals anyway, can you do me a favor and add an unconditional "project-before-save" signal in write_config, with the same arguments as "project-save"?
Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no "before" signal for the projects settings, and I need one for a plugin of mine.
Hi Dimitar,
what do you need the signal for? The project-save signal is actually emitted before g_key_file_to_data() is called so it is called before it's saved. I use this signal in my plugin too to add my own settings to the project file.
Cheers, Jiri
On Mon, 20 Feb 2012 22:40:50 +0100 Jiří Techet techet@gmail.com wrote:
On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Since you are changing the project signals anyway, can you do me a favor and add an unconditional "project-before-save" signal in write_config, with the same arguments as "project-save"?
Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no "before" signal for the projects settings, and I need one for a plugin of mine.
Hi Dimitar,
what do you need the signal for? The project-save signal is actually emitted before g_key_file_to_data() is called so it is called before it's saved. I use this signal in my plugin too to add my own settings to the project file.
To (a) temporarily revert some file settings before a possible save- session-files and (b) ignore emit_signal, since session save does not depend on it.
On Tue, Feb 21, 2012 at 19:23, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 20 Feb 2012 22:40:50 +0100 Jiří Techet techet@gmail.com wrote:
On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Since you are changing the project signals anyway, can you do me a favor and add an unconditional "project-before-save" signal in write_config, with the same arguments as "project-save"?
Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no "before" signal for the projects settings, and I need one for a plugin of mine.
Hi Dimitar,
what do you need the signal for? The project-save signal is actually emitted before g_key_file_to_data() is called so it is called before it's saved. I use this signal in my plugin too to add my own settings to the project file.
To (a) temporarily revert some file settings before a possible save- session-files and (b) ignore emit_signal, since session save does not depend on it.
Hi Dimitar,
have a look at the attached patch - I've added the signal but as I don't know exactly when you need to emit it, you'll probably need to modify it. Also I haven't documented the signal as I still don't completely understand its purpose. Feel free to use this patch as a template for the modifications you need to do.
Jiri
On Tue, 21 Feb 2012 23:25:02 +0100 Jiří Techet techet@gmail.com wrote:
Hi Dimitar,
have a look at the attached patch - I've added the signal but as I don't know exactly when you need to emit it, you'll probably need to modify it. Also I haven't documented the signal as I still don't completely understand its purpose. Feel free to use this patch as a template for the modifications you need to do.
Thanks!