On Mon, 2012-01-23 at 17:12 +0200, Zeeshan Ali (Khattak) wrote: > On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi <eba...@gmail.com> wrote: > > hi Zeeshan; > > Hi Emmanuele, > > > On 23 January 2012 02:14, Zeeshan Ali (Khattak) <zeesha...@gnome.org> wrote: > >> On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau <t...@gnome.org> > >> wrote: > >>> 2012/1/21 Zeeshan Ali (Khattak) <zeesha...@gnome.org>: > > > >>>> There are way > >>>> too many of the libraries to take care of and on top of that they > >>>> change all the time. Ideally each library should be providing vala > >>>> bindings and take care of keeping it up2date. So its really not a > >>>> fault of vala itself. > > > > I don't agree with this assessment. > > > > you're just deferring the issue to every library under the sun, and > > this is very much problematic in a variety of reasons: > > > > - as a maintainer, now I'd have to care not only about introspection, > > but also about a vapi file - which is another redundant format that > > expresses the library's API; so the first thing I'd look at would be > > generating the latter in terms of the former, which introduces a build > > dependency (albeit optional) on Vala. so it's my library that now has > > to deal with the compiler and generator bugs. yeah, right: not going > > to happen. > > What I was proposing wasn't so different from what you are saying > here. Vala bindings should still be generated out of gir bindings but > since gir doesn't support some of the essential features that vala > apps have been depending on for some time now, we'll need to have > *some* vala-specific metadata, at least until gir supports those > features.
I've been putting together a guide for people wanting to maintain bindings upstream, and it includes an incomplete list of discrepancies between GIR and Vala (and how to work around them): https://live.gnome.org/Vala/UpstreamGuide#Using_Metadata_Files > If having any vala-specific metadata in a few libraries isn't > acceptable to maintainers, yeah we should first separate out the > bindings into another package and then push the bindings that are > purely generated from gir to their respective libraries. I think it's worth pointing out here that most libraries aren't going to have a lot of metadata. Clutter's API is pretty large (the vapi is 7283 lines) and it only has 158 lines (including comments and whitespace, less once bug #667840 is resolved) of metadata, but most libraries will only have a few lines. > BTW just for the record, It should be noted that gir is the cause of > the problem here not vala. That's not really fair. It's true that there is some stuff that GIR doesn't support that we would like them to, but Vala's GIR parser has bugs too. Up until fairly recently Vala's GIR parser was definitely the bigger problem. > > - I have used Vala, but I'm not an expert on figuring out its quirks, > > nor am I using it for my day to day work; this means that I'll have to > > rely on Vala developers to update the Vala bindings. this means that > > Vala developers and users will now need to go through various bugzilla > > products and git repositories to fix the Vala bindings in each and > > every project that ships one. > > They'll have to go through the same procedures as python and > javascript users so I don't think this is an issue. Actually this will > give good motivation to vala developers to fix/improve your gir > annotations for you. Yes! After the initial work to get bindings working properly, most of the stuff we do is actually fixing things in the metadata file that could/should really be fixed in annotations within the upstream project. This means that currently my workflow often looks something like this: 1. Tweak the metadata to fix the issue in the vala repository and regenerate the bindings. 2. Create a patch against the upstream library to resolve the issue with annotations. 3. File a bug report with the patch and wait for upstream to resolve the issue. Example: clutter bug #667840 4. Undo the changes to the metadata file in the vala repository and instead regenerate the bindings using the updated GIR. My offer to help with maintenance for libraries wanting to move bindings upstream wasn't entirely selfless; I could eliminate steps 1 and 4. It also means that you get those annotation fixes sooner rather than later (sometimes much later since I sometimes don't get around to #2 for a while, and sometimes someone else does #1 doesn't worry about the rest), which fixes the GIR-based bindings for other languages as well. The other obvious advantage is that users don't have to wait for a new Vala release to get updated bindings. Finally, we can stop worrying about a whole class of issues where the bindings are too new. Say a library has a virtual function and they decide they want to add a method which invokes it (a pretty common scenario). After you regenerate the Vala bindings valac will start using the invoker automatically instead of calling the vfunc directly, which works great for the latest version of the library, but breaks for people running an older version. If Vala bindings are distributed with your library the API will match the library on that system. Another example is gdk_pixbuf_get_pixels_with_length, which could replace Gdk.Pixbuf.get_pixels in the Vala API transparently but for the fact that it doesn't work on older versions of GdkPixbuf. Therefore, we now have a slightly broken get_pixels method for backwards compatibility and a much less nicely named get_pixels_with_length method which is what people should really be using. If the vapi were tied to the installed version this wouldn't be a problem. -Evan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
