| Proposals Table of Contents | Last edited on Jan 21, 2001 3:13 am |
|
|
Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the AbstractZopeGUIDiscussion to make comments.
Martijn Faassen (m.faassen@vet.uu.nl)
Currently the Zope GUI is based on HTML. The GUI code is embedded deeply into the core Zope components; see CleanUpTheCore for a related proposal that deal with this. This proposal assumes CleanUpTheCore is happening; without CleanUpTheCore the problem becomes even more severe.
We would like Zope to support various GUI interfaces besides the current web interface (see also ZopeStudiox and the ManagementInterfaceNG proposal). The implementation technology of the various current and future UIsx varies heavily:
HTML in the current management interface and ManagementInterfaceNG.
wxWindows widget in the various wxWindows Zope client.
other widget sets such as Qt and GTK as well as native Windows would be possible.
etc. We don't know what the future will bring, but we want to be future proof.
We would like all of these developments to have the potential for success. Currently they are severely hindered though. In part this is described in CleanUpTheCore; the other part will be described here.
In order to supply a UI for a particular component, someone (such as the UI developer or the developer of the original component) needs to write an adaptor layer on top of the component that supports that particular UI. When the UI changes, or when a new GUI is developed, the same thing needs to happen again. Thus, any new UI will have to somehow get all components updated.
An alternative approach is to bootstrap a new GUI on top of
another one. ZopeStudiox for instance might display legacy Zope
objects it doesn't know to deal with in their HTML management
interface. This isn't a clean approach however; the point of a new
UI is to improve things, after all. If we can offer more advanced
editing widgets for instance, we don't want these editing widgets
to go unused for most components out there.
Build an abstract GUI layer. Individual Zope GUIsx implement this GUI layer in their own widget set (HTML, native, XUL).
The abstract GUI provides widgets such as views or windows, labels, text entry areas and buttons. There is also a very abstract layout system for these widgets; the idea is to make the abstract GUI as declarative as possible.
Concrete GUIsx such as the through-the-web management interface implements concrete versions of these widgets and the layout system.
A Zope component developer only needs to support the abstract GUI
to be supported by all GUIsx. The various concrete GUIsx that
implement the abstract GUI would then instantly be able to use
these copmonents, and the components would always look
native. The developer only needs to think about the GUI
once. There can be automatic conformance to a lot of GUI
guidelines.
In some cases the Zope GUI may still go beyond the underlying
abstract GUI and directly speak to the components themselves to
offer extra functionality; this can happen when the interface of
the underlying component can be assumed to be stable, or if
certain functionality is certain to be supported by all components
(the object id would be a trivial example of this).
It's a major overhaul.
Older components will need to be converted to the new abstract GUI (but only once, and they'd only need to track this GUI).
It is partially dependent on CleanUpTheCore to provide a good basis to build on.
Building generic GUI systems can take up a lot of time.
lowest common denominator effect; it is harder for the
component developer to do special user interfaces if the
abstract GUI does not support what they want. (this does
increase GUI consistency though)
This is a large project and should therefore be aiming for inclusion in Zope 3.0. Development of an abstract GUI can start at any time however. The transition could be made more gradual by providing abstract GUI functionality to product developers (with a HTML implemention) in parallel to the original Zope HTML GUI.
The project would not develop any concrete GUI except a reference implementation with a HTML interface.
Abstract GUI widgets that can be used to construct a Zope GUI (text entry, labels, tabs, views and windows).
An abstract layout system for these widgets.
A concrete GUI implementation that uses a HTML interface.
A layer built on top of the core components using the abstract GUI.
© 2001, Zope Corporation All rights reserved.