Adi Roiban <a...@...> writes: > În data de Mi, 06-05-2009 la 17:48 +0000, Jan Hudec a scris: > > Vlad Grecescu <b100d...@...> writes: > > > On Mon, May 4, 2009 at 4:40 PM, Adi Roiban > > <adi <at> roiban.ro> wrote: > > > > I'm trying to extend the Gtk.CheckMenuItem and unfortunately there are > > > > no set_label or set_mnemonic methods. > > > > I was thinking to call the base constructor, but instead of > > > > gtk_check_menu_item_new_with_label, vala generates > > > > gtk_check_menu_item_construct_with_label > > > > Do you know how can I call a base constructor? > > > > You don't want to call gtk_check_menu_item_new_with_label, because it's > > not a constructor! It's an allocator, which is not the thing you want. > True! > > My goal is to call the contructor callend for > gtk_check_menu_item_new_with_label
Unfortunately in this case -- and most other in Gtk -- it does not exist as a separate function. For vala generated code it exists, but here not. > > GObject is limited to initializing base objects is by setting their > > construct-time properties. Unfortunately the check_menu_item does not seem to > > have one for label or mnemonic, so you'll have to manually > > add(new Gtk.Label(...)) > > in your constructor. > That's what I did... but I don't want to recreate the widget. > It is not feasible for more complex widgets. Actually, for most of them it is. For most widgets properties exist which correspond directly to parameters of their allocator functions and those allocator functions just pach their arguments into GParameter array and call g_object_newv. It's definitely true for any widgets where it ever makes sense to inherit them. [...] > > Functionality is better implemented by connecting handlers to the signals > > emited by the widget, where the handlers are implemented either in a class > > representing the document or dialog. You can also take advantage of the > > GtkAction (GtkToggleAction in your case) class, that can connect to or serve > > as factory for menu items, buttons and toolbar buttons and inherit that to > > provide your common functionality. > True! > Basicaly, that what I wanted to do .... but I failed. > > For example in the case of MenuItem, we have the "activated" signal and > there is not way to pass userdata when connecting the signal. > The method called for the "activate" signal will only receive a pointer > to the MenuItem... and I can not pass userdata. False! You can always specify a user data for g_signal_connect(). Vala uses that pointer to pass in the *invocant* of the handler. So all you have to do is create an object describing the action to take and connect it's instance method (*not* static) to the activated signal of the menu item. Alternatively, you can simply attach data to the MenuItem using the Glib::Object method set_data (and corresponding get_data to read them). > Maybe this is a problem with GTK bindings for Vala. I see the only problem in that it might not be immediately obvious where the data argument of g_signal_connect has gone and how to use it. Regards, Jan _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
