51–60 of 136 posts
I checked out Digikam recently because my camera didn't support PTP but instead a custom protocol and I wanted to copy pictures over (Dolphin had no support). Sadly, Digikam had to mess with the metadata of each picture and put its name inside. Which contribution has the program done other than download the picture from the camera? So I went to using an SD card reader instead.
Earlier quoted context omitted.
And crash in the most spectacular way.
Right, computers do have loads of RAM. So just spin up a chromium fork for the UI, and a handful of http servers for the different background tasks, pull in a bazillion of dependencies, and... it's gone. The RAM, that is.
So the same for all other complicated tasks.
It is not that handling run time errors has demonstrated to be a trivial tasks for a main app.
Earlier quoted context omitted.
I've been using it since 2011 and no problems with anything. Over 200k photos.
The infamous "Works on my laptop"
- Maybe you are constantly trying it on the same distro that constantly has problems with its build for some reason or other. Consistent bad experience for the smaller number of users who conclude incorrectly that digikam is broken. For example suppose it uses out of date libraries that the software depends on.
- Maybe your configuration is unusual in some fashion and because of this consistently hits the same bug. If nobody reports it then it never gets fixed if it doesn't also effect a developers machine.
Neither of these is an indication that the projects low level architectural direction is problematic.
I checked out Digikam recently because my camera didn't support PTP but instead a custom protocol and I wanted to copy pictures over (Dolphin had no support). Sadly, Digikam had to mess with the metadata of each picture and put its name inside. Which contribution has the program done other than download the picture from the camera? So I went to using an SD card reader instead.
Since this is an open source project, could you remove that part of the code?
Earlier quoted context omitted.
The infamous "Works on my laptop"
Conversely the a singular anecdote also doesn't mean it doesn't work either. I strongly suspect that when you have a largish body of people are using something without issue and one person is constantly experiencing problems there might be a reason why. - Maybe you are constantly trying it on the same distro that constantly has problems with its build for some reason or other. Consistent bad experience for the smalle…
What we actually have is a tiny number of users who use Linux as a desktop that have pretty much identical use case with a small number of images succeed. All other workflows flop.
> Neither of these is an indication that the projects low level architectural direction is problematic.
In 2020 having a project where processing a corrupted file under any conditions causes the app to crash means the projects has a bad architecture.
Every year for at least last 5 years I have been trying Digikam. Every year like 99.9% of the reasonably complicated GUI-based single process multi-functional software written on Linux it would blow up while working with marginally large sets of files (~ 50k photos, roughly evenly split between 24 megapixel NEF files and random resolution jpegs ) It is just sad to see that the imaging/image processing/image organizin…
Had the same problem, with an even larger dataset. Picasa on the other hand had no problem with it. But huge albums are a problem for many programs, unfortunateley.
Every year for at least last 5 years I have been trying Digikam. Every year like 99.9% of the reasonably complicated GUI-based single process multi-functional software written on Linux it would blow up while working with marginally large sets of files (~ 50k photos, roughly evenly split between 24 megapixel NEF files and random resolution jpegs ) It is just sad to see that the imaging/image processing/image organizin…
(Not a dozen components, though; just four. A main/watchdog service, a web service, a volume watchdog and directory scanner service, and a cluster of sync-file jobs).
Related: it was a total pita to handle real-time debugging until I made my own `tail -f` that sorted by timestamp and automatically updated as new processes added new log files).