Re: Proposed: gnome-system-tools

[mike <mike redtux1 uklinux net>]

On Mon, 2004-01-05 at 02:05, Carlos Garnacho wrote:
> El dom, 04-01-2004 a las 17:14, Havoc Pennington escribió:
> > On Sun, 2004-01-04 at 01:52, Jeff Waugh wrote:
> > > Hrm, I don't know what to say about these, apart from the fact that they're
> > > really sweet these days. Clearly people want them, but there hasn't been
> > > much distributor buy-in or commentary at all, really.
> > 
> > I had a few comments last time we discussed it - 
> > http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00243.html
> > http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00255.html
> > 
> > Re-reading these, my main concern continues to be that nobody is sitting
> > down and holistically thinking through the control panels as a whole,
> > how they appear in the menus, where each setting lives and how the user
> > finds it.
> > 
> > Not a problem introduced by the system tools, but here is the thing:
> > it's the main problem including system tools in GNOME could _solve_,
> > that we can't solve easily in distribution-specific tools.
> 

How about this as an initial proposal for resorting

Scrap server tools as a main level (where it is used)

Then have System tools with the following sub-headings

Network Access (connection to outside the local machine as client)

Server Settings - only settings that relate to acting as a server
(named, smb, mail etc)

Local Machine Settings (packages, system logs, services, password etc)

peripherals (printers, mouse etc)

This would keep one sub-level and be more obvious



> You're right, IMHO this problem has been there for too long, about a
> year ago I faced the decision of moving the g-s-t menu items from
> "desktop preferences" to "system settings", it wasn't the correct
> decision, but neither was keeping it in "desktop preferences" because:
> 
>  - the g-s-t aren't for desktop preferences
>  - mixing in the same menu elements that require root password and
> elements that doesn't isn't a good idea
> 
> To avoid problems like these, I think that the control center should be
> sorted and categorized in some way, of course with the g-s-t in mind to
> make it feel like a whole. Anyways, I consider that merging g-s-t and
> g-c-c is a bad idea
> 
> > 
> > My secondary concern was that some of the system tools didn't make sense
> > to me, though I haven't checked whether they are all still included. So
> > I do think we should consider them one at a time, not as a bundle.
> 
> Even when I'd want all the tools to become part of gnome 2.6, I think I
> already agreed to split the toolset if it's necessary, so the correct
> consensus should be on which tools to accept. Of course the development
> on the "rejected" tools won't stop
> 
> In one of these messages you also raise the issue of accessing HAL
> through the backends, all I can say is that in the short term this will
> be hard to happen, as the backends are perl scripts, but in a longer
> term it will be more feasible
> 
> Sorry for not having answered these questions before :)
> 
> 	regards
> 
> > 
> > Havoc
> > 
> > 
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>