I'm maintaining the Xfce goodies for Fedora and one of the users of xfce4-screenshooter reported that 'copy to clipboard' doesn't work. From the original Bug report at https://bugzilla.redhat.com/show_bug.cgi?id=517408 "I'm a newbie running Fedora 11 trying to run xfce4-screenshooter. Everything works great except when I select a region with copy to clipboard I am unable to paste it into OpenOffice Impress like I can with gnome screenshot." I can confirm this observation, the clipboard does not work at all. Version-Release number of selected component (if applicable): xfce4-screenshooter-1.5.1-1.fc11 How reproducible: always Steps to Reproduce: 1. run xfce4-screenshooter with "copy to the clipboard": 2. try to insert the content of the clipboard into OpenOffice writer -> nothing happens 3. try to insert the content in GIMP. Actual results: "GIMP Message There is no image data in the clipboard to paste." Expected results: Content should be pasted into OpenOffice or GIMP
I need some additional information. This feature relies on a clipboard manager, do you have one running? Without a clipboard manager, this feature should only only work for the panel plugin as nothing stores the image once the application has been exited.
Ok, I see. I have a clipboard manager running, but pacellite doesn't work. I have tried the following combinations: xfce4-screenshooter + parcellite: fail xfce4-screenshooter + xfce4-clipman-plugin: works xfce4-screenshooter-plugin: fail xfce4-screenshooter in Gnome + glipper: fail gnome-screenshoot + parcellite: fail gnome-screenshoot + xfce4-clipman-plugin: works gnome-screenshoot in a Gnome session: works In Gnome no clipboard manager is needed, seems like there's something handling the clipboard (and it's not glipper), but xfce4-screenshooter is not compatible to it. Maybe "copy to clipboard" should be greyed out if there is not suitable clipboard manager available? Why doesn't the panel plugin work?
Ok, first glipper and parcellite don't implement the persistence of images, so it'll never work with those two. The panel plugin works fine here, with or without clipboard manager. I don't see what can prevent it from working, I'll try to investigate this. The Gnome session has a clipboard manager which supports images built-in, so it should work. I'll try to test that.
Ok, I just tested this in a Gnome session. gnome-screenshot works if you press the "Copy to clipboard" button and don't exit the application. If you exit the application, pasting fails as with xfce4-screenshooter. I would say it's a bug in the gnome clipboard daemon, because Open Office detects there is a bitmap in the clipboard but fails to retrieve it. So the only bug I could do something for is the panel plugin one. Is there anything displayed in logs when you test it with or without a clipboard manager running? It fails in a Gnome session, in an Xfce one? In both?
(In reply to comment #4) > Is there > anything displayed in logs when you test it with or without a clipboard manager > running? First I followed the instructions from http://wiki.xfce.org/howto/panel_plugin_debug#temporarily_capturing_messages_to_stdout_and_stderr but nothing, but got nothing. Then I tried valgrind as described on that page. when starting the plugin i get some messages on the terminal: (xfce4-screenshooter-plugin:3848): GLib-GIO-WARNING **: Could not initialize inotify (xfce4-screenshooter-plugin:3848): GLib-GIO-WARNING **: Could not initialize inotify When the screenshot is taken, there are not errors, not even in screenshooter-valgrind.log $ tail -f screenshooter-valgrind.log ==3848== display_name=Bildschirmfoto ==3848== Valgrid ==3848== size=28 ==3848== screen_position=2 ==3848== --3848-- WARNING: unhandled syscall: 294 --3848-- You may be able to write your own handler. --3848-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --3848-- Nevertheless we consider this a bug. Please report --3848-- it at http://valgrind.org/support/bug_reports.html. ==3848== ==3848== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 14 from 3) ==3848== malloc/free: in use at exit: 4,874,427 bytes in 40,024 blocks. ==3848== malloc/free: 263,456 allocs, 223,432 frees, 50,040,559 bytes allocated. ==3848== For counts of detected errors, rerun with: -v ==3848== searching for pointers to 40,024 not-freed blocks. ==3848== checked 4,870,360 bytes. ==3848== ==3848== LEAK SUMMARY: ==3848== definitely lost: 32,064 bytes in 749 blocks. ==3848== possibly lost: 248,644 bytes in 231 blocks. ==3848== still reachable: 4,593,719 bytes in 39,044 blocks. ==3848== suppressed: 0 bytes in 0 blocks. ==3848== Rerun with --leak-check=full to see details of leaked memory. > It fails in a Gnome session, in an Xfce one? In both? I only tried the Xfce session because usually I don't have xfce4-panel running in Gnome. I hope this helps. If not, I can still use gdb, but not sure if this makes much sense.
Ok, I don't gdb would be of much help too. In fact, the panel plugin works fine when there is no cliboard daemon running, but when using xfce4-clipman-plugin a weird thing can happen (happens with the application too sometimes): you take the screenshot, select copy to clipboard. If you check in clipman, the image is displayed in the list, but if you try to paste it in open office for example it lags, then nothing is pasted. But if you click on the image in the clipman list, then try to paste, it works. Can you confirm this? If yes, that could be a bug in xfce4-clipman-plugin. Additionally, I checked and they are not calling gtk_clipboard_store, so I tried to remove that in git. It would be great if you could test this.
(In reply to comment #6) > Ok, I don't gdb would be of much help too. > > In fact, the panel plugin works fine when there is no cliboard daemon running, Hmm, I think you are right: GIMP, Inkscape, mtPaint and Mypaint work fine with the plugin and without clipman, only OO.org does not. But when I select "Paste special"in OO.org, at least it recognizes there is a bitmap in the clipbard. So I assume the data arrives in OO.org correctly and the bug is in OO.org. > but when using xfce4-clipman-plugin a weird thing can happen (happens with the > application too sometimes): you take the screenshot, select copy to clipboard. > If you check in clipman, the image is displayed in the list, but if you try to > paste it in open office for example it lags, then nothing is pasted. Confirmed, see above. The lag makes me think there is something going wrong in OO.org. > But if you > click on the image in the clipman list, then try to paste, it works. Can you > confirm this? If yes, that could be a bug in xfce4-clipman-plugin. Confirmed too. Not sure if this is a clipman bug because it doesn't work with the plugin ether. > Additionally, I checked and they are not calling gtk_clipboard_store, so I > tried to remove that in git. It would be great if you could test this. I will try later today, just wanted to report my observations so far.
I have tested the git version, but I don't see any difference.
Clipman has the same daemon as GNOME (gnome-settings-daemon)... it was a good idea to switch to it since it allows to save the TARGETS of a clipboard and works perfectly for texts but it shows bugs with saving text selections and as I learn here images. The problem is not the clipboard manager, the problem is the usual => "application X closes" => "clipboard is lost". Running gtk_clipboard_store is... well, I don't know what's it good for. If you check the box in screenshoter to not close the image the image will still be pasted elsewhere. All I can do is to fix the bugs in the gsd-clipboard-manager but don't get big hopes by reading this, it is unlikely. It uses the lower level X11 to handle the clipboard and it is anything but fun to hack on. I'm poking around the idea to get in touch with GNOME hackers to know what they think about the plugin and if it is a good idea to rewrite it with the higher level functions from GTK+. I cannot think of anything that you could do in the meanwhile.
(In reply to comment #9) Or not, it actually works without problem with Gimp etc. Reading through the comments I notice a bug only with OO.o. Gonna test that later.
(In reply to comment #1) > I need some additional information. This feature relies on a clipboard manager, > do you have one running? Without a clipboard manager, this feature should only > only work for the panel plugin as nothing stores the image once the application > has been exited. FWIW, to check if a clipboard manager is running you only need something like this: static gboolean clipboard_manager_ownership_exists () { Display *display; Atom atom; display = GDK_DISPLAY (); atom = XInternAtom (display, "CLIPBOARD_MANAGER", FALSE); return XGetSelectionOwner (display, atom); } the XInternAtom (..., FALSE) retrieves the atom but doesn't create it if there isn't any existing one (TRUE would create the atom). The next function looks up the owner of the atom if any. You should consider using it to set either visibility or sensitivity of that radio button cause I can confirm (unlike my first comment) that without a clipboard manager you won't be able to paste the image after the screenshot application exists.
(In reply to comment #0) > I'm maintaining the Xfce goodies for Fedora and one of the users of > xfce4-screenshooter reported that 'copy to clipboard' doesn't work. From the > original Bug report at https://bugzilla.redhat.com/show_bug.cgi?id=517408 > > "I'm a newbie running Fedora 11 trying to run xfce4-screenshooter. Everything > works great except when I select a region with copy to clipboard I am unable to > paste it into OpenOffice Impress like I can with gnome screenshot." I looked up Koji, and F11 has only version 1.0 of clipman. The daemon I mentioned has been introduced starting at 1.1. If you try with that version you should see that everything is fine even with OO.o. OK I didn't try yet, but I'm optimist on this one ;-) (Ready to reboot my machine now and gonna test OO.o right away)
(In reply to comment #12) > If you try with that version you should see that everything is fine even with > OO.o. OK I didn't try yet, but I'm optimist on this one ;-) Sorry to rain on your parade, but I'm running 1.1.0 on F11. I have just fired up a build of 1.1.1 for F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1781688
Ah, alright then, I looked up the first result with fc11 in it. I tried OOo and the clipboard manager is not save the exact same TARGETS for an image :-/ This is what the TARGETS look like without a clipboard manager: TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS image/png image/jpeg image/x-icon image/x-ico image/x-win-bitmap image/tiff image/bmp image/x-bmp image/x-MS-bmp this is what the clipboard manager saves it to: TARGETS MULTIPLE image/x-MS-bmp image/x-bmp image/bmp image/tiff image/jpeg image/png SAVE_TARGETS TIMESTAMP probably OO.o is interpreting the image as a bmp instead of a png, dunno. I cannot tell if OO.o is to blame but it seems the target aren't saved in the same order, and there are even targets missing.
Submitted to OOo (#106549) hopefully they will have a good idea.
(In reply to comment #4) > Ok, I just tested this in a Gnome session. gnome-screenshot works if you press > the "Copy to clipboard" button and don't exit the application. If you exit the > application, pasting fails as with xfce4-screenshooter. I would say it's a bug > in the gnome clipboard daemon, because Open Office detects there is a bitmap in > the clipboard but fails to retrieve it. > > So the only bug I could do something for is the panel plugin one. Is there > anything displayed in logs when you test it with or without a clipboard manager > running? It fails in a Gnome session, in an Xfce one? In both? gnome-screenshot does not call store (I actually get it what it does now) hence the XATOMS (not TARGETS actually) won't be modified. Only once the gnome-screenshot application gets closed the image will be stored within the clipboard daemon and the XATOMS will be different (as pasted in comment #14). With these, it seems, OOo is missbehaving. I hope everything is up and clear! The user who reported the issue either 1) did not run a clipboard manager and tried to paste the image after xfce4-screenshooter was closed or 2) had a clipboard manager and OOo was hanging.
Ok, while we are still waiting for a solution from the OO guys, is there anything we can do in the screenshooter? IMO "Copy to clibboard" should be greyed out if there is not clipboard available and the plugin is not running. Additionally, there should be a short explanation. Is that possible?
Ok, I just committed some code to only show this option in the application when a clipboard manager is running, thanks for the code Mike. I read this thread two or three times and still do not get this, shall I use gtk_clipboard_store or not?
(In reply to comment #18) > Ok, I just committed some code to only show this option in the application when > a clipboard manager is running, thanks for the code Mike. > > I read this thread two or three times and still do not get this, shall I use > gtk_clipboard_store or not? It's useless, by calling it, it will pass the data directly to the clipboard manager. If it doesn't get called, the clipboard manager will take the clipboard data after the application is closed.
Ok, thanks a lot for the additional explanation Mike! I'm closing this as the remaining issue is an Open Office one.
I just found out this function: http://library.gnome.org/devel/gdk/stable/GdkDisplay.html#gdk-display-supports-clipboard-persistence It does a check for a running clipboard manager and returns TRUE if it finds one. I tested it and it works fine. It drops the necessity to include X libraries.
Thanks for this Mike, it allowed me to drop some code. I have the X includes anyway to use the shape extensions on rounded corners, but still that removes some duplicated code.