CRDSS_Task1_05-15_BuildingGUIComponents

Home Browse Search

portable GUI builder. Because the Motif code ports to the SGI, it is not cost-effective to rewrite this code. The consumptive use model interface is likely to be largely based on existing code developed for previous models at CSU IDS. Consequently, it too will be developed most cost-effectively using Motif. The top-level interface for the CRDSS, and the interfaces for the CRSM and AOP models will be developed most cost-effectively using XVT because the GUI components will be new and will not depend on existing Motif code. XVT will also be useful in situations where a compact GUI- based utility is to be developed, especially where porting to PC's is possible (e.g., where code does not depend on complex code available only for workstations). A consistent ?look and feel? can be provided by relying on the native environment's standards (e.g., standard menu items like ?F ile? and ?H elp?). For workstations, this means that the Motif standards will be used, both in coded developed using Motif, and in code developed using the XVT product (which relies on Motif and therefore conforms to its standards). Resource files will be used to specify defaults such as fonts and colors. GUIs will be kept simple to limit the amount of non- standard look and feel. It is the consultant's opinion that a certain amount of programming experience will be required to do any maintenance. Although new code developed with a GUI builder can be maintained with the builder (e.g., adding a button), this requires that the programmer understand the GUI builder (not a trivial task) and also be able to understand the underlying code that is connected to the GUI (the code to execute after the button is added must still be coded manually). Where Motif code is used, maintenance will have to be done by an experienced Motif programmer. Efforts will be made to thoroughly document the code and to make the code flexible such that recoding will not be difficult. One way to do this is to make sure that GUIs are data-driven and do not depend on hard-coded settings. Development of GUI Components for CRDSS The budget for the CRDSS is not large enough to allow a great deal of money to be spent on extensive GUI implementation. This is especially true in Year 1, where the database and Gunnison prototypes of the water rights planning and consumptive use models are the most important tasks, and in Year 2, where much of the effort will be on the database and model calibration for the remaining Colorado River basins within Colorado. Consequently, the budget for GUI development must be spent on the most important aspects of the CRDSS GUIs. RTi proposes that the best way to do so is to anticipate future GUI needs and provide for those needs by developing a good ?foundation? for GUI design in Year 1. Enhancements to GUIs in Years 2, 3, and 4 can therefore be made without reworking the basic design of GUI components. Additionally, because each feature of a GUI requires funding, RTi proposes placing limits on the functionality of GUIs in Year 1. These limits are outlined in the task memoranda describing the CRDSS display capabilities (Task Memoranda 1.05-16, 1.05-17, and 1.05-18), and in Task Memorandum 1.05-22, which describes prototyping. Rather than provide a GUI that has ?everything for everyone,? GUIs developed for the CRDSS will concentrate on providing basic display capabilities that reflect the needs of models and the contents of the CRDSS database. Providing this level of functionality will be possible within the project will budget. The area that demand extensive budget is the development of GUI capabilities for handling scenarios, a task that is slated for Year 2 (Task 2.11). The general procedure for handling scenarios is discussed in Task Memorandum 1.05-9. GUI development in Year 1 will concentrate on providing display capabilities only, with the exception of a few important scenario parameters. 8 A275 07.28.94 1.05-15 Malers