On Sun, 2013-09-01 at 20:20 +0200, Kjell Ahlstedt wrote: > 2013-08-31 21:12, Juan Rafael García Blanco skrev: > > On Mon, 2013-08-26 at 19:50 +0100, Chris Vine wrote: > >> On Mon, 26 Aug 2013 09:00:34 +0200 > >> Kjell Ahlstedt <kjell.ahlst...@bredband.net> wrote: > >>> 2013-08-25 12:19, Juan Rafael Garcia Blanco skrev: > >>>> Hello, > >>>> > >>>> I'm fairly new to developing inside gtkmm. I'm trying to wrap > >>>> GtkPlacesSidebar. I managed to get a first version > >>>> (https://bugzilla.gnome.org/show_bug.cgi?id=705642) and now I'm > >>>> writing a simple example to test it. > >>>> > >>>> In that example program I attach a handler to the open-location > >>>> signal. That signal, when emitted, provides a Gio::File object in > >>>> the form of Glib::Object; when it is emitted I get this message: > >>>> > >>>> glibmm-WARNING **: Failed to wrap object of type 'GLocalFile'. > >>>> Hint: this error is commonly caused by failing to call a library > >>>> init() function. > >>>> > >>>> GtkPlacesSidebar docs state that the signature for that signal > >>>> handler should be: > >>>> > >>>> void user_function (GtkPlacesSidebar *sidebar, > >>>> GObject *location, > >>>> ...) > >>>> > >>>> where location is a GFile. > >>>> > >>>> I've added Gio::init() at the beginning of my main.cc, but the > >>>> problem remains. I would like to learn how this can be done, and > >>>> why it is not working. > >>>> > >>>> Thank you very much in advance. > >>>> > >>>> Regards, > >>>> Juan. > >>>> > >>> gtk_init() must be called in a gtk+ program, and thus also in a gtkmm > >>> program. gtk_init() is called by > >>> Gtk::Application::create(int& argc, char**& argv, const > >>> Glib::ustring& application_id, Gio::ApplicationFlags flags) > >>> but it's not called by > >>> Gtk::Application::create(const Glib::ustring& application_id, > >>> Gio::ApplicationFlags flags) > >>> > >>> Don't know if this is bug, or done deliberately. My guess is that > >>> both Gtk::Application::create() shall call gtk_init(). > >>> Don't know if a missing call to gtk_init() is the reason for your > >>> warning message. > >> g_application_run() is not subclassed in GtkApplication to call > >> gtk_init(), and it doesn't need to be because GtkApplication itself > >> initializes GTK+ when the object is constructed. When using > >> GtkApplication you can call gtk_init(), but you do not have to. The > >> main point is that g_application_run() does not strip out command line > >> arguments which are GTK+ specific, such as --display and the like. > >> That is the only reason, in a GTK+ program, to call gtk_init() with > >> GtkApplication. (I think the suggestion is that you should not do so, > >> but should use environmental variables or the GOptionGroup/GOptionEntry > >> interface.) > >> > >> Given the different approach to library initialization taken by gtkmm, > >> this no doubt caused a problem. The decision seems to have been taken > >> to pass the program arguments to gtk_init() when they are passed to > >> Gtk::Application::create(), but not to call gtk_init() otherwise. This > >> should work OK. The problem may lie elsewhere: perhaps there is > >> something wrong about the use of (or wrapping of) GApplication's 'open' > >> signal. > >> > >> Chris > > I think the problem is not related to missing ::init() funtions. I think > > the problem has something to do with the fact that the handler takes a > > GObject instead of a GFile. I think I'm missing some _CONVERSION macro. > > As I said the open_location signal handler takes a GFile argument as a > > GObject. I'm wrapping it with this line: > > > > _WRAP_SIGNAL(void open_location(const Glib::RefPtr<Glib::Object>& > > location, PlacesOpenFlags open_flags=Gtk::PLACES_OPEN_NORMAL), > > "open_location"); > > > > I took a look at how Gtk::Entry has wrapped the populate_popup signal, > > which also takes a GtkWidget argument that actually is a GMenu. But it > > gives me little information since the wrapped signal handler does not > > use RefPtr<>. > > > > Thank you in advance. > > > Now I understand what causes your problem, but I'm not sure what's the > best way to fix it. > > PlacesSidebar_signal_open_location_callback() gets a GObject* p0, where > p0 points to an object which is actually a GLocalFile. GLocalFile is not > wrapped in gtkmm. > Glib::wrap(p0) tries to create a C++ wrapper. It fails because > Glib::wrap_auto() only tries to find a corresponding C++ class for > GLocalFIle and those of its base classes that derive from GObject, i.e. > no interfaces derived from GInterface. There is a corresponding C++ > class for GObject itself (Glib::Object), but Glib::wrap_auto() does not > find it, because it's not registered with a call to > Glib::wrap_register(). A Glib::Object wrapper would probably be useless > anyway. It would not be possible to dynamic_cast it to a Gio::File. > > Probably GLocalFile shall not be wrapped. I suspect that there are a > number of gtk+ classes that implement the GFile interface, and all of > those shall be wrapped in a Gio::File wrapper. > > There is already a gtkmm/gtk/src/gtk_signals.defs.patch file that > patches the file generated by > gtkmm/tools/extra_defs_gen/generate_defs_gtk. Perhaps it would help to > add a patch for PlacesSidebar's open_location signal, changing > '("GObject*" "p0") > to > '("GFile*" "p0") > > You should then also change the _WRAP_SIGNAL directive to > _WRAP_SIGNAL(void open_location(const Glib::RefPtr<Gio::File>& > location, PlacesOpenFlags open_flags=Gtk::PLACES_OPEN_NORMAL), > "open_location"); > > Kjell >
How can I generate the gtk_signals.defs.patch file? I'm not sure how to do that. Thank you very much. Regards, Juan. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
