Re: [Vala] Signal questions, Compilation problem

[Jürg Billeter <j bitron ch>]

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