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
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..
(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.
Created attachment 162783 [details] Screenshot Table of contents dialog
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.
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
(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.
(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
(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.
Mentioned on bug 134274, we could expand the 'more' sections in case of large screens by default. No shuffling needed and easy to implement.
(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
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).
(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 :-)
Created attachment 163006 [details] Screencast of different option
Created attachment 163008 [details] Another print dialog screencast: Acrobat Reader
(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
Please note that for the Acrobat Reader example, there would also be VISIBLE duplex settings, if the printer supported duplex.
*** Bug 135426 has been marked as a duplicate of this bug. ***
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.
*** Bug 135690 has been marked as a duplicate of this bug. ***
*** Bug 136797 has been marked as a duplicate of this bug. ***
*** Bug 137266 has been marked as a duplicate of this bug. ***
(In reply to Timur from comment #18) > snip... remember expanded state? ...snip... best solution for all people.
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.
(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.
*** Bug 140094 has been marked as a duplicate of this bug. ***
(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
(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
(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
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;
Also reproduced in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e and Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
(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
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.
(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"
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.
(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
(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
*** Bug 134274 has been marked as a duplicate of this bug. ***
(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
*** Bug 147946 has been marked as a duplicate of this bug. ***
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 :/
(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".