Re: Release Team's Almost-Final Modules List

[Sander Vesik <Sander Vesik Sun COM>]

On 29 May 2003, Ole Laursen wrote:

> Sander Vesik <Sander Vesik Sun COM> writes:
> 
> > > My[1] concern (and this is probably something that needs to go into GEP
> > > 10) is not so much for 'does it run on FreeBSD' as ''can it run on
> > > FreeBSD.' Joe, if it's your opinion that porting the current g-s-t
> > > infrastructure will be difficult/very hard (once you've been able to
> > > inspect it thoroughly), that's a huge strike against it. 
> > > 
> > 
> > well, presently its much more 'gnome-linux-system-tools' than
> > 'gnome-system-tools' that could be expected to work and be useful on a
> > variety of (non-linux) systems. Its not just the matter of porting /
> > writing new backend pieces. ultimately its design is backwards - instead
> > of an GUI that adjust itself to what its present backend/system is capable
> > of, it is a gui into which you can plug a new backend that needs to
> > provide the gui with what it thingks will be there on the system.
> 
> But if you have to rewrite both the GUI and the backend then there's
> no point in having any common ground, is there?
> 

uhhh, no, you would not write separate GUI-s - thats why you need it to be
self-adjusting. So instead of having builtin knowledge that the user
parameters to display are {user, uid, home, shell, group}, theh gui would
ask the backend what these are and then display the result - which might
be say {user, uid, home, shell, group, login class} or something
considerably different. 

features/bugs that don't exist on the system at hand (like say runlevels)
should never be exposed in the ui. 

> -- 
> Ole Laursen
> http://www.cs.auc.dk/~olau/
> 

	Sander

OpenOffice.org - conquering the world 14000 PC-s at a time