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 448261 - selection-changed signal for GtkEditables and GtkTextBuffers
selection-changed signal for GtkEditables and GtkTextBuffers
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.10.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-06-16 17:16 UTC by Sebastian Rittau
Modified: 2018-02-10 03:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sebastian Rittau 2007-06-16 17:16:56 UTC 
I would like to see a "selection-changed" signal for GtkEditables and GtkTextBuffers. Currently you have to resort to hacks to detect whether the selection has changed (for example to enable/disable cut/copy menu items). These hacks include regular checks of the selection status (using a timeout), or a notification on GtkTextBuffers "has-selection" property.
Comment 1 Matthew Barnes 2010-09-12 10:54:10 UTC 
+1 - I'd like this for Evolution as well for updating Cut/Copy/Paste main menu actions.

For widgets implementing GtkEditable, we currently update our main menu actions in response to any GtkClipboard::owner-change signal, which can be triggered by any app.  So it's way overkill.
Comment 2 Matthias Clasen 2018-02-10 03:38:52 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.