[PD] [openpanel]/[savepanel] directory, [cd]
reduzierer at yahoo.de
Thu May 29 10:04:12 CEST 2008
On Wed, 2008-05-28 at 23:57 -0700, Rich E wrote:
> it does and it has been discussed multiple times on this list:
> sending a command to the [shell] will start a new process
> (shell), run
> the command and quit. like it should be, child processes do
> not modify
> parent processes and siblings.
> Ah. This makes sense.
> i am not sure what you would like to achieve with [pwd] or
> that is: if you could manage with [pwd] and [cd], why can't
> you do so
> with the current absolute/relative path in [openpanel]?
> I was just looking for a quick hack to get my patches working that try
> to open up a specific directory using [openpanel]. But I guess the
> real solution is making [openpanel]/[savepanel] relative to the patch
> it they live in. I don't really know how this would work for an
> [openpanel]/[savepanel] within an abstraction.
i agree with you, that this new feature of [openpanel] and [savepanel]
is kind of bogus the way it is implemented now. in so many cases you
rather would want to set a path relative to the patch instead of
relative to pd start location.
i personally think, that [[open][save]panel]s within abstractions should
behave accordingly: path should be relative to the file location (the
path that is written in the window title, when you open the window).
the same goes for the 'open' message to pd: i can't think of a good
reason for the actual behaviour. relative to the patch would make much
more sense, IMO.
i stop saying this over and over again, as soon as someone comes up with
a really good explanation for the current implementation(sorry for being
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
More information about the Pd-list