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 the existing GtkDialog signals instead of having custom signals for doing the same.
Jiri