Re: [Vala] [PATCH] gtk_action_group_add_*_actions add user_data



On Wed, 2008-04-02 at 20:08 +0200, Jaap A. Haitsma wrote:
On Wed, Apr 2, 2008 at 1:13 PM, Juerg Billeter <j bitron ch> wrote:
On Wed, April 2, 2008 07:34, Jaap A. Haitsma wrote:
 > I've ran into an issue when using ActionGroup.add_toggle_actions or
 > ActionGroup.add_radio_actions. The field user_data is not being set by
 > the vala compiler so the C compiler complains. Attached patch should
 > resolve this I think. In my opinion it would be even better if the
 > user_data field was not there but that the vala compiler would
 > automatically set it to the this pointer. Is this possible?

 Thanks for the patch. It looks fine, I'll merge that as soon as possible.
 'this' might not always be the right choice, so I don't think we should do
 that.

For g_signal_connect functions (e.g. the callbacks of widgets) vala
doesn't let you specify user_data. The this pointer is just passed
automatically as user data. I was very surprised to see that I needed
to specify user data for add_actions. So for consistency I would
recommend not to pass user_data for add_actions. Furthermore without
it the use is easier.

Not quite right. Vala allows you to pass userdata when connecting
signals, just not as separate parameter. It uses the instance of the
callback method you're connecting.

    button.clicked += on_clicked;

which is the same as

    button.clicked += this.on_clicked;

both pass 'this' as user_data.

However, you can also write something like

    button.clicked += some_other_object.on_clicked;

which will pass some_other_object as user_data. Passing 'this' is
certainly the most common case.

The issue with add_actions is that you specify the method at a different
place (in the const array) than the user_data, so we can't use the same
approach as we use for signal connections (and other callbacks).

Jürg




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]