Bug 127846 - digikam crash when 2nd gphoto camera dialog is closed
Summary: digikam crash when 2nd gphoto camera dialog is closed
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Import-Gphoto2 (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-22 21:30 UTC by Achim Bohnet
Modified: 2020-08-13 15:52 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.9.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Achim Bohnet 2006-05-22 21:30:26 UTC
Version:           0.8.2-rc1 (using KDE 3.5.2, Kubuntu Package 4:3.5.2-0ubuntu18 dapper)
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.15-23-686

I can reproduce the bug with a Canon Powershot A40
when I open 2 times for the same model.

o open ghoto camera download dialog
o open same camera download dialog a second time
         ==> error msg: failed to open camera ...
o close second camera dialog
         ==> digkam crashes


Instead of opening a second download dialog for the same
camera, bring the 1st one to front.

Achim
P.S. for USB mass storage camera I can also open several dialog
for the _same camera definition.  Digikam does not crash, but I don't think that's a useful feature.

Achim
Comment 1 Marcel Wiesweg 2006-06-08 14:03:45 UTC
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  
Comment 2 Marcel Wiesweg 2006-07-12 12:07:16 UTC
Closing this bug now