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. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
