*_new() functions do more than call g_object_new().

Logged In: YES
user_id=6254
Originator: NO

That was from me, by the way. The awful sourceforge bug-tracker didn't require me to log in.

Logged In: YES
user_id=186672
Originator: NO

Ideally I suppose we should have construct functions for all of them, though I don't have time to do that now.

But if you find any that are causing real problems I'll try to fix them.

Logged In: NO

Almost all of these are causing real problems, such as the inability to override default signal handlers and vfuncs in gtkmm. They really need to have properties. I'll probably get someone from Openismus to create a patch for this.

Logged In: YES
user_id=908
Originator: NO

I have never found any of these to be a problem for the Python bindings. By far the best solution of all is to ignore all these *_new functions and provide only one generic constructor that accepts named arguments (**kwargs in python) uses g_object_newv to create the object with construct properties equal to the named arguments. Works beautifully, and makes the bindings significantly more maintainable.. ;-)

Logged In: NO

We don't actually use the _new() functions. That's the point. But the _new() functions use private API, which suggests that the objects will not be properly initialized if you don't use them.

Logged In: YES
user_id=908
Originator: NO

Last time I checked (long ago), *_new() only did two things: 1. create an object with g_object_new, passing some parameters as construct properties; 2. add the child item to the parent container (parent is always the first argument). IMHO, doing #2 is useless, the programmer can do it himself with one line of code, so the Python bindings only do #1.

Logged In: YES
user_id=6254
Originator: NO

I checked too. Believe me. Anyway, we'll fix this where necessary with a patch.

Logged In: YES
user_id=7017
Originator: NO

I did review the code and as gustavo said, the _new functions really just sets properties (in an obfuscated manner by not using common initializers for item_model and item constructors and by not using common methods for the constructors and the property accessors).

goo_canvas_item_accessible_new()
goo_canvas_widget_accessible_new()
goo_canvas_accessible_new()
- moved atk_object_initialize to the _init functions

goo_canvas_ellipse_new()
goo_canvas_ellipse_model_new()
- they just set center-x, center-y, radius-x, radius-y and parent properties

goo_canvas_group_new()
goo_canvas_group_model_new()
- they just set parent property

goo_canvas_image_new()
goo_canvas_image_model_new()
- they just set x, y, pixmap (implies width, height, pattern) and parent properties

goo_canvas_path_new()
goo_canvas_path_model_new()
- they just set data and parent properties

goo_canvas_polyline_new()
goo_canvas_polyline_new_line()
goo_canvas_polyline_model_new()
goo_canvas_polyline_model_new_line()
- they just set close_path, points and parent properties

goo_canvas_rect_new()
goo_canvas_rect_model_new()
- they just set x, y, width, height, radius-x, radius-y properties

goo_canvas_table_new()
goo_canvas_table_model_new()
- they just set the parent property

goo_canvas_text_new
goo_canvas_text_model_new
- they just set x, y, width, anchor and text properties

goo_canvas_widget_new
- they just set x, y, width, height, widget properties.
- the gtk_widget_show call looks critical at the first moment, but after looking at the code for the visibility and the widget setter it seems to be correct.

So for me this bug report looks invalid.

Logged In: YES
user_id=7017
Originator: NO

Well, almost invalid:

https://sourceforge.net/tracker/index.php?func=detail&aid=1813746&group_id=173653&atid=866270
https://sourceforge.net/tracker/index.php?func=detail&aid=1813748&group_id=173653&atid=866270

Logged In: YES
user_id=6254
Originator: NO

> goo_canvas_accessible_new()
> - moved atk_object_initialize to the _init functions

Do you have a patch for this?

> goo_canvas_widget_new
> - the gtk_widget_show call looks critical at the first moment, but after
> looking at the code for the visibility and the widget setter it seems to be
> correct.

Could you explain this, please.

Logged In: YES
user_id=7017
Originator: NO

>> goo_canvas_accessible_new()
>> - moved atk_object_initialize to the _init functions
>
> Do you have a patch for this?

https://sourceforge.net/tracker/index.php?func=detail&aid=1813748&group_id=173653&atid=866270

>> goo_canvas_widget_new
>> - the gtk_widget_show call looks critical at the first moment, but after
>> looking at the code for the visibility and the widget setter it seems to be
>> correct.
>
> Could you explain this, please.

goo_canvas_widget_new calls gtk_widget_show when a widget is passed. This seems to be a side effect going over the scope of a convenience function in the first moment, but the code for both properties ("visibility" and "widget") correctly adjust the widget's visibility. So those calls are aquivalent:

goo_canvas_widget_new (NULL, widget, 0, 0, 100, 100, NULL);
g_object_new (GOO_TYPE_CANVAS_WIDGET, "widget", widget, "width", 100, "height", 100, NULL);

Same for those:

goo_canvas_widget_new (NULL, widget, 0, 0, 100, 100, "visibility", FALSE, NULL);

g_object_new (GOO_TYPE_CANVAS_WIDGET,
"visibility", FALSE, "widget", widget,
"width", 100, "height", 100, NULL);

g_object_new (GOO_TYPE_CANVAS_WIDGET,
"widget", widget, "visibility", FALSE,
"width", 100, "height", 100, NULL);

Logged In: YES
user_id=6254
Originator: NO

This bug report should be clsoed because patches were filed instead. Sourceforge separates bugs and patches in separate systems. Sourceforge is awful.