Summary: | respond to user replacing hardware | ||
---|---|---|---|
Product: | [Frameworks and Libraries] solid | Reporter: | Dik Takken <kde> |
Component: | general | Assignee: | Kevin Ottens <ervin> |
Status: | RESOLVED NOT A BUG | ||
Severity: | wishlist | CC: | drew.m.fisher |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Dik Takken
2008-12-30 12:33:13 UTC
The suggestion as written sounds dangerous. As you said, one of the design goals of UDEV was to have persistant, unique naming for each piece of hardware. Making UDEV behave in a way different than what its documentation and design say it should can have unforeseen consequences and could cause problems down the road. The real problem is in other apps directly reference specific hardware devices. KDE should not be changing settings other subsystems (HAL, UDEV) to fix non-KDE apps designed in this manner. In the same token, KDE apps should be designed to gracefully handle such hardware changes. A better solution to clobbering UDEV configuration files would be to have Solid know what the device is supposed to do, and simply choose the most appropriate, currently-present hardware to pass to the application. I was under the impression that this is a design goal of Solid. There's already a network management backend that talks to NetworkManager on Linux. So rather than having Solid change the UDEV rules to make the new device work as a replacement of the old one, it should change *its* rules so that applications using Solid will Just Work (TM). To me, it seems like the Right Solution is to not step on the toes of other subsystems, but work with them to make the user experience smooth. Apps that still directly talk to hardware *should* suffer your described problem - it's a side effect of the assumptions the application author made, and should be fixed by that application's developer, not hidden by a change made by an unrelated project here. Further discussion should probably move to a mailinglist. A completely agree on your remark about the design gloal of UDEV. Having persistent device names usually is a blessing, provided by UDEV. However, persistent device names are not always what the user wants. UDEV has no means to interact with the user and solve hardware issues interactively. So, UDEV is doing the right thing and it cannot solve this problem. The desktop environment (KDE in this case) can. You say we should not step on the toes of other subsystems, but work with them to make the user experience smooth. As I see it, KDE currently does *not* work with them and therefore does *not* make the user experience smooth (I'm talking about the specific problem of replacing hardware here). Currently I, the user, have to go in and manually remove UDEV rules from config files when I replace my DVD drive. That's not smooth. I'd rather see KDE clobbering config files (after asking the user) than to force users to start clobbering around. Solid can make UDEV work with the user and make the experience smooth. I agree that the issue can be solved in a more elegant way when applications do not use device names like '/dev/cdrom1' directly. They should ask Solid to provide them with one. But... This solution works for KDE applications only. Even if GNOME would adopt Solid, it would not solve the problem of device names. There's more than just KDE and GNOME applications. It's OK with me to discuss this on a mailing list. Which one? You do make some good points, particularly about having Solid do the edits rather than force the end user to tinker with global conf files himself... kde-hardware-devel@kde.org seems most appropriate. If you'll start off with a new thread (maybe even just copy-paste your original wish/explanation?), I'll be more than happy to discuss further. Thanks! :) |