[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Fwd: Re: YaST2 for Debian (aka nYaST)]


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.


Reply to: