Hi; I'd like to point out that this is not really just about introspection: gtk-doc has the same issue, since it tries to initialize types in order to get the list of signals and properties.
There are a bunch of issues at play: * a bunch of our types rely on library initialization, and that's just not always feasible in all the conditions (e.g. build machines), but we cannot know which one from the outside, and we cannot reliably test against this * we're still introspecting properties and signals at run time * we're still requiring initialization prior to usage for libraries The intersection of all three issue is where all our build issues, our cross-compilation issues, and our introspection issues lie. We cannot "fix introspection" alone — though we should stop running code to introspect properties and signals and run-time, and just parse the gtk-doc stanzas for those elements; I mean: we're already parsing C code, parsing g_signal_new/g_param_spec_* invocations is not really much of a jump; this would only solve a part of the problem. Having classes depend on side effects and not know whether or not those side effects are actually satisfied is not going to work in the long run. Each class may also have side effects on existing classes — like when we used to register new GtkSettings properties depending on whether or not a single GtkButton was created. We have some parts of our platform that can work reliably without necessarily having a display connection — like, in this case, the default modifiers mask; we need to map those parts out and untangle them from GdkDisplay . Ideally, I'd really like in the future to get to the point where everything that requires a display connection to automatically initialize itself on demand, thus not having to deal with initializing GDK and GTK as a whole. Ciao, Emmanuele. On 29 August 2015 at 14:35, Emmanuele Bassi <eba...@gmail.com> wrote: > The issue was introduced by the fix for the bug: > > https://bugzilla.gnome.org/show_bug.cgi?id=736125 > > i.e. commit: > > > https://git.gnome.org/browse/gtk+/commit/?id=c55ff6e41fb3c6272b5e7a084c8273dea60d7dee > > I've reverted the commit from Matthias, since it broke the build, and > I'd also revert the commit from John Ralls, because it introduced a > regression: now everything that creates a class with a key binding > requires an open display connection — including building the GTK API > reference. > > This is not really something that can be fixed with a GOnce, though; > installing key bindings happen in the class initialization all over > the place. > > We could have something that defers the initialization of the actual > key binding until the widget is realized, i.e. when we know it has a > display connection available. > > Ciao, > Emmanuele. > > On 29 August 2015 at 14:01, Colin Walters <walt...@verbum.org> wrote: >> In >> https://git.gnome.org/browse/gtk+/commit/?id=6838861d26bfec9af53438022bd1f5b60bab3bf4 >> >> I think we need to avoid get_type() functions requiring any explicit >> initialization or external resources; we definitely don't want to require an >> X server for builds that use introspection. >> >> See: https://bugzilla.gnome.org/show_bug.cgi?id=696457 for an earlier >> variant. A general pattern here is to break out initialization components >> into GOnce. >> >> Right? >> _______________________________________________ >> gtk-devel-list mailing list >> gtk-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
