Bug 93569

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.