[Geany-devel] Empty project properties dialog

[Jiří Techet]

On Thu, Jan 12, 2012 at 16:51, Matthew Brush <mbrush at 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