Re: [Geany-devel] Empty project properties dialog
On 01/12/2012 04:12 PM, Jiří Techet wrote: On Thu, Jan 12, 2012 at 16:51, Matthew Brush 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Thu, Jan 12, 2012 at 16:51, Matthew Brush 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
[...] > > 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
[...] > 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Any content for next newsletter release?
Hi folks, Its been a couple of weeks since last newsletter release and I'm thinking of preparing a new one. As always in this state: Anybody any content which would fit into? If so, maybe you can just send your article to me or use the github capabilities at https://github.com/geany/newsletter Would be cool ;) Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
Am 12.01.2012 04:05, schrieb Matthew Brush: > You aren't kidding! I was reading a bug report[1] on Pidgin's tracker a > while back about the auto-sizing of a text box or something and the tone > was absolutely incredible, including demands, threats, name-calling and > much more. I couldn't work on a project like Pidgin with so many > disrespectful users. Yepp. And also disrespectful companies. E.g. it seems a bit like Oracle and a couple of others are using Pidgin somewhere internally (which is good for sure), but looks a bit like they are communicating: ask @support mailing list ... But we are changing topics ;D Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
