[PD-dev] question about current directory

[Dan Wilcox]

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/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20171201/26f4d446/attachment-0001.html>