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 668203 - Prevent unreasonable GtkApplication property changes
Prevent unreasonable GtkApplication property changes
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Class: GtkApplication
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-01-18 18:42 UTC by Allison Karlitskaya (desrt)
Modified: 2018-02-10 04:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add restrictions to GtkApplication (4.01 KB, patch)
2012-01-18 18:42 UTC, Allison Karlitskaya (desrt)
reviewed Details | Review
Don't call set_application() in gtk_window_realize (809 bytes, patch)
2012-01-18 18:42 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Allison Karlitskaya (desrt) 2012-01-18 18:42:08 UTC
We should restrict the time at which certain properties can change on
applications and application windows:

 - it should not be possible to change the application associated with a
   window after it has been realized

 - it should not be possible to call set_app_menu() or set_menubar()
   after windows have been created and associated with the app
Comment 1 Allison Karlitskaya (desrt) 2012-01-18 18:42:10 UTC
Created attachment 205557 [details] [review]
Add restrictions to GtkApplication

- 'application' property cannot be changed on realized windows

 - 'app-menu' and 'menubar' property cannot be changed if the
   application has windows associated with it (but the content of the
   menus themselves can change).
Comment 2 Allison Karlitskaya (desrt) 2012-01-18 18:42:13 UTC
Created attachment 205558 [details] [review]
Don't call set_application() in gtk_window_realize

This call has no effect and with the newly-added restrictions it's
violating the set-application-after-realized rule.
Comment 3 Colin Walters 2012-01-18 19:38:22 UTC
Review of attachment 205558 [details] [review]:

Makes sense.
Comment 4 Allison Karlitskaya (desrt) 2012-01-18 19:53:25 UTC
Comment on attachment 205558 [details] [review]
Don't call set_application() in gtk_window_realize

Attachment 205558 [details] pushed as ba9546f - Don't call set_application() in gtk_window_realize
Comment 5 Matthias Clasen 2012-01-19 18:46:18 UTC
Review of attachment 205557 [details] [review]:

All these restrictions look fine to me - have you spot-checked any GtkApplication users for violations ?

::: gtk/gtkapplication.c
@@ +1046,3 @@
+ * The application menu must be set before any windows are associated
+ * with the application.  An ideal place to do this is from the
+ * 'startup' virtual function (or signal) or #GApplication.

Could also add an xref to the bloatpad example here, since we do it correctly there now.
Comment 6 Christophe Fergeau 2012-01-24 14:48:39 UTC
 < teuf> desrt: hey, just tried your patch adding sanity checks for _set_app_menu, it doesn't catch what gnome-boxes is doing [1] and goes in an infinite loop in the /* keep trying until we get a working name... */ block in gtk_application_x11_publish_menu
 <@desrt> teuf: clearly we need an extra restriction! 
 <@desrt> "you may not set menus until after you are registered as the primary instance" 

[1] http://git.gnome.org/browse/gnome-boxes/tree/src/app.vala?id=32045340cd6a232ff55de600f1de9db8d92bf2e4#n110
Comment 7 Matthias Clasen 2018-02-10 04:38:10 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.