GrandOrgue / GoOdf

A tool for creating/editing organ definition files for GrandOrgue
GNU General Public License v3.0
11 stars 1 forks source link

relative vs full path for pipes and images. #9

Closed davidgritter closed 1 year ago

davidgritter commented 1 year ago

I've been playing with your new release, and it has loaded a variety of .organ files quite well. However when playing with a loaded file, I notice that the pipe and image files in loaded .organ files remain as realative references, for example ../OrganInstallationPackages/xxxx/pipes/.... This relative reference is needed to make the .organ file portable to another computer. However when choosing new pipes, I always get (and save in the .organ file) a complete path name, for example /home/dave/GrandOrgue/OrganInstallationPackages/xxxx/pipes/....

The loading of pipes with the complete path is also seen in earlier releases, even if "Location of the .organ file:" is set properly relative to the pipes.

larspalo commented 1 year ago

@davidgritter Could you please come up with a step by step procedure how to reproduce the issue in the simplest possible way?

Internally, GOODF will keep track of the absolute path as well as the relative. When the .organ file is written the relative path should always be used, except if the organ path is not set. I must be able to reproduce the issue to pinpoint what exactly goes wrong.

davidgritter commented 1 year ago

I have attached a libreoffice document with screen captures to show how I tested this. I am running on Mageia8 linux (very similar to fedora) . In initial testing I found this problem by loading an existing .organ file, checking that the pipe and image references were relative, then loading new pipe and images over the existing references; but as you see in the document I can reproduce with a very simple newly defined .organ file as well. absolutereferences.odt

larspalo commented 1 year ago

@davidgritter Ok, I can see the where the problem occurs now. It's caused by the fact that the pipes or images doesn't live in a child directory to the .organ file (organ root). I've always assumed that the organ root would be the parent of all files and the way I implemented the relative paths when writing the organ file was just to simply remove the organ root from the pipe/image path strings.

I'll see if I can provide a better way to make the paths relative when writing the .organ file. I know that it's very easy to do when one converts the string paths to wxFileName but for now the very simple workaround is to always put the .organ file (organ root) as a parent directory of all other things in the organ file.

By the way, with my commits done today, I've tried to fix a few serious bugs in the .organ file reading - especially related to manuals.

davidgritter commented 1 year ago

I confirm that in your scenario it works, and if that is the only solution, a simple change to the documentation can be made. I found this because I was working with Hauptwerk organ definitions which typically reside in a directory structure as shown in my post above. I used OdfEdit to create a .organ file from the hauptwerk xml, and then GOODF to correct the deficiencies in that conversion

larspalo commented 1 year ago

@davidgritter I've changed the returned paths so that they should truly be relative to the base organ path no matter where they are. So far, it seems to be working as it should - but please stress test it and report back!

davidgritter commented 1 year ago

It works in all the scenarios i could envision.