wm161.net
About
Trever Fischer is a junior at The University of Akron
with a strong enthusiasm towards coding, writing, photography, and above all: oranges.
This is his site. Specifically, this is his "About" box. He is also a full-time hacker who tinkers with Amarok, Plasma, various KDE bits, and PHP.
![[FSF Associate Member]](/images/content/fsf-membership-button.png){kind=small}
Archives
Links
Places to find me
device-automounter in kdereview, SRPM for Fedora 11
Two quick notes here:
Over the weekend I moved device-automounter into kdereview. If all goes according to plan, it should be in kdebase, after which I shall continue hacking on it and combining it with the solid-actions stuff (and perhaps consolidate the other two hardware-centric KCMs into one ‘hardware’ page) for 4.4.
Also over the weekend I tinkered around with RPM packaging and created my first RPM. Its an RPM for device-automounter that should work nicely on Fedora 11 KDE 4.3. Get it here. Its my opinion that if there is anyone thinking of including this into fedora repositories, they shouldn’t. It is an already out-of-date export of the svn, it isn’t a ‘real’ release 0.1, and it (hopefully) will be released as part of kdebase-4.4. Having said, that, enjoy automounting in your KDE 4.3 on fedora :)
9 Responses to “device-automounter in kdereview, SRPM for Fedora 11”
Leave a Reply
The content of wm161.net by Trever Fischer is licensed under a Creative Commons Attribution 3.0 United States License unless noted otherwise.
See http://wm161.net/copyright for more details.
“and perhaps consolidate the other two hardware-centric KCMs into one ‘hardware’ page”
yes! , please do it :)
openSUSE users can get up-to-date packages from the buildservice. http://software.opensuse.org/search?baseproject=openSUSE%3A11.1&p=1&q=device-automounter
Nice to hear it’s finally getting done! Does this perform automount using Solid abstraction layer? If so, I see you’re using Fedora, so is there any news on libudev (aka Device-Kit) Solid backend? ‘Cause it looks like nobody’s working on it, and if Fedora finally makes the switch from HAL… then KDE is dead ((
Is this a plasma widget? There is already the device manager plasmoid.
LINK: http://kde-look.org/content/show.php/Device+Manager?content=106051
@thorGT Yes, it does use Solid. And I myself looked at Devkit to try and figure out how to use it, but for the life of me I can’t find any documentation on how to do something simple like give me the status of my battery. Writing a solid backend is easy, but figuring out Devkit isn’t.
@lefty No, this isn’t a plasma widget. This is a normal KDED plugin, separate from plasma. That way you don’t have to have a specific widget added just to have this feature.
Well, if you’re seriously looking into writing a Solid backend, you could ask in Devkit mailing list, in case you find no documentation. And considering battery status, there’s the Devkit-power daemon, which does the job for you IIRC. (Devkit’s three separate parts, libudev, Devkit-disks and Devkit-power, if I’m not mistaken) And would you actually consider writing a Solid backend in the meanwhile? Maybe for testing purposes only.
First, there really is no point in working on a DeviceKit backend for solid until they have a stable API, or at least a proper release at all.
Secondly; what’s the idea behind automounting, as opposed to mounting just when the disk is accessed?
@thorGT There already is a Devkit backend in /branches/work/solid-devicekit.
@sandsmark Because other apps like OpenOffice or firefox don’t know how to mount a device, let alone know about unmounted devices. Having to manually mount the device before you can use openoffice’s open a file dialog is an extra hoop people have to jump through. Also, I disagree with waiting for a stable API. If devs don’t use the unstable API, and it turns out the API doesn’t work too well with solid, the end result isn’t too great either. Constant feedback turns an unstable API into a quality stable one. Finally, you can’t have some global daemon magically intercept requests for an unmounted device’s future mounting point without needing some kernel intervention, like autofs does.
I think we should package the device automounter and keep it updated. Of course, this would imply we’d need sources which build against 4.3. (This has been a major source of trouble for kde-plasma-weather with 4.2. I ended up shipping the old code, with some fixes backported from trunk and some custom hacks to work around issues I couldn’t easily backport fixes for. Other stuff, like Okteta on 4.0, has been much less troublesome. I don’t know how it will be for your code.)
As for Solid and DeviceKit, there’s a more complete backend (using also libudev) in the works here:
http://websvn.kde.org/branches/work/alternate-solid-devicekit/
But according to its author, it’s not ready for production use either. It’s incomplete both at the Solid level (some interfaces not implemented yet) and at the underlying level: There’s still information which is only available through HAL, projects like libgpod don’t put the information we’d like into udev yet.