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 154004 - Values above VScale widgets from a Glade UI disappear when the widget is used
Values above VScale widgets from a Glade UI disappear when the widget is used
Status: RESOLVED FIXED
Product: libglademm
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 168747
Blocks:
 
 
Reported: 2004-09-28 21:12 UTC by Lars Luthman
Modified: 2011-01-16 23:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test_c.cpp (371 bytes, text/x-c++src)
2004-09-29 20:13 UTC, Murray Cumming
Details
test.cpp (280 bytes, text/x-c++src)
2004-09-29 20:14 UTC, Murray Cumming
Details
test.glade (7.96 KB, application/x-glade)
2004-09-29 20:14 UTC, Murray Cumming
Details

Description Lars Luthman 2004-09-28 21:12:43 UTC
Download the program and glade files from http://www.d.kth.se/~d00-llu/glade/
(they are very small).

Compile test.cpp with the command 'g++ `pkg-config --libs --cflags
libglademm-2.4` test.cpp' and run the program. Try to move some of the scales.
The values on top of the scales will disappear (at least they did for me with
libglademm2.4_1-2.4.1-2mdk, gcc-c++-3.4.1-3mdk, libgtkmm2.4_1-2.4.5-1mdk).
Comment 1 Murray Cumming 2004-09-29 20:12:31 UTC
This does seem to be specific to the C++ wrapper. I'm attaching a C test case as
well as the C++ one.
Comment 2 Murray Cumming 2004-09-29 20:13:32 UTC
Created attachment 32083 [details]
test_c.cpp
Comment 3 Murray Cumming 2004-09-29 20:14:03 UTC
Created attachment 32084 [details]
test.cpp
Comment 4 Murray Cumming 2004-09-29 20:14:32 UTC
Created attachment 32085 [details]
test.glade
Comment 5 Michael Hofmann 2005-02-24 10:19:16 UTC
I got it fixed for C++. There the bug is caused by the C++ wrapper using
Glib::ustrings, which do not understand the concept of NULL. 

To format a value, a signal is emmited. single_string_accumulator
(gtkscale.c:114) is used to decide whether more handler 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 works fine as long as there is no C++ wrapper around. With the wrapper, it
goes sth. like this (I'm a little bit confused by the code of who calls who, so
it may be slightly different):

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 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. 

This also breaks overwriting the on_format_value method in the wrapper, because
it gets never executed, because single_string_accumulator breaks after it got an
empty string from the default handler.

A first patch looks may look like this:
--- gtkscale.c.orig     2004-08-09 19:59:52.000000000 +0300
+++ gtkscale.c  2005-02-24 11:50:05.000000000 +0200
@@ -121,6 +121,8 @@
   const gchar *str;

   str = g_value_get_string (handler_return);
+  if (str != NULL && str[0] == 0)
+    str = NULL;
   g_value_set_string (return_accu, str);
   continue_emission = str == NULL;

This patches single_string_accumulator to react on empty strings in the same way
 like on NULL. I don't know whether other wrappers are affected, maybe this
should be handled there.

Sorry for the confusing text, I'm not used to programming raw Gtk+.
Comment 6 Murray Cumming 2005-02-28 09:56:31 UTC
This is good detective work. I think you should submit a GTK+ bug. I suggest
using g_strlen() instead of str[0], though C isn't my thing. And your patch
should also add a comment saying why it's necessary.
Comment 7 Michael Hofmann 2005-02-28 12:01:57 UTC
GTK+ bug: http://bugzilla.gnome.org/show_bug.cgi?id=168747
Comment 8 Michael Hofmann 2005-02-28 17:31:57 UTC
Hmm, I first thought that python is also affected, but Owen Taylor proved me
wrong on this.

Maybe this could be changed in the bindings by modifying the signal to sth like
  bool format_value (const int value, Glib::ustring& result) 

I don't think the callback was used in any gtkmm program yet.
Comment 9 Murray Cumming 2005-03-03 12:22:44 UTC
In scale.hg, I have prevented format_value from ever returning an empty string
to GTK+. This is in HEAD (gtkmm 2.5/2.6 only). Thanks for the hard work. Please
reopen if this doesn't fix it.