After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 584259 - unable to call metacity gradient_create_multi function in Python
unable to call metacity gradient_create_multi function in Python
Status: RESOLVED WONTFIX
Product: gnome-python-desktop
Classification: Deprecated
Component: metacity
unspecified
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2009-05-30 07:34 UTC by Gianni Moschini
Modified: 2014-08-02 13:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Here is an example, drawing a pixbuf returned by the gradient_create_multi function on a drawingarea (1.67 KB, application/x-compressed-tar)
2009-05-30 07:44 UTC, Gianni Moschini
Details
An example of what it could be (2.10 KB, text/plain)
2009-05-31 16:50 UTC, Gianni Moschini
Details

Description Gianni Moschini 2009-05-30 07:34:34 UTC
Please describe the problem:
The function needs an array of GdkColors as an argument, like the C counterpart.

But I can't send any array in Python. So I tried sending a list of gtk.gtk.Colors, but the result is a bit strange: the color in the gradient are not the one sent to the function.

For reference, the function is defined like this in gnome-python-desktop/metacity/metacity.defs :

> (define-function gradient_create_multi
>   (c-name "meta_gradient_create_multi")
>   (return-type "GdkPixbuf*")
>   (parameters
>     '("int" "width")
>     '("int" "height")
>     '("const-GdkColor*" "colors")
>     '("int" "n_colors")
>     '("MetaGradientType" "style")
>   )
> )


And here is the C function definition

> GdkPixbuf*
> meta_gradient_create_multi (int              width,
> int              height,
> const GdkColor  *colors,
> int              n_colors,
> MetaGradientType style)

Which then calls meta_gradient_create_multi_vertical (c part)

> static GdkPixbuf*
> meta_gradient_create_multi_vertical (int width, int height,
>  GdkColor *colors,
>  int count)

Here is an example of the call to the meta_gradient_create_multi in C, from metacity/src/testgradient.c (simplified)

> GdkColor colors[5];
> pixbuf = meta_gradient_create_multi (width, height, colors, 5, type);



Steps to reproduce:
1. create a list of gtk.gdk.Colors objects
2. send the list to the metacity.gradient_create_multi function



Actual results:
the pixbuf returned by the function will have strange colors (not the one passed in the list)

Expected results:
The gradient created should always be based on the colors passed by the list.

Does this happen every time?
When calling the function with a list in which you add/remove objects, the result will differ greatly from one call to another.

Other information:
I looked at another gtk function which takes an array in C, and the Python bindings has been overrided to use a list. The function is gtk.targets_include_image, which then transform the list to an array in c. But that is not the case here. Maybe some code should be added in the gnome-python-desktop/metacity/metacitymodule.c or something related.

I don't know much about Python binding C functions, so I'm kind of unaware of what needs to be done.

If anyone knows how it's handled in Python in other functions, when the C counterpart works with an array of G objects as an argument, that may help.
Comment 1 Gianni Moschini 2009-05-30 07:44:20 UTC
Created attachment 135601 [details]
Here is an example, drawing a pixbuf returned by the gradient_create_multi function on a drawingarea

The important part is in the on_drawing_expose_event:
> metacity.gradient_create_multi(100, 100, colors[0], len(colors), metacity.GRADIENT_VERTICAL)

And the colors variable is a list of gtk.gdk.Colors objects defined as
> colors = [
>             colormap.alloc_color( "yellow" ),
>             colormap.alloc_color( "green" ),
>             colormap.alloc_color( "white" )
>         ]
Comment 2 Gian Mario Tagliaretti 2009-05-30 11:21:33 UTC
Look at the generated C code


    if (pyg_boxed_check(py_colors, GDK_TYPE_COLOR))
        colors = pyg_boxed_get(py_colors, GdkColor);
    else {
        PyErr_SetString(PyExc_TypeError, "colors should be a GdkColor");
        return NULL;
    }
    
    ret = meta_gradient_create_multi(width, height, colors, n_colors, style);


which is wrong, it doesn't expect a list of colors but a single GdkColor, this function should be wrapped manually.
Comment 3 Gianni Moschini 2009-05-31 09:26:17 UTC
(In reply to comment #2)
> which is wrong, it doesn't expect a list of colors but a single GdkColor, this
> function should be wrapped manually.
> 

That's my point. It would be better if we could send a list in Python. But I know this needs a lot of work, and I don't have the knowledge to do that.

I already looked at some other functions in C, like I said, that waits for a list in Python, and send an array in C. And I don't understand much of that code. But I suppose it's always the same technique. So if someone has the ability, the experience, and the time to do that, he will be able to copy/paste the important parts, and adapt the code, which could take extra work, but it would be worth it, really.

Anyway, if you have a link to some Python code calling any C function waiting for an array, or even an brief theorical explanation on how to do this (like which module are needed), it would be greatly appreciated, because I didn't found anything relevant on the subject yet.

Comment 4 Gianni Moschini 2009-05-31 16:50:07 UTC
Created attachment 135675 [details]
An example of what it could be

This is what I meant by copy/pasticodes codes ng. I just did tried to retrieve some bits of from the pygtk code, and adapting it for this function.

I don't know if it would be working, or even compiling. And anyway I don't how to test this code. So I'm just putting it in here for reference.
Comment 5 John Finlay 2009-06-01 21:38:17 UTC
I've done some work to make it easier to handle lists in the override files by factoring out the common list handling code but I've been stymied in checking in code because of the git changeover. Once I get up to speed using git then I can add some helper functions for dealing with GSList and GList items.
Comment 6 André Klapper 2014-08-02 13:02:33 UTC
The last gnome-python-desktop code changes took place in January 2011:
https://git.gnome.org/browse/archive/gnome-python-desktop/log/

This project is not under active development anymore.

This project got recently archived in GNOME Git.

It is currently unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. If you are interested in maintainership, inform https://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-python-desktop wrapped application API in GNOME 2. For Python in GNOME 3, see https://wiki.gnome.org/Projects/PyGObject and its gobject-introspection approach.