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 422823 - widgets jump around in glade file
widgets jump around in glade file
Status: RESOLVED FIXED
Product: glade
Classification: Applications
Component: general
git master
Other All
: Normal normal
: 3.4.0
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
: 402941 466607 535008 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-03-25 22:43 UTC by Christian Persch
Modified: 2009-03-01 22:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
.glade file with a paned widget and two children (1.66 KB, application/x-glade)
2007-04-01 15:16 UTC, Vincent Geddes
  Details
.glade file test case for mutated data (219.33 KB, application/x-glade)
2007-04-27 22:11 UTC, Jeff Westerinen
  Details
Fixing widgets (2.20 KB, patch)
2008-06-01 23:32 UTC, Pavel Kostyuchenko
none Details | Review

Description Christian Persch 2007-03-25 22:43:00 UTC
Steps:
0) Open totem's totem/data/totem.glade file in glade-3, save, close
1) Copy the newly converted totem.glade to test.glade
2) Open totem.glade in glade-3 again, save, close
3) diff -u test.glade totem.glade
4) Repeat steps 2 and 3

Expected results:
No diff in steps 3 and 4

Actual results:
Nontrivial differences in step 3 !
In step 4, the diff to the totem.glade from step 3 is nontrivial, while the diff to test.glade is ALMOST but NOT COMPLETELY empty!

This is a) extremely bad for getting minimal diffs, and b) the nonempty diff in step 4 indicates a dataloss/datamutation problem somewhere.


glade-3 svn trunk, totem.glade from totem svn trunk.
Comment 1 Vincent Geddes 2007-04-01 15:15:12 UTC
Yep, there is certainly some data loss with the "resize" child property of GtkPaned widgets. The property value gets saved correctly to the glade file, but it's value is lost when the glade file is loaded again.

Steps:
0) Open paned.glade (attached) in Glade
1) Set the "resize" property of label1 and label2 to "Yes".
2) Save and close paned.glade
3) Open paned.glade again

Expected results:
The "resize" property of label1 and label2 set to "Yes"

Actual results:
The "resize" property of label1 is set to "No".
Comment 2 Vincent Geddes 2007-04-01 15:16:40 UTC
Created attachment 85660 [details]
.glade file with a paned widget and two children
Comment 3 Jeff Westerinen 2007-04-27 22:11:25 UTC
Created attachment 87171 [details]
.glade file test case for mutated data

I am seeing a similar problem, but this attached .glade file was created with Glade3 v 3.0.x.  This implies that there may be a regression introduced between 3.0.x to 3.2.0.  Use the same procedure described above to reproduce the problem, i.e. only need to read in the file then write it out again, and the diff will be non-trivial.  The following problems are most prevalent:
 - packing property "top_attach" and "bottom_attach" are being changed
 - GtkTextView ID is getting changed
 - GtkButon "response_id" getting negated, e.g. from -9 to 9
Comment 4 Jeff Westerinen 2007-05-02 20:31:01 UTC
There exists a bug, 434207, that describes the negated response ID described above.  It will be fixed in 3.2.1.  At this point, it is the top- and bottom-attach packing properties that are the problem.
Comment 5 Tristan Van Berkom 2007-05-09 20:45:39 UTC
364215 closed and fixes this bug, do widgets still jump around, is this
bug still valid ?
Comment 6 Christian Persch 2007-05-09 20:59:31 UTC
Yes, still happens, with the steps from comment 0.
Comment 7 Jeff Westerinen 2007-05-09 21:44:36 UTC
I have identified a fix for the behavior described in Comment 1, which seems to be a distillation of the problem in Comment 0.  With respect to my Comment 3, it turns out that the only problem was with negated button response IDs, and that problem has been fixed, so, I am retracting that comment and my test case.  Are there problems in Comment 0 beyond those more succinctly described in Comment 1?  If not, once I've contributed my fix, we can close this bug.
Comment 8 Jeff Westerinen 2007-05-10 17:40:37 UTC
My apologies for messing this bug report up.  I didn't notice that Tristan had referenced another bug the fix for which is what I was referring to in my comment 7.  I have nothing left to add.
Comment 9 Tristan Van Berkom 2007-05-16 19:58:15 UTC
Ok I was confused about this bug, I thought that widgets were jumping around
in the UI, but its the same UI saved slightly differently.

