[Vala] Exposing the CLUTTER_COLOR_* macros in Vala
I've created a patch for Vala [1] that will expose the CLUTTER_COLOR_*
macros in Vala as Clutter.Color.*. It maps e.g. CLUTTER_COLOR_Red to
Clutter.Color.RED and CLUTTER_COLOR_DarkOrange to
Clutter.Color.DARK_ORANGE. This convention disagrees with
ClutterStaticColor (but does agree with CLUTTER_COLOR_*). ebassi, do
you think this convention is OK?
- Kerrick
[1]
Expose the CLUTTER_COLOR_* C macros
Expose the CLUTTER_COLOR_* C macros (which provide a set of pre-defined
colors) as Clutter.Color.*. For example, CLUTTER_COLOR_Red (in C)
becomes Clutter.Color.RED (in Vala).
Note that these names are not quite the same as the StaticColor.* names,
because StaticColor treats light/dark colors inconsistently: it includes
e.g. DARK_GREEN while also including e.g. ORANGE_DARK. In the new
Color.* names, these are DARK_GREEN and DARK_ORANGE, respectively (which
also follows the convention used by CLUTTER_COLOR_*).
---
vapi/metadata/Clutter-1.0-custom.vala | 90 +++
1 file changed, 90 insertions(+)
diff --git a/vapi/metadata/Clutter-1.0-custom.vala
b/vapi/metadata/Clutter-1.0-custom.vala
index 025c504..44b109b 100644
--- a/vapi/metadata/Clutter-1.0-custom.vala
+++ b/vapi/metadata/Clutter-1.0-custom.vala
@@ -45,6 +45,96 @@ namespace Clutter {
public Color.from_string (string str);
[CCode (cname = "clutter_color_from_string")]
public bool parse_string (string str);
+ [CCode (cname = "(*CLUTTER_COLOR_White)")]
+ public static Color WHITE;
+ [CCode (cname = "(*CLUTTER_COLOR_Black)")]
+ public static Color BLACK;
+ [CCode (cname = "(*CLUTTER_COLOR_Red)")]
+ public static Color RED;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkRed)")]
+ public static Color DARK_RED;
+ [CCode (cname = "(*CLUTTER_COLOR_Green)")]
+ public static Color GREEN;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkGreen)")]
+ public static Color DARK_GREEN;
+ [CCode (cname = "(*CLUTTER_COLOR_Blue)")]
+ public static Color BLUE;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkBlue)")]
+ public static Color DARK_BLUE;
+ [CCode (cname = "(*CLUTTER_COLOR_Cyan)")]
+ public static Color CYAN;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkCyan)")]
+ public static Color DARK_CYAN;
+ [CCode (cname = "(*CLUTTER_COLOR_Magenta)")]
+ public static Color MAGENTA;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkMagenta)")]
+ public static Color DARK_MAGENTA;
+ [CCode (cname = "(*CLUTTER_COLOR_Yellow)")]
+ public static Color YELLOW;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkYellow)")]
+ public static Color DARK_YELLOW;
+ [CCode (cname = "(*CLUTTER_COLOR_Gray)")]
+ public static Color GRAY;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkGray)")]
+ public static Color DARK_GRAY;
+ [CCode (cname = "(*CLUTTER_COLOR_LightGray)")]
+ public static Color LIGHT_GRAY;
+ [CCode (cname = "(*CLUTTER_COLOR_Butter)")]
+ public static Color BUTTER;
+ [CCode (cname = "(*CLUTTER_COLOR_LightButter)")]
+ public static Color LIGHT_BUTTER;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkButter)")]
+ public static Color DARK_BUTTER;
+ [CCode (cname = "(*CLUTTER_COLOR_Orange)")]
+ public static Color ORANGE;
+ [CCode (cname = "(*CLUTTER_COLOR_LightOrange)")]
+ public static Color LIGHT_ORANGE;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkOrange)")]
+ public static Color DARK_ORANGE;
+ [CCode (cname = "(*CLUTTER_COLOR_Chocolate)")]
+ public static Color CHOCOLATE;
+ [CCode (cname = "(*CLUTTER_COLOR_LightChocolate)")]
+ public static Color LIGHT_CHOCOLATE;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkChocolate)")]
+ public static Color DARK_CHOCOLATE;
+ [CCode (cname = "(*CLUTTER_COLOR_Chameleon)")]
+ public static Color CHAMELEON;
+ [CCode (cname = "(*CLUTTER_COLOR_LightChameleon)")]
+ public static Color LIGHT_CHAMELEON;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkChameleon)")]
+ public static Color DARK_CHAMELEON;
+ [CCode (cname = "(*CLUTTER_COLOR_SkyBlue)")]
+ public static Color SKY_BLUE;
+ [CCode (cname = "(*CLUTTER_COLOR_LightSkyBlue)")]
+ public static Color LIGHT_SKY_BLUE;
+ [CCode (cname = "(*CLUTTER_COLOR_DarkSkyBlue)")]
+ public static Color DARK_SKY_BLUE;
+ [CCode (cname = "(*CLUT
Re: [Vala] Vala arrays and libraries bindings
Hello,
I don't quite understand your problem, but one thing to note is that a
function like
void my_vala_func(int[] arr)
{
...
}
in Vala translates to something like
void my_c_func(int[] arr, int arr_length)
{
...
}
in C. Note that there's an extra argument to the function: this is the
length of the array. Vala passes this implicitly (as a property of the
array object), but in C it needs to be passed explicitly (since C arrays
don't track their own length). That's why the extra argument is showing up
in the generated C code.
If your code won't compile, perhaps you could provide the specific error
messages that the compiler outputs?
- Kerrick
On Sun, May 27, 2012 at 6:30 PM, Дмитрий Петров wrote:
> Hello everyone,
>
> I'm very new to vala and my current task is to build an application
> using webkit-gtk component. One thing that I can't deal with is
> how valac translates the arrays, that should be passed to the function.
>
> As an example: I need to define a javascript function that will return
> an js array object:
>
>public static JSCore.Value js_read_dir (Context ctx,
>JSCore.Object function,
>JSCore.Object thisObject,
>JSCore.Value[] arguments,
>out JSCore.Value exception) {
>
>JSCore.Value[] dirs = {};
>dirs += new JSCore.Value.string( ctx, new
> String.with_utf8_c_string ("a") );
>dirs += new JSCore.Value.string( ctx, new
> String.with_utf8_c_string ("b") );
>JSCore.Value err = new JSCore.Value.null( ctx );
>
>return new JSCore.Object.array( ctx, 2, dirs, out err);
>}
>
> Here is the method definition from the vapi file:
>[CCode (cname = "JSObjectMakeArray")]
>public Object.array (Context ctx, size_t argument_count,
> JSCore.Value[] arguments,
> out JSCore.Value exception);
>
> Everything seems ok to me, but valac adds an additional argument to
> the method call
> for some reason and this prevents the code from compiling. Here is how
> the generated
> call looks like:
>
> _tmp9_ = JSObjectMakeArray (_tmp8_, (gsize) 2, dirs, dirs_length1, &err);
>
> As you can see, there is an extra argument - dir_length1, which
> doesn't exist neither in
> bindings nor in vala code. I've searched for some examples and the
> only thing I've found
> was that people construct json strings, evaluate them and get
> the objects they need from evaluation.
>
> So, where am I wrong? How can I fix my code to use standard bindings?
>
> --
> Kind regards, Dmitry Petrov
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Chain up base constructor troubles with C code...
Axel,
I believe that when you're inheriting from a C class in Vala code, calling
the base class's constructor is not supported [1]. Instead, just replicate
the original constructor's functionality at the beginning of your derived
class's constructor:
public class FolderView : Fm.FolderView, BaseView
{
public FolderView()
{
// initialize Fm.FolderView's properties
fmFoldViewProp1 = "foo";
...
// do FolderView-specific initialization
foldViewProp1 = "bar";
}
}
- Kerrick
[1]
As far as I understand it, this is because the C constructors
(e.g. fm_folder_view_new) do two logically separate things:
1) allocate memory for the new object
2) initialize the fields comprising that memory
Since (in general) a derived object occupies more memory than the
corresponding base object, the base constructor generally doesn't allocate
enough memory at step (1), and so the object returned by the base
constructor is pretty much useless (unless the derived constructor wants to
call realloc, but that would incur a performance penalty). Instead, each
constructor has to duplicate the functionality of its parent constructor.
In Vala, they handled this problem a little more nicely, and so constructor
chaining works as expected, but again this only works if you're inheriting
from a Vala class.
This discussion has more information:
http://osdir.com/ml/vala-list/2009-09/msg00376.html
On Sun, May 27, 2012 at 6:51 AM, Axel FILMORE wrote:
> Hi there,
>
> to avoid some nasty duplicated code I try to use inheritance with a base
> abstract class and derived views.
>
> I need to create a terminal view and a folder view, while it works fine
> with my terminal view which is written in Vala, I've some troubles with the
> folder view which is C code. :(
>
> I have the following :
>
> namespace Manager {
>
>public class FolderView : Fm.FolderView, BaseView {
>
>construct {
>base.new (Fm.FolderViewMode.LIST_VIEW);
>//Object ();
>//base (Fm.FolderViewMode.LIST_VIEW);
>}
>
>public FolderView () {
>//Object (mode: Fm.FolderViewMode.LIST_VIEW);
>//base (Fm.FolderViewMode.LIST_VIEW);
>
>base.new (Fm.FolderViewMode.LIST_VIEW);
>}
>}
> }
>
> I tried a few things without much success, the problem is that the base
> object doesn't seem to be created.
>
> BaseView is an abstract class in Vala and Fm.FolderView is my base object
> in C, the one that gives my some troubles. :-P
>
> In my Vapi file for the base object, I have :
>
> [CCode (cheader_filename = "gtk/fm-folder-view.h")]
> public class FolderView : Gtk.ScrolledWindow,
> Atk.Implementor,
> Gtk.Buildable {
>
>public Fm.FolderViewMode mode;
>
>[CCode (has_construct_function = false,
>cname = "fm_folder_view_new",
>type = "GtkWidget*")]
>
>public FolderView (int mode);
>
> }
>
>
> The problem is that the new function (fm_folder_view_new) is not called
> from Vala code.
>
> I tried to use "Object (mode: Fm.FolderViewMode.LIST_VIEW);"
> but "mode" is not a property and it fails.
>
> Is there a way so that when doing var = new Manager.FolderView ();
> the base function "fm_folder_view_new" is called ?
>
> Thanks. :)
>
>
> --
> Axel FILMORE
> #-**---#
>https://github.com/afilmore
> #-**---#
> Vala - Compiler For The GObject Type System
>https://live.gnome.org/Vala
> #-**---#
> __**_
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/**mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Using float literals in Vala source
When a floating-point literal (e.g. "3.0") appears in Vala source code, it is treated as a double. Since Vala will not automatically convert doubles to floats, you can't write something such as: var constraint = new Clutter.AlignConstraint(stage, AlignAxis.X_AXIS, 0.5); This code gives the error: Cannot convert from `double' to `float' To fix it, the 0.5 must be changed to 0.5f. I think it would be more convenient and intuitive to automatically cast the double to a float in this context. Automatic casting would be consistent with C and C++ but inconsistent with C# and Java. - Kerrick ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
