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

Reply via email to