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 585662 - GtkAdjustment's value depends on the order of property tags
GtkAdjustment's value depends on the order of property tags
Status: RESOLVED DUPLICATE of bug 578484
Product: gtk+
Classification: Platform
Component: Class: GtkBuilder
2.16.x
Other All
: Normal normal
: ---
Assigned To: GtkBuilder maintainers
GtkBuilder maintainers
Depends on:
Blocks:
 
 
Reported: 2009-06-13 16:29 UTC by Ivan Baldin
Modified: 2009-07-21 11:50 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Ivan Baldin 2009-06-13 16:29:07 UTC
Please describe the problem:
When you define GtkAdjustment object in your interface file and "value" property tag is put before "upper", it gets reset to 0.
It could be just a glade3 bug but order sensitivity feels rather unintuitive in this case.

Steps to reproduce:
The easiest way is to write a small python script.

import gtk

ui = """
<interface>
    <object class="GtkAdjustment" id="adj-1">
        <property name="value">27</property>
        <property name="upper">100</property>
    </object>

    <object class="GtkAdjustment" id="adj-2">
        <property name="upper">100</property>
        <property name="value">27</property>
    </object>
</interface>"""

builder = gtk.Builder()
builder.add_from_string(ui)

for name in ("adj-1", "adj-2"):
    adj = builder.get_object(name)
    print "%s: upper=%.1f, value=%.1f" % (name, adj.upper, adj.value)


Actual results:
adj-1: upper=100.0, value=0.0
adj-2: upper=100.0, value=27.0


Expected results:
adj-1: upper=100.0, value=27.0
adj-2: upper=100.0, value=27.0

Does this happen every time?
yes

Other information:
Comment 1 Pietro Battiston 2009-07-21 11:50:55 UTC
It is the opinion of both gtkBuilder and glade developers that order sensitivity is indeed the key (or at least the current solution).

*** This bug has been marked as a duplicate of 578484 ***