Added command line option to import preferences from from an old program
version (0.4.11 or earlier).
Implemented auto unmount using GIO (which is used on most Linux desktops) and
UDisks2 (all those desktops that don’t use GIO, e.g. KDE).
Fixed bug while logging processes being forcefully terminated.
Fixed bug where stored sequence number was not being correctly used when
renaming files.
Fixed bug where download would crash on Python 3.4 systems due to use of Python
3.5 only math.inf
Download details and instructions: http://damonlynch.net/rapid/download.html. It’s simple, really: for Fedora or Debian/Ubuntu users, just run ./install.py rapid-photo-downloader-0.9.0a2.tar.gz
I’m happy with the way it imports preferences from the old version. I wanted to do it so that it didn’t require installing all the old pygtk packages, which would be a real pain when it comes to packaging it. Instead it requires only the presence of gconftool-2, which it checks for at run time (i.e. it’s not required for installation).
Finally, I managed to configure Apache correctly on my website so that it makes pages expire in the browser cache after 10 minutes instead of never expiring, as it did before. No more having to refresh the page to get the latest version, which was really rather silly.
I discovered your software with @RileyB’s FOSS photography tutorials, and it looks very useful (I haven’t started using it yet, still using my very old-school manual way of copying files over).
A quick question, since you’re talking about packaging: will it be packaged at some point, or is the method described in the link you give the usual one? I’m asking because, as a Ubuntu user, it seems like a bit of an “exotic” way to install a software
Thanks again for taking the time to develop this tool!
Edit: It looks like the answer to my question is “Yes” because I can see a Debian folder in the source code repository
Packaging is a skill that requires quite some time to master, and the skills need to be kept up-to-date, because the packaging tools and standards are constantly evolving.
While it’s conceivable I could package the latest version myself, using the familiar deb package, the most obvious problem is that any time I put into developing the package means time taken away from writing the program. But the second problem is that some of the tools the most recent version Rapid Photo Downloader uses are not themselves packaged in Debian/Ubuntu. The most important is python-gphoto2. I put in a request to the Debian developers that this be packaged about a year ago, but so far no Debian developer is interested. Without that package, a deb package of Rapid Photo Downloader is worthless.
Using a snap is far more promising. However the big question is how the sandboxing that comes with snap will hinder use of Rapid Photo Downloader, given that by it’s very nature the point of Rapid Photo Downloader is to be able to have write access to the file system, including outside the user’s home directory.
Finally given you use Ubuntu don’t be shy about installing it the way I suggest. It’s actually extremely easy and safe!! I’ve tested it on every version of Ubuntu, i.e. Lubuntu, Kubuntu, Xubuntu, etc. The only problem I’ve seen is that Ubuntu Mate is having problems displaying the graphical elements of Qt 5 applications (it seems they’d fixed that bug at some point, but it seems to have reappeared).
I cannot agree more. I had to deal with Debian packaging recently and it’s not an easy task at all!
Did you try contacting the developers on IRC or on their mailing list? Also, did you have a look at AppImage or Flatpak?
Also, did you try putting Rapid Photo Downloader on PyPi ? This way, a simple pip install rapid would do the trick… Unless there are dependency problems there as well?
Did you try to get in touch with Dariusz Duma? He is maintaining the Highly Explosive Ubuntu PPA, with lots of photography-related packages… Maybe he is interested in including rapid photo downloader as well?
We have set-up a photoflow package many months ago, and it is working like a charm!
Making a snap is on my TODO list. The others are not, because if they were, I’d never get the application finished!.
Sadly it’s not possible to put it on Pypi because it has Python dependencies that are not on Pypi, e.g. all the gobject introspection modules. That’s why I needed to write my own custom install script. [quote=“Carmelo_DrRaw, post:5, topic:1424”]
Did you try to get in touch with Dariusz Duma
[/quote]
If Dariusz or someone else could volunteer to package python-gphoto2 and a couple of other Python modules, that would be an enormous contribution. Then I can revive my own Rapid Photo Downloader package in my PPA.
@RileyB it depends on whether you have the generate thumbnails option set on or not. If you see generate_thumbnails=false in the Rapid Photo Downloader.conf located in ~/.config/Rapid Photo Downloader, then thumbnails simply won’t be shown regardless of whether a file was previously downloaded or not.
If however it’s not set to that (the default is show thumbnails, of course), then there is indeed a bug.
It looks like I’m going to have to update my VirtualBox copy of Fedora 23! I pay for internet by the MB (which sure sucks, believe me) so I’m reluctant to download hundreds of MB of updates unless I have to, but in this case it seems I should because you’re reporting some bugs I’ve not seen while developing on Ubuntu Hopefully I can replicate them in a VM and not running bare metal.
More generally, as i wrote here, the missing features of the program are the components of the graphical user interface that are used to configure file renaming, download subfolder generation, backups, and miscellaneous other program preferences. Otherwise everything else should be working. If it’s not working, that’s a bug.
And btw thanks very much for taking the time to report any problems – it’s much appreciated!
I updated my VM copy of F23 and replicated the bug with the thumbnails not being displayed for previously downloaded files when the program is restarted. No need to file a bug - I’m looking into it now.
However I wasn’t able to replicate problems reading files from an external CF card, in my case from a 1D X using a USB 3 reader. That’s an odd one.
.
I pay for internet by the MB (which sure sucks, believe me) so I’m reluctant to download hundreds of MB of updates unless I have to, but in this case it seems I should because you’re reporting some bugs I’ve not seen while developing on Ubuntu 
Hopefully I can replicate them in a VM and not running bare metal.