Created attachment 137421 [details] [review]
this does it

is g_get_user_special_dir (G_USER_DIRECTORY_DOCUMENTS) always guaranteed to not return null?

Also, the patch hardcodes .pdf, what happens if ps is selected instead in the print dialog? can we inspect that setting and figure out the rigth extension?


(patch looks good apart from the above comments)

Oh,  you are right about g_get_user_special_dir possibly returning NULL. Need to handle that.

Wrt to .pdf, the print dialog replaces the extension when you change to ps, afair. Quick testing seems to confirm that.

Created attachment 137425 [details] [review]
handle NULL dir

well, what I meant is the case when the dialog comes up set to ps in the first place (it happens here if you set ps the last time you used it)

Also, the second patch doesn't actually use the dir variable when constructing the uri.

Yeah, but hold on anyway. I just discovered that this doesn't work correctly when switching between cups and file printers anyway. Switching back and force replaces the nice name by the default output.pdf. Something to fix in GTK+ first, I guess

Created attachment 137441 [details] [review]
last version of the patch

Thinking again about it, maybe we should get the dirname of the file instead of using documents dir?
I have to admit I am not a user of the "Documents" directory etc, so I am biased, but putting it alongside the actual file seems a better idea to me.

apart from that the patch looks good to me... it is not clear to me if we should wait for the gtk bug to be fixed or if it is safe to apply with older gtk.

Hello Paolo,

Could you take a second look, now that the blocker bug is fixed?

As said in the previous comment, I am not a big fan of the "Documents" xdg dir, I never find stuff in it.

That said, the patch is better than what we have now so I am not opposed to including it.

However I wonder if we should not improve the gtk api instead: it is a bit lame to have to do "if (ps) ext=.ps else ext=.pdf" in all the apps: maybe gtk could have print settings for OUTPUT_DIR_URI and OUTPUT_BASENAME and figure out the extension itself

I have filed a blocker bug here: https://bugzilla.gnome.org/show_bug.cgi?id=657322

(In reply to comment #12)
> I have filed a blocker bug

...adding it to Dependency list.

I have submitted a patch to support the new GTK settings in bug 657322

Created attachment 214914 [details] [review]
Set default print to file filename to short document name

Updated patch to use new print settings currently in gtk master

ping - can Timothy's patch get a review?

I think we should set GTK_PRINT_SETTINGS_OUTPUT_URI instead of BASENAME, or maybe both? Besides that the patch looks good.

Review of attachment 214914 [details] [review]:

The patch is great. It would be really nice if this could get commited. Despite what i wrote in Comment #17, the BASENAME is just fine.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

Sorry for the loooong delay and thanks for the persistence in getting this issue fixed.

Just curious here: I found this report while searching before almost submitting a similar report on the six year anniversary of this annoyance, because I haven't seen this fixed in the latest fully updated Ubuntu or Linux Mint. 

But as stated above, the issue was patched nearly a year and merged over half a year ago. Is this fix still 'too new' or do they need to actively implement or backport this fix before 'we' (end users) can throw a party over this?

The fix hit the development version of gedit only a month before the last Ubuntu release so its most likely not in there yet. The 13.04 release of Ubuntu should have it though which is due out this month (April 25th)