GNOME Bugzilla – Bug 168747
Values next to Scale widgets are not displayed with C++ wrappers
Last modified: 2005-03-03 12:20:53 UTC
Alt least three issues with Scale widgets are caused by this bug: - Values next to them are not displayed with C++ wrappers if requested (see also http://bugzilla.gnome.org/show_bug.cgi?id=154004) - format_value callback doesn't work in C++ - chaining of format_value callbacks with the C++/Python wrappers doesn't work This is caused by the way scale widgets format their value in order to display it. To format a value, a signal is emmited. single_string_accumulator (gtkscale.c:114) is used to decide whether more handlers need to be called. It evaluates the return value (the formatted text) of the previus handler for NULL and if not, goes on calling more handlers if available. This approach creates problems for wrappers that do not understand the concept of NULL for strings, which affects at least C++ and python. Because of this, it is not possible to chain python and C++ format_value handlers. There is no way to tell single_string_accumulator to go on because NULL can't be returned. For the C++ wrapper, the value is not displayed at all. It goes sth. like this: emit: expects gchar*, NULL value breaks Scale_Class::format_value_callback: returns gchar* class::on_format_value:: returns Glib::ustring calls C format_value method: returns gchar* Because the last C function is normally a placeholder which returns NULL which is converted to Glib::ustring("") which is converted back to a gchar*("") which is not NULL this breaks the system. The default action in _gtk_scale_format_value (gtkscale.c:636) is never executed because it expects NULL when nobody else has a better way to convert, which is not possible because single_string_accumulator returns an empty string, which it regards as a value, not NULL, although there is nobody handling it. To fix all this, single_string_accumulator should be changed to react to an empty string in the same way it does react to NULL.
Created attachment 38044 [details] [review] Fixes the problem in the way described above.
NULL is certainly in no way the same as "" in general. We can conceivably permit "" as a synonym for NULL if "" has no possible other value; is that really the case here? Is it right to say that the format_value callback can never result in the empty string? How is something like gtk_action_group_add_action_with_accel() bound in gtkmm? This not the only place in the GTK+ API where NULL strings appear. While certainly you can't expect all lanugages to have a NULL-equivalent string value, I don't think avoiding that concept is something we've done so far. (And Python? if returning None out of the callback is producing "" rather than NULL, that's just a language binding bug pure and simple.)
You're right, None in python has the desired effect. This leaves only the C++ bindings with these problems.
> We can conceivably permit "" as a synonym for NULL if "" has no possible other value; is that really the case here? I guess that is a worry. Some application might really be using it to show an empty displayed value, and this would make it show "0" instead. It's difficult, but we can hack together some hand-written code to do this in gtkmm instead. The meaning of a NULL return value in Scale::format_value should be documented. > How is something like gtk_action_group_add_action_with_accel() bound in gtkmm? I guess you are referring to the char* parameter that can be NULL. NULL parameters are no problem - we just add an extra method (a C++ method overload) that does not have that parameter. However, we have no way to mark a return string as invalid. We would need an extra "bool& ignore_result" parameter. We can't change our API now though.
I have fixed this in gtkmm. gtkmm will now never return an empty string, so you can never use this technique to show an empty string with gtkmm. When we can break ABI then we can add the extra output parameter. Thanks for the advice.