RE: 2.4: System Tools - Please try them

[Seth Nickell <snickell stanford edu>]

On Mon, 2003-06-02 at 04:01, Mark Finlay wrote:
> > "Boot" - maybe useful, but probably not something you'd have as a
> > seperate dialogue in a perfect world.
> 
> Well in a perfect world no-one would be dual booting, but the fact is
> that pretty much everyone who installs linux nowadays is familiar with
> the idea of a boot manager. That makes this a really useful tool IMHO.

I still contend that the number of people who actually want to tweak
this setting around (as opposed to it just working, which it does when
you install new kernels and stuff) is relatively small. Like I said, not
a feature I'd cut, but probably one that'd I'd bury. Menu items are very
much at a premium.

> > "Runlevel" - A *services* focused dialogue would be awesome, much like
> > RH presents under "setup" where you can click and turn things on and
> > off. Mixing this with the traditional unix runlevels, and presenting it
> > as such in the menus, is confusing and gets in the way of what people
> > usually want to do, which is just to turn something on or off.
> 
> I agree that the idea of runlevels should be hidden from non-advnaced
> user. There are very few people who want something enabled in runlevel 3
> and not in runlevel 5.
>
> But I don't think that this requires any massive changes to the tool.
> The way it works now is that it only shows the current runlevel by
> default. To me this is pretty much the functional equivelent to just
> showing on off by default. The main problem with the dialog is the
> cryptic lightbulbs.
> 
> > "Time" - great, but maybe doesn't need a menu item and should be just
> > under the right click menu of the clock applet.
> 
> I think having it both places would be good..

In situ settings are in general preferred to centralized wherever they
can be found. We have a clock, lets let people set it rather than
pushing the abstraction of their being a "system clock" that the panel
applet is merely a display of, etc etc. There are both conceptual and
practical (menu items are at a premium) reasons to not put it in the
desktop prefs.

> > In general I'm not sure having these all under a "System Tools" category
> > is what we want. System Tools (i.e. things requiring root access) can be
> > of very different natures. As I've suggested before the best approach
> > might be to provide a "requires root access" emblem, or to use a special
> > icon style for items requiring root access (like Black and White or
> > something). Also the amount of time the applets take to start up (esp.
> > w/ the scanning system stuff) is a little irritating, but maybe there's
> > no way to work around that and still keep system abstraction...
> 
> IMHO this stuff is not on gnome-system-tools plate. Once we've fixed the
> gnome menus the gnome-system-tools can fit in very easily. So the
> questions is really "Can we commit to fixing Desktop Preferences by
> 2.4?", if not then we may have trouble fitting the gst in.

Not necessarily on gst's plate, no, though as the primary "GNOME module"
that would be affected by it, I would guess they'd participate in
looking for a solution.

> > I'd like us to consider the gst as items for inclusion, but in a future
> > release of GNOME when more of their usability issues can be resolved
> > (and to work more closely with the gst folk to specify what we
> > want/need, how they should fit in with the desktop prefs, etc). 
> 
> I think that if we can fix the lightbulb issue with the current tools,

And renname it to not deal with runlevels.

> and fix the gnome menus they could be fixed now. 

And make the dialogues use OK & Cancel not "Apply" & "Close".

> On the other hand I'd love to see them in 2.6 with a modem dialer, a
> fixed "services" editor, and modem dialer with notification area support
> and maybe some other tools - like being able to choose the system
> language or keybaord.
> 
> Also if we get libgnomesu working in the 2.6 timeframe we could
> serviously look at, as you say, making "Gnome the Operating system".
> And hiding implementation details from the user (eg. Having a user
> keyboard tool and a root keyboard tool)

In the end my primary worry is that these are a minorly useful set of
system tools relative to the possible ones, and I suspect they were
implemented because they are relatively uniform across distributions. If
you had to pick 6 systems tools to have implemented, I suspect that only
networking would be in this list. Will the gst stuff be able to handle
the more important (but probably harder) system settings? Will it?

-Seth