On Sun, Feb 19, 2012 at 17:57, Jiří Techet <tec...@gmail.com> wrote: > On Sat, Jan 14, 2012 at 21:16, Jiří Techet <tec...@gmail.com> wrote: >> On Fri, Jan 13, 2012 at 22:57, Lex Trotman <ele...@gmail.com> wrote: >>> On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush <mbr...@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 _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel