Statement of Requirements
Items in italics are still to be decided. The first version of Pythoncard will support;
Static Text
Sometimes known as labels or boilerplate.
Fields
- Single and multi-line fields for text entry. They will support tab-order between fields (TabOrder, TabIndex properties).
- Can styled text be supported without complicating the interface and code?
- Can we get scrolling text fields with scrollbars "for free "?
Buttons
- Standard
- Radio
- Radio button groups - Optional for first release
- Bitmap Buttons - Optional for first release
Data Entry widgets
- Checkbox. Support for tab-order integrated with field tab order if possible
- Listbox. Scrolling text list. Optional for first release
- Combobox. Drop-down menu list. Optional for first release
Static bitmap
Which formats should be supported(GIF, JPG, BMP, PNG)?
Menus
- File. Exit, Open, Save.
- Edit. Cut, Copy, Paste for fields.
- About. User-defined menus/menu items that are bound to commands. Could be a sub-menu from help.
- Help. Links to help (in HTML format) and version information.
Common dialogs
- File Open/Save
- Message (About)
- Choice (Yes/No, Ok/Cancel)
- Text entry choice (single field plus Ok/Cancel)
Miscellaneous
The following items are notes and placeholders for future consideration that don't fit easily into any of the earlier categories.
- Clipboard support for textual data (Cut/Copy/Paste).
- Overlapping buttons, fields, bitmaps will probably look messy at best until layering is available, so avoid rect of objects overlapping.
- All the widgets should receive and be able to respond to events like: click(mouseDown), double-click, mouseOver, keyPress, closeField [need to complete this list for each widget type)
- All widget descriptions to be stored in an external resource file.
- Initially, the layout might be handled by a variety of programs such as Boa, wxDesigner, Glade, and then scripts in Python can translate the resulting output files to our own description format. The format should be text to allow easy editing of widget properties.
- Fixed pixel-based widget positions.
- Single layer, unless multi-layer doesn't complicate framework too much
- Single card/stack, so no multi-stack issues, messaging between stacks, etc.
- Some kind of idle event so object scripts don't have to block. The simple example would be that the card object catches the idle event once a second and calls a method to update a label/field/button with the current time.
- Don't monopolize the CPU.
- No printing.
- Minimum of one resizable window with initial size defined in the resource file.
- Offscreen buffering of window contents if necessary to preserve contents when window is obscured, minimized, etc.
- Support scrolling of window contents if possible
- openCard, closeCard, nextCard, previousCard events can be generated, but no persistent data store, so the card class will need to be overridden to support record-level read/write. Those routines will also need to call methods to clear all fields, reset buttons, and load fields with data.
- Objects should be able to call existing Python modules.
$Revision: 1.4 $ : $Author: andy47 $ : Last updated $Date: 2004/04/23 19:57:47 $