[Vala] Property accessors in bindings
Hi,
last month I posted this message [1] in this list but, as you can see, it
went unanswered. As it was a some time ago, I'm writing to see if someone
can answer it now.
Since my first post I've figured out that what I need to do is make
vapigen not to use the [NoAccessorMethod] property attribute, but I've
found nothing about this attribute in the GIR metadata format [2] or in the
GObjectIntrospection annotations [3] documentation. What I found is that
the GIDL metadata format has a way to set property attributes [4]. But as
far as I know and according to my tests, this format is not working with
the version 0.20 of vala.
Also, I've seen that there are some properties generated without the
[NoAccessorMethod] attribute and are translated using the accessor methods
I created for these. I don't notice any difference between these and the
ones with the attribute set in the C code. I don't know how to tell vapigen
wich methods to use for each property neither, so I guess it's done using
method names like {get | set}_property_name in C.
I have to note that the *_{get | set}_property methods of my classes call
my accessors methods so the execution result I have now will be the same,
but what I want is to avoid the extra work done by the call to
g_object_{get | set} when I have a method written to do the same, that can
also increase the readability of the generated vala code.
Regards,
Alex
PS: I also asked in stackoverflow [5], with almost the same results.
[1] https://mail.gnome.org/archives/vala-list/2013-July/msg00043.html
[2] https://wiki.gnome.org/Vala/Manual/GIR%20metadata%20format
[3] https://wiki.gnome.org/GObjectIntrospection/Annotations
[4]
https://wiki.gnome.org/Vala/Manual/GIDL%20metadata%20format#Properties_Reference
[5]
http://stackoverflow.com/questions/18308629/how-to-tell-vala-which-getters-and-setters-to-use-using-gobjectintrospection-and
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Getters and setters in vapi files
Hi,
I've written a C library and used vapigen to create the vapis for it. In
the generated files there are some properties defined like:
public int index { get; set; }
And the accessor methods (which I use from C and only return the value of
the property) duplicating this 'get' and 'set' functionality:
public int get_index ();
public void set_index (int index);
What I want to do is to tell Vala to call my methods when the Vala code
gets or sets the properties using the notation:
i = object.index;
object.index = 42;
instead of translating it to a g_object_set call.
Is there any way to do this?
Regards,
Alex
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Internazionalize genie program
2013/6/3 Gontzal Uriarte > Hello: > How can I internationalize a genie program using Glib.intl > Hi, if you are using Autotools, you can follow this manual[1], I used it with C and also in a Vala porject, the onliy difference is in the sorce code, but using valadoc.org documentation you should find any C symbol for its transaltion to Vala or Genie, I guess. Another approach, if you use the Anjuta IDE, is to generate a Vala project with it and get some inspiration from the generated Autotools configuration. Maybe this is not the best option, but if you get the Autotools and gettext manuals and learn what the macros and all the stuff you use do, you may learn a lot this way (at least I did). Anyway, Trying it by yourself first is the best approach, if you have the time. [1] http://people.gnome.org/~malcolm/i18n/ ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Metatada files doubts
2012/10/24 Andrea Del Signore > Hi, > > On Wed, Oct 24, 2012 at 2:07 PM, Alejandro T. Colombini > wrote: > > Hi, > > I'm binding a C library I wrote and right now I was only using the > > metadata files to avoid vapigen from skipping some methods with varargs > and > > rename things. > ... > > Also, I use a slightly different notation for everything: > > > > > > > My doubts are: are there two different metadata languages? > > Yes there are two way to make a binding file (vapi file). > > The first one use a .gi file generated with vala-gen-introspect [1] > command and the second one just use the .gir file. > > The .gi method is older its metadata format is documented here [2], > instead the .gir one is what is we prefer today and its metadata > format is documented here [3] as you already know. > > HTH, > Andrea > > [1] https://live.gnome.org/Vala/Bindings/GI > [2] https://live.gnome.org/Vala/Manual/GIDL%20metadata%20format > [3] https://live.gnome.org/Vala/Manual/GIR%20metadata%20format > Thanks, Andrea. Any idea about what to do (or what the valac Gtk binding does) to use a C boxed type binded to a vala struct like: var iter = Gtk.TreeIter (); from Vala? I've not seen any custom vala code to adapt it. Also, I've used the 'struct' argument to use my boxed as a vala struct, but when i try to set its methods as 'hidden' vapigen warns about the argument being ignored. Regards, Alex ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Metatada files doubts
Hi, I'm binding a C library I wrote and right now I was only using the metadata files to avoid vapigen from skipping some methods with varargs and rename things. As I was testing the library from Vala using the generated vapi files I noticed that a boxed type I used was not being translated as expected to Vala, as this boxed type is very similar to the Gtk.TreeIter and I also noticed that this one was working exactly as I expected mine to work, I looked at how it was binded to Vala and it was not a [Compact] annotated class like mine, it was a struct and also, from Vala, it could be declared using "var iter = Gtk.TreeIter ();", so I looked at the metadata file used to generate it in the vala repository and I just found this: GtkTreeIter is_value_type="1" gtk_tree_iter_copy hidden="1" gtk_tree_iter_free hidden="1" Then, when I tried to apply these lines in my metadata, vapigen gave me an error: Db-1.0.metadata:6.6-6.18: error: unknown argument Also, I use a slightly different notation for everything: Db cheader_filename="db/db.h" Model.get skip=false Model.set skip=false Being db_model_get and db_model_set the C headers for the methods skipped by GObject Introspection. I've read in the list that 'skip' and 'hidden' offer the same results, so this problem is solved, but using the is_value_type is not possible in my metadata files. I've tried more of the metadata parameters listed in [1] and i've got the same error, or in some cases (like the hidden parameter) just a warning telling that the argument is never used. My doubts are: are there two different metadata languages? And, is the Gtk.TreeIter created binded using just these three lines of metadata or is there something more? Regards, Alex 1: https://live.gnome.org/Vala/Manual/GIDL%20metadata%20format ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] How to set the type of the elements in a container on bindings.
Hello vala-list,
I'm generating a Vala binding for a C library using vapigen and I've
managed to set the type of the elements by using the GObject
Introspection's "element-type" annotation for both the parameters and
return values of functions, but now I need a way to do the same thing for
the element type of object memebers.
A simple example of what I want:
public class MyObject : GLib.Object{
public weak GLib.SList object_list;
}
And this is what I've generated so far:
public class MyObject : GLib.Object{
public weak GLib.SList object_list;
}
I've taken a look at the GIDL metadata and also the GObject
Instrospection documentations, but i've found nothing that suits my needs.
If there's still no way (or will never be) to do this, I guess there's no
problem leaving the element type as "void*" in the generated .vapi files.
Regards, and thanks!
Alex
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
I've finally generated all the .vapi files I needed. The error was in the call to vapigen itself. The library was uninstalled, so I had to tell vapigen where to look for the uninstalled .gir files. I didn't know I could use the "--girdir" option multiple times, and that's exactly what I needed. Thanks for your help! Regards, Alex ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
Abderrahim, I did. In fact I needed to, in order to generate the Sql-0.1.gir and the subsequent .girs'. I noted that the name the error gives to the package is not the same I gave it when exporting it. I called it gvn-0.1 and the error talks about Gvn-0.1, which is not a correct package name. I thought vapigen parsed the name from the .gir and lower the case. May be the name the error gives to the package has no relevance, I don't know. As you can see, I'm kind of lost right now in all this .vapi generation thing (it's the first time I use a mailing list!), but I guess this is the funniest part of programming. Thanks for the link, I'll give it a look. Thanks! Regards, Alex. El 27 de marzo de 2012 18:07, Abderrahim Kitouni escribió: > في ث، 27-03-2012 عند 17:05 +0200 ، كتب Alejandro T Colombini Gómez: > > August, > > I just didn't know that. Reading the documentation and looking at an > > official gnome project (GDA, that does the same thing I was trying to > do) I > > though it was the only way to bind C to Vala. And the other developers I > > mentioned are using Vala by the first time, too. > > > > If I can do this that way I'll save some time! Can you give me some > > reference to that method? > > Actually, the recommended way to use a gobject library from Vala is to > generate the vapi from the GIR. It's actually possible to use the GIR > directly, but I'm not sure whether it's a good idea. > > Anyway, in case you didn't already see it, look at this: > http://live.gnome.org/Vala/UpstreamGuide > > As for your question: > > To generate the .girs I've used the --include-uninstalled option to > > include the previously generated .gir file of the project. Now, when > > the > > build system tries to run vapigen to generate a .vapi that depends on > > another part of the library, it fails. > > > > The call to vapigen is something like this: > > $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d > > $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir > > > > The .vapi file of the "gvn" package is alredy generated (and put in > > the directory specified via the --vapidir option) at this point, as > > well > > as the .gir of the current package. > > > > And this is the error it produces: > > error: Package `Gvn-0.1' not found in specified Vala API > > directories > > or GObject-Introspection GIR directories > > Just a guess, but I think the problem is that your gir file doesn't > reference the package, and so valac doesn't know that gvn-0.1.vapi and > Gvn-0.1.gir are the same. You have to add --pkg-export=gvn-0.1 to your > g-ir-scanner flags. > > HTH, > Abderrahim > > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
August, I just didn't know that. Reading the documentation and looking at an official gnome project (GDA, that does the same thing I was trying to do) I though it was the only way to bind C to Vala. And the other developers I mentioned are using Vala by the first time, too. If I can do this that way I'll save some time! Can you give me some reference to that method? Thanks! Alex El 27 de marzo de 2012 16:48, august escribió: > Alejandro, > > Is there a reason to create a .vapi file? Couldn't your vala developers > just > use the .gir file? AFAIK, that is the preferred method for binding to > vala if > you are already writing gobject libs. > > -august. > > > > Hi, vala-list. > > Before anything else, I have to say I'm new to Vala and also to > > vapigen usage. I've been working on a library which uses GObject and GTK > > + and is written in C, now other developers are going to use this > > library to write an application, but they will do it using Vala, so I'm > > currently binding it using GObjectIntrospecton and vapigen, both > > integrated with the GNU Autotools. > > > > The directory structure of the library is composed by 4 directories, > > each of which contains an alredy generated .gir file. I've managed to > > integrate GObjectInstrospection in the project, and right now I'm > > dealing with vapigen (whose documentation about integration with > > Autotools doesn't exist, currently). > > > > The 4 directories have an horizontal dependency so the .gir of the > > first one is needed to generate the .gir (and .vapi) of the next one and > > so on with all of them, all being in the same level of the build tree. > > > > To generate the .girs I've used the --include-uninstalled option to > > include the previously generated .gir file of the project. Now, when the > > build system tries to run vapigen to generate a .vapi that depends on > > another part of the library, it fails. > > > > The call to vapigen is something like this: > > $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d > > $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir > > > > The .vapi file of the "gvn" package is alredy generated (and put in > > the directory specified via the --vapidir option) at this point, as well > > as the .gir of the current package. > > > > And this is the error it produces: > > error: Package `Gvn-0.1' not found in specified Vala API directories > > or GObject-Introspection GIR directories > > > > I guess it has something to do with the package not being installed, > > but I couldn't find a way to tell it to vapigen. However that's just a > > guess, so I don't really know what i'm doing wrong and/or how to solve > > this. Can anyone help me with it? > > > > Thanks in advance! > > > > Regards, > > Alex > > > > PS: sorry if my english is a mess, if something is not clear tell me and > > I'll try to rewrite it. > > > > ___ > > vala-list mailing list > > vala-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/vala-list > > -- > http://aug.ment.org > GPG: 0A8D 2BC7 243D 57D0 469D 9736 C557 458F 003E 6952 > > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] vapigen and Autotools problem
Hi, vala-list. Before anything else, I have to say I'm new to Vala and also to vapigen usage. I've been working on a library which uses GObject and GTK + and is written in C, now other developers are going to use this library to write an application, but they will do it using Vala, so I'm currently binding it using GObjectIntrospecton and vapigen, both integrated with the GNU Autotools. The directory structure of the library is composed by 4 directories, each of which contains an alredy generated .gir file. I've managed to integrate GObjectInstrospection in the project, and right now I'm dealing with vapigen (whose documentation about integration with Autotools doesn't exist, currently). The 4 directories have an horizontal dependency so the .gir of the first one is needed to generate the .gir (and .vapi) of the next one and so on with all of them, all being in the same level of the build tree. To generate the .girs I've used the --include-uninstalled option to include the previously generated .gir file of the project. Now, when the build system tries to run vapigen to generate a .vapi that depends on another part of the library, it fails. The call to vapigen is something like this: $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir The .vapi file of the "gvn" package is alredy generated (and put in the directory specified via the --vapidir option) at this point, as well as the .gir of the current package. And this is the error it produces: error: Package `Gvn-0.1' not found in specified Vala API directories or GObject-Introspection GIR directories I guess it has something to do with the package not being installed, but I couldn't find a way to tell it to vapigen. However that's just a guess, so I don't really know what i'm doing wrong and/or how to solve this. Can anyone help me with it? Thanks in advance! Regards, Alex PS: sorry if my english is a mess, if something is not clear tell me and I'll try to rewrite it. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
