GNOME Bugzilla – Bug 317786
copy and paste menu entries are always active
Last modified: 2007-03-12 16:47:48 UTC
paste should only become active when you have copied something. similarly copy should be greyed out when you have copied something.
iirc gcalctool uses a textview for the display... I recently submitted a patch to gtk that adds a 'has_selection' property to GtkTextBuffer: once the required gtk version will be bumped to 2.10 you will just need to connect to the 'notify' signal of that property and set the sensitivity accordingly. With gtk 2.8 doing it is a bit of a pain (you need to track the state yourself).
Hi Paolo. Is there a bug number I can track for the 2.10 Gtk patch? I think I'll wait until that's there, before I try to fix this. Thanks.
Hi Rich. I don't recall the bug number, but the patch has been merged a few months ago, so you should be able to use it already. Also note (in case it wasn't clear from the first comment) that tracking the has_selection property allows to set the sensitivity of 'cut' and 'copy'. 'Paste' is way more difficult since the clipboard can be filled by another app.
Okay, now I'm confused. Doesn't take much. ;-) If it was merged a few months ago, did it make it into Gtk+ v2.8.x series? Or is this something that was specifically put into a separate Gtk+ 2.10 branch?
since it adds a new property and the relative getter function it was only added to HEAD (that is gtk 2.10) and not to the api frozen gtk-2-8 branch
I'm seeing a related issue, except with the popup context menu entries. The Paste option in the context menu is never activated, so when/if you get a chance to fixing reported problem here, could you look at this aswell. Thanks.
Created attachment 80236 [details] [review] Patch to make the "Copy" and "Paste" menu and popup buttons insensitive when there is nothing to copy/paste, and sensitive otherwise.
Thanks Thomas. I'll have a look at it on Tuesday when I return to work.
Great, thanks :) Here is a short overview of the changes: 1) The menubar is fixed by making sure the menu bar handler (mb_proc) is called when the Edit menu is populated. The "Paste" button is active iff the clipboard is able to supply us with text and the "Copy" button is active iff the text buffer has a selection. The code doing this is the function update_copy_paste_status() and a few edits to make sure we have the paste and copy widgets handy and that the "EditMenu" activation event is catched. 2) The context menu for the text buffer is (perhaps somewhat clumsily) fixed by listening to the "populate-popup" signal. The menu items in the popup menu is iterated (using gtk_container_foreach) and when we find the button labelled "Paste" we activate it iff the clipboard has any text ready. Note that comparing the labels with the string "Paste" is bound to fail in translated versions, the line: if (strcmp(gtk_label_get_text(GTK_LABEL(label)),"Paste")==0) { in the function "for_each_menu" in the patch should be changed so the translated version of "Paste" is used instead. The solution to 1) is prettier than the solution to 2) but I was unable to find another way to modify the popup menu. By the way, the context menu for the text buffer will also work correctly with regards to the copy/paste buttons if the "editable" property of the text view (X->display_item) is set to TRUE. However, this yields some funny results since the handle_selection function currently used when pasting text is bypassed. I am looking forward to your comments.
Nice work. I've checked what you've done into SVN trunk. W.r.t. the localisation problem. Can't this be fixed with a simple change from: if (strcmp(gtk_label_get_text(GTK_LABEL(label)),"Paste")==0) { to: if (strcmp(gtk_label_get_text(GTK_LABEL(label)), _("Paste"))==0) { Gman, Paolo, Matt, care to comment? ... Thanks again.
I have not looked at the patch in details, but I really don't see why why all the hacks for the right-click menu are needed: as far as I know GtkTextView already takes care of setting the sensitivity of copy/paste on its own.
GtkTextView does handle the copy/paste stuff fine when the editable property is set to TRUE, but this property is explicitly set to FALSE in the code so I kept it that way. There might be a simpler way, I am no GTK expert ;)
I've heard nothing back on my suggestion in comment #10, so what I plan to do is leave this bug open and after 2.17/18 is released, adjust the code as described above. If anybody thinks I should do otherwise, let me know.
Code adjusted as per comment #10 (in SVN trunk/HEAD after branch for gnome-2-18; i.e. post GNOME 2.18 release). Closing as FIXED. Thanks again Thomas.