Rapid Photo Downloader 0.9.9 is released

Yes indeed, I graduated with a BSc in 1994. How about yourself?

BSc 1991 (Computer Science).
Since then I’ve done other things (as have you, from your web page!!!)

Getting back to the actual thread :smile:

I’m in the midst of trying to transition to Manjaro as my distro because it gives me a stable video driver supporting opencl (necessary for dartable without painfully slow editing steps) as well as a stable KDE Plasma desktop (which I prefer to gnome shell and unity). I can’t meet these requirements with any Ubuntu or openSUSE and my hardware.

However the deal-breaker may be being able to install your excellent software. The AUR version is 0.4.11-4. I’ve tried to go manually by installing dependencies as per the README, but the script won’t let me install (since I’m on an Arch derivative). I am thinking of the nuke option:

Caution: untarring the archive, building it and installing it using sudo python3 setup.py install is not supported, and not recommended.

Is there an alternative that is possible? I haven’t yet resorted to hacking the install.py script, but that was something else I have considered.

What might be an alternative?

Replying to my own query … ! :wink:

though I cannot use the octopi package software to fnd it, on the cli using yaourt the 0.99 .bzr version does show. No luck installing yet …dependency issues, but hopefully just a matter of time.

Anyone else using Manjaro may find that trying to use either a gui tool or yaourt from the cli it sems impossible to install python-pymediainfo.

I discovered that downloading from here then installing as a locall package was the only way I could achieve this.

The other dependencis were satisfied by yaourt using the 0.99. bzr release of rapid-photo-downloader from aur.

Very happy I can now run my goto software (without rebooting into my old Ubuntu environment). :slight_smile:

I guess my chain of poss have been less about this software and more about the quirks of getting it installed on this particular linux distro .

I don’t know much about the Arch family of distros, sorry. I do know people have been using the AUR version in Arch since 0.9.0 was in alpha, so they must have some way of installing all the dependencies.

i’m working on uploading this to debian.

2 Likes

i uploaded this as a “NMU” (Non-maintainer uploader) to Debian, which will take 10 days to trickle down to unstable, and from there, another 10 days to trickle down in testing. I don’t know how much time it will take to trickle down into Ubuntu, and some work will be needed to make the cut for 18.04LTS, but that’s outside of my jurisdiction now.

BTW, as part of the NMU process, we have the habit of sharing a diff between the two versions on the bugtracker. This was a problem for RPD the diff between 0.9.7 and 0.9.9 is huge:

$ git diff upstream/0.9.7 upstream/0.9.9 | wc -c
28707596

That’s 28MBs! It looks like most of the changes are in raphodo/qrc_resources.py but there are also thousands of lines of changes in upgrade.py and install.py. It would be nice to avoid such massive changes in the future, maybe by moving those assets to a separate directory?

Thanks for getting process started that will result in the package being updated. The diffs result from changes in binary assets – embedded zip files of translations (in the case of install.py and upgrade.py) and icons/images (in the case of qrc_resources.py). There are good reasons behind both.

shouldn’t icons be shipped as standalone files? this would make the diff more manageable, especially from git’s point of view…

The first example there shows exactly what I was suggesting, ie. not embed the file:

<qresource>
    <file>images/copy.png</file>
...

Now those resources need to be compiled in binary form, but that could be done at build time: it doesn’t need to be stored in the repository…

I think you might be unfamiliar with how Qt resources are handled in PyQt 5. In PyQt 5, the file resources.qrc is used to generate qrc_resources.py by using the method outlined here: http://pyqt.sourceforge.net/Docs/PyQt5/resources.html

yes, but this could be done at build time and not shipped in the source…

anyways, 0.9.9 just entered Debian unstable after the 10-day NMU delay:

https://tracker.debian.org/news/942697/accepted-rapid-photo-downloader-099-1-source-all-into-unstable/

enjoy!

1 Like

Hello, RPD stopped showing my USB sticks and SD cards in “Devices” however I am able to find them in “This Computer” in /run/media/user/…
I was wondering if I can fix that. The system is openSUSE Tumbleweed KDE (up-to-date)

Works for me in a Virtual Box instance of Tumbleweed and a USB 3.0 card reader. So I don’t know what issue you might be facing on your system. When running under KDE, Rapid Photo Downloader interfaces directly with UDisks2, in contrast to when it is running under desktops which use GIO/GVFS.

I have noticed that the issue occurs if you turn the “Devices” slider OFF and try to turn it back ON later. Maybe it caused by my configuration only though. I have 6 USB ports and one SD card reader in my laptop and there is always something plugged in into them.

You can file a bug report here: https://bugs.launchpad.net/rapid/+filebug
Be sure to include the log files found in ~/.cache/rapid-photo-downloader/log/

@damonlynch, thank you for this great program. I am in the process of packaging it for NixOS and was wondering about the tests the source comes with. Are these up-to-date? For example I encountered some errors with test_generatenameconfig.py and am not sure what to do with test_proximity.py. test_thumbnail.py is commented out and test_thumbnailpara.py looks to me like a manual test.

1 Like

No. They are not automated tests. They are are a mix of transient tests used for only particular stages of development and benchmarking. Sorry for any confusion.