! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
XFCE copy paste behavior
Status:
RESOLVED: INVALID

Comments

Description carbonfreeze 2008-03-20 20:34:37 CET
XFCE 4.4.2. Verified issue exists in suse 10.3 & xubuntu 8.04.

XFCE forgets data placed into the clipboard when an application is closed.
Example:

In mousepad:
1). Open mousepad. Type some text.
2). Select the text & copy (either via right click or ctrl-c).
3). Close mousepad.
4). Reopen mousepad or any other text editor.
5). Attempt to paste the data, nothing appears on the screen & paste function in edit is blanked out.

In thunar:
1). Open thunar. Create a new file, or select a pre-existing file.
2). Copy or cut the selected file.
3). Close thunar.
4). Open a new instance of thunar, attempt to paste the file(s). Nothing happens.

XFCE shouldn't forget data in the clipboard, even if the source application is closed, atleast not until the user logs out of XFCE/xorg.

Note:
I also tested this issue with the "clipman" panel plugin, and text copy/paste works as expected when "prevent empty clipboard" option is enabled in this plugin when using mousepad/text data in the clipboard. Thunar file cut/copy still does not function as expected when using clipman.
Comment 1 Olivier Fourdan editbugs 2008-03-20 21:22:13 CET
This is the normal X behavior. If you want the data to be available after the source application has vanished, use a clipboard manager such as the Xfce Clipman plugin.

http://goodies.xfce.org/projects/panel-plugins/xfce4-clipman-plugin
Comment 2 Olivier Fourdan editbugs 2008-03-20 21:24:40 CET
Ah sorry, there is two different bugs if Thunar behaves differently. Reassigning to Thunar then.
Comment 3 Mike Massonnet editbugs 2008-03-20 21:29:40 CET
For Thunar it might be good to reassign indeed, tho I'm not sure where the habit to 1) open a window 2) copy 3) close the window 4) open a new window 5) paste, is right...

Benny?
Comment 4 carbonfreeze 2008-03-21 03:30:33 CET
(In reply to comment #3)
> For Thunar it might be good to reassign indeed, tho I'm not sure where the
> habit to 1) open a window 2) copy 3) close the window 4) open a new window 5)
> paste, is right...

I was simply illustrating a method to reproduce the issue.


(In reply to comment #1)
Ok, but should the basic behavior of clipman (persistent clipboard) not be the default behavior of a desktop environment? I can understand performance reasons (garbage collection) for removing an application's clipboard contents from RAM, but I would expect something that I placed in the clipboard to be there until I 

1). Logout
2). halt/reboot the machine
3). Replace it with something else. 

Is xorg setup so that each application has its own clipboard? Why should cut/copy be different than the highlight-to-copy behavior of xorg (which IS persistent).
Comment 5 carbonfreeze 2008-03-21 03:36:33 CET
(In reply to comment #4)
> Is xorg setup so that each application has its own clipboard? Why should
> cut/copy be different than the highlight-to-copy behavior of xorg (which IS
> persistent).

Woops. Was testing with clipman on. highlight-to-copy is not persistent.
Comment 6 Brian J. Tarricone (not reading bugmail) 2008-03-22 03:24:58 CET
Pretty sure this was correct as INVALID.  You're not understanding how the "clipboard" works on X11.  There is no actual "clipboard."  When you select text or do Edit->Copy, no data gets sent anywhere.  The application just says "I own the clipboard" (or in the case of a mouse selection, "I own the primary selection").  If another app wants to paste, it sends a message that tells the app that cut/copied to send the data to the pasting app.  If the app with the data isn't running anymore, then there's no app to send data from.

That's why we have the clipman plugin -- it makes the clipboard behave more like the Windows/Mac clipboard for people who want that behavior.  If there's a problem with that, please file a bug for the clipman plugin.  There's no bug in Xfce itself related to clipboard/primary selection handling, and if there was, it would likely be a gtk problem, as we don't really handle that sort of stuff ourselves.
Comment 7 Mike Massonnet editbugs 2008-03-22 12:24:45 CET
That isn't invalid for Thunar.  As of your own application, you can request the clipboard to be stored so that it stays when the application quits.

http://library.gnome.org/devel/gtk/unstable/gtk-Clipboards.html#gtk-clipboard-store

(And for text clipboards, it is easier to install the clipman plugin as already told unlike to patch each GTK+ application that doesn't care about storing the clipboard).
Comment 8 Yves-Alexis Perez editbugs 2008-03-22 13:00:30 CET
(In reply to comment #7)
> That isn't invalid for Thunar.  As of your own application, you can request the
> clipboard to be stored so that it stays when the application quits.

It's not invalid for Thunar especially since Thunar is intended to be used as a daemon too. When you close a thunar window, the process keeps running, so it should be able to keep the clipboard for another thunar window.

Bug #3954

Reported by:
carbonfreeze
Reported on: 2008-03-20
Last modified on: 2009-07-17

People

Assignee:
Jannis Pohlmann
CC List:
0 users

Version

Version:
unspecified

Attachments

Additional information