RE: gnome system tools

[Havoc Pennington <hp redhat com>]

On Sat, 2003-10-11 at 04:05, Murray Cumming Comneon com wrote:
> > From: Havoc Pennington [mailto:hp redhat com] 
> >  - I wonder if we should be bundling the g-s-t discussion as a whole; 
> >    the thread here already seems to be wanting to take some of the 
> >    tools but not others. Is that an option or do they come as one 
> >    framework/package?
> 
> I have suggested just a few of the tools because I think an all-or-nothing 
> proposal risks leaving GNOME 2.6 with none of them. I think the maintainer 
> would like all of them in 2.6.

My question is, are the maintainers willing to split in this way, and do
people think it makes sense to consider them one at a time.

> The control panels might be consolidated more, but that's a different 
> discussion, I think.

I don't really agree; part of the process here should be ensuring we
have a rational control panel setup. The "control panel creep" in 1.4
was the result of panels being added/created according to
maintainer/module-ownership boundaries, rather than planned as a global
whole.

An example: the Sawfish control panels, vs. the way metacity just folds
in to the Keyboard Shortcuts, etc. panels.

It _may_ even make sense to have g-s-t part of the control-center
module. Worth a good solid think.

Take an example: gnome-sound-properties and redhat-config-sound. To me
one of the advantages of using GST over redhat-config-sound would be to
maybe merge those or relate them in some way.

Now is the time to sit down and figure this out, instead of just piling
in the menu items and additional dialogs.

> >  - one thing that can be more clever is to avoid the tool entirely. 
> >    e.g. Windows XP often doesn't make you configure a network at 
> >    all, it basically just dhcp's any network card you plug in
> >    and also monitors the link status and dhcps if you plug in 
> >    a cable. So for a laptop for example, there's not much 
> >    configuration to be done.
> 
> Obviously it would be good to make everything just work, but some people
> will still need
> to change settings sometimes. I think that having a GNOME Network control
> panel that's the 
> same on all distros is a step towards making networking easier in general.
> 
> I'd be very happy if we can one day hide these things deeply or relegate
> them to some 
> hacker-tools release set, but I don't think that idealism should stop us
> from providing 
> the functionality that people need now. Maybe I am too pragmatic.

I'm not saying have no tool, I am saying maybe it's not the primary UI
and maybe it's a bit buried in the menus in favor of opening it
automatically or making things work automatically as devices come and
go.

What we want to avoid is assuming that "network configuration"
automatically means writing a single "tool" which is a single dialog.
The user task is "make my network go" - and we can do a lot that's
_outside_ of the dialog, pervading the whole desktop.

Take "file sharing" as another example; we probably don't want a tool
there, it should probably be part of Nautilus.

Don't want to knee-jerk default to a one-dialog tool for all problems.
Instead you want to take the problem as a user task and find all the
ways you can address it.

> >  - should part of the "backend" of certain tools be the hardware 
> >    abstraction layer? A tool like redhat-config-sound is potentially 
> >    a trivial HAL wrapper for example. Or HAL could expose list of 
> >    network cards and notify on link status changes.
> 
> Do we want to wait for HAL?

I'm not suggesting that. I am suggesting that we should be taking a look
at using this infrastructure. Otherwise we risk having a pile of
Linux-2.4-specific code all over the place. Especially if we don't limit
ourselves to the "all code related to networking is in the one tool"
approach.

Havoc