|
Date |
September 13th 2001 |
|---|
Weekly User Interface meeting
TODOs
|
Previous week's TODOs |
Responsible |
Status |
|---|---|---|
|
Create a team section on staroffice-doc and on OOo |
OS |
In progress |
|
Determine and publish responsibilities |
OS |
In progress |
|
New TODOs |
|
|
|
assemble list of UI components/classes/dependencies |
OS |
|
|
check if common UI code can/should be moved from SfxApplication to OfficeApplication |
FS |
|
Location of the new UI project(s)
A lot of the common UI classes uses specialized SfxPoolItems which are located in SVX. This means that the new UI project(s) need to be located above SVX. On the long term, this dependency should be removed, but at the moment having it would ease the migration.
OTOH, the projects should be below OFFMGR, which would be a main client of the functionallity.
Configuration
It seems desirable to have a separation of configuration data, to distinguish between framework UI data and application UI data. At the moment, this is no primary goal for feasibility reasons.
Customizeable UI
On the long term, SO should have customizeable UI in a sense (at least) that vendors can replace dialogs, menus, toolboxes etc. with their own implementations. For this, the question rose where the line between exchangeable and not-exchangeable components should be draw. For instance, it seems difficult to allow to exchange single tab-pages in common dialoges. This would make the interface of such components very complex (and probably expensive).
Instead, it seems reasonable to claim that (only) dialogs as a whole are exchangeable. For this, such a dialog component would simply work on an object which can be passed (e.g. the shape which's properties are to be changed), this way keeping the interface rather simple. Our “default implementations” then would have the full power of all the common helpers (SfxItemSet etc.), without the need to model this in UNO.
Taking an inventory
As not everybody has a clear perception about the amount of classes/helpers which are now in the responsibilities of the UI team (especially FS complained), OS is to assemble of list of them, including dependencies to the different projects which at the moment contain common UI (TODO).
After this, the splitting/regrouping of all this code can be discussed, including questions about which components should be loaded on demand etc.
Preferred application class
In the course of the upcoming changes, we should have a clear responsibility for the application UI. At the moment, the SfxApplication (sfx2) as well as the OfficeApplication (offmgr) both take a part of them. To have a clear distinction between framework and office UI, it seems desired to move the latter to the OfficeApplication. FS will discuss this idea with MBA and see if there are any objections from the framework side.
Remark: All initials for names should be interpreted as <Initial>@openoffice.org
