Hi! Am Wednesday 24 November 2004 01:58 schrieb Carlos Garnacho: > > > Now, if the backends could also abstract out the syntax (inheritanble > > > parsers) and semantic (config description files) it could be much > > > easier to extend and maintain the config tools. > > Yes, It could be easier but also much less intuitive and user-friendly, > user-friendlyness also has a really important role if we're trying to > make a competing desktop based in Debian, and I think that the users > will thank us if we make a bigger effort than showing self-generated > GUIs with the almost raw configuration inside. > > ��������Excuse me if I'm wrong
I can't, because you are right! :) Certainly raw file GUIs wont't cut it. Where does GST generate its GUI elements? I thought in the frontend, too. Let me try to explain two approaches to for easy expansion/maintanance for the app guys *and* nice GUIs. One is to just continue to code the GUI frontends explicitly, having them work on the (XML) representation just as now. Changes in file format may not need changes to the backend, or recompilation though. Extending the functionality of the tool would always require extending the frontend besides a parser and description fitting the desired file The second approach would be to use forms and wizard definitions in the descriptions that contain logic for GUIs (further grouping, sequences, help texts etc.) besides the real names of options, possible values, defaults and helptexts from the regular hierachie generated from config file descriptions. With this it should be possible to autocreate reasonable good tabbed, iconized, treeified or mixed GUIs even for things manpower could not yet customize the frontend for. Maybe the forms and wizard description files could be considered as abstracting out package specific parts of the GUIs or other frontends whereas the description files with options, defaults etc. of the config files could be considered abstracting out the package specifics for the backends/parsers. An important point for user-friendly GUIs is of course good consolidation of options within the meta-configuration. I.e. when the hostname has to be set in a config file, its description file should not create a new property-node for it on the representation level, instead this value should default to be inherited from the node representing the systems hostname. Same for other things that should be cross referenced. Thus if you change the hostname on the representation level the write operation will change it in all the places and invoke reloading the necessary files as also given in the description file for those files. Cheers, Christian
