GNOME Bugzilla – Bug 650239
print chooser blocks needed information in window below
Last modified: 2021-07-05 14:31:46 UTC
Regularly I log into various accounts online and download PDF statements and bills for safekeeping. In the midst of this today I noticed that when I go to 'print to PDF' from within an HTML statement, the print chooser dialog pops up as a sheet and covers up the service date on the bill, which I use to decide a name for the PDF file in the print chooser. Since I can't read the date, I don't know what name I should be giving the file. I'm going to work around this by getting a pad of paper and writing down the date before printing to pdf, but that is a less than desirable solution. Possible ideas?: - Is there some way a keycombo could be added so I could hit alt or something and middleclick drag the window out of the way? - As has been suggested in the past for GIMP palettes to maximize visibility of artwork underneath, could the print chooser dialog (or any immovable dialog blocking information) be rendered as partially transparent? - Make it so you can drag the sheet along a constrained horizontal axis? (I'm not sure this would be enough to show the date in these statements though) Thanks
Tricky one because really this is "Save as PDF" and not really print at all. For saving it would be best for the save dialog to show you some metadata directly - including of course a suggested name which would likely just solve your problem. (Longstanding peeve of mine)
There's a long discussion on another report about these modal dialog, mainly with the file chooser, which is a very similar use case. I think that's essentially a duplicate but - Damn, I can't find it! As for the file chooser guessing a nice name, that would maybe work for Web pages, but for PDFs very often the title given in the meta-data is completely stupid, and the real title is on the first page of the document. Hard to fix without changing the minds of all PDF producers on Earth. ;-)
Hi Milan, exactly. The problem is that the positioning of this dialog where you must choose a filename is typically directly over the title of a document, which you would like to (but cannot) refer to in naming the file. :(
Ah, that wasn't a bug report, but a thread on the mailing list. It's quite long, but a few interesting points were made (among which the ones we've just raised): http://mail.gnome.org/archives/gnome-shell-list/2011-May/msg00362.html
And one solution is to write in the HIG that printing and saving dialogs are too complex to behave like other dialogs, so they shouldn't be made modal. That's what Evince does ATM, but e.g. not Firefox; so we need a rule for that either way anyways.
Printing is not too complex. You choose a printer and print. File saving should have context available. The solution should not be: make the user move windows around to get the job done.
(In reply to comment #6) > Printing is not too complex. You choose a printer and print. Yeah, probably. > File saving should > have context available. The solution should not be: make the user move windows > around to get the job done. "Have context"? Precisely, how can we give the user access to the data that's shown in the document, given the app cannot guess it? I know really sounds stupid, but that breaks the workflow when saving documents you've just read.
The app doesn't have to guess - in many cases it already knows. And when it doesn't it can provide a very educated guess as a default. We need new designs for file saving dialogs. One of the more important parts of any Finding and Reminding work.
(In reply to comment #8) > The app doesn't have to guess - in many cases it already knows. And when it > doesn't it can provide a very educated guess as a default. That doesn't work. :-( Open any of the 20 PDFs from [1], and save them. You'll rarely useful title from Evince, mostly something with only author names, or weird numbers. This is a good sample of what titles academic papers have saved as PDF metadata. In most cases, I need to retype the title I read from the first page. That's potentially the same problem with many webpages. 1: http://olivier.godechot.free.fr/hoprubrique.php?id_rub=57
You don't need to save a pdf as pdf. web pages all have titles.
I won't claim my own little use case should draw the whole design, but I do save PDFs as PDF, just because my usual workflow is: 1) click on a link on a webpage to open it in Evince 2) see if the document is what you want/expect, and/or read it 3) save it under a name meaningful to me (author name + real title usually) The other solution is to right click on the link, save the file somewhere, and then find and open it to check it's correct. Not efficient, and you still need to find the title information somewhere (e.g. long title, author name orthography...).
Dude, that is not at all what we're talking about here. Evince has a separate menu item for that. This is about the print dialog.
Since the answer from Máirín in comment #3, I've assumed we'd deal with both printing and saving dialogs in this report (since they were raised in the mail thread too). Sorry if I didn't make it clear. Anyway, I gave you all of my arguments, so I'll stop spamming the report.
*** Bug 650180 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.