Presentation Layer API
The choice of API, of course, depends upon the application requirements, which I do not intend to specify here in any detail. Generally, though, the applications I hope to develop exhibit the following patterns:
- The application (often) leverages a local data store or shared network workspace.
- There are many associations between items in the data store.
- The application relies on numerous real-time calculations to provide essential user views.
- Maintenance of a transparent information flow between applications and data store(s) is integral.
- Reliability of data access is mission critical to the application.
- (Adapted from Mark Sigal.)
Points 2 and 3 are especially important. In our applications, many fields (and perhaps some graphics) will be computed in real time from data entered by the user (perhaps using a spin button or slider, for example) or from independent variables in the data store. I would also emphasize that for the most part there will be no reliance on a separate server. The data store *may* be a database system running on a network server, but it may *also* be a file or files on a shared network drive or the local hard drive. Thus my target applications are true "clients" or "thick clients" ("fat clients"). They may or may not be considered "rich clients" or "smart clients" (probably not), and certainly they are not "thin clients".
What this means is that the most technology-neutral open standards are nearly irrelevant in my situation. By this I mean that browser-based user interfaces (and their related W3C standards) will not be acceptable for me. I am open to changing my mind about this, but for the moment I am not planning to explore Web-based application development. I am attracted to the W3C standards such as CSS, DOM, HTML, RDF, SOAP, XForms, XHTML, XML and XSL precisely because they are among the most widely accepted open standards for interoperability. But because they are intended primarily for Web-based technologies, which I have rejected, it is not immediately obvious how to take advantage of these standards.
Now, I am quite aware of the fact that the W3C standards mentioned above are not limited to browser-based applications. XML, in particular, is extremely flexible and widely used in the exchange of a wide variety of data, both on the Web and elsewhere. For example, XRC is wxWidget's "XML Resource Code" API, and XUL is Mozilla's XML User Interface Language. There are, however, several problems associated with using XML for this purpose. First, XML files must be parsed and interpreted by a specific runtime environment (RTE) or rendering engine (RE), and even though cross-platform RE's can be provided, this requirement means that the API is no longer "technology neutral", because it is dependant upon the rendering engine. Second, XML files are not easy to write by hand (and not easily read by people either). The XRC page, for example, states that "It is highly recommended that you use a resource editing tool, since it's fiddly writing XRC files by hand." This means that one not only needs a RTE/RE, but a specialized editor as well. For the sake of completeness, there are at least two other XML-based API's: UsiXML and UIML, both with similar limitations. All four (XRC, XUL, UsiXML and UIML) require a third party RTE/RE because they do not use a Web browser. By contrast, XForms is an API that uses a Web browser as its RE. One advantage of XHTML/XML-based API's is that CSS is designed to work with markup languages so that it is relatively easy to use styles. More on XHTML/XML/CSS later.
Having decided not to develop Web-browser-based applications (for right or wrong and for reasons only partially discussed above), the next question becomes what kind of RTE/RE to use. Regardless of what API we come up with, the UI needs to be rendered by one engine or another. The options available depend, of course, on the programming language one chooses. Each language usually has one or more rendering engines (also called GUI toolkits) available. For example, Java applications typically use Swing, Tcl uses Tk, and C++ applications may use wxWidgets or FLTK, just to name two among many. The programming languages and associated GUI toolkits named also happen to work on multiple operating systems (are cross-platform).
For reasons not stated here but immediately obvious to Python enthusiasts everywhere, I have chosen Python for my programming language. Among the cross-platform toolkits that are available for Python are wrappers around the Tk (Tkinter), wxWidgets (wxPython) and FLTK (pyFLTK) toolkits mentioned above. Incidentally, wxPython includes an interpreter for XRC as well. To my knowledge, there are no Python interpreters (RE's) for XUL, UIML, or UsiXML.
Needless to say these GUI toolkits for Python have widely varying API's. Moreover, some of these toolkits are considered to have long learning curves and to be somewhat difficult to maintain. A few years ago a project, Anygui, was initiated to create a common (and hopefully simpler) API for different backend toolkits, including those mentioned above. Although that project has been abandoned, its API is still of interest as it represents a common denominator among the different toolkits.
More recently Greg Ewing has started a project (PyGUI) to develop a GUI API specifically for Python. Instead of relying on one or another of the standard GUI toolkits, his goal is to provide an implementation of the API that is small and lightweight using the underlying platform's GUI facilities (such as Gtk). Still in early development and not yet truly cross-platform, this API is of interest because of its focus on Python. Finally, I am aware of three other projects with API's that may be instructive: PyUI, PyGame, and PyOpenGL based on OpenGL.
So, what kind of strategy should I adopt in deciding on an API? First of all, it seems unlikely that I will find an API to adopt as is without changes or additions. If I follow a substantial portion of a given API (80%, 90%, 95%, 99% ?), however, I could claim it as a standard, but for my purposes it would be ok to come up with a new API if necessary. That said, I have no desire to reinvent the wheel without good reason, and it only makes sense to take advantage of work that has already been done whenever possible.
Since Mindwrapper uses Python syntax, if I am going to adopt a given standard, it would probably have to be the PyGUI API. Although PyGUI has no official standing, it was written by a respected senior member of the Python community and, by default, would seem to be the de facto Python standard if there is one. It remains to be seen, though, how closely I am willing to adhere to the PyGUI API. In terms of Python syntax, AnyGUI may also a good place to look for ideas.
If I decide to part ways with PyGUI to any degree, it would seem wise to look at the XML-based API's. I could not adopt any one of them as a standard, because I am unwilling to parse XML, but one or more of them could be a valuable source of inspiration. An even more likely source might be XForms. In any case, CSS also bears a careful examination. By itself, CSS cannot be a presentation API, but if the notion of styles is to be considered at all, CSS is the first place to look.
The last place to look for insights would be in the various Python GUI toolkits and their underlying (wrapped) implementations. These are the "last" sources to be considered because for the most part they are competing API's. On the other hand, picking and choosing the best features (assuming they can be implemented by modifying other toolkits) is not necessarily a bad idea. And finally, it might be worth taking a look at PythonCard, Dabo and Wax, frameworks using wxPython.