Re: [Setup-tool-hackers] RE: 2.4: System Tools - Please try them
- From: "Carlos Garnacho Parro" <garnacho tuxerver net>
- To: "Seth Nickell" <snickell stanford edu>
- Cc: murray cumming comneon com, garnacho tuxerver net, desktop-devel-list gnome org, rodrigo gnome-db org, gpoo ubiobio cl, setup-tool-hackers lists ximian com
- Subject: Re: [Setup-tool-hackers] RE: 2.4: System Tools - Please try them
- Date: Mon, 2 Jun 2003 12:00:11 +0200 (CEST)
Hi Seth!
> On Mon, 2003-06-02 at 01:01, Murray Cumming Comneon com wrote:
>> > From: Seth Nickell [mailto:snickell stanford edu]
>> > I have general concerns that the system tools I'm seeing are also not
>> > really the ones that we have a big need for, and are often confusing.
>> > That said, as I'm sure you all know, I'm a big fan of GNOME
>> > starting to
>> > think of itself as an operating system and provide a uniform interface
>> > to hardware/system settings, and gst seems like a good place to start.
>> >
>> > "Boot" - maybe useful, but probably not something you'd have as a
>> > seperate dialogue in a perfect world.
>> >
>> > "Networking" - Great! Probably the most common system
>> > configuration task
>> > (though less important when DHCP stuff just works, but it doesn't
>> > always).
>> >
>> >
>> > "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.
>> >
>> > "Time" - great, but maybe doesn't need a menu item and should be just
>> > under the right click menu of the clock applet.
>> >
>> > "Users" - good to have, esp. if you're admining a machine
>>
>> Sure. I don't think any of these are things that should stop it from
>> going
>> into GNOME now. Improvements can and should happen, but modules don't
>> have
>> to be perfect to get into GNOME - they need to be not awful and there
>> need
>> to be no obstacles to them becoming perfect. I think adding them to
>> GNOME
>> will make people such as yourself perfect them.
>
> My comment mostly is that the current set of features isn't what we
> (well, what I think we) want. If we want a banana, we shouldn't take an
> orange and then try to change it ;-) Certainely we don't/shouldn't
> require perfection, because nothing has that, but we do want to make
> sure that when we accept something its fitting into our goal for
> accepting it. I'm a little concerned that gst isn't targeted (or at
> least well targeted) toward meeting the nebulous "manage your
> system/hardware" goal that would be the primary reason for its
> inclusion.
The GST (due to its infrastructure) is perfectly targeted to the "manage
your system/hardware" goal, and IMHO gnome wants bananas and oranges ;-),
it's true that there are some tools that could be needed by gnome too, and
gst doesn't (still) provide them, but it's just a matter of time, they
would/will be done in a later stage of development, and the current tools
are desirable too in a friendly environment (or maybe you just prefer
editing /etc/lilo.conf, /boot/grub/menu.lst, /etc/yaboot.conf for changing
your bootloader settings, or symlinking /etc/rc*.c, editing /etc/rc*.d or
/etc/runlevel.conf for adding/removing a service at boot time)
>
> Also worrying me is that I don't see large changes to gst since the past
> year or so, at least in this direction, so I wonder if I or other
> usability people thinking gst should have a Bar config tool and a Baz
> config tool, and should drop the Boot and totally change the Runlevel
> config would have any impact on the actual implementation in a timely
> manner (say... for 2.6). Basically, I think gst is only about 25%
> "feature complete", and the features it does have are more than half not
> terribly important features or have usability problems so serious that
> most people will not find them useful (runlevels).
Changing the runlevel tool to make in services oriented tool is mostly an
UI Change (the backend could remain the same), and can be done quite
easily, but I need a better design for it, since I think that the
runlevels concept (abstracted or not, at least for sysv and file-rc) are
neccesary for a tool like this, I'll try to contact the usability people
for this.
anyways, what kind of desktop would offer a clock that allows changing to
UTC, internet time, showing a calendar... and not changing the time? ;-)
Regards
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]