Re: [Fwd: Re: YaST2 for Debian (aka nYaST)]
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
Reply to: