Re: Cannot `dynamic_cast` custom wrapped widget from Gtk::Builder

[Josh Bialkowski <josh bialkowski gmail com>]

> You said in a previous post that you execute...

Wellllll... this is executed inside the generated `wrap_init()` which is part of the `Gtk::` namespace (in hindsight, a bad idea) and apparently this function is not getting called. If I call it directly in `main()` then things are working. At first, I thought there must be a `Gtk::wrap_init()` somewhere already in gtkmm but I can't find it, so the other possibility is maybe a build system error and a left over build artifact somewhere. Maybe? In any case, to summarize, my understanding is that:

1. I used _CLASS_GOBJECT which generates a Glib::wrap returning a `Glib::RefPtr` instead of _CLASS_GTKOBJECT which generates Glib::wrap returning a raw pointer. This may or may not have contributed to the particular problem, as perhaps some type/overload resolution somewhere depended on this. Or it was a latent error that wasn't involved in this particular problem.
2. Lacking a `wrap_init`, I was not calling `Glib::wrap_register`, which sounds like the most likely culprit
3. Even after I generated `wrap_init()`, it apparently wasn't getting called. Possibly due to some link-order issue or a stale build artifact or something. 

> Perhaps you can double-check that Glade and GtkBuilder really give you a GtkPanZoomArea, and not just a GtkDrawingArea

This is a bit moot now, but since you asked I will answer: I'm pretty confident that the `GtkPanZoomArea` was getting constructed. It uses some custom signals for `area-motion`, `area-button` and `area-draw`. Those signals and their default handlers (virtual functions) were both working in a demo application. If it were actually constructing a drawing area I would expect that connecting those signals would error. 

Lastly, I spent the morning pushing the library containing this widget to github to help with the discussion. It's not relevant anymore but since I posted it I'll go ahead and share the links. 

* Here is the header for GtkPanZoomArea (source nextdoor): https://github.com/cheshirekow/tangent-gtk/blob/master/tangent/gtkutil/panzoomarea.h 
* Here is panzoomarea.hg: https://github.com/cheshirekow/tangent-gtk/blob/master/tangent/gtkutil/mm/panzoomarea.hg 

Given this learning experience I'll probably do some reorganization/refactoring to improve the mm- wrapping situation. 

Thank very much, Kjell, for your help. I think this problem is solved. 

On Mon, May 4, 2020 at 4:30 AM Kjell Ahlstedt <kjellahlstedt gmail com> wrote:

On 2020-05-03 20:12, Josh Bialkowski wrote:

Ok, I think I figured it out the m4 include path issue for gmmproc, but I still can't load the widget from GtkBuilder even when using `_CLASS_GTKOBJECT`. I think that with two `-I` in the command line, one must be overriding the other. The following command line seems to work, and generates a reasonable .h file. 

~~~
M4PATH=/usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/m4:/usr/lib/x86_64-linux-gnu/atkmm-1.6/proc/m4:/usr/lib/x86_64-linux-gnu/pangomm-1.4/proc/m4 /usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/gmmproc -I /usr/lib/x86_64-linux-gnu/gtkmm-3.0/proc/m4 panzoomarea mm mm
~~~

I should have realized that gmmproc must be able to find atkmm's and pangomm's m4 files. They are included from convert_gtkmm.m4. gmmproc usually works well if all its input is correct, but it's not always good at telling what's wrong when some input is wrong or missing.

So, now we're back at your first question: Why does the dynamic_cast to Gtk::PanZoomArea* fail?

You said in a previous post that you execute

Glib::wrap_register(gtk_panzoom_area_get_type(), &PanZoomArea_Class::wrap_new);

That's necessary. Still it looks like Glib::wrap_auto() and Glib::wrap_create_new_wrapper() wrap a GtkPanZoomArea in a Gtk::DrawingArea. I don't understand why.

Perhaps you can double-check that Glade and GtkBuilder really give you a GtkPanZoomArea, and not just a GtkDrawingArea. You've said that

GtkPanZoomArea* panzoom_ = GTK_PANZOOM_AREA(builder->get_object("overhead-view")->gobj());

works. I don't know if GTK_PANZOOM_AREA() checks the type, or if it just casts unconditionally.