Since the last hotplug release, the way to do this is:
- /etc/hotplug/usb/FOO.usermap ... what devices supported
- /etc/hotplug/usb/FOO ... what to do when they're connected
IMHO, applications shouldn't create or modify those files. The potential
for conflicts is too great. What if the user wants two different
applications to be able to access the same device?
Text editors or PDF viewers have the same problem: some file that
can be used with multiple applications. The traditional answer is
that the apps learn to co-exist ... not that they hamstring themselves
by avoiding the standard configuration mechanisms.
I'm thinking of something
like /home/mark/.usb/VID:PID.autorun, that contains:
* /usr/bin/xsane --device=%DEVPATH%
/usr/bin/gimp --acquire=%DEVPATH%
This is a different problem than text editors have, since devices
start out managed by "the system" (which includes xsane and gimp
as well as hotplug, with blurry lines) and you've just assumed a
stage where they're handed off to some user.
It's that "hand device off to user" facility that we need. Once it
exists we can start asking questions like how to package or bundle it.
What it comes down to is that the user should be in control of the
hotplug policy at all times, not the applications at install time.
Which user though? And control through what user interface? User
control is a fine thing, so long as it's not as badly done as most
similar UNIX user interfaces have been done. And one user option
should certainly be to let the system automatically set up, for one
example, the new printers or disk that are attached ... and manage
them as system resources, not unsharable resources tied to one user.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
