GNOME Bugzilla – Bug 325708
Use a GtkFileChooserDialog instead of the current dialog
Last modified: 2020-11-26 15:33:20 UTC
Please describe the problem: Typing a complete path, like /tmp/screenshot.png, into the name entry in the screenshot tool does not work. No error is shown and no file is written. Furthermore "handle_transfer_vfs_error" is written to ~/.xsession-errors everytime I tried this. Steps to reproduce: 1. Open "Desktop" on the panel 2. Select "Take screenshot" 3. Type a full path into the name entry, eg. /tmp/screenshot.png Actual results: Nothing, all seems fine, but isn't. Expected results: I would expect the file to be written to the path I typed. Does this happen every time? Yes. Other information: Using the provided directory picker is not an option (merely a workaround). It takes a lot more time if you do several shots (even though it remembers the last used location).
confirmed with gnome-screenshot HEAD.
the patch below shows the error to the user. if I try to use "/tmp/shot.png" as the target filename, though, the error is "File not found" - which means that there's something deeper in the logic of the screenshot file creation that is triggered by this behaviour. wouter, could you please apply this patch to gnome-screenshot HEAD and verify that it shows a "File not found" error dialog? maybe it's a bit too late to try and fix this for 2.13.5, but I'll see if I can shovel this before the 2.14 release.
Created attachment 57465 [details] [review] show error dialog
uhm, it seems that the temporary directory is being created using its own algorithm (cfr: screenshot-save.c:make_temp_directory) instead of using the standard glib wrappers or - better - why it has to create a directory instead of just creating a temporary file using g_mkstemp()? anyway, it seems that the target file name is built using the last saved directory; the file entry is just for the file name, and cannot accept a path; e.g.: last_saved_directory = "/some/path" entry = "/tmp/shot.png" target_uri = "/some/path" + "/tmp/shot.png" = "/some/path/tmp/shot.png" and, quite obviously, if "/some/path/tmp" is not a valid path by sheer luck, gnome-vfs will complain that the "file was not found". this means that gnome-screenshot should either dump the filename entry + directory chooser and use a FileChooserButton, or alert the user with a Big Fscking Warning. I'd prefer the former solution, which would allow us to insert a file name *and* a complete path. I'll try and come up with a patch, after 2.13.5. jrb: what do you think?
I think the best solution is to kill the file entry completely and just use GtkFileChooserButton, since this is the standard GNOME widget for filenames.
Oh, and if only a GtkFileChooserButton is shown, it could be positioned below the thumbnail to make the dialog nicer: +======== Save Screenshot ========+ | | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXX preview XXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | | | Filename: [chooserbutton] | | | | [Help] [Cancel] [Save] | +---------------------------------+
comment #6 - indeed, it should be nicer with a vertical layout, also for smaller resolutions. right now there's a lot of unused space below the entry/directory chooser; a vertical layout would sensibly reduce it a make the window appear more compact.
Created attachment 57489 [details] [review] Quick patch to the glade file to create a vertical layout Try this patch (against current CVS HEAD) if you want a vertical layout in the dialog (just like my ascii art).
*** Bug 314446 has been marked as a duplicate of this bug. ***
Any progress with switching to using GtkFileChooser? Here's my use case: we have screenshots that we've named appropriately for ourwebsite, etc [ie, not the default name that is composed out of the window title full of spaces and what not] and as my applications evolve I like to update the screenshots. Which means selecting a specific file[name]. As it is now, following the drop down directory list, then picking Other, you can only pick the directory. There seems little reason not to just use FileChooser[Button] full on. This all seems still applicable as at 2.14 AfC
sorry, I did not have time to work on this in the 2.15 cycle, and now we are in UI freeze. pinning down for 2.17/2.18. as for the UI re-design: a simple GtkFileChooserDialog with a preview widget (drag and drop capable) should really be enough for every use case: we would have the capability of deciding the full name of the file using the GtkFileChooser UI. this might be a nice job for a new programmer of the platform, by the way. the current screenshot-dialog widget should be remove and all the UI interaction should be wrapped around in a sub class of a GtkFileChooserDialog widget, adding a preview widget with the drag source targets set. the hard part is to keep the async machinery that saves the pixmap to a temporary location on the disk inside a child process.
retitling for clarity, sorry for the spam.
as I said on desktop-devel-list, after the switch to a GtkFileChooserDialog or a GtkDialog+GtkFileChooserWidget save dialog, gnome-screenshot should provide a that dialog (e.g. GnomeScreenshotDialog) for other applications to use, like Totem, in a shared library object.
attaching some mock ups with the horizontal and vertical layout and an embedded GtkFileChooserWidget.
Created attachment 72345 [details] vertical layout, collapsed
Created attachment 72346 [details] vertical layout, expanded
Created attachment 72347 [details] horizontal layout, collapsed
Created attachment 72349 [details] horizontal layout, expanded
The horizontal layout won't fit many screens. The vertical layout looks good, though.
(In reply to comment #19) > The horizontal layout won't fit many screens. The vertical layout looks good, > though. The vertical layout barely fits on my 1280x800 screen, once expanded. I'm not sure it's such a good idea to have the other folders be available directly from the same dialogue.
I used a 350x220 preview of the screenshot; it could be smaller. > The vertical layout barely fits on my 1280x800 screen maybe we could switch layout depending on the screen width/height ratio. > I'm not sure it's such a good idea to have the other folders be available > directly from the same dialogue ideally, most of the time you should not have to resort to the expanded form: the name field does tab completion; the problem is: how do I mimic a GtkFileChooserDialog without having to reimplement most of it? also consider that the GtkFileChooser interface is not public, so I *cannot* reimplement most of it yet.
Using a xinerama setup with horizontally adjacent monitors, I'd prefer the vertical layout. But then again, there might be some people having a vertical xinerama layout. I agree on comment #20 and don't think that choosing the destination folder should be on the same dialog. Having a text field and a "browse" button should be enough, but only if the text field accepts path names.
*** Bug 436475 has been marked as a duplicate of this bug. ***
Could we please decide on this bug? I'd strongly vote for a vertical layout. Not sure whether an expander with some file chooser UI is a good idea, a GtkFileChooserButton suffices for me.
+======== Save Screenshot ========+ | | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXX preview XXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | | | Folder: [chooserbutton] | | Filename: [filename entry] | | | | [Help] [Cancel] [Save] | +---------------------------------+ This perhaps?
As I find the splitting of filename in one field and folder-selection (possibly via dialog) in another field error-prone and cumbersome, I vote for GtkFileChooserWidget as in #15 to #18. (Which I understand is very similar to GtkFileChooserDialog). I'm not sure how a GtkFileChooserButton (comment #6 and #24) works when clicked/expanded. Can you tell me some standard application where I can see it in action? Or describe or make a screenshot with it "expanded" so I can make a statment concerning GtkFileChooserWidget vs. GtkFileChooserButton. As to vertical vs. horizontal it does not really matter to me. But, I can't avoid commenting anyway: I think vertical looks good when collapsed and horizontal when expanded, and I personally never save screenshots in Desktop so I always must expand the chooser, therfore I could vote for comment #18 (horizontal, initially epanded). The screen-resolution must of course be taken into account. Personally I don't see the need for such a large preview, shrink it when the GtkFileChooserWidget is expanded, or let the image be smaller from start (possibly vertical layout then). If I press PrintScreen then I surely know why I did it, and what was on my screen at that moment, having the image in the dialog as confirmation is good, but it does not need to dominate completely.
*** Bug 513648 has been marked as a duplicate of this bug. ***
While you're working on this, please consider adding an 'Edit' button to the dialog, so that an image editor will open the image, instead of saving it. This covers the 'I usually do some editing on the image before really saving it' use case. See http://bugs.debian.org/465478.
*** Bug 554328 has been marked as a duplicate of this bug. ***
*** Bug 567600 has been marked as a duplicate of this bug. ***
*** Bug 635690 has been marked as a duplicate of this bug. ***
*** Bug 614418 has been marked as a duplicate of this bug. ***
The discussion from this ticket is fairly old. Right now looking at GtkFileChooser I see that there are properties for an extra-widget and a preview widget, so I think this could be solvable with simply overriding some methods of GtkFileChooserDialog (implementing GtkFileChooser) to add the screenshot preview above the file selection. I would be interested in working on it, once it's clear what should be done: vertical vs horizontal layout (file selection below or next to the screenshot preview) and filename entry + directory selection vs file chooser widget.
GNOME Screenshot has been completely redesigned[0], so I think we can close this as obsolete. [0]: https://help.gnome.org/misc/release-notes/3.38/#utilities