Re: introspection vs gtk_init()

[Emmanuele Bassi <ebassi gmail com>]

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 <ebassi 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 <walters 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]