Use relative directories in xLights configurations instead of fixed paths

[smtpboy]

Is your feature request related to a problem? Please describe. I realize this would require a number of changes in how configs and sequences are saved to disk, but for those of us who store our show directories on shared spaces like Dropbox, NAS, iCloud, etc... the directory paths are usually different from machine to machine. This can cause weirdness and sometimes confuses xLights, esp when moving between Windows and MacOS interchangeably. It would also solve the issue of when you move a sequence between show directories on the same host and the resources are present in the new path, but it continues pointing to old hard paths instead and things sometimes go missing. If path references would instead use a show directory relative variable prefix, this could potentially solve a number of those issues and make things very consistent, including when exporting/importing sequences.

Describe the solution you'd like Instead of using hard paths in config files, allow directory variables and relative file paths for all models, faces, resources, etc.

Describe alternatives you've considered N/A

Additional context Add any other context or screenshots about the feature request here.

[smtpboy]

Any thoughts on this ER? This is particularly annoying with warnings about Faces/etc causing the "nor under show directory" warnings when running "Check Sequence" because xLights doesn't realize that the path is actually correct. If the check sequence was comparing the paths to a relative path versus a hard path, these errors wouldn't throw... because it would know that "DownloadedFaces" actually IS under the show directory, for example.

[computergeek1507]

Are you using relative paths higher than your show folder? Relative paths within the show folder will auto resolve but then will save as the new absolute path.

[smtpboy]

@computergeek1507 Let me see if I can better explain. I keep my show folder in Dropbox and use it across 4-5 different machines, both Windows and Mac. Let's say on one machine the show folder is /Users/joe/Dropbox/xLights - but you have a face that lives in $SHOWDIR/DownloadedFaces in that show folder. However, if you open this on a different machine, where that directory exists with a slightly different path and is something like C:\Dropbox\xLights or /Volumes/External SSD/Dropbox/xLights, when you run Check Sequence, it will throw all kinds of warnings because it thinks those files/directories don't exist under the ShowFolder, when in actuality they do. If the file/directory checking relied on relative directories instead of looking at hard paths, it would realize those subdirectories and files actually exist under the show folder, instead of throwing all those warnings. Make sense?

Quick Addition...I think what i'm trying to poorly convey here is that if paths referring to graphics/images/faces/etc were stored as relative paths inside of the xlights_rgbeffects.xml instead of hard paths, with the assumption that they all live under the show directory, this could negate the errors generated by Check Sequence.

[AzGilrock]

Problem is everyone wanted to be able to store things anywhere on their machine so they aren't always relative to the show folder. I'm sure it could be improved but it's definitely not high on my list. I just use the package sequence and import features to get around the problem.

[smtpboy]

@AzGilrock Its not really a packaging issue and that won't address the problem - the issue is how Check Sequence is interpreting directory structures. Check Sequence/xLights is finding the files and the sequences work fine, but it is throwing warnings that aren't accurate... because it thinks the sub-directories are not in the Show Folder when they really are because the hard paths to the faces/media/etc are confusing it.

With more and more people using Dropbox, iCloud, OneDrive, etc to host their show folders and doing so across multiple machines which will have different paths and directory structures, I'm just trying to offer up a potentially better approach. I'm not a coder, or I would try to help. Perhaps its nothing more than a cosmetic issue, but warnings are warnings.

[AzGilrock]

We don't want check sequence trying to fix filepaths. They need to be fixed before you run it. I forget what will do that but definitely render all and then save should try to resolve all the paths. You cannot expect to run check sequence on file from another show folder path before you've resolved the paths.

[computergeek1507]

when you click Render All xLights should auto update the paths if the files are under the show folder

[smtpboy]

Guys, I understand your points and what not, but what you're saying should happen is not what is actually happening. It is not about xLights not finding the objects or asking Check Sequence to fix file paths, xlights does find the objects properly and the paths are actually legit and real. Things render just fine. Opening the sequence, saving it and re-rendering it do not solve the issue.

The problem is about Check Sequence generating incorrect warnings and not understanding that the show directory really is the show directory, even when it may be a symlink. Maybe the key point here is that I'm talking specifically about a scenario with cloud storage, which is almost always a symlink directory. This is true of Dropbox, iCloud, Google Drive, OneDrive, etc pretty much across the board on MacOS.

Let me give you an explicit example:

My mac's Show directory is /Volumes/External SSD/Dropbox/Xlights 2023/Christmas. There is a symlink that points /Users/joe/Dropbox/Xlights 2023/Christmas/ to this directory as well, because this is how MacOS defines where your Dropbox folder is. It does the same exact thing with iCloud, Google Drive, etc. - those often exist under /Users//Library/CloudStorage//directory.

With that said, if I run Check Sequence, it generates a ton of warnings about Faces, because it thinks "/Users/joe/Dropbox/Xlights 2023/Christmas/DownloadedFaces/" is not under the show directory, BUT IT IS, but Check Sequence doesn't know to follow the symlink. When I defined those faces, probably on my other Mac, xLights set the hard path as pointing to the symlink directory name vs the expanded path.

Maybe this is as simple as Check Sequence doesn't understand symlinks or isn't doing enough range checking of the paths.

Maybe this is a non-issue and something I should just live with. However, I'd be curious if any of you aren't seeing it in your setups simply because you're not storing your show directories on Cloud Storage services.

[AzGilrock]

I don't recall symlinks being mentioned till now. I have no idea how they get handled. I hate using cloud services especially for xLights. It causes everyone problems.

[computergeek1507]

can you do a package sequence or manually zip your files related to sequence and we can lookin it. I put all my show folder in github and use it across, three windows PCs and a Mac M1 without issue.

[smtpboy]

For what it's worth, on a whim I opened and checked this on my Windows machine, and as best I can tell, Windows cleans up the file paths by itself in the xlights_rgbeffects.xml, and as a result it does NOT generate the errors. The net result is that because it fixes all the paths, the problem no longer occurs on MacOS.

Maybe MacOS doesn't do this by itself and Windows does? So maybe MacOS isn't cleaning up the paths like Windows does, but it does rewrite them to the correct show folder on open after I launched xLIghts on windows. So who knows what weirdness is going on here.

It doesn't seem like this is something anyone really seems to want to chase down, so I'm just going to close the case at this point unless you guys really want to explore it more... obviously this will only impact a small percentage of the user community.