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