I’m still trying out the software and learning how it works, so it’s possible I’ve missed something. I see it is easy to add a scanned folder as an event and then decide to move it into the library for Aspect to manage. This is great and helps me migrate my old folder structure into Aspect’s library to take advantage of the easy organization and event creation. However, I couldn’t find an easy way to do the same with individual photos which are in the scanned folders and not part of an event.
I tried simply dragging them into the Aspect library folder to see what would happen, and I got a message that there were photos in a folder that wasn’t supposed to have photos. This is smart! But then it automatically moves them back, not where they came from exactly, but to my main Pictures folder (which is the parent scanned folder). Anyway, this is ok because it was just a test. But then I saw another option to “Move to shoe box” instead, and here’s where I didn’t understand what happened (perhaps there are a few bugs).
First of all, I have no idea what the shoe box is and I couldn’t find any way to look at the shoe box in the application. But I noticed that in the Aspect library folder it created a new folder with the same name as the folder from which my individual photos came. I tested moving a bunch of individual pictures from a folder called “Desktop Backgrounds” which lives under Pictures, my main scanned folder. A folder “Desktop Backgrounds” was recreated in the Aspect folder when I clicked “Move to shoe box” and it contained the pictures. Not only that, it also created a bunch of empty event date folders with dates which matched those photos, but with nothing inside since they lived in the new “Desktop Backgrounds” folder instead.
Since it was just a test I moved/deleted the photos from the folder, and Aspect asked me if I wanted to remove them from the catalog. I did so. The empty date folders were then deleted along with the now empty “Desktop Backgrounds” folder, but then funnily enough it then created a new date folder 2025 and an event folder inside called “2025-11-10 Desktop Backgrounds”, also empty. An empty event Desktop Backgrounds was also added inside Aspect. So it appears there are a few bugs and unclear workflow with the shoe box, whatever that is…
Mac OS Sequoia, 15.7.1. Aspect version 1.0.0-rc.38 free
This is a good point – as far as I can see, this currently requires to first move the images into an event and then back into the photo stream. I think it probably makes most sense to just add a new menu entry Image → Move Into Library Folder that only shows up for files that are in a scanned folder or in a referenced event. I’ll see if I can add that for the next update.
The term “shoe box” is a relict from an early version where the photo stream was still called like that, I’ve fixed this for the next release. I was also able to reproduce the issue with the extra folders. The root of the issue appears to be that the files are reported as deleted when in reality they have just been moved. I’ll have to do some more testing to see whether this is possibly an operating system dependent problem and why this isn’t caught during our automated testing, which tests pretty much the exact same scenario.
Thanks so much for the quick update which includes the new feature Move to Library Folder. Just noticing a couple bugs and suggestions for improvements:
When I opened Aspect for the first time after updating, it informed me about several duplicate event folders within other folders and also some files removed from file system, asking if I want to remove them from the catalog. I hadn’t done anything that I could remember, so it seemed out of place – unless it was something that I did last time I had Aspect open and it was just cleaning up.
Then I tested out the new Move to Library Folder option. I took all the photos in January 2019 which are scanned from one of my folders called “01. January”, and tried the feature. It moved them into 2019 in the Aspect library, but put them initially in a folder called 01. January. I was hoping they would go into Aspect’s own Individual Photos folder so that I could take advantage of that automatic naming. I tried closing and reopening Aspect to see if something more would happen, and I saw that it had converted this folder 01. January into an event, naming it that way in the Aspect library folder and also showing it in Aspect as an event. This is not what I expected. As mentioned, I was hoping they would go into Aspect’s individual photos folder and would still appear as individual photos in the Photo Stream.
Also noting that the same duplicate event notification popped up this time as well when I opened Aspect the second time. It is confusing because I am not sure where these events come from. After dismissing the dialogs, there were several empty events within Aspect which I had not created or imported.
So in general the behavior where the sub folder of the moved files gets retained when moving them between different places is working as intended, with the idea that it would be worse to accidentally lose existing folder organization when moving files around. However, the issue of explicitly wanting to get rid of the existing folder structure came up a few times in the past and there is also an internal ticket for this (#1535). I’ll open this up for discussion for the next release.
I’m not sure about the detected duplicate events and removed files - did they continue to come up on later starts of the application? Under normal circumstances, the library catalog should always be back in sync with the file system after all of such changes have been handled (regardless of the choice, “keep” vs. “remove” or “merge back”), and consequently, no further dialogs should come up for the same change afterwards.
However, there are two main possibilities how this could happen: If the application crashes or gets forcefully terminated while the change notification dialogs are still on the screen, or shortly afterwards, the library catalog will not have been stored, yet, so that more or less the same differences between the catalog and the file system would get detected again. The other possibility would be that there are certain files or folders that cannot be moved, either due to file system permissions or because files are open in another applications. In that case it could happen that certain operations, such as merging back a duplicate event fail and leave back the same discrepancy that generated the original change notification.
In case you do still get some of the same notifications, can you possibly send me a log file of a run where you just open the application, dismiss the dialogs and then close it again?
I can understand preserving subfolder structure, but here the parent folder was being recreated whenever I tried to move individual photos from a scanned folder to the Library. The photos were contained in a folder called 1. January, and in the Library under 2019, a folder was created called 1. January with those individual photos. I don’t know if that is intended?
My original scanned folder structure is as follows: 2019>01. January> folders for events & individual loose photos. I can easily move the events into the library, but the individual photos I would like to be moved into Aspect’s own Individual Photos folders. Basically, I am using Aspect to reorganize my files with consistent naming and therefore would like to also clean up the individual photos into folders of their own.
This is generally as intended, but definitely debatable whether that is always the right choice. The idea is that it allows you to drop whole folders into the library folder in order to create events from those. But in this specific case, where the folder comes from a scanned folder and contains individual photos, the expectation might indeed usually rather be to keep them as individual photos.
The detection whether such a folder originates from a scanned folder would require some kind of heuristic, because there is a number of mixed scenarios, such as moving only part of a folder, adding new/modified files to it after the move, or copying files instead of moving. All of these make it less clear what the intention might have been.
Alternatively, we could always make this a user-choice and show a dialog, which would also make it more clear what happens, but of course with the disadvantage of slowing down the workflow. A similar issue arises for a potential decision to either keep the sub folder hierarchy of the files, or to fully or partially flatten it.
Definitely needs some more thought in order to avoid making this unnecessarily complex.