Free project hosting by
Latest release: tba
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.3 $ : $Author: kasplat $ : Last updated $Date: 2002/02/07 23:48:27 $