Hi, Thank you very much. That script got serious :) I patched gtk_signals.defs and that did the trick: now I don't see the warning message, and the GFile is wrapped just fine.
I still have a few problems: - How can I provide a const version of _WRAP_METHOD(std::vector< Glib::RefPtr<Gio::File> > list_shortcuts(), gtk_places_sidebar_list_shortcuts) - How can I deal with gpointers that are actually well known objects? Regards, Juan. On Thu, 2013-09-05 at 17:27 +0200, Kjell Ahlstedt wrote: > 2013-09-04 22:20, Juan Rafael García Blanco skrev: > > 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. > > > > > I have updated > https://git.gnome.org/browse/gtkmm/tree/tools/gen_scripts/gtk_generate_extra_defs.sh. > Read the comments there. > > Kjell _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
