GNOME Bugzilla – Bug 422823
widgets jump around in glade file
Last modified: 2009-03-01 22:47:16 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.
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".
Created attachment 85660 [details] .glade file with a paned widget and two children
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
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.
364215 closed and fixes this bug, do widgets still jump around, is this bug still valid ?
Yes, still happens, with the steps from comment 0.
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.
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.
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.
*** Bug 402941 has been marked as a duplicate of this bug. ***
*** Bug 466607 has been marked as a duplicate of this bug. ***
(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.
*** Bug 535008 has been marked as a duplicate of this bug. ***
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.
Created attachment 111921 [details] [review] Fixing widgets
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.
(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.
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)
Committed Pavel's patch regarding GtkTable child ordering, and fixed toplevel ordering myself, in svn - closing this bug finally.
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?
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).