On 1/15/19 5:08 PM, Alexandre Torres Porres wrote:
I don't know what the start location is on platforms where you double- click an icon to launch the application. But you can easily figure that out by sending [symbol .( to [openpanel].
Sending a "symbol ." here in the latest macOS and Pd opens the root of HD
which happens to be the directory where Pd is started from when you double click the Pd.app i agree that "/" is not a very useful placeas a starting point.
From there, relative paths should work. I guess, they do so also on macOS and on Windows once you know where your starting point is.
So, a bang opens ~/Documents/Pd, but no relative paths work from there!
could you elaborate on that?
So it seems like a bug for mac, and also, we want the behaviour to be relative to the patch's path, right? At least when sending it "symbol ./"
What I was trying to say in my previous post is that relative paths
are pretty useless when they must be relative to this arbitrary starting point, since the patch has no notion of that path. Most often you want [openpanel] to show some directory relative to the main patch of your project. For me, relative to patch would make much more sense. I don't see any meaningful use case with the current implementation of 'relative to Pd's start location'.
agreed
hmm, when starting Pd from the cmdline, this has a lot of meaning. here at work, i was *seriously* flamed for about 3 months because [openpanel] stopped opening from the path where Pd was started from.
there's a ticket about this: https://github.com/pure-data/pure-data/issues/478
gfmsard IOhannes