Problem description: Steps to reproduce: [1] Start LibreOffice and open a new text document. [2] File > Print... > tab "LibreOffice Writer" [3] Change one the displayed options. Then "Cancel". [4] File > Print... > tab "LibreOffice Writer". The changed option has been saved, despite of cancelling the dialog. As far as I checked this problem, all options of the tab 'LibreOffice Writer' and the option "Brochure" of tab 'Page Layout' are saved if cancelling the dialog. Possibly also the option "Print Comments" of tab 'General', but I did not checked it. Expected behaviour: If the Print Dialog is cancelled, changed options should not be changed. Or better: Message: "You have changed print options. Do you want to save them?" Hint: bug 33245, bug 42657 and bug 43932 also deal with print options. Problem also observed with V. 3.4.5. Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28
Thanks for bugreport reproduced in 3.5.4 on Fedora 64 bit (Windows not tested) When click "Cancel" then options saved, but when close LO and open again, options resets to defaults. May be here should be added button "Apply" for saving options. And "Cancel" should not save options. IMHO users print most documents with the same options. Only some document needed to be printed with different options. And then arises another problem: how to not forget to change options to previous state again. So, adding ability to set default printing options may be very useful.
Not only when closing LO, also when opening a new document, print options for this document are determined by the options determined in the dialog Tools -> Options -> LibreOffice Writer -> Print. This means most documents are printed with the same options. That's OK for me. But if you go on with the steps to reproduce: [5] Cancel dialog and insert some words. [6] Close and save the document. [7] Close LO and start it again. [8] Open document again. [9] File > Print... tab "LibreOffice Writer". You see the changed option (despite Cancel) has been saved together with the document. And this is not OK for me. I am not convinced, if an additional button ("Apply" or "Save Print Options" or similar) makes sense, because may be some users (especially less experienced users) may be irritated by such a button. To my opinion print options should be saved together with the document, if it or a part of it has been printed. A little problem rises here: Shall the "Document's Change Status" change to "Changed", even only print options have been changed and the document itself has not been changed? In case of "Changed" of the stauts the user would be prompted to save the document at the end of his LO session, even he did not change the document itself.
Confirmed, setting as NEW, prioritizing and assigning to myself Priority - MINOR - MEDIUM I marked as Minor, Medium because, while it's not affecting ability to really make high quality work, it doesn't reflect well on LibreOffice to have cancel and Ok mean the same thing for our options. Also, I think the potential to irritate enough users is high enough to quality for a medium priority
Hey Michael, I was hoping you could mentor me a bit on this one. I think I have the relevant code: http://opengrok.libreoffice.org/xref/core/sw/source/ui/uno/unotxdoc.cxx#2439 and I believe it needs to be moved out of sw and into the general printdlg.cxx in order to capture the push of "Ok Button" http://opengrok.libreoffice.org/xref/core/vcl/source/window/printdlg.cxx This way I think also it would be much easier to implement saving preferences from other components as well. Looking to: a) confirm I'm on the right track b) Get pointers on how I move the stuff from unotxdoc.cxx to printdlg.cxx as they are in completely different areas of core (vcl vs. sw), so there are a bunch of hxx files associated. Do I move them all one by one, do I make new hxx files, link them somehow without moving anything? Many thanks and apologies for the ping
if someone wants to take this away from me, feel free to do so - I think someone with a bit more skill could get it done relatively fast. Here is an email that I got from Caolan ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ short answer is that what we want to happen is roughly a) remove that implicit store of settings in the writer code where it happens as a side effect and get it called explicitly in some store options configuration e.g. in PrintDialog::storeToSettings have a maPController->storeUIOptions(); call and that maPController fundamentally comes from new SfxPrinterController in sfx2/source/view/viewprn.cxx and takes a SfxViewShell as an argument so it should be possible somewhere around there to add a virtual storeUIOptions to the vcl::PrinterController, implement it in SfxPrinterController and propagate (here its the usual frustrating haze of "shells") the task to yet-another app-specific virtual store method and move the writer implicit-save code into that method instead. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Unfortunately I just haven't had the time to solve this bug - if I make any progress I will report back but until then setting back to default and NEW
*** Bug 80872 has been marked as a duplicate of this bug. ***
I have no time to continue looking into this - setting assigned to default.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.