Jump to: navigation, search

Deprecating UI Forms

Revision as of 11:41, 17 June 2011 by Cwindatt.ca.ibm.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

There is a desire to deprecate UI Forms and discontinue it's usage within Eclipse. We are exploring the feasibility, starting with the largest consumer, PDE.

Benefits

  • Focus in 4.2 and Orion is web technology
  • No resources available to continue UI Forms support or improve it
  • Opportunity to change the look of editors, improve workflow
  • Opportunity to clean up editor code and editing models in PDE

Costs

  • PDE usage is very high
    • Multiple editors with different requirements, UI widgets
    • Target Editor: Custom filtered checkbox tree, UI code shared between editor and a wizard
    • Manifest Editor: Mixes editor pages for three files, changes on one page affect buttons/actions/content on others
  • Lose layouts provided by forms and widgets provided by SWT/jface
    • Have to provide some generic tooling to reduce code duplication
    • Accessibility support (BIDI, translation) must still function
    • Layouts and other UI elements could be browser dependent
  • Minimally all Eclipse installs will require a SWT compatible browser to function
    • No fall back like currently exists in Intro

Concerns

  • Need master/details section of some sort (reused throughout PDE)
  • Text editor functionality must still exist for PDE editors (community will not accept loss of functionality)
  • What effects this will have on products
  • Accessibility requirements may force us into using a UI framework like Dojo.
  • New editors must improve on originals (no ROI to rewrite the editors and have them look the same)

Work Planned

  1. Investigate PDE Models
    • What dependencies do they have on the forms API
    • Can they be streamlined as part of this process
  2. Select a PDE editor to work on as pilot project
    • The Table of Contents editor from PDE UI/UA is top pick currently. Good choice because:
      • Single page editor
      • Uses the master/details structure
      • Current code is heavy
      • Used by a variety of developers, but not important to products
      • Uses both a UI and text based models
    • ToC editor may not be the best choice because:
      • Other editors may demonstrate major blocking issues before too much time is invested
      • ToC only uses a small number of widgets with a simple workflow
  3. Mock up an editor in browser
    • No connection to model or editor framework

Links

Embedded Orion Editor Example