If all goes to plan, the next version of Rapid Photo Downloader will have a couple of quality-of-life improvements in the GUI that will be helpful to people new to the program, and also to users that regularly switch the download destinations / sources.
Sometimes users choose a read-only folder as a download destination, whether by accidentally clicking on the wrong folder, or because they didn’t realise it was read-only. In current releases, the program will immediately reject the choice, display an error message dialog, and reset the destination folder to be not set (as if nothing was clicked on). This behaviour has always been somewhat user-hostile. Future releases will prominently show the problem, and not reset the destination folder:
When a download folder no longer exists, future releases will display a similar warning, rather than resetting the destination as it previously did. This is useful when the folder has temporarily disappeared (it happens).
in the above screenshot, the little downwards facing chevron (right beside the cursor) indicates there is a drop-down menu. Here you can choose a previous download destination:
This is a feature I’ve wanted to include for a very long time. For now, the chevron appears only when the mouse hovers over grey bar, instead of being displayed all the time. This is an aesthetic choice. It might be the wrong one, given it reduces the feature apostrophe’s visibility. Time will tell.
Another small change is that when there is not enough space, a warning is prominently displayed:
These features are a long way off being released, unfortunately. it could take another six months, or even a year.
The first reason it will take so long to release these features is that me having Long Covid means I can work on the code only when I feel well enough. Recently I have not been able to work on it.
The second reason is that to make these features work properly — and just as importantly, to improve the overall reliability of the program — requires rewriting a lot of the underlying user interface code. This rewrite is laser-focused on tracking the application’s state. A simplified example of a state is something like “the program is currently scanning from one memory card, is not downloading, another memory card has just been inserted, the timeline needs to be generated, photos and videos are being downloaded to different partitions, and the download button needs to be enabled when the scans are complete”. It’s far more complicated in reality. Writing a response-driven UI is difficult.
Like many GUI applications (probably the vast majority), Rapid Photo Downloader’s code to handle the UI is written ad-hoc. That is, whenever a UI element is selected or clicked on, a specific block of logic is run in response. In such ad-hoc code, the program’s state is not front-and-centre. This works pretty well in most situations, but as Rapid Photo Downloader gets more complex, this ad-hoc approach’s weaknesses are becoming increasingly intolerable. The program’s state needs to be tracked much more systematically. I’m beginning to investigate whether the use of a formal state machine or a hybrid approach is more appropriate. If anyone reading this has expertise in this area, I would be grateful to talk with you about your insights.