On Sun, 29 May 2005 17:17:45 +0000, Rajeev J Sebastian wrote:
>>
>> Sounds a little like reinventing the wheel. Between ivman, hotplug,
>> udev, hal, dbus & friends there shouldn't be (much) need to add more
>> stuff
>
> Problem is, if we don't do it, Kubuntu users will be stuck with
> hal-device-manager, or some C++ version of it (which IMHO i really don't
> agree with). Otoh, I really would like to get pmount to work, but so far
> nothing I have tried has got it up and running.
To get pmount to work you simply have to contact the pmount developer
and tell him to add support for local hard disks, explaining that it's
essential for live distributions. It's probably enough to have this
fixed, since ivman uses pmount, and for the rest KDE users in general
(Kubuntu users in particular) could use the media:// protocol, or an
extension thereof which handles all aspects of the HAL&DBUS combo.
> Plus, why would a system like this be "re-inventing the wheel" ? Other than
> ivman, such a program would have little in common with the other packages.
> And, wrt ivman, we have to edit XML (ugh) files, with a limited scope of
> applicability (DBUS events).
Ok, I hate XML too, but this can be fixed with appropriate frontends.
> Not that there is anything wrong with XML, but generally describing processes
> that execute based on some condition (when pen drive available, mount it,
> check hardware-spec/filesystem and start appropriate software after
> confirming with user) is basically what a programming language is for, and
> what a beautiful language python is :)
>
> Plus, the sheer number of such rules (conditions+processes) almost requires
> an
> easy-to-read, easy-to-change, easy-to-understand system.
Can't hotplug and udev handle this?
> Making this system in python would be i think, quite straightforward, and
> deep
> integration with KDE (and other systems) would also be possible. (For e.g.,
> modify sources.list, if a cdrom with a specific file-system structure was
> inserted).
This can be handled by ivman, IIRC.
> And, it seems, not quite everything makes it into DBUS - for e.g., my monitor
> doesnt show up in hal-device-manager.
How is such an event signaled? Can't ivman be extended to handle this?
> Not to mention, the lack of a KDE
> version of hal-device-manager.
Ok, this can be fixed by writing the frontend for hal; basically, an
extension of the media:// protocol, as I mentioned.
> Of course this leads to the second problem: over-configurability (like
> Control
> Centre). But that is a question of the design. Perhaps, we can make it
> better ?
Don't know the answer to this :)
>> ... maybe, as I said, the only thing that should be added is
>> pmount support for fixed hard disk.
> But this *should* work out of the box. But it doesnt. Of course, it is truly
> a
> problem to be solved, and so is next on my agenda.
Well, pmount is *not* supposed to work with hard disks so what you
need is either something like pmount or an extension of pmount. The
latter seems like the best idea, to me.
--
Giuseppe "Oblomov" Bilotta
"I weep for our generation" -- Charlie Brown
|
