|
OpenOffice.org |
||||
Bi-Weekly Meeting common User Interface (CUI) |
||||
|
Date |
November 20th, 2003 |
|||
|---|---|---|---|---|
|
Time |
10am, MEST |
|||
|
Location |
Palo Alto, eham02 |
|||
|
Attendees |
+ Oliver Specht (OS) +Mathias Bauer |
|||
|
Minute Taker |
MMP (next: OS, PB, GT, OS, DR, CJ, CL, FS, MMP) |
|||
|
Distribution List |
||||
Table of Contents1 Action Items |
||||
|
Item |
Responsible |
Status |
||
|
previous items |
||||
|
Arrange meeting to discuss technical problems for new context sensitive toolbar handling |
Christian Jansen |
open |
||
|
new items |
||||
|
Provide a list of controls in OOo to support the project of native controls |
Christian Jansen | new | ||
| BP will find out if the TabListBox can be utilized for a two column tree control | Hans-Peter Burow | new | ||
1.1 Comments on Action Items2 Roundtable2.1 Undo2.1.1 Undo HistoryHenning wrote a spec for a more descriptive undo history in OOo Writer. We will adopt this approach for all OOo modules. It has to be specified what actions need a better name. >Insert "Oxmox"< in OOo Writer is fine while >Move Frame to Position xy< is less informative. For OOo Calc we should display the affected cells. [cf. http://specs.openoffice.org/writer/undo/Undo_GeneralWriter.sxw] 2.1.2 Undo StepsWe like to improve the chunks for undo actions. E.g. typing in OOo Writer records: >Word1 | SPACE | Word2< as 3 steps, rather than taking Word1+SPACE as 1 UNDO action. Replace All is treated as 1 undo action. Spellchecking is treated as several actions. [cf. http://specs.openoffice.org/appwide/linguistic/Spellcheckdialog.sxw] According to OS, a Save operation in OOo Writer flushes the undo stack. As the other modules do not show this behavior this is considered as a bug. Redlining in OOo Writer tables is a problematic area for undo. What about document property dialog changes. They definitely change the document. Are they candidates for undo? In any case they should not flush the undo stack. Insert a object from the Navigator to the document with drag&drop. The object is inserted as a section. And the action cannot be undone. This is another candidate to improve the undo capabilities of OOo. Please contact Matthias (mmp@openoffice.org) to point out more areas for undo. 2.1.3 Limited Undo StackWe have no statistical data on the memory footprint of the undo stack. But 20 steps is definitely a too small number. We decided to increase the default [Options>OOo>Memory>Undo>Number of Steps] to 100. A new maximum is needed because an unlimited (= just memory constrained) undo stack is technically not possible for OOo2.0 2.1.4 Undo of MacrosThe situation is complex. Macros start and stop. They change documents, not necessary just the document that was active when they were started. Additionally macros can run in parallel. For undo have to distinguish at least between programmed macros and recorded macros. For recorded macros we can offer a one step undo because they are related to just one document. Undo APIThe undo API needs functions to access the undo stack.
We do not need undo calls to add new items to the undo stack. UNO calls should wrap the undo API calls. 2.2 Native ControlsStephan Schäfer and Dan Williams are working on native controls for OOo2. Stephan with focus on Windows, Dan on Gnome. OOo 2.0 will utilize native controls from the operating systems. Buttons, combo boxes, check controls, radio controls, tab controls, and scrollbars (to name a few) will be drawn by the OS libraries. This is VCL-internal. Proprietary controls outside VCL keep the OOo1.1 style. This means that e.g. rulers, progress bars, header bars are not affected by this change. Nonetheless they can adopt style elements like disclosure plus/minus signs for tree list controls in the future. Menus are not part of the native controls project. They have to be considered in a separate step. OS: WindowsVCL will use Windows XP Theme API calls to draw the controls in OOo. Window Blinds are supported. This gives OOo the Luna look for Windows XP. We are also prepared for Longhorn in the future. Windows 2000 uses a different API. We have to see to what degree the changes work here as well. OS: GnomeOOo2 will support native controls on Gnome. OS: MacOOo 2 will no longer have the option Option>OpenOffice.org>View>Look&Feel. But the use of native controls is also a huge step for an Aqua version of OOo on Mac OS X. Form ControlsOOo will continue to use our own controls for form elements. This assures that documents look the same on all platforms, and that all features are available. Basic Dialog EditorThe Basic dialog editor will adopt the native controls. Printing of dialogs is an open question. AccessibilityIn OOo 1.1 VCL draws the text for all controls. It was key to provide an API for assistive technology to tell what string is at position xy on the screen. If the controls draw the text on their own we have to find a solution to gather the information for the assistive tools. Maybe we provide an internal flag to draw the text the one way or the other. Changes in Appearance Options
Problems todayHighlighting/hot state/mouse over is not working yet. UI-mirroring for right-to-left user interfaces (RTL) can bear some problems with shading, ie. the light source coming from top right instead of top left. We can address this for Windows, while Gnome is an open area. 2.3 Two-Column Layout for TreeView ControlCJ likes to introduce a two-column tree control for the customization of the menu structure. 1st column displays the menu items, while the second displays the shortcuts. A requirement is that the columns are sizable. PB will find out if the TabListBox can be utilized for this |
||||
