Re: [Utopia] Roadmap to Utopia

[Robert Love <rml ximian com>]

On Wed, 2004-04-21 at 23:07 +0200, David Zeuthen wrote:

I've heard of this Project Utopia thing...

> Now, by user experience, I mean the whole deal, i.e.
> 
>  1. How is installed hardware discovered by users? How is it used?
>     And how does the user tweak settings on hardware, if at all
>     deemed a good thing?
> 
>     For an example of tweaking hardware settings, consider storage
>     devices; one popular OS allows the user to specify whether
>     the OS should use write-caching or not - this is a trade off 
>     between performance (faster writes) or usability/convenience (user
>     can yank out the device without clicking a button on the desktop)

Which they bury in the advanced tab of the device's properties in Device
Manager, which is only accessible from the Advanced tab of System
properties (or some such, right?).  Point being it is complicated and
hidden, probably intentionally, although I don't give their UI design
any credit either.

So my feeling is that we aim to not expose a whole bunch of tweakable
settings.  Power users can edit the appropriate /etc files if they want
to fine-tune things (but even I don't mess with parameters to any of my
drivers.  Stuff should just work).

As far as discovery, I think that hardware should just start working.
The user should have minimal interaction with the system in that regard
- if the user attaches a new device, that act alone should signify that
the new hardware works.  E.g., plugin a printer, now you have a new
printer to print from.  Plugin a new drive, and a new drive appears in
Nautilus.

For device browsing, something like hal-device-manager is fine.

We could put a notification applet in the GNOME notify area if we want,
which could glow or something when a device is attached.  But I don't
overly love that idea.

>  2. What happens during insertion of new hardware? Does it 'just work'?
>     If it needs to be configured, how does this happen? What if the user
>     inserts the hardware when GNOME is not running and it needs to be
>     configured? How is the user notified, if at all?

As much as possible, everything should just work.  Very few devices
require explicit user configuration (printers, networking cards not yet
configured being the exception).  For those, if a user is logged in, we
can invoke a configuration utility.  If a user is not logged in, then we
don't.

>  3. What happens when hardware is removed? How is the user notified?
>     (Both questions probably needs to be answered both when the system
>     and/or GNOME is running and when it's not)

We could use a little glowing GNOME applet for this.  Or, do nothing -
again, the user ought to know that they just unplugged something.

>     Does the user have to do something before unplugging a device when
>     the system is running?

I think we should definitely aim for a big definite NO here, except
where otherwise impossible.  E.g., users have to unmount storage volumes
before removing the backing device, and they are going to have to learn
to live with that.  But, otherwise, the user should be able to rip
anything out at anytime.

>  4. How does the presence of hardware notification and configuration
>     affect the ecosystem of applications at the GNOME level? 
> 
>     To be more concrete, look at gnome-volume-manager - currently it
>     can start applications like totem and gthumb. Is there a need for
>     a richer model? Should applications be able to register themselves
>     with g-v-m on installation? For instance, if I install Rhythmbox
>     should it register itself as handler for music players (e.g. ipod)?

Yes, applications should be able to register themselves, although not
with g-v-m I do not think but with a generic MIME-like responsibility
database.  E.g., "music player" should be a type.  Or, "CD Burner" or
"Video player".  Just like we do today under default applications for
text editors and web browsers.

Then g-v-m just queries those preferences.

>  5. How does auto configuration play with different distributions and
>     operating systems? 
> 
>     I mean, presently we use HAL to abstract all the hardware
>     which is all good, because we believe that it can run
>     on other OS'es than those based on a Linux 2.6 kernel. But HAL is
>     deliberately designed to avoid policy decisions and e.g. rely on
>     the OS/distro to load kernel modules and so forth.
> 
>     In other words: How does software at the GNOME level apply
>     configuration parameters that is OS/distribution specific?

At some very high level, unless distributions unify their settings,
these things are going to remain vendor-dependent.  Take networking
configuration, for example.  I am working on callout code for that now.
Different vendors can obviously share HAL, the callout scripts I am
writing, and maybe some other glue.  But since we have different
configuration files, and different configuration utilities, that stuff
will remain separate.

But that is not any change from the status quo today - e.g., whether or
not Project Utopia is implemented on a given distribution, you still
have vendor-specific configuration utilities.  If vendors ever unify
around a single configuration utility, then that code too will be
shared.

The further up the stack you get, the more vendor-specific and
policy-specific you get, so naturally the less and less that will be
shared.  I think our goal is to make the infrastructure as rich,
flexible, and kick ass as possible so as little nontrivial stuff as
possible is not shared.

For example, take the current system stack in Red Hat: the kernel,
MAKEDEV, kudzu (and all of that stuff), and the redhat-config tools.
Plus all the RH-specific stuff such as initscripts, networking scripts,
configuration files, and other magic.

Project Utopia could unify almost all of that, but not all of it.  The
big thing to get rid of in the above is kudzu, imo ;-)

>  6. Corner cases; what happens when there is no driver for a device?
>                   etc etc etc.
>
> Phew, these are all pretty difficult questions. I realize that. I also
> realize that most of them got pretty fundamental answers, while some
> don't. I really don't pretend to have the answers - maybe it's not even
> the right questions?

Who knows.  I don't believe I am necessarily right on any of the above,
either.  But I have been thinking about these issues for a long time,
and I have a general idea where I want to take Project Utopia.

> I'm hoping that at some point we can identify a) existing apps/
> components that can be enhanced as part of the Utopia process; b) new
> apps/components that needs to be developed; and c) end at some kind of
> roadmap. For this identification process, maybe it's useful to look at
> one device type at a time, e.g. networking devices, storage devices,
> input devices, music players (e.g. ipod), cameras and so forth. 

We did this here at Ximian.  Joe and I sat down with our lead designer
and hashed out use cases for a whole bunch of hardware.  I posted most
of those to my blog a week or so ago.

I think the initial goal for Project Utopia is laying the infrastructure
to do neat stuff with the hardware.  As we move out of that phase (and
we are - HAL is maturing, etc.) we can start figuring out how the
hardware events we are generating fit into the GNOME world and what we
can do about them.

I think g-v-m solves the storage issue pretty well (although we still
need some gnome-vfs loving), Joe hacked HAL into CUPS, and I am working
on some callout scripts for networking stuff as we speak.  So we are
getting there! :>

> However, I think it might be best to have a discussion on the generic
> level first, e.g. how does the user relate to hardware, cf. points 1-6
> above.
> 
> Oh, and there's probably a bunch of technical issues, we'll get to them
> at some point :-)

I feel that if you look at all of the current Project Utopia work (dbus,
udev, HAL, policy stuff like g-v-m), plus the 2.6 kernel work that went
on, we have a lot of the technical issues solved.  It is all the other
"stuff" that needs to be done. ;-)

	Robert Love