Version: (using KDE KDE 3.3.1) Installed from: 00 What has always a bit annoyed me about Digikam, was that I had to first mount the camera and then connect to it in Digikam. 3-times connecting the camera (if you count the physical connection too) does cast a shadow on an otherwise user-friendly application. It would be a lot easier if in the case of USB cameras clicking on the "connect USB camera" would also mount the camera, and clicking on disconnect USB camera" would also unmount the camera. I don't this should be too difficult to implement, but then again I'm no coder. :]
I think digikam should use HAL (freedesktop's hardware abstraction layer, hal.freedesktop.org) for detecting cameras (usb mass storage cameras and gphoto supported cameras).
HAL is a very good idea too. But is it ripe yet?
Using it on Gentoo since about a half year I would say yes. There is also a new stable version 0.4.x which IMHO has all features needed for using with digikam and cameras. The only problem is that hal present only works with Linux 2.6.x, so this is not a solution for Linux 2.4.x, BSD, ...
That would be a nice solution then. But wouldn't HAL solve the problem the other way around? That you'd have to mount the camera and then DigiKam would pop up automagically? off topic P.S. I'll emerge HAL asap ;)
I think HAL is a little bit overrated. In kernel 2.6 there is udev, a devicemanager running in userspace. You can also start scripts triggered by udev. But udev also makes it easy to use hotplug e.g. /etc/hotplug/usb/usb-storage. Cause you use udev you can be sure that your cam has a unique devicename so its easy to mount and umount it. The name of the device and its mountpoint lives only as long as the device is really connected. Here is my /etc/udev/rules.d/10-udev.rules for my CF-cardreader: BUS="scsi", KERNEL="sd*", SYSFS{model}="223 U HS-CF", NAME="%k", SYMLINK="cards/cf%n" This mounts any partition of the CF-card to /dev/cards/cf[1..n] Cause I only use one partion with my cards I use a very simple /etc/hotplug/usb/usb-storage: #!/bin/bash logger "`basename $0`: USB-Storage working...$PRODUCT" id="424/223a/195" dev=/dev/cards/cf1 mntpoint=/mnt/storage if [ $PRODUCT = $id ]; then mkdir $mntpoint mount -t vfat $dev $mntpoint -o rw,sync,umask=000 logger "`basename $0`: $mntpoint ready" cat > "$REMOVER" <<-EOF #!/bin/bash fuser -k $mntpoint fuser -k $dev sleep 1 umount -f $mntpoint sleep 1 rmdir $mntpoint logger "`basename $0`: $mntpoint disabled" EOF chmod a+x $REMOVER fi Ok, HAL now goes one step further. You have a messaging system via dbus. This is fine but current KDE did not support dbus today. The KDE equivaltent would be a dcop call to talk to listen apps. Maybe you can try to work with dcop kded mountwatcher but I am not sure if this improves the handling. HTH Thorsten
A "quick hack" would be to scan /mnt and /media for directories named things like "camera", then try to mount them if not already mounted and then use them, or use them if they already are. Not elegant, or scalable, but would work for most cases. Any errors in doing this shouldn't be reported to the user, as it's not the user's fault if quick hacks don't work!
*** This bug has been confirmed by popular vote. ***
I'll put my 2 cents worth in. I'm trying to create a Linux environment that a typical desktop user would like. Having an easy to use digital camera interface is a requirement.
Now we got media:/ (dbus/hal) support in KDE-3.4. Why not using this abilities in digikam. It's a feature I'd really like to see instead of doing dirty hacks or reconfiguring digikam each time, I connect another digicam. Just plug in the cam and show the new detected device in the camera dialog. Thanks!!
Yes, it would be really great if digikam could use media:/ (and I think that is a clean, non-hackish solution) Anyway thanks for digikam!
Hi, we 'all' want the same. Nevertheless, it's no good idea for digikam to support dbus/hal media or whaterver. What's (IMO) needed is a application that knows abouts dbus/hal media and allows application like digikam to register for certain events. A _start_ in this direction is, e.g., kay: http://jr.falleri.free.fr/fichiers/devel/kay/kay_0.3_dialog1.jpg All digikam needs to support is to start/stop the download camera dialog via commandline and/or dcop (also for mountpoints). JMTC, Achim
With the advent of KDE 3.5 (Or was this available before 3.5?) KDE can handle dbus/hal events itself, so when a device gets connected an eerily windows-esque type window opens asking what you want to do. With a bit of HAL messing-aboutery, it's more than possible to simply get KDE to automatically open "digikam --detect-camera" when your camera's inserted.
actually it already opens digikam with the correct camera import dialog.
coolo? cant this be closed?
I'm afraid it's only in the SUSE packages so far. What I've did is installing this as konqueror service menu: [Desktop Action OpenDigikam] Exec=digikam --download-from %u Icon=digikam Name=Open in Digikam [Desktop Entry] Actions=OpenDigikam; ServiceTypes=media/gphoto2camera,media/camera_mounted,media/camera_unmounted
Short before 0.8.1 release, rudimentary media:/ support was added. It was disabled due to some buglets, like e.g., when digikam is already running, it did not switch to this desktop and it looks like nothing happened while digikam was waiting on the other desktop. The TODO file contain some of the bugs I discovered when I tested the experimental media: code. From above comments it looks like SuSE at least enalbed the code. If there are additional media: patches by SuSE, please attach them here. Would be really nice to get the buglets get fixed before the 0.8.2 release. If any developer is interested in finished media: support: AFAIK KDE svn contain a enhanced version of the digikam media code in extragear/review (?) seperated as a library. As long as this is not finished, API frozen, the author Tom Albers recommends to use a copy of it in applications. Achim
Created attachment 15691 [details] patch the only patch I have is backported from SVN
This functionality is also allowable in Debian. By adding the service menu to /usr/share/apps/konqueror/servicemenus/ [Desktop Action Upload photos to Digikam] Exec=digikam --download-from %u Icon=digikam Name=Upload photos to Digikam [Desktop Entry] Actions=Upload photos to Digikam ServiceTypes=media/removable_mounted,media/camera_unmounted,media/camera_mounted,media/gphoto2camera,media/cdrom_unmounted,media/cdrom_mounted,media/cdwriter_mounted ,media/removable_unmounted,media/cdwriter_unmounted It also works. I have committed to svn.debian.org, but perhaps this should also be included upstream.
There is even more media: functionality already. One just have to remove the #if 0. (see 0.8.1 ChangeLog) I only had time for a quick look at the coolos patch but when this makes media/gphoto2camera work with --download-from that's a nice addition. Service menues that handle partially the case when digikam is running are branches/stable/extragear/graphics/ and the tarball in digikam/utilities/hotplug One has to add hotplug in utilities/Makefile.am and rework the text used in .desktop files. Achim
SVN commit 549373 by mwiesweg: Trying to solve the remaining media support problems - apply Coolo's patch for resolving media:/ URLs (from #93569) - close CameraUI cleanly - ask user if he wants to cancel the current operation when closing - cancel operation when closing - delete object when closed - dont add new tasks to the queue when closing - Allow only once CameraUI per CameraType object - store current UI with a QGuardedPtr - when a non-closed UI is found up and running, raise it, dont create a new one - when camera interface is called via DCOP (probably from media menu) - call KWin::deIconifyWindow - call KWin::activateWindow() - do not compute image dimension when listing from a UMSCamera. This is a _huge_ speedup, say 5 minutes to 5 seconds. - do only compute image dimension if requested in UMSCamera - compute image dimension if not yet done in CameraItemPropertiesTab - various speed and crash fixes in CameraUI/CameraIconView - do not crash when the first item was deleted from camera and then removed from IconView - do not request exif for items which will be deleted - IconView: allow to delay updating frequency a bit - use a ched itemRect for CameraIconView. Its faster, but more importantly, there was a crash with a pretty long story BUGS: 126112 CCBUGS: 127846, 93569 CCMAIL: digikam-devel@kde.org M +17 -6 digikam/cameratype.cpp M +13 -6 digikam/cameratype.h M +113 -35 digikam/digikamapp.cpp M +2 -0 digikam/digikamapp.h M +26 -5 digikam/iconview.cpp M +4 -0 digikam/iconview.h M +30 -2 libs/imageproperties/cameraitempropertiestab.cpp M +2 -1 libs/imageproperties/cameraitempropertiestab.h M +3 -2 libs/imageproperties/imagepropertiessidebarcamgui.cpp M +34 -6 utilities/cameragui/cameracontroller.cpp M +24 -24 utilities/cameragui/cameraiconview.cpp M +4 -1 utilities/cameragui/cameraiconview.h M +77 -9 utilities/cameragui/cameraui.cpp M +2 -1 utilities/cameragui/cameraui.h M +3 -1 utilities/cameragui/dkcamera.h M +1 -1 utilities/cameragui/gpcamera.cpp M +1 -1 utilities/cameragui/gpcamera.h M +20 -17 utilities/cameragui/umscamera.cpp M +1 -1 utilities/cameragui/umscamera.h
To me it seems digikam has now all the support that is possible with the current state of hardware integration in KDE and the free desktop in general. I am wondering if it's ok to close this bug now - I will close it in a few days if no other opinion comes up.
As said in my last comment, I close the bug now as fixed because digikam provides the level of hardware integration that can be expected from application developers under KDE 3.5. When KDE4 arrives and provides technologies like "Solid", we will do our best and improve hardware integration.