[Gtk-sharp-list] GObject Introspection?

Daniel Espinosa esodan at gmail.com
Fri Apr 22 23:55:28 UTC 2016


If GObject Introspection is the way, may is necesary to create a project
getting GIR files and create its bindings, maybe based on bindinator, but
without gtk# dependencies; because If you want to create gtk# bidings for
Gtk why use a tool requiring same bindings or an old one? (I don't know
witch is using)

Even better (if possible), use binary format (.typelib) is better for
performance and never need to generate API/code, but just consume calls;
like Python and others, they just load .typelib files and when you call a
method, it is transformer directly to the on described, no code generated
is needed.



2016-04-20 23:47 GMT-05:00 Daniel Hughes <trampster at gmail.com>:

> I maintain an open source GTK# 2 application which is included in
> debian/ubuntu. However I can't port to GTK# 3 until there are
> supported bindings which are packaged for Debian.
>
> At a minimum I need:
> * The bindings are supported and stable
> * The bindings are packaged for and included in debian (and by extention
> ubuntu)
> * The bindings will be updated as GTK changes (otherwise my app will
> be removed from debian due to unmet dependencies)
>
> If these assurances cannot be made then I have no choice but to
> continue to use GTK# 2.
>
> My guess is that the same is true for other opensource GTK# applications.
>
>
> On Thu, Apr 21, 2016 at 5:58 AM, Tomi Valkeinen <tomi.valkeinen at iki.fi>
> wrote:
> > On 18/04/16 01:10, Stephan Sundermann wrote:
> >> The problem is that using gobject-introspection the API will not be
> >> compatible with the current gtk#3 API. This is because
> >> gobject-introspection data is at a lot of places more accurate than
> >> parsing the source files with a perl script. gobject-introspection
> >> has a lot better information like ownership of a variable or information
> >> on arrays. Especially these two cases are error prone
> >> in the current gtk-sharp bindings.
> >>
> >> I think it's a lot cleaner to use either the current bindinator tool or
> >> write a complete new generator that directly takes the
> >> gobject-introspection data than to use some vala to C# converter.
> >
> > Well, for what it's worth, I very much think that keeping the current,
> > unmaintained, old, (dead?) gtk#3 stable is not of much benefit. If we
> > have an option to get up to date gtk#3 for current gtk versions, which
> > can be kept up to date, and which is more accurate than the current
> > gtk#3, I would recommend going there.
> >
> > The projects that use the current gtk#3 and can't/won't update their
> > code to work with new gtk#3 can quite easily(?) have their own copy of
> > the legacy gtk#3 dlls.
> >
> >  Tomi
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20160422/963ae036/attachment.html>


More information about the Gtk-sharp-list mailing list