I'm noticing that pd and the pd-gui seem to have different notions about the current directory:
* pd: when started on commandline, current path is the working directory when pd was started * pd-gui: when started before pd, current path for panels is $::env(HOME) aka home directory ... even though *actual* current dir is pd bin folder
The problem I'm noticing is that pd-gui's "current path" is only reflected in [openpanel] & [savepanel] while the *actual* tcl current path is different. On macOS, starting Pd by double-clicking a patch sets the cwd to the parent folder of that patch, so relative start directories to a panel work as expected. Opening Pd and then opening the patch leads to different behavior as the actual current working directory is not the same as that of the patch. In this second example, there is also a disparity between what you see when baking an [openpanel] and what relative paths it might find since the displayed location is *different* from the actual location.
I see 5 possible solutions:
1. EASY: append any relative paths from [openpanel] / [savepanel] to the current panel directories ($::fileopendir / $::filenewdir)
2. EASY (but could lead unexpected behavior): change directory to the $::fileopendir on startup when the GUI is started first and without any specific location (aka opened a patch)
3. EASY (but not user friendly): do *not* set $::fileopendir / $::filenewdir to anything other than the tcl [pwd]
4. HARDER (but more user friendly): [openpanel] / [savepanel] could append relative paths to the current canvas path
5. HARDER (but more generally useful): add the ability to query the canvas path in order to build proper fullpaths to give to [openpanel] / [savepanel]
Maybe the best solution is a mix of 2-3 of the above? In any case, I can implement 1-4 relatively easily. IMHO #4 is the better way to go, although it would mean using [openpanel] within an abstraction using the abstraction's parent directory with relative paths...
This probably also touches about path expectations when using [soundfiler] and [readsf~]...
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Or maybe I'm mainly seeing a disparity because I introduced one with the Documents path... ;) hah
On Dec 1, 2017, at 11:55 AM, Dan Wilcox danomatika@gmail.com wrote:
I'm noticing that pd and the pd-gui seem to have different notions about the current directory:
- pd: when started on commandline, current path is the working directory when pd was started
- pd-gui: when started before pd, current path for panels is $::env(HOME) aka home directory ... even though *actual* current dir is pd bin folder
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Ok, sorry for the noise. I realize I misunderstood a number of things. In looking through things now I see:
* if pd is started first, pd-gui uses the current working dir * if pd-gui is started first, it sends the current working dir
So after startup, both should have the same current working dir. Good.
My confusion was coming from the role of $::fileopendir and $::filenewdir. I see that they are really placeholders for the current dir the user has navigated to when using either the menu panels or [openpanel] / [savepanel]. They previously did not directly reflect the current working dir anyway...
On Dec 1, 2017, at 12:13 PM, Dan Wilcox danomatika@gmail.com wrote:
Or maybe I'm mainly seeing a disparity because I introduced one with the Documents path... ;) hah
On Dec 1, 2017, at 11:55 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
I'm noticing that pd and the pd-gui seem to have different notions about the current directory:
- pd: when started on commandline, current path is the working directory when pd was started
- pd-gui: when started before pd, current path for panels is $::env(HOME) aka home directory ... even though *actual* current dir is pd bin folder
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/