Kristian Rietveld <kristian planet nl> writes:
> Hi All,
>
> Here's another snapshot of the new GtkComboBox. There are many many
> changes, see the README in the tarball.
>
> When I was working on it with my CVS glib/GTK+ of October 29, everything
> worked fine. But I just updated my CVS glib/pango/GTK+ and now there are
> problems with the signal handling:
>
> GLib-Object-ERROR **: gsignal.c:928:g_signal_handler_block(): handler
> block_count overflow, please report occourance circumstances to
> gtk-devel-list gnome org
> aborting...
> Trace/breakpoint trap (core dumped)
Yes, this is definitely a GObject bug - block_by_func internally calls:
====================
static guint
signal_handlers_foreach_matched (gpointer instance,
GSignalMatchType mask,
guint signal_id,
GQuark detail,
GClosure *closure,
gpointer func,
gpointer data,
void (*callback) (gpointer instance,
guint handler_id))
{
Handler *handler;
guint n_handlers = 0;
handler = handler_find (instance, mask, signal_id, detail, closure, func, data);
while (handler && handler->id)
{
n_handlers++;
G_UNLOCK (g_signal_mutex);
callback (instance, handler->id);
G_LOCK (g_signal_mutex);
/* need constant relookups due to callback */
handler = handler_find (instance, mask, signal_id, detail, closure, func, data);
}
return n_handlers;
}
====================
Which does reasonably well when @callback is a function that removes
the handler, but rather badly when @callback leaves the handler
in place.
If you want to work around this, a perhaps better way to handle
this anyways is to keep track of the state of the toggle button
yourself and then look at
GTK_TOGGLE_BUTTON (toggle_button)->active
in the ::toggled callback. When you change the toggle yourself,
set your state member before calling gtk_toggle_button_set_active(),
and then you'll know that there is nothing to do in the ::toggled
callback.
> In the lines 546 and 552 of gtkcombobox.c only one signal is being blocked
> and unblocked. Another problem is the popup window of the GtkComboBoxGrid
> which doesn't show up right anymore (see the test program).
Nothing to do with GTK+ changes, as far as I can see - the problem
is that you are positioning the popup menu at the bottom of the
widgets requisition, not at the bottom of the child widgets, and
you are allocting a bunch of extraneous vertical space; here's
a modified gtk_combo_box_size_request that should work better.
(The basic problem was that you were adding the height
of the arrow to the the height of the display widget to get
the height of the requisition, instead of taking the max.
====
GtkComboBox *cbox;
GtkRequisition child_requisition;
g_return_if_fail (widget != NULL);
g_return_if_fail (GTK_IS_COMBO_BOX (widget));
g_return_if_fail (requisition != NULL);
cbox = GTK_COMBO_BOX (widget);
requisition->width = 0;
requisition->height = 0;
if (cbox->display_widget)
{
gtk_widget_size_request (cbox->display_widget, &child_requisition);
requisition->width += child_requisition.width;
requisition->height = MAX (requisition->height, child_requisition.height);
}
gtk_widget_size_request (cbox->arrow_button, &child_requisition);
requisition->width += child_requisition.width;
requisition->height = MAX (requisition->height, child_requisition.height);
requisition->width += GTK_CONTAINER (cbox)->border_width * 2;
requisition->height += GTK_CONTAINER (cbox)->border_width * 2;
}
====
Though note that the positioning of the popup still needs to be
adjusted for container->border_width.
> Because everything worked fine with my earlier CVS glib/GTK+, I _hope_
> that all these crashed are caused by some bugs and not by my code...
> That's why I decided to post this preview despite of the crashes...
Thanks - the problem with the signals was definitely something
that needed to get caught.
Owen