Created attachment 189943 [details] [review]
Save screenshots directly to pictures folder

In a typical workflow I take a screenshot and then check it before doing anything with it, to see if it actually contains what I intended: the current dialog shows me a preview of the screenshot without having to manually open the file in a separate application. How would that use case be addressed? Maybe we should pop up a notification with the preview of the picture(s).

Also, when taking screenshots of gdm, in whose Pictures folder would the files be saved?

I don't think that a tiny thumbnail is a good way to review what was snapped. Also, I don't think that snap-time is the best time to review. You are likely in the critical path of an operation you are trying to capture and just want to make a record of it. If you can defer an action you almost always should. Renaming, filing, and post-processing can all be done later. Or the snap can be worthless and just removed. Basically, time is the limited resource - disk space is not.

GDM uses a different screenshot tool. But GDM is a great case for this. You never ever want to see a file chooser dialog in GDM.

Another future use case is taking a screenshot of the lock screen.

Exactly because I am on the critical path of an operation I need to make sure what I wanted to caputure was there instead of e.g. closing the application check the screenshot find out I got the model in my application in the wrong position, reopen the application, reload the model, wait that it is loaded and retry to take the screenshot.

I am not saying that the tiny preview is the right ui, I am just saying that I think the UI we choose must allow to check if the screenshot is the desired one istead of "driving blind" and check at the end.


With regard to GDM and locked screen I think it is bad that I can walk up to my colleague locked pc and fill his disk with snapshots no matter how cheap the disk is. Also I think that GDM and locked screen are really *not* interesting as a use cases for screenshot application since they basically just matter for the gdm and gnome-screensaver maintainer ;)

Then we agree that it isn't the right UI. :)

Before I forget, when we add this we should change the text description for the keybinding in the System Settings to "Save screenshot of window to Photos" and "Save screenshot of window to clipboard" etc

I agree that showing a dialog right after the screenshot is not the best UI.

What I was thinking of is that screenshots are "piled up" in the notification are and I could preview them by hovering the mouse. That way I can take two or three screenshots, quickly peek at them to make sure I got the intended target and at the end decide what to do with them: keep one, keep them all or discard them.

Created attachment 190398 [details] [review]
Save screenshots directly to pictures folder

Rebase to head

Review of attachment 190398 [details] [review]:

Looks mostly good to me. Some general comments:

Why did you remove integration with GtkRecentManager? I think that's something we still want, even if we don't show any dialog

You're probably not a big fan of configuration keys, but I think we want to have a way to override the target folder. There are two things we could do:
1. add a GSettings key for the default location, empty by default, which if set, always overrides the XDG pictures location.
2. add a --target-file option, to save automatically there. This could be also useful for e.g. scripts; see bug 129768

I think we should have both; the second item is really an enhancement request, so it's not to be addressed with this patch, but for the first item most of what we need is already in place.

::: gnome-screenshot/gnome-screenshot.c
@@ +574,3 @@
                                                 _("Impossible to save the screenshot "
                                                   "to %s.\n Error was %s.\n Please choose another "
+                                                  "location and retry."), uri, error->message);

We should probably drop this dialog altogether and either do nothing or do something else in case of error; at least we should reword it, because we can't really choose another location after this patch :)

@@ +1029,3 @@
+  GFile *file;
+  char *path;
+  file = g_file_new_for_uri (uri);

Maybe you can use g_file_make_directory_with_parents() directly here?

