Re: [Vala] Signal questions, Compilation problem

["Cayle Graumann" <cayle graumann gmail com>]

Jurg,

    While we're talking about bindings files, I've come across a couple of things I don't understand how to do.

I am working on creating a binding to the lightweight XML generation library genx, I have gotten everything wrapped up except for two things:

The function which creates a new xmlwriter, which has a c prototype like this:

genxWriter genxNew(void * (*alloc)(void * userData, int bytes),
		   void (* dealloc)(void * userData, void * data),
		   void * userData);

I've already bound the genxWriter structure and every other function that uses it, but I haven't figured out how to specify that the binding 
needs function pointers.  I assume that this is where using callback comes in.  

Also, 

    In the C header file, there is an enum list containing error codes.  If I duplicate this enum in the vala binding, I end up 
with a copy of the enum declared which won't compile by the C compiler.  Is there an annotation that I'm missing that prevents valac from 
emitting a block into the C code?  

Also, here is another bug for your list in the enum code 

This will not compile by valac 

     enum MyEnum {
           SUCCESS,
           ERROR1,
           ERROR10 = 10
     }
It does not like the assignment.

Cayle
Missouri

On 9/11/06, Jürg Billeter <j bitron ch > wrote:

Hi Daniel,

On Mon, 2006-09-11 at 07:34 +0200, Daniel Borgmann wrote:
> >      Welcome to the vala development list.  Vala is very promising, but it's
> > still incomplete, especially with respect to the language bindings.   I'm
> > still discovering how to make bindings files because I'm trying to create
> > bindings to parts of the C standard library that are not supported yet.  I
> > would recommend you try your hand at adding the signals into the
> > gtk-2.0.vala file in the vapi directory.  When you get them added, I'm sure
> > Jurg wouldn't mind you sending him a patch file with the code you added, to
> > assist him in developing the bindings.
>
> I've tried adding the signals to the interface but this had no effect.
> Instead I had to add the signals to the actual Entry class. Patch
> attached, but I don't think this is right.

Support for interface signals hasn't been added to the compiler yet, I
hope to get soon to fix it. Adding needed signals to the effective class
can be used as a work-around but - as you assumed - it's not the right
solution. The GTK+ bindings are generated by the way (experimental
generator is also in SVN, in the vapigen directory), so I will have to
fix the generator to also support interface signals.

> I have one more question regarding signals: I'm currently writing
> bindings for gtksourceview and the SourceBuffer class has functions

If you want to write bindings for GObject based libraries you might want
to take a closer look to the previously mentioned vapigen, although it
still has a lot of issues and is not yet flexible enough. It's probably
not that obvious how to use it, so here follows a very quick tutorial:

- Create a gtksourceview-1.0 directory similar to the other directories
in vapigen/packages in SVN

- Generate GIDL by running
        gapigen PATH_TO_SOURCE_TARBALL packages/gtksourceview-1.0

- Generate VAPI by running something like
        vapigen --pkg cairo --pkg pango --pkg atk --pkg gdk-2.0 --pkg gtk+-2.0 packages/gtksourceview-1.0/gtksourceview-1.0.gidl

> called "can_redo" and "can_undo" as well as signals called "can-redo"
> and "can-undo". This obviously doesn't work if I name the signals
> can_redo and can_undo, so is there a way to chose a different name but
> still tell vala about the correct C signal name? I tried using the @
> char like some of the functions do, but that made no difference.

The @ sign may only be used to use keywords as identifiers, it's not a
separate namespace. The C signal name may currently not differ from the
Vala signal name (to be fixed), you can set a different C name for
methods as follows, though:

[CCode (cname = "gtk_source_buffer_can_undo")]
public bool can_undo_foo ();

I realize that it'd probably be better to change the signal name (to
something like can_undo_changed) but that has to be deferred until Vala
supports different C signal names.

Regards,

Jürg