Re: Wrapping GtkPlacesSidebar

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 ahlstedt bredband net> wrote:
2013-08-25 12:19, Juan Rafael Garcia Blanco skrev:

I'm fairly new to developing inside gtkmm. I'm trying to wrap
GtkPlacesSidebar. I managed to get a first version
( 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, 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.


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

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'

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),

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")
      '("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),


How can I generate the gtk_signals.defs.patch file? I'm not sure how to
do that. Thank you very much.


I have updated
Read the comments there.


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