Framework/Specification/Specification Enhancement UIMigration
Enhancement for migrating UI configuration data to a new version
| Specification Status | |
| Author | Wu Yan |
| Last Change | 12.08.2009 |
| Status | Final |
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.
References
Contacts
| Role | Name | E-Mail Address |
| Developer | Wu Yan, Carsten Driesner | wuy@openoffice.org, cd@openoffice.org |
| Quality Assurance | Mikhail Voytenko | mav@openofice.org |
| Documentation | Uwe Fischer | ufi@openoffice.org |
| User Experience | no user interaction required |
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: Merge the old ui entries to the new version
When migrating ui configuraiton, we can compare the two diffent version ui configuration settings, and then merge the old entries to the new version. The idea is:
- By checking the ui files(eg.: menubar.xml, standardbar.xml, custom_toolbar_*.xml), which are fully copied from an old OOo version, in the user's home directory, we can get the changed ui information for all application modules.
- To compare the two versions' user data using UI configuration API.
- To merge all the items, which were customized by users or originally exist only on the old OOo installation, to the new version.
There are also some disadvantages:
- Some entries may be duplicated. e.g.: menu:Edit/Navigator, View/Navigator,
- Some entries users may not want to migrate to the new version are also merged to the new version. An improved solution may be as following.
Overall this enhancement assures that users don't lose their added toolbar buttons and menu entries.
Possible enhancements: 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
- screenshot of migrating menubar for writer
- screenshot of migrating toolbar for writer
- Another idea is to display the information on different tab pages of the dialog for menubar/toolbar
- 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.
