Alpha - Basic toolkit features are functional

[bombasticbob]

basic toolkit features must be functional for Alpha release

• platform helper - abstraction of basic OS features
  • system information
  • processes
  • threads and synchronization
  • pointer abstraction for Event handling
• text helper - API for string handling and related
• file helper - API for file handling, listing directories, path searching
• window helper - API for basic UI and event handling
• clipboard helper - full clipboard support using Event-safe API calls
• font helper - API for font selection
• menu helper - API for menus (frame window and popup)
• frame windows - SDI and tabbed MDI owner frame and child frames
• dialog helper - dialog boxes, modality, text-based dialog resources
  • 'fixed' dimensions on dialog boxes
  • A simple dialog resource editor with drag/drop [to self] and other graphical features
  • reserved - resizable dialog boxes
    this has limited usefulness. See 'note 1' below
• dialog controls - basic dialog control windows
  • ability for user-override of callback functions
  • standard and customizable properties associated with each control
  • visible/invisible and 'greyed' (disabled) capability
  • static text
  • static image, icon
  • edit text (single or multi-line)
  • push buttons
  • check buttons (including tri-state)
  • radio buttons
  • scrolling list box
  • static and editable drop-down combo box (other types not required)
  • tree control with collapsible members
  • special file list box and directory tree control that interact with one another
• debug helper

additional 'higher level' features

• edit window, based on child window, that supports text-based document editing

[bombasticbob]

Note 1: re-sizeable dialog boxen

Some GUI toolkits support this feature extensively, by having dialog components be "relative to one another" and by setting up alignment zones like a web page with certain kinds of style sheets.

In cases like Android, device rotation can significantly change the relative alignment of dialog components, and so a lot of this may be seen as 'necessary'. However, in general the landscape/portrait thing could be handled "upstream" by the application, rather than relying on some automatic system to do it. My own experience with Android suggests that having 'portrait version' and 'landscape version' makes the most sense, and in those cases where screen resolution is too low for a larger dialog to be displayed, smaller alternative versions can be used.

So having an application test for 'small screen', landscape, portrait, etc. and THEN generate the appropriate dialog box makes a lot more sense to me than to go through the time/effort to implement something that has 1% usefulness.