GNOME Bugzilla – Bug 668529
print to file defaults to output.pdf
Last modified: 2013-05-29 05:04:39 UTC
When I print to a file it defaults to ~/output.pdf apparently. This isn't very nice because it makes me do a lot more work than is needed in most cases. The home directory is not a good place to save documents and defaulting to output.pdf means that either I'll never find that file again, I'll end up overwriting it, or I have to do work to come up with a name for it. I think we should default to save: ~/Documents/$TITLE_OF_PAGE.pdf
I don't see how this is an Epiphany issue as gedit has the same behavior. Moving to gtk+/printing.
Created attachment 221353 [details] gtk-print-to-file-mockup_1 What about making the "print-to-file" more similar to a standard printer removing the extra options from the print dialog and add a second "Save as..." standard dialog after the click on the "Print" button with a file format combobox (or anything similar, like retrieving the file format from file extension)? See attached mockups.
Created attachment 221354 [details] gtk-print-to-file-mockup_2
For the record, OSX does something like that. When selecting Save as PDF you get a Save As dialog. I think it makes sense that you are not "printing" but "saving a file".
So in order to solve this bug, we would need to: 1. Change the print button from "Print" to "Save". [PATCH AVAILABLE] 2. When save is clicked display the Save dialog (which also offers the type selection) 3. Remove the overwrite confirmation dialog and let the save dialog handle this 4. Remove the print to file specific option I'm not really sure which function handles the callback when Print is clicked right now, could someone point me to it? Anyway it should be possible to adjust my patch for bug #682129 (which adds the browse button). For three: The "error_dialogs" callback needs to be changed and the error confirmation stuff removed. For four: I would guess this needs to be changed in the printer backend at: modules/printbackends/file/gtkprintbackendfile.c I have already prepared a patch for 1., its not much but something to get started with. If I would get a pointer to the callback function that needs changing, then I could also provide more patches. Best Regards Sebastian
Created attachment 221763 [details] [review] Change text in print button to save See my last comment
Review of attachment 221763 [details] [review]: ::: gtk/gtkprintunixdialog.c @@ +1447,3 @@ + if (option != NULL && + option->type == GTK_PRINTER_OPTION_TYPE_FILESAVE) + { Coding style: Oneliner if and else do not use brakets in the surrounding code. See e.g. line 341. If they had more than one line the brakets would have a line of their one, see e.g. 868. See the surrounding code. @@ +1448,3 @@ + option->type == GTK_PRINTER_OPTION_TYPE_FILESAVE) + { + gtk_button_set_label(GTK_BUTTON(priv->print_button), GTK_STOCK_SAVE); Coding style (twice): No space between function name and braket for arguments. See the surrounding code.
Created attachment 221788 [details] [review] Change text in "print"-button to "save" Fixed the formating issues that Andre mentioned.
Created attachment 221790 [details] Screenshot with the save button.
Created attachment 221830 [details] [review] Display the file chooser dialog with filter This is the second patch. * It removes the entry and file chooser widgets. * It displays the file chooser dialog when save is clicked * The file chooser dialog automatically uses a correct filter according to the currently selected output format. The reason I have not removed the output format options as well is as follows. The output format options are created by the printerbackendfile.c according to the supported output formats. If these would be moved to the file chooser dialog, then the dialog would need to knwo about the supported formats, but that seems not like such a good design, so I have left the options in place and added a filter to the file chooser dialog instead. Known issues: The file type extension is currently not appended automatically. So this could probably be improved by checking if the user added the file type extension, and then add the extension if its not there. See also commit 8d1f32aaafedce6326b0dbd837dc5503e889a60e for this.
Created attachment 221831 [details] This is how the print dialog looks now.
Created attachment 221832 [details] This is the file chooser dialog with the filter set to pdf
Created attachment 221850 [details] [review] Presets the file name and appends the file type extension This is the third patch. It gets the file name according to the GTK_PRINT_SETTINGS_OUTPUT_URI from the print settings and sets it in the file chooser dialog. After the dialog returns it checks if the extension matches the currently selected output format and appends the extension if this is not the case.
*** Bug 682129 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > So in order to solve this bug, we would need to: > > 1. Change the print button from "Print" to "Save". [PATCH AVAILABLE] > 2. When save is clicked display the Save dialog (which also offers the type > selection) > 3. Remove the overwrite confirmation dialog and let the save dialog handle this > 4. Remove the print to file specific option > I'm not a big fan of dynamically changed UI, so I would skip step 1, keeping the "Print" label on the button (indeed we are still printing :).
Created attachment 222111 [details] [review] Presets the file name and appends the file type extension Update the the third patch which sets the filename in the file chooser and appends the extension. Now the basename of the file will now be correctly displayed in the file chooser dialog, even if the file does not exist yet.
The general opinion I got from our designers is that bringing up a second dialog when you click 'Save' is really not a good direction to go in. What I'd like to focus on in the short term is to make our default filename better than 'output.pdf'. Can we get a patch to change it to '<appname> <date>.<format>' ? Longer-term, the direction we want to go with the print dialog is outlined in https://live.gnome.org/GnomeOS/Design/Whiteboards/Printing
From what I can see in the mockups in this and other bugs, this is just what people requested, and I dont see the problem with having a file chooser dialog, after all that is already specialized for choosing files, why should we come up with another solution? Also the output.pdf thing is already changed, to provide a more reasonable default name [1] and bug #657322: * If GTK_PRINT_SETTINGS_OUTPUT_BASENAME is set then the destination will default to ~/Documents/<basename>.pdf * If its not set, then we default to ~/Documents/output.pdf The application can also change the folder by specifying GTK_PRINT_SETTINGS_OUTPUT_URI. > Can we get a patch to change it to '<appname> <date>.<format>' ? Yes, that would need to got to around gtkprintbackendfile.c:251. This would not be too complicated. But just making the default file name better is not the ultimate solution, but just a small step forward. Very often people will want to put the file into a different folder or rename it or both, and in that case the current implementation is just not enough, so I would rather like to see this fixed in 3.6 than to wait till 3.(add a high number here) until someone rewrites the whole print dialog, after all this bug is already half a year old. Personally I really don't like the folder chooser widget, because I almost ALWAYS have to click on "Other..." to choose the right folder. For example I have folders like Documents or Code or Pictures in the Bookmarks, but normally when I want to save a picture or a text file, it won't save it directly into the Pictures folder but into some subfolder, and therefore I need to click "Other...", everytime that happens I miss the comfort of the file chooser dialog. And anyway, we can fix this for 3.6 and then go and rewrite the print dialog later. [1] https://live.gnome.org/GnomeGoals/PrintToFile
> And anyway, we can fix this for 3.6 and then go and rewrite the print dialog > later. But we don't have agreement that the 'fix' proposed here is an improvement.
Since there was no agreement on the solution I'm not going to propose the patch for commit.
To get back to the original point made by William in the description. GTK+ already defaults to: ~/Documents/$TITLE_OF_PAGE.pdf if GTK_PRINT_SETTINGS_OUTPUT_BASENAME is set by the application, and ~/Documents/output.pdf if its not set. Therefore I think this is fixed in the GTK+ printing part, and we should open another bug to track the progress of individual applications (see the PrintToFile GnomeGoal [1]). [1] https://live.gnome.org/GnomeGoals/PrintToFile
This bug should be closed. Or marked as a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=657322 In the above bug report I made improvements to GTK printing so that its much easier from applications to set the name/base directory for the output file. Also from comment 2 "I don't see how this is an Epiphany issue as gedit has the same behavior." This is no longer true Gedit uses the updates I made to the printing API see: https://bugzilla.gnome.org/show_bug.cgi?id=587053. Maybe this bug should be reassigned back to Epiphany.
I agree this bug should be closed as fixed. There is a PrintToFile [1] gnome goal for the printing changes . I have just created a tracker bug [2] for the PrintToFile GnomeGoal. I suggest we create a new bug for each affected application and register it to the tracker bug. [1] https://live.gnome.org/GnomeGoals/PrintToFile [2] https://bugzilla.gnome.org/show_bug.cgi?id=686927
*** This bug has been marked as a duplicate of bug 686927 ***