Version: 0.10.0 (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages I'm classifying this as a wish, because I see other bug reports about digiKam crashes in the geolocation code that have been rejected as a problem for the Marble widget. I installed 0.10.0 on the weekend for the first time and was taken aback at how shockingly unstable it was. I even had a run of five crashes and restarts in less than two minutes. If I don't show the right-hand Marble geolocation panel, things are more stable. Other bug reports have reported crashes and these have been attributed to bugs in the Marble project and therefore not applicable to digiKam. As geolocation is one of the nice new features, I want to be able to use it, but the crashing problem is too severe. I cannot think of any application I have used in the last twenty years that has crashed so often. Until I found out it was probably a Marble issue, I was ready to ditch digiKam 0.10.0 as an alpha-quality release that I should never have installed. Is there any way that digiKam can insulate itself better from these kinds of crashes in its dependent libraries or widgets? Even if the best it could do was report that, "Marble has crashed and cannot be used until digiKam has been restarted." That would be better than the current situation where digiKam crashes every few minutes. Even without viewing Marble, 0.10.0 crashes too often (a few times per hour), so some defensive approach to these crashes would be great if it is at all possible. Things are so bad that I'll have to build a debug version of digiKam from source and always run it under gdb to be able to capture all of the back-traces and report the crashes more accurately. I'll probably do that next weekend in the hope that you can fix them in 0.10.1. When is 0.10.1 coming out? The release plan is gone from the digiKam site. Even when it wasn't very accurate, it at least gave users some impression that improvements were in the works. I really appreciated the developers communicating that information and I miss it now.
0.10.0 never be done. 0.11.0 (or 1.0.0) is planed. release plan not yet done. Gilles Caulier
Not sure if this is right place but Marble is becoming a problem. I am running svn-trunk so all crashes are on my responsibility but recently most are caused by avogadro plugin for Marble. Avogadro! This is library used for kalzium - chemistry education software. Sometimes KDE interoperability is going too far.
0.10.0 never be done. => 0.10.1 i want mean (:=))) Gilles
Just to make it easier to find it bug #182470 seems to be the central bug for gelocation crashes right now.
Some comment from a Marble author: If there are crashes of Digikam which maybe happen inside Marble then it's not of too much help to simply send the Backtrace to the Marble team. If you are using Qt and you trigger a bug inside Qt then you wouldn't simply send the backtrace of your application to Qt Software either - instead it would be mostly up to you to create a small test case that triggers the bug (otherwise your bug report will either get ignored or get handled very late -- same with Marble). Likewise we'd prefer it if we'd receive a small test case that triggers the bug in Marble if there is such a thing. Thanks, Torsten
DGardner, Please try again updating marble code. Crash still reproducible ? If yes, please send us a gdb backtrace... Also, you can try last digiKam code from svn where OpenStreetMap support have been added. Gilles Caulier
As an end-user, I suggest you should just integrate DigiKam and Marble into ONE application. After reading bugzilla forums on the subject, it seems clear to me that DigiKam's current dependency on the full Marble package was planned from the onset, and this is not perceived by the developers as a bug. So apparently there are no plans to make Marble an optional component in the future. This is, IMHO, a grave mistake which is not only damaging the perception of DikiKam, but the good name of KDE istelf by extension. Yes, as it has been pointed out in a similar thread, disk space is cheap. Except when you're trying to squeeze that last 20 megabytes or so out of a distro in order to make it fit on a CD. Or when your work computer is an old P4 running Windoze 2k with a crappy 20 GB drive and you only have 3 GB available for your Linux partition and you were hoping for a distro with more features than XFCE. Or when you're running KDE from an image on a USB drive with only 2 GB free for your image. But go ahead, keep on telling yourselves that effectively doubling the size of DigiKam's requirements don't matter. All I know is when I run Synaptic/KDEWin installer and select DigiKam, a get a laundry list of dependencies and a statement that if I want to use DigiKam, it'll cost me another 75 MB of my precious HD space. For 75 MB, I could just install Wine and use XnView. The sad part here is that the bulk of KDE, being so tightly integrated, is vastly more efficient than Gnome, byte for byte. But KDE distros typically end up about 20-30% larger than their Gnome counterparts anyway, due to a few apps thrown into the distro that don't seem to get the whole "just use the shared libs" concept. Tragically, you're inadvertently contributing to the (incorrect) perception that KDE itself is bloated, and causing a lot people who are curious about Linux but on the fence to stick with Windows for their old PCs or new Netbooks. Somewhere between Puppy/DSL and the whole "disk space is cheap" attitude there exists a happy medium that would let users experience the best KDE/Linux has to offer but keep system requirements low enough to avoid the dreaded label "Bloatware". I sincerely hope you'll discover it soon. </rant>
Actually there are plans for KDE 4.4 to split Marble (which currently resides in kde-edu) into a library part (which will go into kdesupport) and an application part (which will stay in kde-edu). This will reduce the package size of the dependency as the data will also get split. There are also plans to provide an interface for Marble that will also give the chance to make Marble a pluggable component for all KDE applications. So yes there are plans to reduce the package size of the marble library and there are plans to make it a pluggable component. Target is KDE 4.4 but I can't promise that we'll be able to deliver on both aspects. Torsten
DGarner, This file still valid using digiKam 2.x serie ? Gilles Caulier
I have no idea if this is still valid. I rarely use Marble within DigiKam, given my past experiences with it. However, when I do use it in 1.9.0, I don't recall that it crashes any more often than the rest of the application--which isn't saying very much. I'm experimenting with DigiKam 2.3.0 at present, but it's far too unstable for any real work, so I don't really exercise many features, such as Marble, and cannot comment on the stability of that feature. (I did try the face recognition feature: it did not detect or recognise a single face and it crashed DigiKam 2.3.0 about every 30 seconds or so. I won't be using that again.)
We dont's talk about instability around face detection here, but around geolocation feature using marble. For me digiKam is not unstable with marble since a long time now, including 2.x release. Gilles Caulier