After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 563619 - Print dialog: Print pages / print range: Remove one redundant user action from the gnome print dialog box
Print dialog: Print pages / print range: Remove one redundant user action fro...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Printing
unspecified
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-12-08 00:28 UTC by Nick Jenkins
Modified: 2010-02-03 06:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
patch removing the redundant step (382 bytes, patch)
2009-03-31 11:48 UTC, Marek Kašík
none Details | Review

Description Nick Jenkins 2008-12-08 00:28:18 UTC
Currently when the user wishes to print a subset / range of pages, from a gnome app (e.g. gedit), they need to do the following 4 things:
1) Go File -> Print...
2) Click the "Range" (in 2.22) or "Pages" (in 2.24) radio button. When the user does this, the text field to the right of the radio button (for typing the page numbers to print) that was inactive / greyed out will now become active.
3) Click inside the text field to the right of the radio button
4) Type out which page numbers they want printed (e.g. "1-2").

However, in the above scenario, step 2) is redundant and unnecessary for the above workflow. This is because, as soon as the user starts typing inside the "Range" or "Pages" text field, it is implicit that they want a range of pages to be printed.

Instead, the workflow could be 3 steps, as follows:
1) Go File -> Print...
2) Click inside the text field to the right of the radio button (which is always active)
3) Type out which page numbers you want printed (e.g. "1-2"). Once the user starts typing, the "Range" or "Pages" (in 2.24) radio button is automatically selected (if it is not already selected).

Please note that the above workflow is how various programs on Windows (e.g. MS Word) behave when printing a range of pages, and it seems to work well (seems to have no redundant steps, and seems unambiguous).

Other information:
P.s. I am not sure if this usability enhancement should be filed under "gnome-print" or under "gtk+", so my apologies in advance if it's under the wrong component.
Comment 1 Nick Jenkins 2008-12-12 01:57:48 UTC
One small variation on this idea that I have noticed in Adobe Acrobat reader for Linux is to have the page range automatically filled out - e.g. if the document has 5 pages then the print range text will be filled out to say "1-5" by default, and clicking in the text field automatically selects the right radio button. That makes it easier for people to know what the know what the correct format is, and may (depending on what you want to print) save one keyboard press, and also shows how many pages there are.
Comment 2 Matthias Clasen 2008-12-13 05:11:22 UTC
Sounds plausible.

What we should do at a minimum is to move the focus to the entry when the user selects the last radio option.
Comment 3 Marek Kašík 2009-03-31 11:48:10 UTC
Created attachment 131769 [details] [review]
patch removing the redundant step

Hi,
this patch grabs focus for the entry widget when its radio button is activated.
It doesn't grab focus when the entry widget is clicked, because the widget is not sensitive (it doesn't receive necessary signals).
It doesn't prefill the entry with the page range because GtkPrintUnixDialog doesn't have an information about number of pages.

  Marek
Comment 4 Matthias Clasen 2009-03-31 14:50:57 UTC
Patch makes sense. Please commit to git once the git conversion is done.
Comment 5 Nick Jenkins 2009-04-01 22:36:41 UTC
> this patch grabs focus for the entry widget when its radio button is activated.

Thank you, that sounds great!

> It doesn't prefill the entry with the page range because GtkPrintUnixDialog
> doesn't have an information about number of pages.

Fair enough - if that information is not available to the print dialog (which I suspected might be the case), then it's just not possible - thanks for clarifying this.

> It doesn't grab focus when the entry widget is clicked, because the widget
> is not sensitive (it doesn't receive necessary signals).

Do you mean that when the user types in the page range, that the radio button is not activated? If so, if there some alternative way that this could be done? Speaking from a purely personal end-user perspective, I'm sure that this is the method that I'd use the most, if it was possible - i.e. have the page range textbox active, with any typing/change/modification in that textbox resulting in the "Pages" radio-button getting auto-selected.
Comment 6 Matthias Clasen 2009-04-11 05:50:25 UTC
I've done this already
Comment 7 Nick Jenkins 2010-02-03 06:41:53 UTC
> I've done this already

I don't think this is done - I have just upgraded to Gnome 2.28.1, and clicking the print range radio button will focus the field for entering the range (yay! thank you!), but the reverse does not work as the field for entering the range is greyed out (boo!).

The updates made so far are great and a big improvement, but is there some way to solve the remaining unsolved half of this? Adding the necessary signals or somesuch?

I.e. so that clicking in the range text field and typing something would a) be possible (even when something else like "All pages" was selected) and b) would automatically select the "Pages:" print range radio button.

Happy to log it as a new request if that's the best way.