The Free and Open Productivity Suite
Follow us on Twitter: @ApacheOO

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

Apache Software Foundation

Copyright & License | Privacy | Website Feedback | Contact Us | Donate | Thanks

Apache, the Apache feather logo, and OpenOffice are trademarks of The Apache Software Foundation. OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.