Hi,
Would it be possible to use something like the following
[symbol ./( | | [openfolder]
to open the dialog window in the current patch folder?
This syntax works when you save or load files (ie with [textfile]), but doesn't seem to work with [openpanel] and [savepanel].
Cheers, Mario
On Tue, 2019-01-15 at 13:35 +0000, Mario Buoninfante wrote:
Would it be possible to use something like the following
[symbol ./( | | [openfolder]
to open the dialog window in the current patch folder?
This syntax works when you save or load files (ie with [textfile]), but doesn't seem to work with [openpanel] and [savepanel].
The help file says that you can use [symbol <some path>( to open a specific directory. However, when you give a relative path, it is relative to Pd's start location, which is pretty useless.
I am in favor of your suggestions. For this to work, pathes should be relative to the patch, which would make much more sense, imho.
Roman
Em ter, 15 de jan de 2019 às 12:30, Roman Haefeli reduzent@gmail.com escreveu:
On Tue, 2019-01-15 at 13:35 +0000, Mario Buoninfante wrote:
Would it be possible to use something like the following
[symbol ./( | | [openfolder]
to open the dialog window in the current patch folder?
This syntax works when you save or load files (ie with [textfile]), but doesn't seem to work with [openpanel] and [savepanel].
The help file says that you can use [symbol <some path>( to open a specific directory. However, when you give a relative path, it is relative to Pd's start location, which is pretty useless.
is it? cause it seems to me it's just not working at all!
On Tue, 2019-01-15 at 13:28 -0200, Alexandre Torres Porres wrote:
Em ter, 15 de jan de 2019 às 12:30, Roman Haefeli <reduzent@gmail.com
escreveu: On Tue, 2019-01-15 at 13:35 +0000, Mario Buoninfante wrote:
Would it be possible to use something like the following
[symbol ./( | | [openfolder]
to open the dialog window in the current patch folder?
This syntax works when you save or load files (ie with
[textfile]),
but doesn't seem to work with [openpanel] and [savepanel].
The help file says that you can use [symbol <some path>( to open a specific directory. However, when you give a relative path, it is relative to Pd's start location, which is pretty useless.
is it? cause it seems to me it's just not working at all!
I can currently only test on Linux, but yes it works. However, when banging [openpanel] initially, it doesn't open in Pd's start location, but in its "Home" which happens to be ~/Documents/Pd in my version of Pd (0.49.1). When sending [symbol .(, it opens the directory I started Pd from. I can open any directory when specifying it relative to the one shown by [symbol .( . If the given relative path cannot be resolved, it opens . (the start location) instead.
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]. 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.
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'.
Roman
Em ter, 15 de jan de 2019 às 13:56, Roman Haefeli reduzent@gmail.com escreveu:
On Tue, 2019-01-15 at 13:28 -0200, Alexandre Torres Porres wrote:
Em ter, 15 de jan de 2019 às 12:30, Roman Haefeli <reduzent@gmail.com
escreveu: On Tue, 2019-01-15 at 13:35 +0000, Mario Buoninfante wrote:
Would it be possible to use something like the following
[symbol ./( | | [openfolder]
to open the dialog window in the current patch folder?
This syntax works when you save or load files (ie with
[textfile]),
but doesn't seem to work with [openpanel] and [savepanel].
The help file says that you can use [symbol <some path>( to open a specific directory. However, when you give a relative path, it is relative to Pd's start location, which is pretty useless.
is it? cause it seems to me it's just not working at all!
I can currently only test on Linux, but yes it works. However, when banging [openpanel] initially, it doesn't open in Pd's start location, but in its "Home" which happens to be ~/Documents/Pd in my version of Pd (0.49.1).
that's actually 0.49-0, right? 49.1 is only for mac
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
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!
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
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
Em ter, 15 de jan de 2019 às 17:31, IOhannes m zmölnig zmoelnig@iem.at escreveu:
So, a bang opens ~/Documents/Pd, but no relative paths work from there!
could you elaborate on that?
Say I have a relative "externals" folder. Sending "symbol ./externals" (or just "externals", ".externals" or "/externals") doesn't work.
So what I mean is that this feature is not happening for macOS => bug detected
On 1/15/19 10:29 PM, Alexandre Torres Porres wrote:
Em ter, 15 de jan de 2019 às 17:31, IOhannes m zmölnig zmoelnig@iem.at escreveu:
So, a bang opens ~/Documents/Pd, but no relative paths work from there!
could you elaborate on that?
Say I have a relative "externals" folder.
relative to what?
[symbol .( opens up "/". now "." is already a relative directory, and it refers to "itself". since "." opens up "/", the base for relative directories is "/".
Sending "symbol ./externals" (or just "externals", ".externals" or "/externals") doesn't work.
i guess, all of them work, they are are just not what you expect.
- "./externals" should expand to the *full* path "/"+"./externals",
which is "/./externals" (or just "/externals")
- "externals" should expand tothe *full* path "/"+"externals" which is
"/externals" as well.
- ".externals" should expand to "/.externals" (a hidden directory!)
- "/externals" is an absolute path, and should therefore resolve to
"/externals" (again).
so if there is an "/externals" directory (or a "/.externals") directory on your harddisk, that folder will open up.
you could try to use "./Applications", "Applications", ".vol" or "/Applications" to see whether it works.
So what I mean is that this feature is not happening for macOS => bug detected
which feature is not happening? which bug did you detect?
as roman said, the relative notation is relative to the startup location of Pd. on macOS, if you double click the Pd.app (or open it via "open") this is the root directory of your system, which we all agree is pretty useless. on other systems there are much more useful startup directories. but that doesn't mean that the "feature" is "not happening".
gfamrds IOhannes
Em ter, 15 de jan de 2019 às 19:49, IOhannes m zmölnig zmoelnig@iem.at escreveu:
As roman said, the relative notation is relative to the startup location of Pd. On macOS, if you double click the Pd.app (or open it via "open") this is the root directory of your system, which we all agree is pretty useless. on other systems there are much more useful startup directories. but that doesn't mean that the "feature" is "not happening".
Yeah, I realized that later on when Roman did better explain himself. I guess then that at least this startup location, being useless, can be thought of as sort of a bug.
Anyway, one solution would be to have a new [path]/[canvas] object, discussed here before, that can give us the path where the patch is opened.
This wouldn't require "deep" changes to [openpanel]
Em ter, 15 de jan de 2019 às 21:22, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em ter, 15 de jan de 2019 às 19:49, IOhannes m zmölnig zmoelnig@iem.at escreveu:
As roman said, the relative notation is relative to the startup location of Pd. On macOS, if you double click the Pd.app (or open it via "open") this is the root directory of your system, which we all agree is pretty useless. on other systems there are much more useful startup directories. but that doesn't mean that the "feature" is "not happening".
Yeah, I realized that later on when Roman did better explain himself. I guess then that at least this startup location, being useless, can be thought of as sort of a bug.
On Tue, 2019-01-15 at 14:08 -0200, Alexandre Torres Porres wrote:
Em ter, 15 de jan de 2019 às 13:56, Roman Haefeli <reduzent@gmail.com
escreveu:
I can currently only test on Linux, but yes it works. However, when banging [openpanel] initially, it doesn't open in Pd's start location, but in its "Home" which happens to be ~/Documents/Pd in my version of Pd (0.49.1).
that's actually 0.49-0, right? 49.1 is only for mac
0.49.1 is what Pd shows. I compiled it myself, so maybe I'm using a version where the most recent changes affect only macOS.
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
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!
I try to make myself more clear: [bang ( opens what I called Pd's Home. In order to use relative paths you send it [symbol .( and this
path is what I called Pd's start location. Relative paths work only
relative to what [symbol .( shows, NOT to what [bang( shows.
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 ./"
It's not a bug, unless you say, that paths are not even working relative to what [symbol .( shows. You haven't said that yet. You only said, that it is not working relative to what [bang ( shows.
Roman
Em ter, 15 de jan de 2019 às 17:32, Roman Haefeli reduzent@gmail.com escreveu:
0.49.1 is what Pd shows. I compiled it myself, so maybe I'm using a version where the most recent changes affect only macOS.
If you compiled yourself, then it shows 0.49.1 alright :)
It's not a bug, unless you say, that paths are not even working
relative to what [symbol .( shows. You haven't said that yet. You only said, that it is not working relative to what [bang ( shows.
Oh, well, it does work yeah, but since what opens is the root of the HD, what we're dealing with in a way is actually a full path, not quite "relative". But yeah, it's relative to the root...
Em ter, 15 de jan de 2019 às 17:32, Roman Haefeli reduzent@gmail.com escreveu:
I try to make myself more clear: [bang ( opens what I called
Pd's Home. In order to use relative paths you send it [symbol .( and this path is what I called Pd's start location. Relative paths work only relative to what [symbol .( shows, NOT to what [bang( shows.
But shouldn't both "bang" and "." provide the same then?
On 1/15/19 10:35 PM, Alexandre Torres Porres wrote:
Em ter, 15 de jan de 2019 às 17:32, Roman Haefeli reduzent@gmail.com escreveu:
I try to make myself more clear: [bang ( opens what I called
Pd's Home. In order to use relative paths you send it [symbol .( and this path is what I called Pd's start location. Relative paths work only relative to what [symbol .( shows, NOT to what [bang( shows.But shouldn't both "bang" and "." provide the same then?
why?
fgmards IOhannes
Em ter, 15 de jan de 2019 às 19:42, IOhannes m zmölnig zmoelnig@iem.at escreveu:
But shouldn't both "bang" and "." provide the same then?
why?
Well, why do we have both then? I don't get it.
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Mario Buoninfante -
Roman Haefeli