This is not going to be addressed in the core.

We have refactoring plans to allow plugin backends to save widgets/properties
in custom ways (this will be nescissary to support GtkBuilder), at that point
we can special case GtkTable children to be saved in a specific order.

Since the other related bugs are fixed, and glade file diffability
is not a major priority, I am lowering the priority of this bug back
to normal.
Comment 10 Vincent Geddes 2007-06-17 01:25:28 UTC
*** Bug 402941 has been marked as a duplicate of this bug. ***
Comment 11 Tristan Van Berkom 2007-08-14 14:31:43 UTC
*** Bug 466607 has been marked as a duplicate of this bug. ***
Comment 12 Mardy 2007-08-20 10:18:12 UTC
(In reply to comment #9)
> Since the other related bugs are fixed, and glade file diffability
> is not a major priority, I am lowering the priority of this bug back
> to normal.

Diffability involves almost all SCM systems; it's hard to track the history of one file if parts of it are moving here and there with no apparent logic.
I agree that supporting GtkBuilder is of higher priority, but I hope that this issue will be taken into account when implementing it.
Comment 13 Juan Pablo Ugarte 2008-05-27 17:42:12 UTC
*** Bug 535008 has been marked as a duplicate of this bug. ***
Comment 14 Pavel Kostyuchenko 2008-06-01 23:31:53 UTC
I will attach a patch that fixes jumping widgets in the next post. But is there any legible order for properties? Seems like they can jump too.
Comment 15 Pavel Kostyuchenko 2008-06-01 23:32:42 UTC
Created attachment 111921 [details] [review]
Fixing widgets
Comment 16 Tristan Van Berkom 2008-08-09 22:27:05 UTC
Wow is was that really all that needs to be done ?

I think properties are usually in a consistant order
(we even make a feeble attempt at sorting them in the editor
by way of the "weight" property in the catalog) can you 
reproduce properties jumping around in widgets with the 
above patch applied ?

I'll try this and probably apply when I boot up into
my working environment... would be nice if we could close
this issue.
Comment 17 Pavel Kostyuchenko 2008-08-10 09:49:45 UTC
(In reply to comment #16)
> I think properties are usually in a consistant order
> (we even make a feeble attempt at sorting them in the editor
> by way of the "weight" property in the catalog) can you 
> reproduce properties jumping around in widgets with the 
> above patch applied ?

Maybe I used a glade file which was saved by another version of glade or modified manually. Properties order isn't changed when I use the only one version of glade.
Comment 18 Yevgen Muntyan 2008-09-08 06:32:09 UTC
Steps to reproduce ("widgets jump around", not properties):

1) Create a new file;
2) create a window (it's named "window1");
3) create a window again (it's named "window2");
4) rename window1 to window3;
5) save the file; make a copy of it to compare to the next saved copy;
6) close, reopen, save.

Result - first file has window2, window3; second one has window3, window2 (hash table order? doesn't seem some logical one)
Comment 19 Tristan Van Berkom 2008-09-17 18:22:53 UTC
Committed Pavel's patch regarding GtkTable child ordering, and
fixed toplevel ordering myself, in svn - closing this bug finally.
Comment 20 Andreas Köhler 2009-03-01 19:57:12 UTC
Two formal questions:
(1) The patch status is committed?
(2) The target milestone does not reflect the version this was fixed, right?  Is that Glade 3.5.3?
Comment 21 Tristan Van Berkom 2009-03-01 22:47:16 UTC
Couldnt tell ya off hand, but I'm sure its in at least 3.5.4 (cause I know
I did that before introducing builder).

Its ofcourse all in the changelog (I note all the releases and commits
in there, usually bug numbers are also included in the changelog).