Re: Focus vs Sensitivity

[David NeÄas <yeti physics muni cz>]

On Fri, Dec 21, 2012 at 07:16:07PM -0200, Ivan Baldo wrote:
> What happens is that the Tab handler runs before the value-changed
> handler

This is the wrong view what happens.  The adjustment value is not
updated during user's editing of the entry.  If the spin button is not
set to "numeric" its entry can contain any text during the editing
(whereas setting "numeric" ensures the entry contents always parses as a
number, making impossible to enter numbers in the scientific format, for
instance).  The value is updated when editing finishes, for which one
possibility is that the entry loses focus.  So *first* the focus leaves
the entry then *in consequence* the adjustment value is updated.

However, this does not seem to be entirely the core of your problem.
The CRITICAL errors are printed becuase in gtk_window_real_set_focus()
this:

    if (priv->has_focus)
        do_focus_change (priv->focus_widget, TRUE);

    g_object_notify (G_OBJECT (priv->focus_widget), "is-focus");

assumes that do_focus_change() cannot make priv->focus_widget become
NULL.  IMO there may be sane use cases when this can occur (like yours)
so I would try to report a bug.

How to work around it?  Instead of connecting to "value-changed" monitor
all changes to the entry text:

    g_signal_connect(spin_button, "changed", G_CALLBACK(spin_entry_changed), spin_button2);

    ...

    static void
    spin_entry_changed(GtkEntry *entry, GtkWidget *target)
    {
        gtk_widget_set_sensitive(target, g_strtod(gtk_entry_get_text(entry), NULL) != 0);
    }

This will *also* make the second entry insensitive when the content of
the first does not parse as a number at all (which is likely a good
thing though perhaps not).

Regards,

Yeti