Bug 134640 - Print dialog: dialog size is not remembered after reopening (GEN)
Summary: Print dialog: dialog size is not remembered after reopening (GEN)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.1 all versions
Hardware: All All
: high minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 134274 135426 135690 136797 137266 140094 147946 (view as bug list)
Depends on:
Blocks: Print-Dialog Dialog-Remember-Settings
  Show dependency treegraph
 
Reported: 2020-07-08 08:46 UTC by Telesto
Modified: 2022-09-01 15:43 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot Table of contents dialog (77.82 KB, image/png)
2020-07-08 09:16 UTC, Telesto
Details
Quick and dirty shuffle (273.58 KB, image/jpeg)
2020-07-08 10:13 UTC, Telesto
Details
Screencast of different option (1.03 MB, video/quicktime)
2020-07-14 10:20 UTC, Telesto
Details
Another print dialog screencast: Acrobat Reader (183.67 KB, image/gif)
2020-07-14 10:41 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-08 08:46:55 UTC
Description:
UI: Printer settings hidden under more

Steps to Reproduce:
1. Open Writer/Impress
2. Press the print button

Actual Results:
Range and copies.. has a 'more button'.. but 
(a) you have to click to know what behind it
(b) It are rather common settings (duplex, or number of copy's)
(c) It's certainly so small to fit a small screen with all settings open

Expected Results:
Make it a wider screen.. bit like the Insert the Insert Table of content..
Slides number box can be smaller.. So with some shuffling it should fit


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: c48e4d795e37f23b71d647247590807ab9e52223
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-07-08 08:52:07 UTC
Sorry the bring this thing up again.. As this dialog is being redesigned recently..

And yes, I didn't follow the whole discussion back then.. so pointers or summary :-). Not that it really matters.. the current design isn't it. Someone needs to shuffle some things around with a dialog builder (or make a mock-up).

And no, I don't think people will be overblown by a few more settings visible 

Take the size - of the Insert table of content..
Comment 2 Mike Kaganski 2020-07-08 08:58:14 UTC
(In reply to Telesto from comment #0)
> (c) It's certainly so small to fit a small screen with all settings open

See https://ask.libreoffice.org/en/question/254028/ though.
Comment 3 Telesto 2020-07-08 09:16:32 UTC
Created attachment 162783 [details]
Screenshot Table of contents dialog
Comment 4 Heiko Tietze 2020-07-08 09:29:54 UTC
The dialog has to fit on small screens, see bug 127782 (and duplicates).

It boils down what properties are most common and, to less extend, what properties belong together. Duplex is likely nothing all users have on the printer and if we would move the number of copies into the visible part we'd also have to take the order. I don't see alternative except we split the options again, as it was before, and you have to go to another tab.
Comment 5 Telesto 2020-07-08 10:13:37 UTC
Created attachment 162788 [details]
Quick and dirty shuffle

The dialog has to fit on small screens, see bug 127782 (and duplicates).

It boils down what properties are most common and, to less extend, what properties belong together. Duplex is likely nothing all users have on the printer and if we would move the number of copies into the visible part we'd also have to take the order. I don't see alternative except we split the options again, as it was before, and you have to go to another tab.

What is common is open for debate. I have a duplex printer. And rather common in offices I assume (also a targeted group). Hiding things behind more buttons is frustrating. As no don't know what you get. Tabs are already better, but I prefer not to much tab switching.. 

Made a reshuffle... however not measured things.. so maybe still too large
Comment 6 Heiko Tietze 2020-07-08 10:21:21 UTC
(In reply to Telesto from comment #5)
> Created attachment 162788 [details]
> Quick and dirty shuffle

More dirty than quick shuffle. The even/odd thing is now in an extra dropdown. And I disagree with randomly placed radio buttons. You also removed all "more" sections but controls and spacing is typically more narrow on Windows. 

A potential solution is to expand/remove the more sections and require scrolling.
Comment 7 Telesto 2020-07-08 10:34:30 UTC
(In reply to Heiko Tietze from comment #6)
> (In reply to Telesto from comment #5)
> > Created attachment 162788 [details]
> > Quick and dirty shuffle
> 
> More dirty than quick shuffle. The even/odd thing is now in an extra
> dropdown. And I disagree with randomly placed radio buttons. You also
> removed all "more" sections but controls and spacing is typically more
> narrow on Windows. 
> 
> A potential solution is to expand/remove the more sections and require
> scrolling.

Could be part of the solution.

Randomly placed radio buttons.
-> yes, didn't really think this through.. However, the list is also 'random' to me. Why is selection at the bottom?. And the large 'page' input field makes no sense.. How many pages can a document contain.. there is room for a very very large number :-)

And the whole list is wasting precious space. 

So vertical alignment makes sense to me
* All pages | * Selection |* Pages [XXXXX]
* Even Pages | * Odd pages

I don't think people get confused.. Or that's 'random'. Even and odd pages are a 'set'. All pages selection, or specific page can be seen as a set.
The ratio button prevents to that both rows can be seen a separate settings
And easier to read too

However, of course my personal preferences, more input is needed
Comment 8 khagaroth 2020-07-10 16:48:49 UTC
(In reply to Telesto from comment #5)
>Duplex is likely nothing all users have on the
> printer

Well let me tell you that for users that do have duplex the current state of the dialog is rage inducing.

One solution I would suggest is to make the dialog remember it's size/state. Actually, remembering size should be a thing for other dialogs as well, because after the move to glade ui files a lot of the dialogs have cut off labels, way too narrow dropdowns and other similar issues.
Comment 9 Heiko Tietze 2020-07-13 09:56:32 UTC
Mentioned on bug 134274, we could expand the 'more' sections in case of large screens by default. No shuffling needed and easy to implement.
Comment 10 Telesto 2020-07-13 21:07:58 UTC
(In reply to Heiko Tietze from comment #9)
> Mentioned on bug 134274, we could expand the 'more' sections in case of
> large screens by default. No shuffling needed and easy to implement.

What do call a large screen HiDPI? The thing is really big if Pages to sheet set to custom on my Linux VM gen backend. Yes there are few borders of Windowed screen. And all those with lesser resolution have to do with more expand button + scrolling down. 

I prefer uniformity across the board for all screens; no second class citizens. I voting for a new tab for page layout. Caolan happy, me happy (and hopefully a lot of people :-). And it's not untested.. Or is there a list of bugs/enhancement requests related to the move of the page layout to the main screen
Comment 11 Mike Kaganski 2020-07-14 06:04:01 UTC
Please don't add more pages. (Could you please remind where is the rationale for GSoC that introduced the change btw, to keep it in mind?) It's normal practice to have collapsed sections. It just needs deciding which should be inside the collapsing regions, and which are important (current choice is largely random).
Comment 12 Telesto 2020-07-14 10:19:30 UTC
(In reply to Mike Kaganski from comment #11)
> Please don't add more pages. (Could you please remind where is the rationale
> for GSoC that introduced the change btw, to keep it in mind?) It's normal
> practice to have collapsed sections. It just needs deciding which should be
> inside the collapsing regions, and which are important (current choice is
> largely random).

I really get the objection, and it's not my first choice either. However, the current one is awfully big. You can hide stuff behind more (but always out of sight), so people can't find it.. mor expand it to look what it does, and it won't fit on screen. 

My alternative (already proposed)
(a) shrink the list of 'range of copy's. So instead of vertical list/ more horizontal. Comment 7/ and my quick and dirty reshuffle
(b) Removing the 'more"  expander space 
(c) Page per sheet -> custom -> settings maybe hidden in a dialog instead of expanding below

This should be enough for MacOS/Windows to fit on screen with everything one screen. However, not sure about GTK3/GEN/QT5. And I'm slightly out of idea's... the tab thing is more the last resort.

Number of copy's box could be reduced in size, but sure what to benefit would be.
And the orientation and paper size is less of a requirement from my point of view. I'm used to use printer properties for that. 

---
BTW, if we start redesign it again. Can the somewhat useless 'More options button' be removed too. It has only one setting which belongs to Collate anyhow. I expected multitude of options, not a single one :-)
Comment 13 Telesto 2020-07-14 10:20:08 UTC
Created attachment 163006 [details]
Screencast of different option
Comment 14 Mike Kaganski 2020-07-14 10:41:38 UTC
Created attachment 163008 [details]
Another print dialog screencast: Acrobat Reader
Comment 15 Telesto 2020-07-14 16:00:04 UTC
(In reply to Mike Kaganski from comment #14)
> Created attachment 163008 [details]
> Another print dialog screencast: Acrobat Reader

Also nice. Lets see what Heiko designs
Comment 16 khagaroth 2020-07-17 14:42:36 UTC
Please note that for the Acrobat Reader example, there would also be VISIBLE duplex settings, if the printer supported duplex.
Comment 17 Timur 2020-08-04 09:20:21 UTC
*** Bug 135426 has been marked as a duplicate of this bug. ***
Comment 18 Timur 2020-08-04 09:23:36 UTC
Could someone explain why talk about shuffle, isn't a solution possible to remember expanded state? So that only first run window is small and we expand it once for good. Not sure if Search and Replace works like that.
Comment 19 Timur 2020-08-13 19:26:30 UTC
*** Bug 135690 has been marked as a duplicate of this bug. ***
Comment 20 Timur 2020-09-16 10:03:29 UTC
*** Bug 136797 has been marked as a duplicate of this bug. ***
Comment 21 Mike Kaganski 2020-10-05 13:28:07 UTC
*** Bug 137266 has been marked as a duplicate of this bug. ***
Comment 22 simonb 2021-01-21 17:00:57 UTC
(In reply to Timur from comment #18)
> snip... remember expanded state? ...snip...
best solution for all people.
Comment 23 Matt McKenzie 2021-02-01 16:55:01 UTC
Can I just say that the current print dialog is a total pain. I have to click BOTH "more" arrows EVERY time I open it.

I have a large screen AND I have a duplex printer AND I want to check the "brochure" setting AND I want to select the number of copies.

ALSO it does some pretty weird stuff with paper sizes. I have a custom paper size defined on the printer 150mm x 320mm. I go into the printer properties dialog to check that I've selected the right things and when it returns it has set the "Paper size" under Page Layout to 105mm x 148mm. Where has it got that from?

AND having set everything up to perfection (brochure ticked, landscape format) after the dialog is closed and reopened, the preview comes up as a portrait image - until you click the <next> button under preview when it correctly shows as two pages side by side on landscape paper.
Comment 24 E Net Arch 2021-02-07 06:53:24 UTC
(In reply to Heiko Tietze from comment #4)
> The dialog has to fit on small screens, see bug 127782 (and duplicates).
> 
> It boils down what properties are most common and, to less extend, what
> properties belong together. Duplex is likely nothing all users have on the
> printer and if we would move the number of copies into the visible part we'd
> also have to take the order. I don't see alternative except we split the
> options again, as it was before, and you have to go to another tab.

This sounds like a CSS problem.

May I recommend that you make the dialog a little more intelligent.  If the screen with allows, open everything. If it's doesn't allow minimize.  And then allow the user to determine what options they want PINNED open.
Comment 25 Timur 2021-04-22 12:56:19 UTC
*** Bug 140094 has been marked as a duplicate of this bug. ***
Comment 26 Xisco Faulí 2021-04-28 18:52:22 UTC
(In reply to Matt McKenzie from comment #23)
> Can I just say that the current print dialog is a total pain. I have to
> click BOTH "more" arrows EVERY time I open it.

This is fixed in https://cgit.freedesktop.org/libreoffice/core/commit/?id=149807eb6100090e178505ba4a264bb38eba1e0c

author	Heiko Tietze <tietze.heiko@gmail.com>	2021-02-09 12:03:08 +0100
committer	Heiko Tietze <heiko.tietze@documentfoundation.org>	2021-02-27 20:19:17 +0100
commit 149807eb6100090e178505ba4a264bb38eba1e0c (patch)
tree b37315820a1632644be4655780d2964502a21963
parent 28e022c258682dc030668fed7879d9d3f078b720 (diff)
Resolves tdf#127782 - Print dialog height

OTOH, the commit says "* Window size remembered", however, if I open the dialog, resize it, close it and open it again, the size of the dialog is not remembered.
@Heiko, was your commit suppose to fix it ?

@Caolán, I thought you might be interested in this issue
Comment 27 Xisco Faulí 2021-04-28 19:09:19 UTC
(In reply to Xisco Faulí from comment #26)
> (In reply to Matt McKenzie from comment #23)
> > Can I just say that the current print dialog is a total pain. I have to
> > click BOTH "more" arrows EVERY time I open it.
> 
> This is fixed in
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=149807eb6100090e178505ba4a264bb38eba1e0c

Backported to libreoffice-7-1 in https://gerrit.libreoffice.org/c/core/+/114821
Comment 28 Xisco Faulí 2021-04-29 07:58:34 UTC Comment hidden (obsolete)
Comment 29 Xisco Faulí 2021-04-29 10:52:54 UTC
and no, the problem with the dialog size not being remembered after reopening is not new, I can also reproduce it with the old dialog ( before the GSOC project ).
Reproduced in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 5.7; Render: default;
Comment 30 Xisco Faulí 2021-04-29 10:55:22 UTC
Also reproduced in

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

and

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 31 Xisco Faulí 2021-04-29 11:18:56 UTC
(In reply to Xisco Faulí from comment #28)
> (In reply to Xisco Faulí from comment #26)
> > OTOH, the commit says "* Window size remembered", however, if I open the
> > dialog, resize it, close it and open it again, the size of the dialog is not
> > remembered.
> > @Heiko, was your commit suppose to fix it ?
> > 
> > @Caolán, I thought you might be interested in this issue
> 
> For the record, the window size is remembered in GTK3, but not with GEN

in GTK3, the problem got fixed in

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bab77fcf8b80594fb49561254dfbaea381da8934

author	Caolán McNamara <caolanm@redhat.com>	2019-10-01 10:20:29 +0100
committer	Caolán McNamara <caolanm@redhat.com>	2019-10-02 20:28:28 +0200
commit bab77fcf8b80594fb49561254dfbaea381da8934 (patch)
tree be5deb3285355ea8df73f4eb10f0a83a889754e0
parent 21c00be1677638fc18e30425658ac7c1a6fe541c (diff)
weld PrintDialog
Comment 32 Timur 2021-04-29 11:28:54 UTC Comment hidden (obsolete)
Comment 33 Xisco Faulí 2021-04-29 11:38:08 UTC
(In reply to Timur from comment #32)
> This was reported for Win and final comment is for Lin.
> This one can be All or just Lin, there's also Win bug 135691 and bug 134679.
> All those are High priority, for great visibility.

GEN environment can be read as "every environment but GTK3, Win included"
Comment 34 Heiko Tietze 2021-06-30 10:05:54 UTC
Caolan removed the broken code completely in https://gerrit.libreoffice.org/c/core/+/114874

He argues that size depends on content and screen settings (font size, scaling etc.). If we change the dialog it wont fit user settings anymore.
Comment 35 Caolán McNamara 2021-06-30 11:05:32 UTC
(In reply to Heiko Tietze from comment #34)
> Caolan removed the broken code completely in
> https://gerrit.libreoffice.org/c/core/+/114874

For the record that wasn't me
Comment 36 Telesto 2021-06-30 15:04:03 UTC
(In reply to Heiko Tietze from comment #34)
> Caolan removed the broken code completely in
> https://gerrit.libreoffice.org/c/core/+/114874
> 
> He argues that size depends on content and screen settings (font size,
> scaling etc.). If we change the dialog it wont fit user settings anymore.

I don't follow the reasoning? A commit is pushed doesn't make anything final. The issue - the bug - is still there. The solution for bug 127782 makes the dialog less productive for the rest (and being rather pain in the ass to work with)

Is it not possible to simply set both "more expanders" to 'true' on dialog creation if certain screen resolution is detected? This should make the window to fit the full content; as size of dialog matches the content. 

This would mean: exposing all settings & preventing the scrollbar in dialog effect 

Putting the bug back to NEW
Comment 37 Heiko Tietze 2021-07-01 08:47:12 UTC
*** Bug 134274 has been marked as a duplicate of this bug. ***
Comment 38 Xisco Faulí 2021-07-07 13:33:36 UTC
(In reply to Telesto from comment #36)
> (In reply to Heiko Tietze from comment #34)
> > Caolan removed the broken code completely in
> > https://gerrit.libreoffice.org/c/core/+/114874
> > 
> > He argues that size depends on content and screen settings (font size,
> > scaling etc.). If we change the dialog it wont fit user settings anymore.
> 
> I don't follow the reasoning? A commit is pushed doesn't make anything
> final. The issue - the bug - is still there. The solution for bug 127782
> makes the dialog less productive for the rest (and being rather pain in the
> ass to work with)

See comment 26
Comment 39 Timur 2022-03-14 09:34:27 UTC
*** Bug 147946 has been marked as a duplicate of this bug. ***
Comment 40 bugzilla2 2022-09-01 15:39:55 UTC
After reading this bug, I'm surprised that most of the content of the bug doesn't match the headline :D The headline is "Print dialog: dialog size is not remembered after reopening (GEN)" (which made me click the bug) and most of the content is about the layout of the print dialog...

Whatever: I can confirm, that the print-dialog still doesn't remember its size (on Windows). And being an owner of a high-dpi-screen (since a couple of weeks), this is kind of a problem to me too (not the only one, not the biggest one, but it is :D)

Remembering Window-Sizes (or any kind of GUI-Sizes) seems to be extremely hard in LibO in general (I have other bugs open due to those issues). On Non-High-DPI-Screens most things work better, because the default-sizes are chose to fit, but on High-DPI this really brakes apart a lot :/
Comment 41 Mike Kaganski 2022-09-01 15:43:24 UTC
(In reply to bugzilla2 from comment #40)

The topic was last changed in comment 29, and I suppose that was wrong. Before that, the topic was "Print dialog: Expand sections on large screens and remember user configuration".