Framework/Specification/Specification Enhancement UIMigration
Enhancement for migrating UI configuration data to a new version
Specification Status | |
Author | Wu Yan |
Last Change | 09.30.2009 |
Status | Preliminary |
Abstract
Currently we copy user changed user interface configuration files from an OOo version to another new version. This results that the entries introduced by the new version are not visible. The enhancement is to provide a new UI where the user could see what user interface has been changed, and he/she could determine what data should be migrated or not.
References
Contacts
Role | Name | E-Mail Address |
Developer | Wu Yan, Carsten Driesner | wuy@openoffice.org, cd@openoffice.org |
Quality Assurance | ||
Documentation | Wu Yan | wuy@openoffice.org |
User Experience |
Acronyms and Abbreviations
Acronym / Abbreviation | Definition |
Detailed Specification
During the migration process, if we mark the check box on the 'Personal Data' page, all the personal configuration files, including user interface files, from an old OOo version(e.g.: OpenOffice.org 2.4) will be copied to the new version(e.g.:OpenOffice.org 3.1).
As a result, the entries introduced by the new version, e.g.: menu:View/Notes,View/Navigator, will be hidden. Currently, there are two solutions to improve this.
Solution 1: Migrate all the old ui entries to the new version by default
When migrating ui configuraiton, we can compare the two diffent version ui configuration settings, and then merge the old entries to the new version. All the entries, which were customized by users or originally exist only on the old OOo installation will be merged to the new version.There are also some disadvantages: (1)some entries may be duplicated. e.g.: menu:Edit/Navigator, View/Navigator, (2)some entries users may not want to migrate to the new new version are also merged to the new version. An improved solution may be as solution 2.
Solution 2: Provide a UI to users
With such a UI(e.g.: a migration dialog), users could determine which items should be migrated .If he/she doesn't want to migrate one item, e.g.: menu: Edit/Navigator, he could delete it from the listbox of the dialog, finally this item will not be merged to the new version. If he/she want to hide a entry introduced by the new version, e.g.: menu: View/Navigator, View/Notes, he/she could delete it from the other listbox as well, and this item will be hidden in the new version at last.
What's UI will be presented to users?
Because there are ui configuration changes for every application module. So we have to display all the ui uiconfiguration changes between two different version for all application modules.
- The first idea is to provide one dialog for menubar/toolbar for each module.
- Another idea is to display the information on different tab pages of the dialog for menubar/toolbar.
- There should be other experiences and better ideas.
Because users can not change the statusbar via Tools->customized, so it isn't necessary to support for migrating statusbar. Considering the ui configuration for accelerators has been changed from xml based files to xcu based files, we should find a different solution for migrating accelerators.
Migration
Configuration
There are no configuration items involved.
File Format
There are no changes to the file format necessary.