After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708866 - Gtk::HeaderBar usage example
Gtk::HeaderBar usage example
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: documentation
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 709049
Blocks:
 
 
Reported: 2013-09-26 19:01 UTC by Juan R. Garcia Blanco
Modified: 2013-10-06 08:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Gtk::HeaderBar example (6.53 KB, patch)
2013-09-26 19:01 UTC, Juan R. Garcia Blanco
committed Details | Review
Gtk::HeaderBar example (6.97 KB, patch)
2013-09-28 09:52 UTC, Juan R. Garcia Blanco
none Details | Review
debug_titlebar_dispose.patch (2.19 KB, patch)
2013-09-29 20:43 UTC, Murray Cumming
none Details | Review
Gtk::HeaderBar::get_show_close_button constness (897 bytes, patch)
2013-10-03 19:20 UTC, Juan R. Garcia Blanco
none Details | Review

Description Juan R. Garcia Blanco 2013-09-26 19:01:15 UTC
Created attachment 255869 [details] [review]
Gtk::HeaderBar example

Here's a small demo of Gtk::HeaderBar.
Comment 1 Murray Cumming 2013-09-27 10:33:26 UTC
It looks fine. Could you try patching examples/Makefile.am too, please?
Comment 2 Juan R. Garcia Blanco 2013-09-28 09:52:23 UTC
Created attachment 255974 [details] [review]
Gtk::HeaderBar example

Sorry; damn, I didn't manage to get a hole in one yet.
Comment 3 Murray Cumming 2013-09-29 20:16:11 UTC
Thanks. I have pushed that, with a slight change to add some column and row spacing to the Gtk::Grid, and to actually mention the source files in the examples/Makefile.am file.

I also corrected your Author email address in the commit.


However, this example shows that there is a problem during destruction, when using set_titlebar():

(example:4666): Gtk-CRITICAL **: gtk_bin_remove: assertion 'priv->child == child' failed



gdb has this backtrace at that use of g_log():

Breakpoint 1, g_log (log_domain=0xb72a9586 "Gtk", log_level=G_LOG_LEVEL_CRITICAL, format=0xb6cd0c38 "%s: assertion '%s' failed")
    at gmessages.c:1024
1024	  va_start (args, format);
(gdb) bt
  • #0 g_log
    at gmessages.c line 1024
  • #1 g_return_if_fail_warning
    at gmessages.c line 1034
  • #2 gtk_bin_remove
    at gtkbin.c line 147
  • #3 Gtk::Container::on_remove
    at container.cc line 984
  • #4 Gtk::Container_Class::remove_callback_normal
    at container.cc line 124
  • #5 Gtk::Container_Class::remove_callback
    at container.cc line 159
  • #6 g_cclosure_marshal_VOID__OBJECT
  • #7 g_type_class_meta_marshal
    at gclosure.c line 970
  • #8 g_closure_invoke
    at gclosure.c line 777
  • #9 signal_emit_unlocked_R
    at gsignal.c line 3516
  • #10 g_signal_emit_valist
    at gsignal.c line 3330
  • #11 g_signal_emit
    at gsignal.c line 3386
  • #12 gtk_container_remove
    at gtkcontainer.c line 1572
  • #13 gtk_widget_dispose
    at gtkwidget.c line 11254
  • #14 Gtk::Widget_Class::dispose_vfunc_callback
    at widget.cc line 673
  • #15 g_object_run_dispose
    at gobject.c line 1067
  • #16 Gtk::Object::_release_c_instance
    at object.cc line 131
  • #17 Gtk::Object::destroy_
    at object.cc line 251
  • #18 Gtk::HeaderBar::~HeaderBar
  • #19 ExampleWindow::~ExampleWindow
    at book/headerbar/examplewindow.cc line 65
  • #20 main
    at book/headerbar/main.cc line 27


I put a g_warning in gtkbin.c and discovered that, for that call, the container (bin) is the Gtk::Window and the child is the Gtk::HeaderBar. So, something is making the GtkWindow try to remove the GtkHeaderBar as if it is the GtkWindow's only child, though that is actually the GtkGrid. gtk_bin_remove() is subsequently called correctly with child = to the GtkGrid.

I wonder why this (presumably) doesn't happen with the GTK+ C API. Maybe we need to make our Widget_Class::dispose_vfunc_callback() cleverer to avoid calling remove() on a header bar (not just a GtkHeaderBar) that has the widget as its parent. Maybe we could check if the widget is a GtkWindow and if the child == get_titlebar(). Unforunately there is not gtk_window_get_titlebar() yet. And I'd prefer something more generic anyway. Maybe a special case for GtkBin that checks if it's really the child.

Of course, if we don't remove it, we might need to do something else to make it (a widget being destroyed) no longer used by GTK+. If remove() can't do that then we'd need to unset the window's titlebar somehow. But gtk_window_set_titlebar() cannot yet take NULL to unset.
Comment 4 Juan R. Garcia Blanco 2013-09-29 20:23:24 UTC
I would have to check again, but I think the same problem is present in py-gobject.
Comment 5 Murray Cumming 2013-09-29 20:43:35 UTC
Created attachment 256038 [details] [review]
debug_titlebar_dispose.patch

This little hacky patch shows that it's not this part of the code that's leading to this warning. I had assumed that gdb (or compiler optimization) was just hiding it in the backtrace.

Maybe we need to try to reproduce it in C somehow.
Comment 6 Kjell Ahlstedt 2013-10-03 17:23:23 UTC
I have added an attachment with a patch to the gtk+ bug 709049.

I've got a question concerning Gtk::HeaderBar itself:
Why is get_show_close_button() not const?
Comment 7 Juan R. Garcia Blanco 2013-10-03 19:20:04 UTC
I guess no reason, that's my fault. I'm not sure if this is the right place, but I'll attach a patch here.
Comment 8 Juan R. Garcia Blanco 2013-10-03 19:20:46 UTC
Created attachment 256416 [details] [review]
Gtk::HeaderBar::get_show_close_button constness
Comment 9 Kjell Ahlstedt 2013-10-05 07:39:33 UTC
I have pushed your patch. I suppose this ABI breaking fix can be applied now,
since HeaderBar is not yet included in a stable release.

Both my question and your patch fit better in bug 708194, but never mind.
Comment 10 Kjell Ahlstedt 2013-10-06 08:58:34 UTC
Gtk+ bug 709049 has been fixed. With that fix, the HeaderBar example works as
expected. Closing this bug.