GObject.java need to be fixed

[GoogleCodeExporter]

1. Problem description:
Some properties can't be getting or setting (Types doesn't defined)

2. Steps that will reproduce the problem:

Element lamemp3enc = ElementFactory.make("lamemp3enc", "lamemp3enc");
lamemp3enc.get("bitrate");
lamemp3enc.set("bitrate",300000);

3. Expected output. What do you see instead?
The expected output is the normally code execution, but instead, we get an 
IllegalArgumentException("Unknown property: " + property). 

4. Solutions
To fix the problem, we need complete some return types. A complete correct 
class can be:

CLASS GObject.java
------------------

private GObjectAPI.GParamSpecTypeSpecific findProperty(String propertyName, 
GType type) {
        Pointer ptr = GOBJECT_API.g_object_class_find_property(handle().getPointer(0), propertyName);
        if (type.equals(GType.INT))
            return new GObjectAPI.GParamSpecInt(ptr);
        else if(type.equals(GType.UINT))
            return new GObjectAPI.GParamSpecUInt(ptr);
        else if(type.equals(GType.CHAR))
            return new GObjectAPI.GParamSpecChar(ptr);
        else if(type.equals(GType.UCHAR))
            return new GObjectAPI.GParamSpecUChar(ptr);
        else if(type.equals(GType.BOOLEAN))
            return new GObjectAPI.GParamSpecBoolean(ptr);
        else if(type.equals(GType.LONG))
            return new GObjectAPI.GParamSpecLong(ptr);
        else if(type.equals(GType.INT64))
            return new GObjectAPI.GParamSpecInt64(ptr);
        else if(type.equals(GType.UINT64))
            return new GObjectAPI.GParamSpecInt64(ptr);
        else if(type.equals(GType.FLOAT))
            return new GObjectAPI.GParamSpecFloat(ptr);
        else if(type.equals(GType.DOUBLE))
            return new GObjectAPI.GParamSpecDouble(ptr);
        else if(type.equals(GType.STRING))
            return new GObjectAPI.GParamSpecString(ptr);
        else if(type.equals(GType.ULONG))
            return new GObjectAPI.GParamSpecLong(ptr);
        throw new IllegalArgumentException("Unknown conversion from GType=" + type);
    }

That's all.

Regards, 
David Gil.

Original issue reported on code.google.com by Drako...@gmail.com on 7 Feb 2011 at 9:58

[GoogleCodeExporter]

Ok, I see, but the problem of using GParamSpecLong and GParamSpecInt64 to hold 
ULONG and UINT64 properties is that overflows can occur if the property value 
is too large for the signed type. 

Original comment by andres.c...@gmail.com on 28 Feb 2011 at 4:02

[GoogleCodeExporter]

This issue was closed by revision r482.

Original comment by andres.c...@gmail.com on 1 Mar 2011 at 8:51

• Changed state: Fixed

[GoogleCodeExporter]

Ok, after some more thinking, there is no problem of using the long and int64 
param types to hold the ulong and uint64 property values. But the programmer 
has to be careful later to treat the values appropriately since in artithmetic 
operations Java will consider them as signed. There are ways to handle these 
situations, for example using the BigInteger type:

http://download.oracle.com/javase/1.4.2/docs/api/java/math/BigInteger.html

or doing some tricks:

http://www.javamex.com/java_equivalents/unsigned_arithmetic.shtml

Original comment by andres.c...@gmail.com on 1 Mar 2011 at 8:51

[GoogleCodeExporter]

I'm not sure if overflows could be occur. The unsigned keyword affects the 
interpretation, not the representation of a number-. In cases where we aren't 
interpreting a value arithmetically it makes essentially no difference whether 
a value is marked as "signed" or "unsigned". Moreover, UINT64 and ULONG are so 
bigger that it rarely will use in a simple property, i think.

Otherwise, i found lots of properties in different elements that i couldn't 
use, cause of this restriction. In my opinion, i prefer have access to this 
properties than gets an IllegalArgumentException.

Original comment by Drako...@gmail.com on 1 Mar 2011 at 9:40

[GoogleCodeExporter]

oh sorry, I have answered about your monday's response. I agree with you. In 
addition, we read the same documentation.

Regards,
David.

Original comment by Drako...@gmail.com on 1 Mar 2011 at 9:46