Laserfiche WebLink
In order to develop useful and flexible GUI components, RTi proposes that, above all, GUI <br />development be kept simple. This will not only allow for faster development, but will also allow <br />future ports to other platforms to be carried out with less effort. <br />Standard GUI components will be used, rather than enhanced features that may not be supported. <br />For example push-buttons and radio-buttons (a set of buttons where only one of the buttons can be <br />selected at a time) will be used for selecting items. These components can be intuitively used and <br />exist in many windowing systems. RTi realizes that many of the CRDSS users may be familiar with <br />Microsoft Windows and may be uncomfortable with GUI components that are not available on that <br />system. <br />Each complex GUI component (such as a form for viewing diversion structure details) will be <br />developed as a stand-alone routine that can be placed in a library for use in various applications. The <br />arguments of the routine will be determined based on the data that are to be displayed by the GUI <br />component and will be coordinated with the identification of data objects, as discussed in Task <br />Memorandum 1.05-8. Such GUI components will initially be prototyped using a GUI builder so that <br />buttons, labels, and other features can be identified and organized. ?Empty? or ?hidden? features <br />will be coded in areas where it is known or anticipated that future enhancements to the code will be <br />made. For example, it is anticipated that many display forms will need to be editable in order to <br />allow for scenario generation. However, providing extensive functionality in this area now would <br />require budget that is not available in Year 1. Therefore, the code will contain provisions for <br />allowing edits, but will not enable that functionality until Year 2. <br />Public domain software will be used where the product has been shown to be portable and is well <br />accepted by the user community. Use of public domain software is advantageous because access to <br />the source code allows developers to choose the version of the software to use. For example, even if <br />a new version of a certain public domain product comes out, the old version of the product may be <br />used in CRDSS because it serves the needs of the project. Because the source code is available, <br />developers can decide when to upgrade rather than having to depend on the upgrade schedule of a <br />software supplier. <br />The ?look and feel? of code will be maintained by following the Open Software Foundation's (OSF) <br />Motif standards. These standards describe the way that GUI features such as menus should appear <br />and also outline basic functionality and default settings. Additionally, GUI attributes will be <br />controlled by resource files and will not be hard-coded. For example, colors used for an application <br />will be set in the application's resource file, rather than being set in the code itself. This will allow <br />all applications to be configured external to the source code. <br />Long-term maintenance of GUI code will be carried out using the methods used for other code. <br />Revision control will be used to track changes to the software. Libraries will be used to store <br />common GUI code components and will be debugged thoroughly so that applications built using <br />library routines can rely on that code as being correct. All routines will be thoroughly documented <br />for use by developers. The State will have access to all code for distribution to other users. GUI <br />code will be maintained using tools described in Task Memorandum 1.05-21. <br />3.0 CONCLUSIONS AND RECOMMENDATIONS <br />9 <br />A275 07.28.94 1.05-15 Malers <br />