[Geany-devel] Empty project properties dialog

[Matthew Brush]

On 01/12/2012 04:12 PM, Jiří Techet wrote:
> 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 :-)
>

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