(In reply to comment #7)

> What I was thinking of is that screenshots are "piled up" in the notification
> are and I could preview them by hovering the mouse. That way I can take two or
> three screenshots, quickly peek at them to make sure I got the intended target
> and at the end decide what to do with them: keep one, keep them all or discard
> them.

I don't believe having any kind of preview/dialog/notification would help much with this use case. We have three modes of operation:
- whole desktop: no need to check for the intended target
- selected area: you already selected the area yourself, so there's no need to check whether what you selected is really what you wanted
- single window: this is probably the only case where it could be useful to check which window has been captured

Note that for all these three cases, we already have a flash effect in git master, so the active window will flash white when you capture it anyway, giving an immediate indication of the target.

(In reply to comment #10)

> - whole desktop: no need to check for the intended target
> - selected area: you already selected the area yourself, so there's no need to
> check whether what you selected is really what you wanted
> - single window: this is probably the only case where it could be useful to
> check which window has been captured
> 
> Note that for all these three cases, we already have a flash effect in git
> master, so the active window will flash white when you capture it anyway,
> giving an immediate indication of the target.

You are making the assumption that the intended target is purely "spatial" and static, but that is often not that case: it is also temporal. Examples.
 - I am taking a screenshot of a 3D application with a rotating model
 - I am taking a screenshot of a tooltip bug that gets popped up at the wrong position
 - I am taking a screenshot of drawing artifacts in an animation
 - I am taking a screenshot of a gnome terminal bug that gets triggered during the scrolling of the compilation
 - I am taking a screenshot of somthing that gets triggered in response to a mouse action and since I have just two hands I am using the mouse and pressing "Print" at the same time and I am not sure I got it right


When you take a group photo you do not just make sure that everyone is in but you also check that everyone was smiling or worse (http://www.repubblica.it/online/politica/gesto/gesto/gesto.html) ;)

(In reply to comment #11)

> You are making the assumption that the intended target is purely "spatial" and
> static, but that is often not that case: it is also temporal. Examples.
>  - I am taking a screenshot of a 3D application with a rotating model
>  - I am taking a screenshot of a tooltip bug that gets popped up at the wrong
> position
>  - I am taking a screenshot of drawing artifacts in an animation
>  - I am taking a screenshot of a gnome terminal bug that gets triggered during
> the scrolling of the compilation
>  - I am taking a screenshot of somthing that gets triggered in response to a
> mouse action and since I have just two hands I am using the mouse and pressing
> "Print" at the same time and I am not sure I got it right
> 
> 
> When you take a group photo you do not just make sure that everyone is in but
> you also check that everyone was smiling or worse
> (http://www.repubblica.it/online/politica/gesto/gesto/gesto.html) ;)

I don't see how a notification could help with these use cases, really. If you need to take multiple screenshots in a sequence because the event you want to capture is fast/random you will need to file and choose later anyway, so you will use a photo manager (or a file manager) which has better previews.

I already made my point in comment #4: setting off to reproduce a bug/usecase of which you want to take a screenshot may be a complicated/slow operation and in those cases I'd like a way to take a peek at the result and make sure the screenshot has the expected content. Having to take 10 random shots just to be sure and then go back and sort them out does not sound like a great way to do things, it's like going back from digital cameras to film based cameras where you had to wait for the negatives to had an idea if you actually had what you want.


The notification was just an idea to have the preview out of the way for the normal case, but available in one click or even by just hovering the mouse if the user wants to take a peek. I am sure there are possible other ways to address the usecase.

*** Bug 489947 has been marked as a duplicate of this bug. ***

i agree with comment#2 where i can check what i snapped and assign an appropriate path/filename in the flow.

as a compromise there should be a checkbox (maybe in display settings?) 
where you could select to enable/disable between 
the described interactive/automatic methods.

I implemented this in git master now.
Note that this only applies when gnome-screenshot is launched with keybindings; the --interactive option will still trigger the old dialog from where it's possible to choose the save path.

The new gnome-screenshot with this popped up in Ubuntu+1 yesterday and we have 8 dupes about this already: 

https://bugs.launchpad.net/ubuntu/+source/gnome-screenshot/+bug/927952

I must say the thinking that doing it this way will move us /away/ from file management hassle is flawed. The exact opposite situation has arisen.

Now, I have to hunt down a file with a useless generic name in a very long list of photos (yes, camera photos, screenshots don’t belong among my photos).

And forget GtkRecent, in Gnome Shell Overview there aren’t even icon previews. It’s a "generic image" icon with the label »Screenshot at 2012...«.

So I have to go to Nautilus and hunt down the screenshots I need in the sequential order in which I need to use them further. They are all completely disassociated from the context in which I snapped them. 

Before all I had to do before was ›shoot‹, ›paste‹, ›describe‹, repeat. All one consistent train of thought, you iterate until the task is done, no context switches or memory required.

And so you will say: that is covered by keybindings. But there are /six/ keybindings now. Who can remember that? What acrobatics it requires! And you don’t even know which one of the six you actually used until you switched to the other app to make sure it was the right one. But you had already cleaned up your desktop to make nice screenshots, so you have a window managment problem now as well.

And where do the Screenshots go? Into the folder for photos, which in actuality is a grabbag where every app just dumps random image potpurri. It’s not user friendly.

Sorry, I filed this before I discovered this FIXED bug. I guess you can delete it.
https://bugzilla.gnome.org/show_bug.cgi?id=652487

Err, that one:
https://bugzilla.gnome.org/show_bug.cgi?id=669629

The Pictures folder is not for photos. Pictures is treated as a larger category. Most photo applications use ${XDG_PICTURES_DIR}/Photos.

If screenshots are being placed in Pictures/Photos by default, there is a problem. Please leave a comment if that is the case.

OMG
William, I don't know why do you think replicating phone/tablet approach on PC is a good idea (I would ask this question for dumbs who decided GS is a good idea too), but I highly doubt it actually is.

In fact, this poorly thought changes increased typical screenshot taking workflow for ALL people I have asked. I don't know what you (including GS buddies) are smoking, but these changes are STUPID. Please, stop this. The old Gnome 2 was a good thing. Definitely MUCH better than this. And I can't remember any recent change that improved anything.

Denis, Tobias:
Two things: 1) This is not a forum but a bugtracker. 2) While you are free to express disagreement, personal attacks and insults are inacceptable. 

Denis: Read https://live.gnome.org/CodeOfConduct before adding any further comments.
Tobias: I have disabled your account as per comment 21. If you feel that this is unjustified, feel free to contact bugmaster@gnome.org .