GNOME Bugzilla – Bug 667628
GtkWindow:application property should have the G_PARAM_CONSTRUCT flag
Last modified: 2012-02-01 18:00:18 UTC
I have an object which is a subclass of GtkWindowApplication. I call gtk_application_set_menubar() in its constructed method. In order to do so, I need the window's application but gtk_window_get_application() returns NULL because, at this state, the property has not beet set yet. Setting the G_PARAM_CONSTRUCT flag solves this.
Created attachment 204944 [details] [review] set the G_PARAM_CONSTRUCT flag on the GtkWindow:application property This allows subclass to get the value of this property in their constructed method.
Review of attachment 204944 [details] [review]: looks good, thanks
Attachment 204944 [details] pushed as d4fe912 - set the G_PARAM_CONSTRUCT flag on the GtkWindow:application property
I don't get quite how it went, but this commit breaks epiphany/newmenus branch. """ GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed GLib-GIO-CRITICAL **: g_action_group_list_actions: assertion `G_IS_ACTION_GROUP (action_group)' failed """ 434 for (i = 0; actions[i]; i++) (gdb) bt full
+ Trace 229434
probably because it is now being explicitly set to NULL on construct...
(In reply to comment #5) > probably because it is now being explicitly set to NULL on construct... So is this a problem in GTK+ or should ephy be doing something?
How are you constructing your GtkApplicationWindow ? Looks like you need to make sure that it has a nonzero application set before you realize it.
if we wanted to make late setting of the application on applicationwindows possible, we would have to add a bunch of NULL checks, and listen to notify::application to update the muxer when the application appears.
Seems the issue is that I was doing gtk_application_add_window but not the opposite (like, passing the application property on construction to the window). That seems to fix things. Are both needed or can I get rid of gtk_application_add_window?
This commit also seems to break some 3.2 apps, I've spotted eog and ephy so far
For those, the main window seems to set the application on init(), but it's then unset on construct(). This holds, then releases the application, so it just goes through g_application_run()
passing the app to the applicationwindow constructor will end up calling gtk_window_set_application, which will in turn call gtk_application_add_window. So you should be good without a manual add_window
I've been thinking about this a bit lately... We originally needed "application" to be writable-after-init so that gtk_window_set_application() and gtk_application_add_window() could work. It's clear that we never want a GtkApplicationWindow to change applications, however -- and it takes the application as a construct-time parameter. I think a decent compromise here (and one that I've been assuming internally without documenting) is that the application will never be changed while the window is realized. Of course, that doesn't help with solving this bug...
(In reply to comment #9) > Seems the issue is that I was doing gtk_application_add_window but not the > opposite (like, passing the application property on construction to the > window). That seems to fix things. Are both needed or can I get rid of > gtk_application_add_window? gtk_application_add_window() and gtk_window_set_application() will call each other. They are more or less completely equivalent. Similarly, set_application(NULL) or to a different application will call gtk_application_remove_window() internally.
Bug 425324 for a bit of a history lesson. In the original patch there, the 'constructed' vfunc wasn't called until after all the properties were set. Tim reworked it a bit to call 'constructed' before the non-construct properties and I failed to notice at the time... So as it stands today, this is roughly the order of places visited during the construction of an object: - init - construct properties set (including to default values) - constructed vfunc - non-construct properties set cassidy's problem was caused by the reworking that happened in bug 425324 -- non-construct properties not being accessible to the 'constructed' function. We fix that by making it a construct property, but that has a side effect: Construct properties *always* have their setters called, after init, to their default values. In this case, that's NULL. So if you set the property to something in _init, you can expect it to be blown away. This is what eog does. So what can we do? - revisit bug 425324 (which would probably cause a lot more similar breakages in lots of existing code) - revert this patch and say that the application is not available in 'constructed' despite the fact that gtk_application_window_new takes it as an argument - fix eog (i'm starting not to like this option...) - make 'application' a construct property only for GtkApplicationWindow and not normal GtkWindow - have our property-based object construction taken out back and shot
I've reverted the original patch to unbreak eog. I think we need to figure out a way to proceed that is back-compat.
After understanding the original nature of the request that caused this bug to be filed, I think it's actually not an issue at all. Nothing broken, nothing to fix.