Desktop GUI
From pyswarm
Good user-interfaces are crucial for the user acceptance of almost any software, so they are for pyswarm-based applications and for the pyswarm project. They are front-ends that enable users to interact with other remote or local components and to access the business data residing in databases managed by pyswarm business logic components. Beside simple command-line interfaces I'm looking for features that allow pyswarm SDK users to easily create modern user-interfaces, either Web-based or native graphical UIs that are installed on a local end-user's device. The user-interfaces should allow
Web-based user-interfaces have plenty of advantages, e.g. no prior installations are needed, integration into existing Web-sites. Recent AJAX-flavored Web user-interfaces improved usability. Although development of them are still rather complex (think of browser compatibility issues) and some features are still missing we can expect that they will improve furthermore, maybe to a grade where the will be a full replacement of native GUIs.
On the other hand, native GUIs provide heavy-users with a very high productivity. Many modern GUI frameworks enable good customization and the incorporation of eye-candy, Qt and wxWidgets are good examples for them. Such native GUIs do provide short-cuts, drag & drop, selection of entire ranges of items (e.g. with SHIFT-key) and de-selecting single items (e.g. with CTLR-key) and many more. As already mentioned in the documentation and mailing lists pyswarm will support GUIs based on wxWidgets. This doesn't mean that other frameworks are not that good. Actually other GUI-frameworks could be supported in med-term future, but now wxWidgets seems to be the best choice for the pyswarm project.
As already done until the preview release Young Pickerl with the pyswarm backend components, I would like to describe some key features of a desktop GUI for a custom pyswarm application. The project wiki seems to be the best place to collect all the ideas that popped up during the recent months. I'm using a (dirty hack) dummy to create screenshots in order to visualize proposals for the desktop GUI. This dummy will not be published.
Based on these ideas I plan to create an extensive example GUI which should work as a blue-print of all GUIs that could be generated by pyswarm SDK, including patterns how these GUIs can be customized or extended by developers. The blue-print should be polished and coded tidy, so the source code can be used directly to create the transformation models and templates that are applied by the SDK when generating GUIs for a custom application.
Unfortunately, I am not a good programmer. Any help planning and implementing the GUI blue-print is appreciated very much.
Contents |
A brief Model-to-GUI example:
Example for a domain class is this Salesproject class:
Not shown in this diagram are some stereotypes and tags that will help to create the GUI-related model.
Depending on the multiplicity of attributes and associations the GUI will contain single widgets or collection widgets (tables, lists). Note that the hierarchy association would result into two widgets, one "parent" with one object linked, and one collection widget with "subprojects".
If one class will have more than one association to be shown in the GUI each collection widget will be embedded in a tab (notebook page) labeled with the name of the association end, e.g. the "assignedCustomers" tab and the "subprojects" tab.
Following you see a state diagram that results from my most recent concept how state machines can be utilized for pyswarm's model-to-code generation. Only triggers explicitly specified in the model may cause transitions (here we have only SendOperationEvents as triggers). A Salesproject object in the state OPEN can have close() called upon it (in this GUI example with a "Close project" button), which will normally transit the state to CLOSED. In that state (CLOSED) there is no "Close project" buttton in the GUI, but a "Reopen project" button.
Probably it's reasonable to add GUI-specific state machines, so developers can specify highly customized features of the GUI at detail grade comparable to the domain logic.

NOTE: The tabs "assignedCustomers" and "subprojects" are missing in this screen-shot.
The dialog action buttons may effect the transaction with the database. A click on "Cancel" button would revert all changes made in this dialog (transaction roll-back), while "Save" button would commit the transaction.
Static-boxes can be used to seperate classes from each other in the same window.
Some general GUI features:
- Gimmicks (Splash screen, sys tray icon, ...)
- About box, license, credits
- Perspectives (menu-bar, tool-bar, panels)
- Built-in panels (SSO, search, meta-bar,...)
- Built-in help, documentation
- Typical elements of domain widgets
- Broadcasting and sharing dialogs
Domain windows
- simple dialog
- complex dialog
- multi-page dialog (wizard)
- frame
Widgets and more
These widgets are designed specifically for working with domain objects of a pyswarm application
- Static box
- Collapsible pane (FoldPanels)>
- Tabs
- Static text (fancy text)>
- Text control
- Check-box
- Radio-box / Radio-button
- ComboBox
- Currency control
- Quantity control
- Choice
- List-table
- Calendar, date and time
- Slider and Spin
- Grid
- Button (plain, image, toggle)
- Throbber
- Open file dialog / File browse
- Save file dialog
- Directory picker
- GenericDirCtrl
- Page setup + Print + Print previews
- Editor (plain text, styled text control)
- Editor (rich text)
- HTML Window
- Progress / Gauge
- Single Choice
- Multi Choice / CheckListBox
- Font Dialog
- Color Picker
- Image browser
- StaticImage
- Popup menu
- PopupWindow / PopupTransientWindow (e.g. for user's notes, bubble-help)
- SashWindow
- DynamicSashWindow
- ScrolledWindow
- Menu (fix + floating)
- Toolbar (fix + floating)
- StatusBar
- OwnerDrawnComboBox
- PyPlot
- PyShell
- For 3D graphics: Python-OpenGL
- For 2D graphics: GraphicsContext (transparency + anti-alias) or OGL (Object Graphics Library)


