Hi Peter,
Peter Kupfer wrote:
Joerg Barfurth wrote:
Peter Kupfer wrote:
This is what they proposed. However in current pre-releases, the opening top last point is disabled and not shortcut key is added, and from what I can tell it will not be added by release date.
How do you know that it won't be added by release date? Did you check if there is an issue? Did you submit one? Of course, without logging an issue nothing will get fixed.
In my original post the issue number is listed: "This is issue #39486 if you want to comment or vote for it. "
Quotes from the issue:
"Additional comments from os Thu Jan 6 03:51:16 -0800 2005
In software almost everything is possible but looking at the release plan and the open tasks for OOo 2.0 this is not possible (3 days est.)."
"Additional comments from es Thu Jan 6 05:00:29 -0800 2005
Ok, so let's keep this for later.
As this feature is a future task in the spec (see URL field in this issue), let's use this issue as reminder."
So, this is were my data came from.
OK. That is what I was missing: That they had classified addition of the shortcut as a "Future task". I had not looked into the spec before. Under this circumstance the behavior of the program is not strictly a defect. Of course a specification that mandates a functional regression like this can be considered defective. But getting a spec change approved and implemented at this stage (well after feature freeze) is far more difficult than getting a deviation from the spec fixed.
OTOH reading the spec really was very instructive. The spec contains many hints on its history. Apparently at first there was a plan to automagically determine whether a user is owner/author of a document and that document is currently being edited and restore the document only in that case.
Fortunately it was realized that this kind of automatism (a) is very fragile and (b) really confuses users. So the idea was dropped.
Then they went back to the user scenario and realized that they need
- a way to restore last edit state for authors working with long documents (plus some other marginalcases, see UFI-1)
- restore to top for most other purposes (people reading/reviewing documents, rarely edited docs, short documents)
As the second case applies more to inexperienced users, it should be the default.
Apparently noone realized that the OOo 1.1.x preference with default changed to "open at top" would have done most of that in a simple fashion - or the desire to get rid of preferences was too strong.
Generally we want to get rid of preference settings. Preferences create persistent modes, which makes support and QA harder (combinatorial number of program states). Very many people don't realize that preferences are there at all, and many preferences are hard to understand for many users. From that point of view it makes sense to make "restore editing position" an action for the (power) users that need it, rather than a preference. That has the added advantage, that you aren't forced to take an all or nothing decision. Generally I want the restore functionality when editing a long document, but when reading someone else's document I want to find it opened at the top.
So they arrived at the solution proposal to remove the preference in favor of a keystroke. So far so good - no functionality was really lost.
But then time pressure (before feature freeze date) kicked in. Looking for things that could be dropped for now, someone saw that this feature had a distinct part "add keyboard shortcut ...". Keyboard shortcuts like this may be a lot of work (see the comment in the issue; 3 days developer effort is a lot), but often are considered less urgent (again most users don't ever use them). So the decision was taken to postpone this to the future. And it looks like this is where the process went wrong: now the spec introduces a functional regression. Noone took the time to step back and realize the problem and that reverting to old behavior (with changed default) would have achieved mostly the same with even less effort[*] and without regression.
[*] I could be wrong here, if the old behavior already was broken by non-maintenance before this time (in anticipation of this feature change).
Maybe this could have been avoided, if more people participated in the specification process. Specs are announced on the <[EMAIL PROTECTED],org> mailing list and anyone can review them.
Admittedly in this case the process was partially broken: The specification change that deferred the keyboard action to be a future task was *not* announced on that list and neither was a feature annoucement sent when the change was implemented.
Ciao, Joerg
-- Joerg Barfurth Sun Microsystems - Desktop - Hamburg >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<< Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
