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 643666 - glade borks this file
glade borks this file
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: general
unspecified
Other Linux
: Normal critical
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-02 13:48 UTC by Christian Persch
Modified: 2018-03-26 15:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2011-03-02 13:48:22 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>
Comment 1 Christian Persch 2011-03-02 13:49:08 UTC
(All of glade, gtk, gnome-control-center git master as of today.)
Comment 2 Tristan Van Berkom 2011-03-02 17:14:31 UTC
(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.
Comment 3 Christian Persch 2011-03-02 17:37:55 UTC
(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.
Comment 4 Tristan Van Berkom 2011-03-02 23:06:59 UTC
(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 ?
Comment 5 Christian Persch 2011-03-02 23:33:23 UTC
(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...
Comment 6 Christian Persch 2011-03-02 23:51:31 UTC
(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.
Comment 7 Tristan Van Berkom 2011-03-02 23:55:20 UTC
(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).
Comment 8 Tristan Van Berkom 2011-03-03 00:00:37 UTC
(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.
Comment 9 GNOME Infrastructure Team 2018-03-26 15:18:24 UTC
-- 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.