Chandler wx Roadmap

David Surovell

Chandler GUI Frameworks Engineer, OSA Foundation

25 October 2005

Draft 0.3

---

---

---

---

Introduction

The Chandler AppsTeam development strategy relies heavily on the wxPython/wxWidgets application framework to cover most of its platform-specific application issues. This document endeavors to describe and assess the work for OSAF Engineering implied by this decision. The important issues and questions that this roadmap document needs to answer are as follows:

1. is there anything missing today from wx that would delay or even prevent an otherwise ready Chandler from being released?
2. are any wx critical tasks which cannot be executed within the OSAF community?
3. what is the priority order of wx-related bug fixes and features?
4. formulate strategies and tactics for reducing wx development hours and risk (particularly debug and build improvements)
5. identify and articulate all important Chandler-related wx dev't tasks
6. spread tasks out across remainder of Chandler's development timeline
   
   
   
   

Any significant shortcoming on the part of wx, either in design or implementation, must be addressed by a Chandler engineering effort. As Chandler moves out of its "lab" development phase and into a nascent usable application phase (alpha-beta-dogfood level), it's not surprising that a substantial number of new wx shortcomings are being identified. This isn't a concern as long as the wx issue fix rate keeps pace with the other Chandler development efforts. This is a significant caveat, and must be managed aggressively.



The upside is that wx is very much open source and the community is active. The latest wx release (v2.6.2) contained a great many bug fixes important to Chandler. There is wxTNG (the next generation), a small, but capable and sincere "blue-sky" redesign effort to correct longstanding class-level design shortcomings, to which OSAF intends to be a contributor.

In summary, there is much important work to do in wx, but many reasons to be hopeful that it can and will get done in an acceptable timeframe.

---

Focus Areas

1. Concerns and unknowns:
   
   
   
   
   • wx bugs - past experience suggests that bugs critical to OSAF will get need to be fixed by OSAF. We will engage and collaborate with the wx community to a greater degree. To that end we will be more "energetic" about filing wx bug reports on SourceForge and posting to wx-dev.
     
     
     
     
   • (lack of) wx interactive source-level debugging (ISLD) support in Chandler context (esp. wxMac, wxGTK) - this is a problem primarily because Chandler is primarly a wxPython application. The wxMSW and wxMac builds of wxWidgets have some amount of ISLD for wxWidgets applications, but the Chandler build system hasn't been changed to convey the runtime support to the Chandler deployed image for wxMac; the state of wxGTK ISLD support is unknown (gdb + ??? UI). In any case, solving this issue should reduce both the impact and risk implied by wx bugs.
     
     
     
     
2. Missing or untested core features (in priority order):
   
   
   
   
   • (partially tested) i18n / ICU support - See the "Internationalization" section for more detail.
     
     
     
     
   • (missing - partial) wx native UI support - particularly for familiar UI elements implemented as subclasses of wxWindow or wxControl. In particular, the following controls appear to need work:
     • tree, toolbar, grid row/column headers.
       
       
       
       
   • (untested) HTML rendering (upcoming, near-future) - important for email and styled text support.
     
     
     
     
   • (missing) accessibility support (upcoming, near-future) - TBD, pending requirements assessment. This area implies much risk, due to the lack of implementation across all 3 Chandler platforms. Additionally, more research needs to be done on Section 508 compliance.

---

Division of Labor

• The work implied by this timeline falls into three categories:
  • additions and revisions to wx framework code
  • additions and revisions to Chandler code
  • additions to Chandler build processes

For OSAF, this distinction is somewhat arbitrary: we will identify the bug/feature and make the appropriate fix, without significant regard for the location of the fix. If the fix happens to be in wx code, then we submit bugs and patches as appropriate, tracking the code differences until the patch is accepted.

For the wx community, the distinction is more meaningful: wx bugs will be considered and fixed ad hoc, wx feature improvements will be considered, and Chandler issues won't be considered.

---

Task Timeline

One last time, to summarize:

• get ISLD working ASAP in order to minimize the QA and schedule impacts of high-priority wx bug fixes
• coordinate with the wx community on the planning, design and implementation of missing needed features
• participate in improving wx architecture in the longer term (wxTNG)

Given these problems and constraints and a start date of early Oct-05, the task timeline should look like this:

1. 0-2 months:
   • implement/integrate ISLD for wxMac
   • evaluate i18n conformance, list shortcomings
   • fix bugs: DnD, grid, etc.
   • integrate list column headers
     
     
     
     
2. 2-6 months:
   • fix bugs: UI focus mgmt., HTML, others TBD
   • implement/integrate ISLD for wxGTK
   • integrate HTML rendering into email
   • build accessibility plan: timeline, dev't coordination
   • address i18n conformance shortcomings
   • identify all performance shortcomings
   • participate as available in wxTNG
     
     
     
     
3. 6-12 months:
   • fix bugs: TBD
   • resolve all accessibility shortcomings
   • resolve all critical performance shortcomings
   • participate more in wxTNG
     
     
     
     
4. 12+ months:
   • wxTNG
   • all else TBD

---

Internationalization (i18n) Issues

• tracked as Bug 3520
• wx documentation is clear about what is well-supported, unclear on all else
  • seeking wx community response to open and/or unanswered questions
• resolution of these issues as they affect Chandler will be the coordinated efforts of David Surovell and Brian Kirsch
  
  
  
  

1. Unicode
   • well supported
     
     
     
     
2. key event -> character value translation
   • well supported (but bugs are likely to be lurking)
     
     
     
     
3. Locales
   • well supported - implemented and functional - setlocale (explicit), gettext (implicit)
   • translation databases appear to be numerous and well-maintained
   • all or nearly all wx-embedded text is locale-sensitive
     
     
     
     
4. Non-Roman language system support (Asian, Arabic, Hebrew)
   • text input support - appears weak at best; non-existent at worst
   • is there a Japanese multiline edit text widget? I don't believe so...
   • native OS text input methodologies - support is unknown
     
     
     
     
5. Text wrapping
   • is it supported at the "native" level?
   • The answers for wxTextCntl are:
     • wxMSW - yes - uses Win32 APIs - system DefProc
     • wxMac - yes - uses HI and ATSUI APIs (for Chandler flavor)
     • wxGTK - yes - uses GTK APIs
   • other widgets may need additional text support, but not likely to raise major issues: tables, dialogs
     
     
     
     
6. PyICU interoperability
   • Chandler's i18n strategy is to rely on PyICU to handle all i18n functions within high-level application code. At the lower levels, where many components operate, the data and UI processes must be synchronized and/or be in agreement with ICU process and specification. i18n-sensitive data obtained from user input needs to be normalized by PyICU. Unicode solves many (but not all) potential encoding problems.
     
     
     
     
   • The current preference is to ensure that all text APIs can be coordinated between wxPython and PyICU
     • wxPython and PyICU are execution peers
     • will probably be less labor-intensive than wxWidgets <==> ICU compile-time intergration
     • willing to entertain counter-arguments
     • this issue is tracked as Bug 3567
       
       
       
       
   • Areas of concern:
     • string sorting
     • date + time strings
     • separators: currency, date, time
     • wxString <==> ICU string