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 702742 - Glade serializes the "visible" and "sensitive" properties of a GtkWidget with a "related-action" set.
Glade serializes the "visible" and "sensitive" properties of a GtkWidget with...
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: user interface
3.15.x
Other Windows
: Normal normal
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-20 12:48 UTC by Domenico Ferrari
Modified: 2018-03-26 15:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (4.25 KB, application/octet-stream)
2013-06-21 09:05 UTC, Domenico Ferrari
Details

Description Domenico Ferrari 2013-06-20 12:48:48 UTC
When a GtkButton has a related action, visible and sensitive properties are always disabled regardless of use-action-appearance is set to False. They become editable only when there's no related action.
Comment 1 Tristan Van Berkom 2013-06-20 13:12:28 UTC
This is intended, and there should also be a tooltip on the
insensitive properties explaining why.

Visibility and Sensitivity are not appearance related properties,
they are *always* controlled by the related action.
Comment 2 Domenico Ferrari 2013-06-20 15:22:58 UTC
The doc says:
 Properties that are always mirrored by proxies are "sensitive" and "visible"

so Glade is right.

But I have
  <object class="GtkAction" id="Act">
    <property name="visible">False</property>
  </object>
...
<object class="GtkCheckButton" id="Btn">
    <property name="related_action">Act</property>

The CheckButton is visible at run time (not in glade). I have to put
  <property name="visible">False</property>
for the button too to make it hidden
Comment 3 Tristan Van Berkom 2013-06-20 16:54:40 UTC
Hi,
   Can you let us know what version of GTK+ you are using ?

This would certainly be a GTK+ bug, so we should get the version
and move this bug to GTK+ produce.

It would be helpful also if you could provide any other information,
such as... does this only happen when initially loading the Glade file ?

If you grab the related action and set it's visibility to TRUE and
then FALSE again, does the button stay visible ?
Comment 4 Domenico Ferrari 2013-06-21 09:05:10 UTC
Created attachment 247413 [details]
test case

When there's a related action, Glade save always the visible properties of the object, not the Action, with value True resulting in a visible button. If I remove the property in the GtkButton object, editing the glade file by hand, the behavior is correct.
Setting the GtkAction property by code the button is correctly hidden.
So I can't say if it's a Glade or a Gtk bug.
Comment 5 Tristan Van Berkom 2013-06-21 10:15:17 UTC
Interesting, it looks like strictly speaking, a GTK+ bug.

But a bug that we can also workaround in Glade.

I'm reopening this as a Glade bug for now, we should be able to provide
a decent workaround for this.


Proposed solution(s):

  a.) Ensure that widget properties that are controlled by a related
      action are not saved (appearance related properties should not
      be saved if use-action-appearance is TRUE)

  b.) Just ensure that the 'related-action' property is serialized 'last'


Option 'a' is surely better than 'b', but 'b' will probably be easier
to implement and cause less complexity in Glade's core.

Strictly speaking, it could be a GTK+ bug that calling gtk_widget_show()
on a widget that is a proxy of an invisible GtkAction, but I think it's
a rather unlikely situation to handle for GTK+.
Comment 6 Domenico Ferrari 2013-06-21 12:43:44 UTC
I've filed a bug in GTK+
Comment 7 GNOME Infrastructure Team 2018-03-26 15:30:40 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/133.