1. Open a .docx attachment from thunderbird. Get a write-protected view. Ok so far, nothing bad yet. But I want to save a local copy for editing. Naturally, I use "save as" 2. File->Save As A big dialog show up. It suggests a filename I won't use, and a wrong directory. Ok so far, libreoffice cannot yet know where I want to store this, or what name I want. 3. Change the "name" field from "SomeName" to directory/subdirectory/myname I am sure the directory names are correct, for I used tab-completion. Very nice feature that. (I just type "dir"<TAB> and get "directory/" automatically. So far all is well... 4. Press the "save"button (not "cancel") to actually do this. At this point, I expected the document to be saved. Instead, a slightly annoying question if I want to use ODF format. It'd be better if this was part of the "save as" dialog. But, that is a very minor annoyance. And the ODF format is ok with me, so: 5. click "Use ODF format". Now I REALLY expect the document to be saved! In the directory I specified (with nice help from the save dialog), with the name I specified, and no further questions or silliness. But here libreoffice fails me! It does not save the document as specified, instead it pops ut the "save" dialog? WTF? The "save" dialog has the new name I specified, and NOT the subdirectory I specified. And why did I get a dialog at all, at this point? No other software do that to me. Everywhere else, when I "save as", the document is indeed "saved as" whatever path/name I specified. The way I see it, this is a bug i9n the user interface. (A programming bug if it indeed wasn't meant to be like that - or a design bug if this somehow is deliberate.) I can NOT see any use for the "save" dialog at this point in time. I have already entered a path and a filename - AND the document format (ODF) too. There is nothing more for me to tell libreoffice, so libreoffice should not ask any more, but just DO WHAT I ALREADY TOLD IT TO DO. If I cancel this extra "save" dialog, then nothing is saved. If I press "save", the document is wrongly saved to my home folder. NOT the folder I specified explicitly - and which libreoffice even helped me to find. So not only am I annoyed by an unnecessary dialog, there is also information loss. I did specify a subdirectory, but this was forgotten when the unnecessary "save" dialog came up. I can work around this in a number of ways (by moving the file to its correct place using the "mv" command), so the bug is not critical. But irritating nonetheless.
Another problem is that the unnecessary unwanted "save" dialog is "halfway modal". The ordinary "save as" dialog is fully modal, in that it stays on top of the main window until dismissed, and I can't use any menu choices either until I dismiss it. The "halfway modal" dialog still block input to the main window - but if I click the main window, it goes on top of the stupid "save" dialog. So I'm stuck with an unresponsive main window and wonder why - there is no dialog floating on top. So why can't I open the help menu (to get the version number for this bug report, for example). This can be worked around by digging up the dialog and closing it. But it'd be better if that dialog never came up, and the document simply was saved as specified. The "Save"dialog does not misbehave when brought up the normal way from File->Save. Then it stays on top as it should.
Sounds like UX material, so punting this over.
The issue here seems to arise from the ambiguity coming from the lack of file extensions in the Save/Save As dialog in Linux (plus that file type dropdown is "All Formats" by default). Here are the general reproduction steps: 1. Start new document. 2. Save it, Save dialog comes up, add .docx extension to the file name so it's going to be saved as DOCX and click Save. 3. Popup comes up to confirm file format, select "Use ODF Format" this time. 4. Another Save dialog comes up, where file name has to be specified again. These are essentially the same steps as described by Helge, except in that case there's already a DOCX document, so it defaults to DOCX even if extension is not added. I can somewhat understand the second Save dialog if the file name was specified with extension: if the user chooses ODF format when the confirmation popup comes up, then the original file name+extension is not valid anymore, and should be confirmed again. The questions relevant to UX in my opinion: -What should happen if no extension was specified? (then the second dialog is unnecessary and confusing) -Is it fine that file name to be saved is shown without extension by default in Linux Save/Save As dialogs? What I consider to be bugs: -File type picker in the bottom of Save/Save As dialogs in Linux is "All formats", and it shows all formats, but saving with a name without extension defaults to ODF format with the relevant ODF extension. -If the user enters additional directories in "Name" field in the first Save/Save As dialog (as Helge wrote in the 3rd step in the Description), the second Save/Save As dialog should change to that directory. Setting to NEW, since the behavior can be legitimately confusing.
Procedure is the same in LibreOffice 3.3. => inherited from OOo
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Guess the issue has been solved meanwhile. When I open a docx file in Writer and SaveAs odt there is no halfway dialog, everything goes straightforward (v6.0). Setting as WFM, please reopen in case there is still an issue.
I can still repro with my steps in comment 3 with a recent 6.0 master build (6ea9062d233e153a5df0e7368af4c6a49d955485).
I see three option: a) suppress second file dialog when only the extension changes b) add extension to the specified name like test.docx.odt c) resolve as WFM with the idea that name changes require confirmation I suggest to resolve the issue as WFM, safety first.
The "file exists" check is a function of the dialog, being a part of the filename choosing process. When a user decides to change a type of the document, the previously solved "file exists" situation does not apply anymore, and a new situation arises. It needs own iteration, and trying to be smart here (e.g. trying to quickly check if such a file exists to decide if to ask again or not) will bring a whole lot of new problems (is FS case sensitive? does it impose some file name limitations like length or forbidden patterns? is it some special FS like CMIS or WebDAV with exotic requirements?) that already solved by specialized Save As dialogs. So clear WONTFIX IMO.
I understand that a "file exists" check needs to be done on the new name. Seeing the file dialog twice, can still be averted by changing the order of operations. Current order: 1. User does a save(as) 2. Check if document.docx exists, showing a file dialog 3. Nag that ODF is the better format, for good reasons. User accepts 4. Check if document.odf exists, showing another file dialog Proposed order: 1. User does a save(as) 2. It is a docx file, so suggest the better ODF format. User accepts or rejects 3. Check if document.odf (or document.docx) exists, depending on selected format. The file dialog is seen only once, for the one format the user went for. No check or dialog done for the rejected file format.
(In reply to Helge Hafting from comment #10) > Proposed order: > 1. User does a save(as) > 2. It is a docx file, so suggest the better ODF format. User accepts or > rejects > 3. Check if document.odf (or document.docx) exists, depending on selected > format. The file dialog is seen only once, for the one format the user went > for. No check or dialog done for the rejected file format. No. It's the file type user chose in the dialog that we check later, not the original type of the document (which is none for a newly created document that had not been saved yet). It's incorrect to interfere *before* user told you which file type they want to use; it would be wrong to show an extra dialog to a user who was going to choose ODF themselves (e.g., opened an old DOCX and is saving to ODT).