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 641087 - Wish: GtkApplication::window-added signal
Wish: GtkApplication::window-added signal
Product: gtk+
Classification: Platform
Component: Class: GtkApplication
Other Linux
: Normal enhancement
: 3.2
Assigned To: gtkdev
Depends on:
Reported: 2011-01-31 23:08 UTC by Matthew Barnes
Modified: 2011-05-31 23:14 UTC
See Also:
GNOME target: ---
GNOME version: ---

Proposed patch (2.03 KB, patch)
2011-01-31 23:48 UTC, Matthew Barnes
none Details | Review

Description Matthew Barnes 2011-01-31 23:08:06 UTC
Associating a new window with a GtkApplication is a useful event for applications and/or plugins to listen for.  Would be nice if gtk_application_add_window() emitted a signal that includes the new GtkWindow.  A method pointer for this signal in the GtkApplicationClass struct would be nice too if it's not too late to break ABI.

Evolution's EShell emits such a signal, which we connect to in numerous places.
Comment 1 Matthew Barnes 2011-01-31 23:48:12 UTC
Created attachment 179756 [details] [review]
Proposed patch

The class struct has some padding so this doesn't break ABI after all.
Comment 2 Matthew Barnes 2011-01-31 23:49:03 UTC
Gah, the padding value in the header should be reduced by 1, not 4.
Comment 3 Matthias Clasen 2011-02-01 00:39:20 UTC
I guess it goes without saying that if you add added, you should also add removed ?
Comment 4 Matthew Barnes 2011-02-01 01:24:13 UTC
For a window-removed signal to be useful it would also need to include the GtkWindow while it's still a GtkWindow, and I see that gtk_application_remove_window() is called during gtk_window_finalize() so I wasn't sure if there would be lifecycle issues with that.  If not then yes I agree.
Comment 5 Matthias Clasen 2011-02-01 03:45:18 UTC
Ah, that is probably true