Re: Proposed: gnome-system-tools

[Carlos Garnacho <garnacho tuxerver net>]

On Tue, 2004-07-20 at 10:01 -0400, Havoc Pennington wrote: 
> On Tue, 2004-07-20 at 01:30, Jeff Waugh wrote:
> > <quote who="Havoc Pennington">
> > 
> > > Reiterate 
> > > http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00161.html
> > 
> > Is that "should not go in until these issues are resolved", or a reminder
> > that we really desperately need to resolve these issues? :-)
> > 
> 
> Two points:
> 
> 1. Anything end-user oriented should be sucked into control center and
> designed top-down as part of control center, not kept separate.
> 
> If there are tools targeted toward *admins* we should consider those as
> a separate module and the interaction design should be done with admin
> as audience.
> 
> So "date and time" should probably be in the control center. "Boot
> loader" is an admin thing, or just "geek power tools"; same for
> "runlevel."
> 
> "Network" is more ambiguous, though the way we're approaching it at Red
> Hat (see Dan's NetManager thing in CVS among other pieces) is to "just
> work" with no config in the dhcp case, you would still need a control
> panel for static IP and so forth. The control panel should be clearly
> specified as admin-targeted or end-user-targeted and maintained with a
> hard line on that.
> 
> For network profiles, probably you want to associate a profile with some
> kind of "signature" (heuristic way to identify a network) and switch the
> profiles automatically when those networks are joined (and then when no
> network is joined switch to Offline mode).

This is too idyllic for me, right now you can't say that all networks
will be configured through DHCP, and there are too the cases in which
users don't have a network at all but still want to connect to internet
(say through a PPP connection).

Regarding heuristics to guess networks, I don't know of any, and if/when
they exist, it will be still necessary a consistent system across
distributions to store and apply those profiles if we want GNOME to just
work...


> 
> 
> 2. The second point is the specific proposed top-down design, which does
> not include all the stuff that's in g-s-t, but does include some of it.
> 
> Basically the proposed list of preferences is a roadmap for what prefs
> we want to have (for users, it ignores admins), so the way to eval g-s-t
> is to include the parts that get us further along the roadmap
> (optionally arguing with the roadmap first, but the roadmap argument
> should be done holistically/top-down by presenting an entire alternate
> roadmap, not piecemeal). We could also add a separate roadmap for admin
> functionality.

I'm ok with separating preferences in admin/non-admin, but there's still
a couple of issues to fix:

- Root password: probably fixable at some point
- we're changing system-wide settings in an ideally user-oriented
app/whatever: this is quite hard to fix, and it's a legacy problem, not
g-s-t fault.

Maybe the better approach to fix this (in the g-s-t side) is an "unlock"
button a-la MacOS tools? it's the better solution I can find right now


> 
> There has to be an overall design for *all* the user's preferences,
> which of them are in control panels, which are elsewhere, and so forth.
> The argument on what to have should be done looking at the whole list
> and whole plan, and then the implementation should iteratively move
> toward the result.
> 

ok, but a first step must be given :)

	Carlos

> 
> Havoc
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>