Gtk::Adjustment ignores initial value in constructor

[Vincent Levesque]

Binary package hint: libgtkmm-2.4-dev

Gtk::Adjustment seems to ignore the initial value it is given in its constructor. In the attached example, an adjustment is initialized to 1 and used with a SpinButton. When you run it though, the SpinButton has a value of 0 and get_value() returns 0. Using set_value() in the Window's constructor, on the other hand, correctly sets the initial value.

I was able to reproduce this bug on two computers running Ubuntu 6.10 but not on another one running Ubuntu 6.06. Using older versions of GCC doesn't seem to help.

See attached sources files.

[Daniel Holbach (dholbach)]

Thanks for your bug report. This looks valid. Murray, do you want me to forward it upstream?

On a brief glance:

Code in gtkmm 2.8.5:
Adjustment::Adjustment(double value,
                       double lower, double upper,
                       double step_increment, double page_increment,
                       double page_size)
:
  Glib::ObjectBase(0), //Mark this class as gtkmmproc-generated, rather than a custom class, to allow vfunc optimisations.
  Gtk::Object(Glib::ConstructParams(adjustment_class_.init(), (char*) 0))
{
  gobj()->lower = lower;
  gobj()->upper = upper;
  gobj()->step_increment = step_increment;
  gobj()->page_increment = page_increment;
  gobj()->page_size = page_size;
  changed();

  set_value(value);
}

void Adjustment::set_value(double value)
{
    gtk_adjustment_set_value(gobj(), value);

}

(For some reason set_value() doesn't use
  gobj()->value = value;
  changed();
as the other set_*() do. But maybe that's a red herring.)

----

Code in gtkmm 2.10.2:
Adjustment::Adjustment(double value, double lower, double upper, double step_increment, double page_increment, double page_si
ze)
:
  Glib::ObjectBase(0), //Mark this class as gtkmmproc-generated, rather than a custom class, to allow vfunc optimisations.
  Gtk::Object(Glib::ConstructParams(adjustment_class_.init(), "value", value, "lower", lower, "upper", upper, "step_increment
", step_increment, "page_increment", page_increment, "page_size", page_size, (char*) 0))
{
  }

[Murray Cumming (murrayc)]

There is discussion about this on the mailing list at the moment, with ongoing discussion. It's fine to submit this to the GNOME bugzilla. Thanks.

[Daniel Holbach (dholbach)]

Tracking upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=369335

[Daniel Holbach (dholbach)]

Fix committed to CVS: http://bugzilla.gnome.org/attachment.cgi?id=76192&action=view

[Burnce (burnce)]

The bug is still present in the most recent binary package for edgy (gtkmm 2.10.2).

It would be nice to have a package for a more recent, fixed version of gtkmm.
Both libglibmm-2.12.3 and lib-gtkmm-2.10.6 run fine when installed from feisty sources on an edgy installation:

$ sudo apt-get -b source -t unstable libglibmm-2.4-dev
$ sudo dpkg -i libglibmm-2.4-1c2a_2.12.3-0ubuntu1_i386.deb
$ sudo dpkg -i libglibmm-2.4-dev_2.12.3-0ubuntu1_i386.deb

$ sudo apt-get -b source -t unstable libgtkmm-2.4-dev
$ sudo dpkg -i libgtkmm-2.4-1c2a_2.10.6-0ubuntu1_i386.deb
$ sudo dpkg -i ;ibgtkmm-2.4-dev_2.10.6-0ubuntu1_i386.deb
$ sudo dpkg -i libgtkmm-2.4-doc_2.10.6-0ubuntu1_all.deb

Cheers,

Burnce

[Daniel Holbach (dholbach)]

Fixed in Feisty.

[Daniel Holbach (dholbach)]

Confirmed to be a problem. If somebody wants to work on this, https://wiki.ubuntu.com/StableReleaseUpdates is the process for that.

[Hew (hew)]

Ubuntu Edgy Eft is no longer supported, so a SRU will not be issued for this release. Marking Edgy as Won't Fix.