GNOME Bugzilla – Bug 643666
glade borks this file
Last modified: 2018-03-26 15:18:24 UTC
Load the file panels/power/power.ui from gnome-control-center git into glade, save it without making any changes, and quit. Result: a) glade has re-arranged the order of some of the objects in the file, resulting in an unnecessary diff. b) critically, combo boxes lose their model: <object class="GtkComboBoxText" id="combobox_sleep"> <property name="visible">True</property> - <property name="model">liststore_time</property> + <property name="can_focus">False</property> </object>
(All of glade, gtk, gnome-control-center git master as of today.)
(In reply to comment #0) > Load the file panels/power/power.ui from gnome-control-center git into glade, > save it without making any changes, and quit. > > Result: > a) glade has re-arranged the order of some of the objects in the file, > resulting in an unnecessary diff. If Glade did not generate the file originally, or if the file was generated by <= 3.6, there will (regretfully) be one time that the file gets reordered. If you save the file, load it, and save it again... is there any diffs between the new saved versions ? > > b) critically, combo boxes lose their model: > > <object class="GtkComboBoxText" id="combobox_sleep"> > <property name="visible">True</property> > - <property name="model">liststore_time</property> > + <property name="can_focus">False</property> > </object> GtkComboBoxText creates and maintains it's own model... Glade should not allow users to set their own model I think, that might work in some cases but would be error prone if in any case the model given to the GtkComboBoxText does not have column 0 as a G_TYPE_STRING column. I think it's best all around that if the user wants something more complex than a simple GtkComboBoxText, they should use GtkComboBox and define a liststore & cell renderers for it.
(In reply to comment #2) > > a) glade has re-arranged the order of some of the objects in the file, > > resulting in an unnecessary diff. > > If Glade did not generate the file originally, or if the file was > generated by <= 3.6, there will (regretfully) be one time that the > file gets reordered. > > If you save the file, load it, and save it again... is there any > diffs between the new saved versions ? No more diff. > > b) critically, combo boxes lose their model: > > > > <object class="GtkComboBoxText" id="combobox_sleep"> > > <property name="visible">True</property> > > - <property name="model">liststore_time</property> > > + <property name="can_focus">False</property> > > </object> > > GtkComboBoxText creates and maintains it's own model... Glade should > not allow users to set their own model I think, that might work in > some cases but would be error prone if in any case the model given > to the GtkComboBoxText does not have column 0 as a G_TYPE_STRING > column. > > I think it's best all around that if the user wants something more > complex than a simple GtkComboBoxText, they should use GtkComboBox > and define a liststore & cell renderers for it. The point is that the .ui file _has_ the combo with that model, and editing the file breaks it. That must never happen.
(In reply to comment #3) > (In reply to comment #2) [...] > > The point is that the .ui file _has_ the combo with that model, and editing the > file breaks it. That must never happen. Well, agreeing here that it would be nice if Glade supported every construct of a .ui file by definition but this is simply not the case (hence the main reason why having kept gtk-builder-convert script around so long has been mostly a cause of grief for Glade, since much of the time, files converted with that script become broken in Glade...). So basically, if the file has a :model property set for a GtkComboBoxText, it's fairly safe to say the file was not generated by Glade, and thus is regretfully not completely supported. Support for files not generated by Glade, or files generated by Glade at another location where some plugins were present, but are not present at the current location... is partially tracked in bug 376628 (this covers unrecognized widget types being swallowed up by Glade, unrecognized or disabled properties are another issue along the same lines). Besides all that, is there a specific reason that you need to have a GtkComboBoxText that has an assigned "model" ? Can you live with using a GtkComboBox and giving it a cell renderer in that case ?
(In reply to comment #4) > Besides all that, is there a specific reason that you need to have a > GtkComboBoxText that has an assigned "model" ? Because it needs not only the text column but also a value column. > Can you live with using a GtkComboBox and giving it a cell renderer > in that case ? That's too complicated, IMHO. > agreeing here that it would be nice if Glade supported every construct of > a .ui file by definition but this is simply not the case (hence the main > reason why having kept gtk-builder-convert script around so long has been > mostly a cause of grief for Glade, since much of the time, files converted > with that script become broken in Glade...). I'd have thought that gtkbuilder defines what's valid in the format, and glade lets you edit it (at the very least keeping stuff it doesn't know about in the file when re-saving), rather than the inverse...
(In reply to comment #5) > (In reply to comment #4) > > Besides all that, is there a specific reason that you need to have a > > GtkComboBoxText that has an assigned "model" ? > > Because it needs not only the text column but also a value column. The extra column is esp. important if you want to bind it use it as "id-column" and bind it to a gsetting key.
(In reply to comment #5) [...] > > I'd have thought that gtkbuilder defines what's valid in the format, and glade > lets you edit it (at the very least keeping stuff it doesn't know about in the > file when re-saving), rather than the inverse... That has thus far never been the case (actually the first libglade was created to parse .glade files that were never intended for libglade's usage). Perhaps if I was a "whole team of developers" that would bring us closer to an ideal tool. However, there are always things that will be "valid input" for GtkBuilder but do not make sense to allow the user to do. In this instance, allowing the user to define a liststore for a GtkComboBoxText is error prone, since the user can define a liststore that will break the combo. It could be done but should require some restraints on what kind of liststore the user is allowed to create (i.e. the liststore must have column 0 as a G_TYPE_STRING). Besides, you do know that Glade allows you to add cell renderers to your GtkComboBox and setup attributes right ? (just select a combo box and hit the "Edit" toolbutton in the toolbar, or right-click on the combo and select the "Edit..." menu item).
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Besides all that, is there a specific reason that you need to have a > > > GtkComboBoxText that has an assigned "model" ? > > > > Because it needs not only the text column but also a value column. > > The extra column is esp. important if you want to bind it use it as "id-column" > and bind it to a gsetting key. For that case, I think we should allow the user to specify that in the "Items" editor and still not require any additional "model" (its already a part of the GtkComboBoxText api, see gtk_combo_box_text_append()). I added the GtkComboBoxText custom parser to parse the items, it could be extended to optionally include an "id" attribute for each text, and then the Items editor could let you save the "id" along with every text item. Admittedly I fell 2 steps short of implementing that portion.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/82.