Re: [Vala] Binding problem or ClutterGst problem or my problem?
Hi, On Fri, 2012-01-06 at 10:02 -0500, Brian Duffy wrote: I'm getting the error set_seek_flags does not exist in the context of ClutterGst.VideoTexture. I have confirmed I'm using Clutter-Gst 1.4.4 with ClutterGst.Version.check(1,4,4) Yes, but the vapi included in vala 0.14 (at least in my debian unstable and from the commandline you wrote also in Fedora 16) is clutter-gst version 1.0 and according to documentation the set_seek_flags function is included from clutter 1.4 I think you must find an updated version of the clutter-gst vapi. HTH, Andrea ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Binding problem or ClutterGst problem or my problem?
I wonder what the policy is concerning new Vala releases. If I can't make assumptions about certain libraries having up to date vapi files then Vala becomes much more difficult to use. I have been going on the assumption that the libraries that are documented in Valadoc, such as clutter and clutter-gst, are having their vapi files updated to something *atleast* relatively recent. On Fri, Jan 13, 2012 at 9:46 AM, Andrea Del Signore seje...@tin.it wrote: On Fri, 2012-01-13 at 09:32 -0500, Brian Duffy wrote: I would be interested if anyone can clarify what the deal is here. I would hate to think that Vala is only providing functionality that has existed in clutter since 1.0 or Clutter-gst since 1.0. I can't believe that is the case. Vala policy is to call the vapi file with the same name of the .pc file. In the case of clutter-gst it's very likely that the vapi is outdated. Regards, Andrea -- Duff ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Compilation error using XClientMessageEvent
Hi,
then I try to compile the following code with vala 0.14, I get a
compilation error from gcc :
using Gtk;
using Gdk;
using X;
public class Test : Object {
enum Message {
REQUEST_DOCK,
BEGIN,
CANCEL
}
private void add_client (long xid) {
}
private void event_filter (Gdk.XEvent xev) {
void* pointer = xev;
X.Event* xevent = (X.Event*) pointer;
if (xevent-xclient.data.l [1] == Message.REQUEST_DOCK)
add_client (xevent-xclient.data.l [2]);
return;
}
static int main (string[] args) {
Gtk.init (ref args);
Gtk.main ();
return 0;
}
}
valac --pkg x11 --pkg gtk+-3.0 --pkg gdk-x11-3.0 xlib.vala
xlib.vala:17.5-17.29: warning: method `Test.event_filter' never used
private void event_filter (Gdk.XEvent xev) {
^
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c: In function
'test_event_filter':
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:83:2: erreur:
unknown type name 'ClientMessageEventData'
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:94:9: erreur:
incompatible types when assigning to type 'int' from type 'union
anonymous'
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:95:17: erreur:
request for member 'l' in something not a structure or union
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:96:25: erreur:
request for member 'l_length1' in something not a structure or union
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:101:3: erreur:
unknown type name 'ClientMessageEventData'
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:107:10: erreur:
incompatible types when assigning to type 'int' from type 'union
anonymous'
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:108:18: erreur:
request for member 'l' in something not a structure or union
/home/hotnuma/Bureau/Projets/samples/x11/xlib.vala.c:109:26: erreur:
request for member 'l_length1' in something not a structure or union
error: cc exited with status 256
Compilation failed: 1 error(s), 1 warning(s)
ClientMessageEventData is an union to ClientMessageEvent (x11.vapi) :
public struct ClientMessageEvent {
public int type;
public ulong serial;/* # of last request processed by server */
public bool send_event;/* true if this came from a
SendEvent request */
public unowned Display display;/* Display the event was
read from */
public Window window;
public Atom message_type;
public int format;
public ClientMessageEventData data;
}
I'm missing something, any help would be appreciated.
Thanks.
-- Axel FILMORE
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] X11 and pointers help
Hi,
I am trying to get a list of the open windows using
_NET_CLIENT_LIST_STACKING (it is important I use this as I need it in
the order of stacking) as seen here
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449346
To do this I am using the Xlib bindings for vala with the following
code, however I cannot get the code at the end of this message to compile
Any help? If I am honest, I am not really sure what the void* stuff is
about :/
--
Andrew
/* Compile with valac --pkg x11 window.vala*/
int main(string[] args) {
X.init_threads();
var xdisplay = new X.Display();
X.Atom type;
int format;
ulong nitems;
ulong bytes_after;
void* list;
xdisplay.get_window_property(xdisplay.default_root_window(),
xdisplay.intern_atom(_NET_CLIENT_LIST_STACKING, true),
0, long.MAX, false, X.XA_CARDINAL, out type, out format, out
nitems, out bytes_after, out list);
for (int i = 0; i nitems; i++) {
ulong xid = (ulong) list[i];
stdout.printf(xid.to_string());
}
X.free(list);
return 0;
}
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] X11 and pointers help
On 13/01/12 17:20, Andrew Higginson wrote:
Hi,
I am trying to get a list of the open windows using
_NET_CLIENT_LIST_STACKING (it is important I use this as I need it in
the order of stacking) as seen here
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449346
To do this I am using the Xlib bindings for vala with the following
code, however I cannot get the code at the end of this message to compile
Any help? If I am honest, I am not really sure what the void* stuff is
about :/
Should also say this is what I get when I compile (C file at the end of
this message) - sorry :)
/tmp/window.vala.c: In function ‘_vala_main’:
/tmp/window.vala.c:71:10: error: variable or field ‘_tmp19_’ declared void
/tmp/window.vala.c:91:22: warning: dereferencing ‘void *’ pointer
[enabled by default]
/tmp/window.vala.c:91:13: error: void value not ignored as it ought to be
error: cc exited with status 256
--
Andrew
/* window.c generated by valac 0.14.0, the Vala compiler
* generated from window.vala, do not modify */
#include glib.h
#include glib-object.h
#include stdlib.h
#include string.h
#include X11/Xlib.h
#include X11/Xatom.h
#include X11/Xutil.h
#include X11/Xregion.h
#include stdio.h
#define _g_free0(var) (var = (g_free (var), NULL))
#define _XCloseDisplay0(var) ((var == NULL) ? NULL : (var =
(XCloseDisplay (var), NULL)))
gint _vala_main (gchar** args, int args_length1);
gint _vala_main (gchar** args, int args_length1) {
gint result = 0;
Display* _tmp0_;
Display* xdisplay;
Atom type = {0};
gint format = 0;
gulong nitems = 0UL;
gulong bytes_after = 0UL;
void* list = NULL;
Display* _tmp1_;
Display* _tmp2_;
Window _tmp3_ = 0;
Display* _tmp4_;
Atom _tmp5_ = {0};
glong _tmp6_;
Atom _tmp7_ = {0};
gint _tmp8_ = 0;
gulong _tmp9_ = 0UL;
gulong _tmp10_ = 0UL;
void* _tmp11_ = NULL;
void* _tmp24_;
XInitThreads ();
_tmp0_ = XOpenDisplay (NULL);
xdisplay = _tmp0_;
_tmp1_ = xdisplay;
_tmp2_ = xdisplay;
_tmp3_ = DefaultRootWindow (_tmp2_);
_tmp4_ = xdisplay;
_tmp5_ = XInternAtom (_tmp4_, _NET_CLIENT_LIST_STACKING, TRUE);
_tmp6_ = G_MAXLONG;
XGetWindowProperty (_tmp1_, _tmp3_, _tmp5_, (glong) 0, _tmp6_, FALSE,
XA_CARDINAL, _tmp7_, _tmp8_, _tmp9_, _tmp10_, (unsigned char **)
(_tmp11_));
type = _tmp7_;
format = _tmp8_;
nitems = _tmp9_;
bytes_after = _tmp10_;
list = _tmp11_;
{
gint i;
i = 0;
{
gboolean _tmp12_;
_tmp12_ = TRUE;
while (TRUE) {
gboolean _tmp13_;
gint _tmp15_;
gulong _tmp16_;
void* _tmp17_;
gint _tmp18_;
void _tmp19_;
gulong xid;
FILE* _tmp20_;
gulong _tmp21_;
gchar* _tmp22_ = NULL;
gchar* _tmp23_;
_tmp13_ = _tmp12_;
if (!_tmp13_) {
gint _tmp14_;
_tmp14_ = i;
i = _tmp14_ + 1;
}
_tmp12_ = FALSE;
_tmp15_ = i;
_tmp16_ = nitems;
if (!(((gulong) _tmp15_) _tmp16_)) {
break;
}
_tmp17_ = list;
_tmp18_ = i;
_tmp19_ = _tmp17_[_tmp18_];
xid = (gulong) _tmp19_;
_tmp20_ = stdout;
_tmp21_ = xid;
_tmp22_ = g_strdup_printf (%lu, _tmp21_);
_tmp23_ = _tmp22_;
fprintf (_tmp20_, %s, _tmp23_);
_g_free0 (_tmp23_);
}
}
}
_tmp24_ = list;
XFree (_tmp24_);
result = 0;
_XCloseDisplay0 (xdisplay);
return result;
}
int main (int argc, char ** argv) {
g_type_init ();
return _vala_main (argv, argc);
}
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] X11 and pointers help
You can do this using Gdk I think :
http://valadoc.org/gdk-3.0/Gdk.Screen.get_window_stack.html
That doesn't explain the compilation error however.
Regards.
On 13/01/2012 18:58, Andrew Higginson wrote:
On 13/01/12 17:20, Andrew Higginson wrote:
Hi,
I am trying to get a list of the open windows using
_NET_CLIENT_LIST_STACKING (it is important I use this as I need it in
the order of stacking) as seen here
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449346
To do this I am using the Xlib bindings for vala with the following
code, however I cannot get the code at the end of this message to compile
Any help? If I am honest, I am not really sure what the void* stuff is
about :/
Should also say this is what I get when I compile (C file at the end of
this message) - sorry :)
/tmp/window.vala.c: In function ‘_vala_main’:
/tmp/window.vala.c:71:10: error: variable or field ‘_tmp19_’ declared void
/tmp/window.vala.c:91:22: warning: dereferencing ‘void *’ pointer
[enabled by default]
/tmp/window.vala.c:91:13: error: void value not ignored as it ought to be
error: cc exited with status 256
--
Andrew
/* window.c generated by valac 0.14.0, the Vala compiler
* generated from window.vala, do not modify */
#includeglib.h
#includeglib-object.h
#includestdlib.h
#includestring.h
#includeX11/Xlib.h
#includeX11/Xatom.h
#includeX11/Xutil.h
#includeX11/Xregion.h
#includestdio.h
#define _g_free0(var) (var = (g_free (var), NULL))
#define _XCloseDisplay0(var) ((var == NULL) ? NULL : (var =
(XCloseDisplay (var), NULL)))
gint _vala_main (gchar** args, int args_length1);
gint _vala_main (gchar** args, int args_length1) {
gint result = 0;
Display* _tmp0_;
Display* xdisplay;
Atom type = {0};
gint format = 0;
gulong nitems = 0UL;
gulong bytes_after = 0UL;
void* list = NULL;
Display* _tmp1_;
Display* _tmp2_;
Window _tmp3_ = 0;
Display* _tmp4_;
Atom _tmp5_ = {0};
glong _tmp6_;
Atom _tmp7_ = {0};
gint _tmp8_ = 0;
gulong _tmp9_ = 0UL;
gulong _tmp10_ = 0UL;
void* _tmp11_ = NULL;
void* _tmp24_;
XInitThreads ();
_tmp0_ = XOpenDisplay (NULL);
xdisplay = _tmp0_;
_tmp1_ = xdisplay;
_tmp2_ = xdisplay;
_tmp3_ = DefaultRootWindow (_tmp2_);
_tmp4_ = xdisplay;
_tmp5_ = XInternAtom (_tmp4_, _NET_CLIENT_LIST_STACKING, TRUE);
_tmp6_ = G_MAXLONG;
XGetWindowProperty (_tmp1_, _tmp3_, _tmp5_, (glong) 0, _tmp6_, FALSE,
XA_CARDINAL,_tmp7_,_tmp8_,_tmp9_,_tmp10_, (unsigned char **)
(_tmp11_));
type = _tmp7_;
format = _tmp8_;
nitems = _tmp9_;
bytes_after = _tmp10_;
list = _tmp11_;
{
gint i;
i = 0;
{
gboolean _tmp12_;
_tmp12_ = TRUE;
while (TRUE) {
gboolean _tmp13_;
gint _tmp15_;
gulong _tmp16_;
void* _tmp17_;
gint _tmp18_;
void _tmp19_;
gulong xid;
FILE* _tmp20_;
gulong _tmp21_;
gchar* _tmp22_ = NULL;
gchar* _tmp23_;
_tmp13_ = _tmp12_;
if (!_tmp13_) {
gint _tmp14_;
_tmp14_ = i;
i = _tmp14_ + 1;
}
_tmp12_ = FALSE;
_tmp15_ = i;
_tmp16_ = nitems;
if (!(((gulong) _tmp15_) _tmp16_)) {
break;
}
_tmp17_ = list;
_tmp18_ = i;
_tmp19_ = _tmp17_[_tmp18_];
xid = (gulong) _tmp19_;
_tmp20_ = stdout;
_tmp21_ = xid;
_tmp22_ = g_strdup_printf (%lu, _tmp21_);
_tmp23_ = _tmp22_;
fprintf (_tmp20_, %s, _tmp23_);
_g_free0 (_tmp23_);
}
}
}
_tmp24_ = list;
XFree (_tmp24_);
result = 0;
_XCloseDisplay0 (xdisplay);
return result;
}
int main (int argc, char ** argv) {
g_type_init ();
return _vala_main (argv, argc);
}
___
vala-list
Re: [Vala] X11 and pointers help
On 13 January 2012 18:07, Axel FILMORE axel.film...@gmail.com wrote: You can do this using Gdk I think : http://valadoc.org/gdk-3.0/Gdk.Screen.get_window_stack.html That doesn't explain the compilation error however. Regards. Many thanks, I think I shall just use that instead :) -- Andrew Higginson ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] X11 and pointers help
Hi,
On Fri, 2012-01-13 at 17:20 +, Andrew Higginson wrote:
Hi,
I am trying to get a list of the open windows using
_NET_CLIENT_LIST_STACKING (it is important I use this as I need it in
the order of stacking) as seen here
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449346
To do this I am using the Xlib bindings for vala with the following
code, however I cannot get the code at the end of this message to compile
Any help? If I am honest, I am not really sure what the void* stuff is
about :/
A void pointer is a pointer to an unknown type and you should cast to a
specific type before using it. For this reason this line is invalid and
vala should complain at compile time like the C compiler is doing:
ulong xid = (ulong) list[i];
You are accessing the list variable with list[i].
I think that you can workaround this situation with a temporary variable
and honestly I don't know a cleaner solution:
unowned ulong[] items = (ulong[])list;
for (int i = 0; i nitems; i++) {
ulong xid = items[i];
stdout.printf(xid.to_string());
}
Regards,
Andrea
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Compilation error using XClientMessageEvent
Hi Axel,
I'm missing something, any help would be appreciated.
Thanks.
I tried modifying x11.vala like this, which almost makes your code work:
[CCode (cname = union { char b[20]; short s[10]; long l[5]; })]
public struct ClientMessageEventData {
which gives the following error:
incompatible types when assigning to type ‘union anonymous’ from
type ‘union anonymous’
So it turns out that you cannot make your own variable of the same
type as the anonymous union and have C consider them as the same type.
I don't think there's an easy way out of this. The fact that the union
is anonymous is beyond vala's control.
Does copying the entire ClientMessageEvent work for you?
Timo Kluck
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Compilation error using XClientMessageEvent
Well, no, currently I can't get it to compile, this sample code is from an
implementation of the system tray specification :
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
There's other implementations in plain C but I'd prefer to have it in Vala,
that's cleaner that mixing C and Vala.
I think that code worked before maybe with another version of the compiler
or with a modified vapi file, I don't know.
:)
On 13/01/2012 19:54, Timo Kluck wrote:
Hi Axel,
I'm missing something, any help would be appreciated.
Thanks.
I tried modifying x11.vala like this, which almost makes your code work:
[CCode (cname = union { char b[20]; short s[10]; long l[5]; })]
public struct ClientMessageEventData {
which gives the following error:
incompatible types when assigning to type ‘unionanonymous’ from
type ‘unionanonymous’
So it turns out that you cannot make your own variable of the same
type as the anonymous union and have C consider them as the same type.
I don't think there's an easy way out of this. The fact that the union
is anonymous is beyond vala's control.
Does copying the entire ClientMessageEvent work for you?
Timo Kluck
--
Axel FILMORE
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Binding problem or ClutterGst problem or my problem?
Surely when they created Vala they saw that coming. Why package VAPIs with Vala to start with? Was it expected you'd retrieve VAPIs manually in situations like this and keep and track yourself, leaving the provided set as (for lack of a better word at the moment) backups? Steven N. Oliver On Fri, Jan 13, 2012 at 12:46 PM, Emmanuele Bassi eba...@linux.intel.comwrote: On 2012-01-13 at 09:32, Brian Duffy wrote: Maybe I'm wrong but I was going on the assumption that the vapi authors are not basing their version numbers on minor releases such as clutter-1.8 or clutter-gst-1.4 or whatever. For instance, when include the clutter package in my application I am using --pkg clutter-1.0 even though I am using the clutter-1.8 that F16 has available through yum. that's because the 1.0 fragment of the clutter-1.0 pkg-config name (which is what Vala uses to find the library compiler and linker flags when you use the --pkg command line argument) is the API version, not the Clutter version. Clutter 1.8 still allows you to use the API of every other release of the 1.x series, as it's API and ABI compatible. I would be interested if anyone can clarify what the deal is here. I would hate to think that Vala is only providing functionality that has existed in clutter since 1.0 or Clutter-gst since 1.0. I can't believe that is the case. it's exactly the case, but it's probably not what you meant. any function at the time 1.0 was released is still available in Clutter 1.8; if you need a specific version of Clutter you'll have to check the version using pkg-config at configure time. Clutter itself has two ways for checking at compile time and run time what version is being used: • the CLUTTER_CHECK_VERSION() macro, which can be used to delimit a section in the C code, e.g.: #if CLUTTER_CHECK_VERSION(1, 8, 0) clutter_object_method_added_in_1_8_0 (foo); #else clutter_object_method_available_before (foo); clutter_object_method_that_may_have_been_deprecated_later (bar); #endif • the clutter_check_version() function, which can be used to check the version of the Clutter library that is *currently* running the application, e.g.: if (clutter_check_version (1, 8, 0)) clutter_object_method (arg); else clutter_object_another_method (another_arg); this obviously applies to the C API; if you need to use a method or a class and the vapi file doesn't list them, then you'll have to update the vapi file and either depend on a new version of Vala that ships that updated vapi, or ship the updated vapi file yourself. yes, that's a problem of Vala, and the fact that all vapi files are centralized with Vala, instead of living outside of the project. ciao, Emmanuele. -- Emmanuele Bassi, Intel Open Source Technology Center ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Binding problem or ClutterGst problem or my problem?
On Fri, 2012-01-13 at 17:46 +, Emmanuele Bassi wrote: On 2012-01-13 at 09:32, Brian Duffy wrote: Maybe I'm wrong but I was going on the assumption that the vapi authors are not basing their version numbers on minor releases such as clutter-1.8 or clutter-gst-1.4 or whatever. For instance, when include the clutter package in my application I am using --pkg clutter-1.0 even though I am using the clutter-1.8 that F16 has available through yum. that's because the 1.0 fragment of the clutter-1.0 pkg-config name (which is what Vala uses to find the library compiler and linker flags when you use the --pkg command line argument) is the API version, not the Clutter version. Clutter 1.8 still allows you to use the API of every other release of the 1.x series, as it's API and ABI compatible. I would be interested if anyone can clarify what the deal is here. I would hate to think that Vala is only providing functionality that has existed in clutter since 1.0 or Clutter-gst since 1.0. I can't believe that is the case. it's exactly the case, but it's probably not what you meant. any function at the time 1.0 was released is still available in Clutter 1.8; if you need a specific version of Clutter you'll have to check the version using pkg-config at configure time. No it isn't. I think you missed the word only. Vala isn't /only/ providing functionality that has existed in Clutter since 1.0, it is providing all the functionality that the library (or libraries) referenced by that pkg-config file provide up until the last time the VAPI was updated. Clutter itself has two ways for checking at compile time and run time what version is being used: It's also worth noting that, AFAIK, most people just use pkg-config to test against a minimum required version using the PKG_CHECK_MODULES macro. • the CLUTTER_CHECK_VERSION() macro, which can be used to delimit a section in the C code, e.g.: #if CLUTTER_CHECK_VERSION(1, 8, 0) clutter_object_method_added_in_1_8_0 (foo); #else clutter_object_method_available_before (foo); clutter_object_method_that_may_have_been_deprecated_later (bar); #endif • the clutter_check_version() function, which can be used to check the version of the Clutter library that is *currently* running the application, e.g.: if (clutter_check_version (1, 8, 0)) clutter_object_method (arg); else clutter_object_another_method (another_arg); this obviously applies to the C API; if you need to use a method or a class and the vapi file doesn't list them, then you'll have to update the vapi file and either depend on a new version of Vala that ships that updated vapi, or ship the updated vapi file yourself. You can also use the extern keyword to create a binding in your Vala code. It's a bit hackish, but not usually a problem if you're just missing a method or two. yes, that's a problem of Vala, and the fact that all vapi files are centralized with Vala, instead of living outside of the project. We don't have a problem with upstream libraries distributing their own VAPIs. In fact, I rather prefer the idea... examples of this include (according to share/vala/vapi in my jhbuild environment): * atasmart * champlain * colord * dconf * folks * gee * gssdp * gtk-vnc * gupnp * libcanberra * libosinfo * libproxy * libvirt * rygel * spice * telepathy * tracker That said, many projects aren't going to want to deal with Vala because of the additional maintenance cost, a lack of familiarity with Vala, apathy, etc. If Clutter would like to build and distribute its own VAPI I certainly wouldn't have any objection, and I don't think anyone else would either. I would even be willing to help maintain the bindings. That offer goes for everyone, not just Clutter or even GNOME. If you would prefer to distribute a VAPI with your project I would be happy to help integrate the bindings into your build system and assist with maintenance. After all, it's not really any more work for me to maintain bindings upstream than in Vala. If you don't want to distribute a VAPI with your project, just recognize that we may forget to update our VAPI, especially for less popular packages. Feel free to file a bug report at [1], or even just ask on IRC (my nick is nemequ on gimpnet and freenode). Also, keep in mind that Vala follows the GNOME release schedule; a new stable branch is only released every six months, and distributions don't tend to package unstable releases. -Evan [1] https://bugzilla.gnome.org/browse.cgi?product=vala ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Binding problem or ClutterGst problem or my problem?
Interesting. I wonder, does Vala mention in their notes for new releases on the web site if they are updating a specific vapi file? How could I go about finding out what version of clutter (for instance) that Vala's release of the clutter vapi file supports? Is it in the name of the vapi file (something like clutter-1.8-vapi)? If not, would looking for a file modification date that I can compare to clutter release dates make sense. It would be nice to know up front what version of a specific library my default Vala vapi supports. At some point I guess I'll have to start understanding how vapi files work but for now I have enough to do just getting up to speed on Vala and Clutter, which by the way is the most fun I have had programming in quite some time. thnx Brian On Fri, Jan 13, 2012 at 3:50 PM, Evan Nemerson e...@coeus-group.com wrote: On Fri, 2012-01-13 at 17:46 +, Emmanuele Bassi wrote: On 2012-01-13 at 09:32, Brian Duffy wrote: Maybe I'm wrong but I was going on the assumption that the vapi authors are not basing their version numbers on minor releases such as clutter-1.8 or clutter-gst-1.4 or whatever. For instance, when include the clutter package in my application I am using --pkg clutter-1.0 even though I am using the clutter-1.8 that F16 has available through yum. that's because the 1.0 fragment of the clutter-1.0 pkg-config name (which is what Vala uses to find the library compiler and linker flags when you use the --pkg command line argument) is the API version, not the Clutter version. Clutter 1.8 still allows you to use the API of every other release of the 1.x series, as it's API and ABI compatible. I would be interested if anyone can clarify what the deal is here. I would hate to think that Vala is only providing functionality that has existed in clutter since 1.0 or Clutter-gst since 1.0. I can't believe that is the case. it's exactly the case, but it's probably not what you meant. any function at the time 1.0 was released is still available in Clutter 1.8; if you need a specific version of Clutter you'll have to check the version using pkg-config at configure time. No it isn't. I think you missed the word only. Vala isn't /only/ providing functionality that has existed in Clutter since 1.0, it is providing all the functionality that the library (or libraries) referenced by that pkg-config file provide up until the last time the VAPI was updated. Clutter itself has two ways for checking at compile time and run time what version is being used: It's also worth noting that, AFAIK, most people just use pkg-config to test against a minimum required version using the PKG_CHECK_MODULES macro. • the CLUTTER_CHECK_VERSION() macro, which can be used to delimit a section in the C code, e.g.: #if CLUTTER_CHECK_VERSION(1, 8, 0) clutter_object_method_added_in_1_8_0 (foo); #else clutter_object_method_available_before (foo); clutter_object_method_that_may_have_been_deprecated_later (bar); #endif • the clutter_check_version() function, which can be used to check the version of the Clutter library that is *currently* running the application, e.g.: if (clutter_check_version (1, 8, 0)) clutter_object_method (arg); else clutter_object_another_method (another_arg); this obviously applies to the C API; if you need to use a method or a class and the vapi file doesn't list them, then you'll have to update the vapi file and either depend on a new version of Vala that ships that updated vapi, or ship the updated vapi file yourself. You can also use the extern keyword to create a binding in your Vala code. It's a bit hackish, but not usually a problem if you're just missing a method or two. yes, that's a problem of Vala, and the fact that all vapi files are centralized with Vala, instead of living outside of the project. We don't have a problem with upstream libraries distributing their own VAPIs. In fact, I rather prefer the idea... examples of this include (according to share/vala/vapi in my jhbuild environment): * atasmart * champlain * colord * dconf * folks * gee * gssdp * gtk-vnc * gupnp * libcanberra * libosinfo * libproxy * libvirt * rygel * spice * telepathy * tracker That said, many projects aren't going to want to deal with Vala because of the additional maintenance cost, a lack of familiarity with Vala, apathy, etc. If Clutter would like to build and distribute its own VAPI I certainly wouldn't have any objection, and I don't think anyone else would either. I would even be willing to help maintain the bindings. That offer goes for everyone, not just Clutter or even GNOME. If you would prefer to distribute a VAPI with your project I would be happy to help integrate the bindings into your
