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 <[email protected]>: > 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 <[email protected]> > 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 - [email protected] > 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)
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
