GNOME Bugzilla – Bug 466607
UI components are not serialized in the same order each time you hit 'save'
Last modified: 2007-08-14 20:21:38 UTC
Please describe the problem: UI is not serialized to same xml each time you hit 'save' and the SCM think (for a gook reason) that the glade file has local modification. Steps to reproduce: Just load and save a project xml with a table of labels and images, e.g: http://git.codethink.co.uk/?p=gupnp-tools;a=blob_plain;f=src/gupnp-universal-cp.glade;hb=HEAD Actual results: the saved xml is not the same as the one loaded. Expected results: the saved xml should be exactly the same as the one loaded. Does this happen every time? Yes Other information:
Glade only tries to save an xml that is an honest representation of the objects and properties in a glade file. Glade makes no guarantee about what order properties or objects will saved in. *** This bug has been marked as a duplicate of 422823 ***
(In reply to comment #1) > > Glade makes no guarantee about what order properties or objects > will saved in. How come i didn't encounter this problem until i (actually debian testing) switched to glade 3? Moreover, how am i supposed to manage the glade file in an SCM?
(In reply to comment #2) > (In reply to comment #1) > > > > Glade makes no guarantee about what order properties or objects > > will saved in. > > How come i didn't encounter this problem until i (actually debian testing) > switched to glade 3? glade 2 is a completely different source base. > Moreover, how am i supposed to manage the glade file in an > SCM? This is more of a sarcastic remark than a question, if it were a question though, the answer would be just checkout/edit/commit/tag as you would any other file.
(In reply to comment #3) > > How come i didn't encounter this problem until i (actually debian testing) > > switched to glade 3? > > glade 2 is a completely different source base. I know that, you can re-write glade as many times as you people like but that shouldn't result in dropping good features that people are used to. > > Moreover, how am i supposed to manage the glade file in an > > SCM? > > This is more of a sarcastic remark than a question, if it were > a question though, the answer would be just checkout/edit/commit/tag > as you would any other file. I am sorry if it sounded like that but it wasn't. There are two problems: 1. Each time i load the file and close it without actually making any changes, i'll have to revert it (just a waste of developer time). 2. Each time I make changes and would want to commit it, some unnecessary changes will also be accompanied with these changes and will make the diff hard to read. Thanks to git 1.5 that provides the way to avoid this but i'll have to make extra efforts and not everyone uses git or darcs.
(In reply to comment #4) > (In reply to comment #3) > > > How come i didn't encounter this problem until i (actually debian testing) > > > switched to glade 3? > > > > glade 2 is a completely different source base. > > I know that, you can re-write glade as many times as you people like but that > shouldn't result in dropping good features that people are used to. I suppose this was not a sarcastic remark either ? > > > Moreover, how am i supposed to manage the glade file in an > > > SCM? > > > > This is more of a sarcastic remark than a question, if it were > > a question though, the answer would be just checkout/edit/commit/tag > > as you would any other file. > > I am sorry if it sounded like that but it wasn't. There are two problems: > > 1. Each time i load the file and close it without actually making any changes, > i'll have to revert it (just a waste of developer time). > > 2. Each time I make changes and would want to commit it, some unnecessary > changes will also be accompanied with these changes and will make the diff hard > to read. Thanks to git 1.5 that provides the way to avoid this but i'll have to > make extra efforts and not everyone uses git or darcs. > Making glade files diff nicely right now is just not a priority.
> > I know that, you can re-write glade as many times as you people like but that > > shouldn't result in dropping good features that people are used to. > > I suppose this was not a sarcastic remark either ? It was a remark, alright but no sarcasm. > Making glade files diff nicely right now is just not a priority. I can understand that but in previous comments from you, it sounded like you don't concider it a problem at all.
(In reply to comment #6) [...] > > Making glade files diff nicely right now is just not a priority. > > I can understand that but in previous comments from you, it sounded like you > don't concider it a problem at all. > Widgets will always be saved in the order in which they are returned from the backend, in most cases this order is dictated by gtk_container_get_children() (or some varient of the same), for some cases (i.e. bug 364078) it will be important for the backend to return widgets in a specific order (in those cases real bugs result from the ordering). I really dont consider it a problem that glade files arent diffable, as specially when weighed against the complexity needed in the core to accomadate such a low priority enhancement. I really do consider it a waste of my time to go deeply in depth on this bug report and explain at length our reasoning on this issue (I've spent upwards to an hour of distraction by now, I could have been integrating the icon chooser dialog instead...) when I can simply say "not gonna happen", "sorry this feature is not a requirement for glade"
Tristan, I think you are overstating the complexity needed to implement this. For example, you could simply sort on name of widget, and inside widget on name of attribute. I agree with Zeeshan that diffability is important, and this would definately be a reason for me not to move to glade-3. After I change layouts (for example pixel spacings) in glade, I prefer to analyze my local diff like any other to make sure I didn't do anything stupid. Zeeshan, why don't you just provide a patch that does an ordering ? I'm sure it would get accepted if done right.
Sure, diffability was never a feature that we intended to implement, if it can be done without being overly complex and you feel like its worth your energy to address it, be my guest. if you want to continue this dialog constructively, its bug 422823.