Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | organize file handling around open/save import/export | ||
---|---|---|---|
Product: | General | Reporter: | Joe Smith <jes> |
Component: | ui | Assignee: | AOO issues mailing list <issues> |
Status: | CONFIRMED --- | QA Contact: | |
Severity: | Normal | ||
Priority: | P3 | CC: | apulsifer, caiot1, elish, issues, kpalagin, mantas, stp |
Version: | OOo 2.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | 4.1.0-dev |
Developer Difficulty: | --- |
Description
Joe Smith
2007-02-10 21:47:56 UTC
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 |