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 the existing GtkDialog signals instead of having custom signals for doing the same. Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel