Re: [Utopia] Roadmap to Utopia

["John (J5) Palmieri" <johnp redhat com>]

On Wed, 2004-04-21 at 17:07, David Zeuthen wrote:
> Hey,
> 
> Second Post! No, seriously, now that we got a mailing list, I was
> thinking that it may be useful to have some kind of discussion on the
> road to Utopia. I, for one, is not quite certain what it looks like!
> 
> First, from a 50000 feet perspective, it would be useful to somewhat
> characterize the feeling we want the user to experience; I'm saying this
> because two other, let's call them Operating Systems, that handle
> hardware in an, uhmm, acceptable way, act in fairly different ways.
> 
> 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?

A couple of options here that I can think of:  
* the classic icon on the desktop
	pros:
	- it's right there
	- we used to do this with volumes such as cdroms
	- I think some other OS's do something similar
	cons: 
	- can be lost in the clutter of some peoples desktops
	- Some people don't like things on their desktop that they didn't put
there

* have a special v-folder called "Devices"
	pros:
	- This is the way we currently do volumes in the Computer vfolder
	- Network works this way
	- Doesn't clutter up the desktop
	cons:
	- Not instantly discoverable
	- If we break devices up into sub categories (e.g. printers, scanners,
handhelds, music, etc.) it could become deeply nested
	- some devices, such as storage make more sense with the rest of the
volumes in the Computer v-folder but some dual use devices such as ipods
make sense in both a music and storage category.
	- Putting all devices in a flat v-folder might get cluttered for those
users who like to have all the newest toys and have them plugged in at
the same time (very unlikely)

* Have the notification applet actually be useful and display icons for
the state of plugged in devices.  This can be used alone or in
conjunction with the above two.
	pros:
	- instantly discoverable
	- does not clutter up desktop
	- people like flashing things
	cons:
	- people hate flashing things
	- some people do not run the notification applet
	- may clutter up panel
	- small icons (on small panels) may not be distinguishing enough. 

>     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)

I thought Gnome was about not giving the user these options.  Hardware
should just work.  For the 1% who cares we can provide a "power tools"
collection of apps without worrying about integration.  In your example
I would like to just say fixed devices get performance boosts and
removable media opts for safety.

Some options may lie in a more gray area.  I think that needs to be
decided on a device class basis.

>  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?

If at all possible it should just work.  This would solve the whole
GNOME running/not running issue.  However this is not a perfect world so
not all devices can just work.  In general does the user need to be
notified?  Depends on the hardware in my view.  If I plugged in an ipod
I pretty much know I plugged it in.  If it doesn't show up where I
expected it to then I assume something went wrong (e.g. other end isn't
plugged in, wire broken, etc.).  Of course having the notification
applet here would be nice because the user can see that the device has
indeed been plugged in and if it has been detected and configured
properly (through the state of the icon).  

Notification when not in GNOME might just be a console beep which I
believe the hotplug stuff does when you plug in a pcmcia card.  It would
be quite annoying if I were typing a command to use the device and a
message flew up on the console.  

>  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)

Console beep, loss of status icon, desktop or v-folder icon disappears? 

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

If at all possible this should be a big NO.  What happens when the user
yanks the USB cord out by accident.  Telling them they should have
pressed the button might piss them off.  If not possible (with storage
devices perhaps) we need to be able recover the device if this happens.

> 
>  4. How does the presence of hardware notification and configuration
>     affect the ecosystem of applications at the GNOME level? 

Send out messages to whoever cares to listen and let the applications
deal with it?

>     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)?

We were talking about this at Red Hat.  In theory the mime system was
supposed to deliver similar functionality to files of different types. 
In reality it is really hard to get right.

>  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?

>  6. Corner cases; what happens when there is no driver for a device?
>                   etc etc etc.

It is hard to say how this will all work.  A device database of sorts? 
Corner cases will most likely have to be delt with when they come up and
after we have the common case working somewhat well.

> 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?

It is a very good start in any case.  I don't pretend that my answers
above are anywhere near correct but it is good we are talking about
these issues.

> 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. 

splitting up devices seems the natural way to tackle them.

> 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 :-)
> 

Technical issues? What are those ;-)

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com