Re: new module proposal: gobject-introspection
On Sat, Apr 24, 2010 at 4:13 PM, Colin Walters wrote: > On Fri, Apr 23, 2010 at 7:22 PM, Zeeshan Ali (Khattak) > wrote: >> Talking of namespaces, is it correct that gir does not allow >> multiple libs to share a namespace? If so, that could be bigger issue >> than not supporting nested namespaces AFAICT. > > You want two shared objects which just get blended into the same GI namespace? Namespace, yes; gi/typelib file, preferably not. I was pointing-out the one-to-one mapping of namespace to gi/typelibe files which could be a problem in certain cases (see below). > That's actually trivial, the shared-library attribute takes a comma separated > list. > > We were actually using this for a while to implement C "overrides", > where importing Gtk would pull in libgtk-x11-2.0.so and libgtk-addons.so. > We've long since moved to just using gtk directly however now that C > accessors exist for all of the widget flags, etc. > > But nothing stops one from using this facility now if you want it. Just > pass --library multiple times to the scanner. If I understood you correctly, that would work if the libraries are in the same (source) package? Is there a way to accomplish the same for libraries in separate packages? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: gobject-introspection
On Fri, Apr 23, 2010 at 7:22 PM, Zeeshan Ali (Khattak) wrote: > Hi, > > On Sat, Apr 24, 2010 at 12:05 AM, Colin Walters wrote: >> We've made a good >> amount of progress in allowing Vala to be rebased on introspection as >> well (though there is one major blocker still left for that). > > The nested namespace issue you mentioned below? Yes. > Isn't death of gir-repository awaiting for moving all gir/typelib to > respective libraries rather than for applications to stop depending on > gir-repository? Well, there's death and then there's the zombie phase afterwards that all software goes through. What I mean is basically that once gnome-shell, gnome-games and anything else in the core is using typelibs built from the source library, I'll declare it dead, rather than waiting until every single library listed in g-ir-repository has it. If gir-repository lives on in a weird undead state after that, that's not too big of a deal. However I personally don't plan to spend a lot of time keeping it alive for operating system vendors which aren't building GTK+ introspection still 6 months from now. >> 2) API/ABI stability. I'm going to try really hard on this. If we end >> up doing nested namespaces for Vala some things will get harder, >> but we'll see. > > Talking of namespaces, is it correct that gir does not allow > multiple libs to share a namespace? If so, that could be bigger issue > than not supporting nested namespaces AFAICT. You want two shared objects which just get blended into the same GI namespace? That's actually trivial, the shared-library attribute takes a comma separated list. We were actually using this for a while to implement C "overrides", where importing Gtk would pull in libgtk-x11-2.0.so and libgtk-addons.so. We've long since moved to just using gtk directly however now that C accessors exist for all of the widget flags, etc. But nothing stops one from using this facility now if you want it. Just pass --library multiple times to the scanner. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: gobject-introspection
Hi, On Sat, Apr 24, 2010 at 12:05 AM, Colin Walters wrote: > We've made a good > amount of progress in allowing Vala to be rebased on introspection as > well (though there is one major blocker still left for that). The nested namespace issue you mentioned below? > 1) gir-repository should be dead - people please stop depending on it. > It's pretty high priority for me to get gnome-shell switched over to > the GTK+ introspection built stack. Isn't death of gir-repository awaiting for moving all gir/typelib to respective libraries rather than for applications to stop depending on gir-repository? > 2) API/ABI stability. I'm going to try really hard on this. If we end > up doing nested namespaces for Vala some things will get harder, > but we'll see. Talking of namespaces, is it correct that gir does not allow multiple libs to share a namespace? If so, that could be bigger issue than not supporting nested namespaces AFAICT. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
new module proposal: gobject-introspection
GObject Introspection in the bindings set --- I'd like to propose GObject Introspection as part of the bindings release set. Introspection is an infrastructure tool for both applications and language bindings. For more background, there's a longer description of what introspection does here: http://live.gnome.org/GObjectIntrospection External Dependencies: Introspection currently depends on Python 2.5 or later for the developer tools *only*. Adoption: We have several binding consumers of introspection (seed/gjs, pygi, sbank, jgir) in various stages. We've made a good amount of progress in allowing Vala to be rebased on introspection as well (though there is one major blocker still left for that). Gnome-shell currently depends on introspection as a way to bind mutter core. GNOME-ness: We feel we're fairly thoroughly GNOMEy =) 3.0 readiness: Relevant in the sense that introspection is a dependency of gnome-shell which we would like to brand as GNOME 3. We don't link to any GTK+ so there's no GSEAL etc. to worry about. License: LGPL 2.1+, a bit of BSD code here and there Now, on to concerns/issues. 1) gir-repository should be dead - people please stop depending on it. It's pretty high priority for me to get gnome-shell switched over to the GTK+ introspection built stack. 2) API/ABI stability. I'm going to try really hard on this. If we end up doing nested namespaces for Vala some things will get harder, but we'll see. 3) Will this conflict with the eventual goal of getting introspection into GLib? My feeling here is that we can preserve typelib compatibility, potentially only the libgirepository API would change. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
new module proposal: gobject-introspection
GObject Introspection in the bindings set --- I know this is slightly past the deadline, hopefully we can work through the issues. I'd like to propose GObject Introspection as part of the bindings release set. Introspection is an infrastructure tool for both applications and language bindings. For more background, there's a longer description of what introspection does here: http://live.gnome.org/GObjectIntrospection External Dependencies: Introspection currently depends on Python 2.5 or later. Adoption: We have several binding consumers of introspection (seed/gjs, pybank, sbank, jgir) in various stages. We've made a good amount of progress in allowing Vala to be rebased on introspection as well. Gnome-shell currently depends on introspection as a way to bind metacity core. GNOME-ness: We feel we're fairly thoroughly GNOMEy =) 3.0 readiness: Relevant in the sense that introspection is a dependency of gnome-shell which we would like to brand as GNOME 3. License: LGPL 2.1+, a bit of BSD code here and there Now, on to concerns/issues. 1) gir-repository is kind of like a "build-dependency black hole". We've made some progress on getting introspection build put into a few modules, but then some core modules like GTK+ gain an (optional) dependency on a desktop module, not in a way critical to the operation of GTK+ itself. We can probably do some more of the key ones for this release and just leave gir-repository aside. 2) API/ABI stability. The point of going in the bindings release is that we can set our own policy, which in this case is likely to be "not guaranteed". 3) Will this conflict with the eventual goal of getting introspection into GLib? My feeling here is that it should generally be fine to have a "flag day" where consumers are converted for any changes. Overall the primary issue to work through is 1). A sort of middle ground option might be to move more of the "dependency black hole" into the gobject-introspection module, specifically GTK+ and deps, Clutter and deps. The main goal is to enable distribution of seed/gjs/gnome-shell and other bindings, while allowing introspection to continue to evolve more under real-world use from projects like gnome-shell. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
