- Edited
When working with Orion Apps that are being called "Profiles" one will notice that they are saved in a format similar to the following:
$HOME/Applications/Orion/Orion\ Profiles/B6958EF9-5006-46C1-B190-389B4D696ABD/Orion\ -\ NAME_OF_PROFILE.app
If you parse this out visually / mentally you note that the first levels make sense in terms of human cognition:
/Applications/
Orion/
Orion Profiles/
B6958EF9-5006-46C1-B190-389B4D696ABD/
(non-human readable UUID)Orion - NAME_OF_PROFILE.app
(aka, human readable / parsable name for app / profile)
But then things slide sideways with having what appears to be a UUID present for a profile identifier instead of a human readable app / profile name. I have, far too many times over the years, found that it is better to put human identifiable attributes first for easy navigation and identification. This is sorely needed when problems arise and one becomes rapidly frustrated if there are many such things to navigate vs having the correct path readily available in a mentally easily parsable fashion since 99/100 when one is looking for such a path, something has already gone wrong. This simply introduces more mental load and frustration that could be resolved early in the game of this feature/functionality.
I think any methodical consideration would yield a similar thought process and thus I consider this likely a simple overside / bug in the implementation vs a feature request.
The expectation would be to have the order reversed for the UUID vs app/profile name, eg, it should be ordered thus (if the UUID is even necessary as a profile identifier, which I suspect it is):
$HOME/Applications/Orion/Orion\ Profiles/Orion\ -\ NAME_OF_PROFILE.app/B6958EF9-5006-46C1-B190-389B4D696ABD/
0.99.126.4.1-beta
Sonoma (14)