Copying and pasting photos
Submitted by an unknown user
Link to original bug (#715502)
Description
---- Reported by shotwell-maint@gnome.bugs 2009-12-08 17:01:00 -0800 ----
Original Redmine bug id: 1098
Original URL: http://redmine.yorba.org/issues/1098
Searchable id: yorba-bug-1098
Original author: Mattias P õldaru
Original description:
Scenario: In thumbnail view select one or more images, press Ctrl+C to copy file(s), paste these into nautilus, openoffice or wherever else.
Could work in full window and why not even in fullscreen or slideshow mode. (Copying image in fullscreen mode may be useful, if you use virtual desktops and search for photos on one desktop fullscreen and use these in slideshow or whatever you are editing on the other, while switching between desktops with shortcut.)
Implementing Ctrl+X would not be that nice, as accidentally removing image from library can be frustrating.
Related issues:
- related to shotwell - Feature #1798 (closed): keep full-resolution version of each edited image (Open)
- related to shotwell - Feature #3451 (closed): Suggestion: add a 'copy path to clipboard' option to the ... (Open)
- related to shotwell - Feature #2517: Copy and paste color adjustments (Fixed)
- duplicated by shotwell - Feature #3619 (closed): Allow copying of photos/paths to clipboard (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2012-04-03 11:59:00 -0700 ----
History
Comment 1
Updated by Adam Dingle almost 4 years ago
-
Priority deleted (
<strike>
_Low_</strike>
)
A reasonable suggestion. Upping to medium priority.
Comment 2
Updated by Jim Nelson almost 4 years ago
- Subject changed from Ctrl+C copy file to Copying and pasting photos
Another aspect of copying and pasting would be to tag photos, by copying them and then pasting them into the tag's view.
This isn't as intuitive with Events, as a photo can only be a member of a single event; a cut-and-paste operation would make more sense (if we were to pursue this).
Comment 3
Updated by Adam Dingle over 3 years ago
- Priority set to High
Comment 4
Updated by Adam Dingle over 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 5
Updated by Adam Dingle over 2 years ago
#3619has been marked as a duplicate of this ticket.
Comment 6
Updated by Anton Keks over 2 years ago
So, 18 months old and nothing still happened. Is it hard to implement?
Comment 7
Updated by Adam Dingle over 2 years ago
Replying to [comment:9 angryziber]:
So, 18 months old and nothing still happened. Is it hard to implement?
I think that implementing this might not be so easy, since Shotwell currently doesn't keep an on-disk copy of each photo with edits applied; instead, it runs photo transformations on the fly each time it needs to display a photo. So for copy/paste, we'd need to decide whether to run the transfomation pipeline at the time photos are copied (which might be annoying) or only when they are pasted (though I'm not sure how technically easy that would be; I'd need to look at the copy/paste architecture more). If we want copied photos to be available for pasting even after Shotwell exits, that would be trickier still since we'd need to run the pipeline before exit and save the resulting images somewhere.
It seems likely that this will all be easier to build once we've implemented#1798.
Comment 8
Updated by Anton Keks over 2 years ago
Ok, I see. Maybe just copying a full path to the photo would be a good start?
I am having troubles with locating the same photo I see in the filesystem. Maybe a right-click option “copy path�
Comment 9
Updated by Adam Dingle over 2 years ago
Yes, copying the path would be much easier to implement than copying the photo image itself, and might be a reasonable first step in this direction.
Comment 10
Updated by Adam Dingle about 2 years ago
- Description updated (diff)
- Priority changed from Low to Normal
Comment 11
Updated by Zac Hilbert over 1 year ago
- File issue1098.patch added
I did a little work on this issue. My code only handles copy one image (or one image's path) at a time. Nothing happens if, for example, multiple files are selected in the library. As for the copy of the image, it takes the 'raw,untransformed, scaled pixbuf from the master' (get_master_pixbuf) and puts it on the clipboard. I'm not sure what this means in terms of the pipeline issue addressed above.
I am able to paste the image from Shotwell into Gimp (and I'd assume any other application that accepts image data from the clipboard.) However, pasting to the file system does not work. I suspect I'd need to fill the clipboard with file data in addition to the pixbuf. I'm not very familiar with the underpinnings of the GTK+ clipboard system, so I'll have to do some research here.
This is my first experience working with Vala and contributing to an open source project, so I am very open to any feedback or criticism.
Thanks.
Comment 12
Updated by Adam Dingle over 1 year ago
- Status changed from Open to Review
Lucas, please review and comment on the work done so far. Thanks!
Comment 13
Updated by Zac Hilbert over 1 year ago
Lucas, I am working on some edits to the patch I submitted a few days ago. Namely, the edits include some revisions to align my code with the Shotwell coding conventions, and some work to make it possible to copy and paste files into Nautilus or other hosts that allow files to be pasted. I hope to have a new patch available tonight.
Comment 14
Updated by Adam Dingle over 1 year ago
- Status changed from Review to Open
Sounds good. Removing review status for now.
Comment 15
Updated by Lucas Beeler over 1 year ago
- Priority changed from Normal to High
- Target version set to 0.13
Comment 16
Updated by Adam Dingle over 1 year ago
It sounds as if the work above is preliminary, so I'd rather not target this for 0.13 just yet. I don't think we can take a copy/paste patch until it applies transformations at copy (or paste) time, which might not be easy. As I mentioned above, #1798 (closed) will make this much easier and we should possibly wait until that's implemented beore trying to complete this.
Comment 17
Updated by Adam Dingle over 1 year ago
-
Target version deleted (
<strike>
_0.13_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:41 UTC ---
This bug was previously known as bug 1098 at http://redmine.yorba.org/show_bug.cgi?id=1098 Imported an attachment (id=261512)
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution