Apache OpenOffice (AOO) Bugzilla – Issue 74415
organize file handling around open/save import/export
Last modified: 2014-02-19 09:18:16 UTC
File handling is probably the single most commonly used part of OOo. Unfortunately it is often one of the most confusing and inconvenient parts as well. I believe this could be greatly improved by organizing the file handling around this basic framework: Open/Save -- no file format changes Import/Export -- full user control over source and destination This would streamline the use of native files and help avoid the confusion naive users currently experience when "saving" their document in a non-native format, because it uses different words and menus for different operations. The Export operation would not register the file as "saved", thus naturally encouraging users to also "save" their file, giving them a native-format version. Exporting a file would also not change the name or file type of the current document, allowing easy creation of foreign-format files, e.g. to send as an attachment. The import/export pathways would include a re-designed user interface for completely specifying the file types and access to all available options for the file translation. This would avoid current problems such as * Loss of data or work when a document is "saved" in a foreign format. E.g, creating a copy of a document, e.g. a spreadsheet, as CSV using "Save As", then exiting Calc to find that no native format file exists. * Inconvenience when saving in a foreign format. E.g, creating by "Save As" a copy of a Writer document as .doc--now the current document has it's name changed and the "Recent Documents" list points to the .doc, rather than the native file. * Mysterious behavior when "opening" foreign files. E.g. opening an "Excel file" from Calc and having the file open in Writer because it is actually a CSV or HTML file. Instead of opening such a file (since a file format change is needed), it would need to be imported, where the user could specifically request conversion from CSV to a Calc document. * Confusing UI issues. The import/export interface would include descriptive names for each file type, in place of the current file type drop-downs which have long lists of often cryptic format names. Access to options for the file transformation could be presented in a uniform way, rather than through ad hoc option dialogs. This would not introduce any new functionality, only re-organize and define a clear policy for the existing file-handling operations. If implemented carefully, I believe this could make OOo more robust and predictable, as well as easier to use. However, this is still a rather fundamental change, so I don't know if it is even practical to consider. If it would help, I can prepare a more detailed proposal.
jes, if this is ever considered please note that some users have foreign file format as default for saving, so implementing this change should not adversely affect them.
> some users have foreign file format as default for saving, so implementing > this change should not adversely affect them. Understood. Should an application allow a naive user to shoot herself in the foot? I feel strongly that "open/save" represents a contract with the user guaranteeing that their work will be preserved. As far as I can see, this is only true in general for ODF, however it may be true for other formats, depending on what features you use. Ideally, OOo could disable features not supported for the format of an "open"ed file. Difficult to do. One way to approach this would be to make the default config strictly safe, but allow the user to easily add formats to the "open/save" pathway. This reconfiguration is where the warning about potential loss of data would be shown--only once--and then the user could agree to take responsibility. Since this is a one-time occurrence, the warning could be presented more clearly than with the cryptic one-liner we have now. Other approaches could be discussed. My personal feeling is that it is a mistake to encourage users to do this. Round-tripping documents in a foreign format is almost guaranteed to generate file compatibility problems at some point, and when that happens, it only looks bad for OOo and the OOo user. But I respect the reality that people want to do it anyway.
TM->requirements: One for you
Lots of overlap with Issue 11393; should probably be combined.
> I feel strongly that "open/save" represents a contract with the > user guaranteeing that their work will be preserved. I don't believe that is a correct statement of the "contract". The "contract" is not that Save As is guaranteed to perfectly preserve the document as it appears on the screen. In fact, a warning dialog pops up to explicitly tell you that it may not. The "contract" is that while Save As might change some of the formatting, whatever state exists immediately after the Save As, or after a later Save, can be recovered by an Open. I believe "the contract", as stated above, is similar to "the contract" offered by any application when you save in one of its earlier file formats, for example, when you use MS Word to save in Word95 format.
hm, how about on the warning which pops up about the file format saving there could be a 'more info' link that shows you to a help page describing it more clearly, perhaps explaining some features which are less likely to work than others As for the save-save as mechanism, I think that there isn't much wrong with the way that OO currently handles it. ATM a user has to explicitly set OOo to save in a completely supported format, if they tell OOo to save as a MS document, for example, then they get a warning to that effect. ATM, Export seems to be a metaphor used for saving in formats that can't be opened natively by OOo. eg: Latek, and PDF. Nothing to wrong with that I feel, but then again nothing wrong with what you're suggesting. I would support sticking with what we've got, since I don't feel it would be worth the confusion of changing the interface for all those users. What should be implemented is a way to 'save a copy' to aleviate problem 2: >* Inconvenience when saving in a foreign format. > E.g, creating by "Save As" a copy of a Writer document as .doc--now the > current document has it's name changed and the "Recent Documents" list > points to the .doc, rather than the native file.
actually here's another though, what if there was a way of rating format filters? in a way so that a user can quickly and easily look it up from within the app? Perhaps colour coded...?
File - Export... - File format:PDF <=> File - Export as PDF... File - Export... - File format:XHTML <=> File - Save As... - File type:HTML AOO410m1(Build:9750) - Rev. 1566800 2014-02-11_04:11:01 - Rev. 1566981 Debian