Chandler Tabular Data UI Dev't Issues
Chandler GUI Frameworks Engineer, OSA Foundation
31 March 2005
This document is intended to describe the ongoing efforts within Chandler to build a tabular ("spreadsheet-like") data UI for presentation and editing that satisfies a broad range of usability and aesthetic criteria. Chandler's near-term UI requirements mandate various UI improvements to the current v0.4 implementation, particularly with regards to tabular data column headers. This document will articulate the development criteria and ongoing discussion of development choices and changes as implied by the various Chandler v0.5 and Kibble UI design and task planning documentation. See the references section below for the appropriate links.
The presentation of tabular data within a desktop application is typically non-trivial, for any number of reasons. Some of the familiar issue domains are as follows:
- text: ASCII or Unicode; plain or styled; font issues, etc.
- graphics: icons, images, etc.
- data access and management:
- is all of the view (cell) data available: machine-local, LAN, WAN, etc.
- support for large datasets, asynchronous loading/rendering, etc.
Enough about that. Suffice it to say that it's hard to build a tabular data UI framework that satisfies a wide range of application scenarios.
As a Chander wiki reader, you're probably well aware of Chandler's choice of wxPython for providing application UI services. wxPython provides a couple of different classes which facilitate the implementation of a tabular data UI.
Chandler has recently changed its underlying tabular data view implementation from using wxListCntl objects to those of type wxGrid. The wxGrid implementation has some shortcomings in the areas of column labelling: to wit, the labels are limited to simple text, without the platform-specific theme support. The wxListCntl has broader support for list column headers, but the support for platform-specific theme appearance is achieved by use of an internal theme engine that approximates platform themes rather than actually using native list header controls.
For a more detailed task analysis, visit Chandler wxPython 0.5 Task Planning?
Currently being considered:
- creation of a wxWidget class to support native column header controls (in development: see next section)
- integration of native MacOS X DataBrowser widgets
- pros: native UI support, good answers to general issues raised in Overview section above
- cons: no native Win32 counterpart; significant Chandler and wxPython/wxWidgets integration work implied
List Column Header Development
The following basic requirements for column headers, as extrapolated from the Chandler UI Reguirements documentation, are as follows:
- geniune platform-theme support: MacOS X: Aqua and Graphite; WinXP: Blue and Silver; Linux: TBD
- non-text column labels (primarily icons)
- column adornment: highlights, sort direction arrows, selectable colors, etc.
- column resizing UI: e.g., draggable dividers
I'm proposing that native list header controls be supported by the implementation of a pair of wxWidget classes: wxListColumnHeader and wxListColumnHeaderItem. I've researched the native support for these particular controls, and I believe that there is a good fit across platforms between the features desired by Chandler UI specifications and the native platform APIs. This lends itself to a platform-neutral set of wxWidget APIs to cover and implement the desired features. The platform-neutral parent class (wxListColumnHeader) is simple relative to the platform-specific item classes, where most of the heavy lifing occurs.
as of 31 March 2005, the third code checkpoint has been reached (MacOS-Win32-GTK, wxPython/wxWidgets) - check the URLs at the bottom of this page
- Public routines
- AppendItem( text, just, width, selected, sort-direction )
- for creating column header items and assigning attribute values
- DeleteItem( itemIndex )
- Get/Set-Enabled( bEnable )
- Get/Set-SelectedItem( itemIndex )
- Get/Set-Item-LabelText( itemIndex, string )
- Get/Set-Item-UIExtent( itemIndex, origin, width )
- Get/Set-Item-AttributeFlag( itemIndex, enable, select, sort-enable, sort-dir )
- ResizeDivision( itemIndex, originX )
- Protected routines
- AppendItems (for multiple items and values)
- Get/Set-ItemData (not for wxPython export)
- Protected members
- Protected routines
- ItemRec (all fields supported by native Mac/Win APIs)
- Attribute (sort direction arrows: none/up/down, etc.)
- owner-drawn (requested by Robin Dunn)
The basic strategy for the item classes are as follows:
- MacOS - Carbon
- build Carbon HIView control:
- straightforward: derive from Apple HIView skeleton
- use DrawThemeButton - 2 different discussions on "lists.apple.com" support this plan
- the company ExitToShell sells an implementation of such a control
- possibility of column header using a DataBrowser with no data rows (under investigation)
- investigated CreateWindowHeaderControl - rendering isn't theme-compliant
- investigated use of segmented controls (see link below) - appearance is theme-compliant, but somewhat "ugly"
- Windows - Win32
- use native (control) window
0, WC_HEADER, (LPCTSTR)NULL,
WS_CHILD | WS_BORDER | HDS_BUTTONS | HDS_HORZ,
0, 0, 0, 0, hwndParent, (HMENU)ID_HEADER, hAppInst,
- borrow from existing wxWidgets - wxListCtrl generic draw code
- fix bugs
- GTK, Win: no selection UI
- Mac: no label text in Unicode build
- review wxWidgets class for column header APIs embedded in wxGrid
- articulate sub-tasks:
- column resizing
- in-place text editing for cell data (currently needed?)
- check out other open source implementations for implementation comparisons:
- most MacOS X 2-D data UIs are DataBrowser-based: Finder, Thunderbird, Xcode, etc.