GNOME Bugzilla – Bug 682129
[PATCH] Print Dialog / Improving "Print to file" option
Last modified: 2012-09-01 02:52:06 UTC
Created attachment 221679 [details] Screenshot of the new "Print to file" dialog. As I wrote a few days ago on the gnome-devel-mailing list, the "Print to file" option in the Gtk print dialog is highly annoying. This patch improves the print to file options as follows: * Remove the file_chooser widget (which could only select folders) * Add a "Browse" button which opens a file chooser dialog to select path AND filename * Allow manually editing the entry files: ~/ is expanded to home directory non absolute filename string is expanded to home directory absolut filename string is used as is The only thing that could be improved is the fact that the GtkEntry containing the filename is rather small. Unfortunately I could not figure out where the radio buttons for "PDF", "Postscript" and "SVG" are added. I would suggest to move the options into a second row under the radio buttons.
Created attachment 221680 [details] [review] Fix for this bug See my previous message.
(In reply to comment #0) > Created an attachment (id=221679) [details] > Screenshot of the new "Print to file" dialog. > > As I wrote a few days ago on the gnome-devel-mailing list, the "Print to file" > option in the Gtk print dialog is highly annoying. The reference to the discussion is ambiguous, it is much better to link the archives: https://mail.gnome.org/archives/desktop-devel-list/2012-August/msg00062.html
As you can see from mockups attached to bug #668529 I would propose to remove any print-to-file specific option from the main dialog and add a standard save as... dialog for file name and format retrieving.
Well that would of course be the best solution, but I believe that would require much more changes than my current patch, so until someone wants to fir bug #668529, i think my patch is at least an improvement to the situation.
Maybe it't time to revert bug 157384 ?
IHMO separating folder selection and file name selection is not a good idea. It gives the user an uncomfortably high amount of work just to achieve a simple task. When ever a file needs to be saved, I think it would be best to have only one widget or dialog, where the user can navigate to the right folder, and then enter the choosen filename. Of course we should still use sensible presets for the filename if possible.
Can you attach a screenshot to know how it looks now?
(In reply to comment #5) > Maybe it't time to revert bug 157384 ? In regard of GtkFileChooserButton, I'd like to remind you it's kind of broken: bug 645065.
I'm not sure what exactly is broken. Can you please explain?
Diego, there is already a screenshot attached that shows how it looks now, have you seen it?
Created attachment 221752 [details] [review] Replace user home prefix with ~ The GtkEntry for the filename is very short, which makes it difficult to read the whole filename. This patch improves the filename by automatically replacing /home/<username> by the '~' shortcut. Internally of course the expanded version is still passed on, when the file is saved.
Created attachment 221759 [details] [review] Replace user home prefix with ~ The last patch was a bit buggy, this one should get it right.
As Luca mentioned in Comment #3 there is a better solution to this bug, which is already being tracked at bug #668529, so I'm closing this as a duplicate of that bug. *** This bug has been marked as a duplicate of bug 668529 ***
(In reply to comment #9) > I'm not sure what exactly is broken. Can you please explain? As I wrote in that bug over a year ago, it's not exactly an expected behavior if clicking Cancel/closing the dialog unsets the previously chosen name on the button.
Created attachment 222830 [details] [review] Add a button to browse for the filename
Review of attachment 222830 [details] [review]: ::: gtk/gtkprinteroptionwidget.c @@ +48,3 @@ static void construct_widgets (GtkPrinterOptionWidget *widget); static void update_widgets (GtkPrinterOptionWidget *widget); +static char* trim_long_filename(char* filename); Space before (. Here and in many places further down @@ +494,3 @@ + GTK_FILE_CHOOSER_ACTION_SAVE, + GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, + GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT, Not sure that SAVE is really the best here. I might go for SELECT instead, but not a big deal. @@ +497,3 @@ + NULL); + + gtk_file_chooser_set_do_overwrite_confirmation (GTK_FILE_CHOOSER (dialog), FALSE); Why no overwrite confirmation ? @@ +498,3 @@ + + gtk_file_chooser_set_do_overwrite_confirmation (GTK_FILE_CHOOSER (dialog), FALSE); + //select the current filename in the dialog no // comments @@ +505,3 @@ + { + gtk_file_chooser_select_uri(GTK_FILE_CHOOSER(dialog), last_location); + GFile* file = g_file_new_for_uri(last_location); Move variable declarations to the beginning of the block, please. Throughout this patch @@ +515,3 @@ + } + + if (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT) We try to avoid gtk_dialog_run (and recursive mainloops in general) nowadays. We should just make this a modal dialog, and connect to the response signal. @@ +552,3 @@ + gchar *uri; + + filename = g_filename_from_utf8 (gtk_entry_get_text (GTK_ENTRY (priv->entry)), Looks like a lot of unnecessary churn here due to the file -> filename rename. Just keep the name. @@ +886,3 @@ gtk_grid_set_column_spacing (GTK_GRID (priv->filechooser), 12); + //priv->entry = gtk_entry_new (); Leftovers ? @@ +931,3 @@ +/** + * If the filename exeeds FILENAME_LENGTH_MAX, then trim it and replace the first + * three letters with dots. FILENAME_LENGTH_MAX doesn't seem to be defined or used ?! @@ +965,3 @@ + if(filename_short != filename_home_prefix) + g_free(filename_home_prefix); + return filename_short; I think there's some refinements we can do here, but this is a good start. One refinements might bo to make sure that the character after the ... is not a .
Playing with this, I get
+ Trace 230765
Created attachment 223059 [details] [review] Fixes the point that mclassen pointed out in his review > Space before (. Here and in many places further down Done. I hope I didn't oversee any thing. > Not sure that SAVE is really the best here. I might go for SELECT instead, but not a big deal. There is no GTK_STOCK_SELECT text > Why no overwrite confirmation ? The confirmation is happens when the user clicks "Print", I have added a comment explaining this. I could prepare another commit that would remove the confirmation dialog in gtk/gtkprintunixdialog.c (error_dialogs function) and then enable it here. But I would like to finish this patch first. > no // comments Done. > Move variable declarations to the beginning of the block, please. Throughout this patch Done. >We try to avoid gtk_dialog_run (and recursive mainloops in general) nowadays. >We should just make this a modal dialog, and connect to the response signal. Done, though I had to add a new variable last_location to the private structure to get this working. >Looks like a lot of unnecessary churn here due to the file -> filename rename. Just keep the name. I just removed that stuff entirely as this callback became unnecessary. > FILENAME_LENGTH_MAX doesn't seem to be defined or used ?! Now it is defined. Also the stack trace you posted is resolved now and I have cleanup the patch to remove any leftover code that is not being used anymore.
Pushed, after some more reworking