GNOME Bugzilla – Bug 523010
Edit menu selection causes clipboard text retreivel
Last modified: 2008-10-27 20:24:22 UTC
Please describe the problem: Use of gtk_clipboard_request_text in edit_menu_activate_callback causes clipboard text to be retrieved unnecessarily prior to 'Paste' item selection which may never actually occur. Also if 'Paste' is selected the the owner of the clipboard will receive two selection-request-events for the text without a way to differentiate which is the actual paste. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information: This patch replaces the use of gtk_clipboard_request_text with gtk_clipboard_wait_is_text_available when the 'Edit' menu is selected. gtk_clipboard_wait_is_text_available will be a little faster as it doesn't retreive the text and selection or clipbord managers will only receive one selection-request-event for the data when the 'Paste' occurs if it ever does. Without this change selection-request-event listeners like selection or clipbord managers receive two selection-request-event one when the 'Edit' menu is selected and the other when 'Paste' is selected and there is no way to differnetiate them. --- gnome-terminal-2.18.4/src/terminal-window.c 2008-03-17 11:30:21.000000000 -0500 +++ gnome-terminal-2.18.4.new/src/terminal-window.c 2008-03-17 11:29:47.000000000 -0500 @@ -753,7 +753,11 @@ window = (TerminalWindow *) user_data; - gtk_clipboard_request_text (window->priv->clipboard, (GtkClipboardTextReceivedFunc) update_edit_menu, window); + if (gtk_clipboard_wait_is_text_available (window->priv->clipboard)) + update_edit_menu (window->priv->clipboard, "", window); + else + update_edit_menu (window->priv->clipboard, NULL, window); + } static void
Created attachment 107465 [details] [review] patch to terminal-window.c
Thanks for the patch! The idea of the patch is right, in that we should only request the targets but not the contents itself. However using blocking API calls in unacceptable; you should use gtk_clipboard_request_contents: with gdk_atom_intern_static_string ("TARGETS") and in the callback test with gtk_target_list_include_text_targets.
Works for me.
(In reply to comment #2) > Thanks for the patch! > > The idea of the patch is right, in that we should only request the targets but > not the contents itself. However using blocking API calls in unacceptable; you > should use gtk_clipboard_request_contents: with gdk_atom_intern_static_string > ("TARGETS") and in the callback test with gtk_target_list_include_text_targets. > Are you going to roll a patch or should I?
It looks like the latest version 2.22.1 is using gtk_clipboard_request_text which is fine in that it is a non-blocking call but it still retrieves the selection text whenever the edit menu is clicked in order to enable the paste menu item. If paste is selected another retrieval of the selection text is done. It would be better if the the suggestion in comment #2 we're implemented to avoid the dual retrieval and to allow a selection manager to know when the actual paste is occurring.
Created attachment 108990 [details] [review] patch to terminal-window.c Implements solution as described in comment #2.
It looks like the same issue exists for the right-mouse click menu, where is the code that handles the right-mouse click?
In terminal-window.c on svn trunk.
The Edit menu and the right click menu are behaving differently. With the patch when I click the Edit menu on the menu bar my selection manager receives a selection-request with target TARGETS as expected. However if I right click the window my selection manager receives a selection-request with target UTF8_STRING before the menu pops up. Any idea what could account for this difference in behaviour?
You mean that even if you also patch screen_show_popup_menu_callback/popup_clipboard_request_callback similarly to your patch here?
Created attachment 109072 [details] [review] gnome-terminal paste patch new version of patch to also handle right click menu
Thanks! I adapted the code to svn trunk, and committed it. (In future, please make patches again the svn trunk version instead of a release.)
This fix is not being applied in version 2.22.2-1, what happened?
This is fixed in 2.24.0; 2.22.x is dead.