No.
Buffer.loadDialog
uses File.openDialog
(which should be changed to Dialog.openPanel
). Unfortunately, this way does not allow the user to specify a starting path. Oh, I’m wrong… Dialog.openPanel
does support a starting path. But Buffer.loadDialog
doesn’t expose that as an option.
In my last GUI project, I’m using FileDialog
directly. I always have to look up some of the arguments (explained well in the help file, so, not really a problem) but it has a number of features not supported by openDialog
.
// fileMode: 1 = single existing file (use 0 for saving)
// acceptMode: 0 = opening; 1 = saving
FileDialog(okFunc, cancelFunc, fileMode: 1, acceptMode: 0, stripResult: false, path)
// For example:
FileDialog({ |path| path.postcs }, fileMode: 1, acceptMode: 0, stripResult: false)
-->
[ "/home/dlm/export-1.wav" ]
// EDIT: But this is probably a little easier
Dialog.openPanel({ |path| path.postcs }, path: Platform.resourceDir);
-->
"/usr/local/share/SuperCollider/README.md"
Or stripResult: true
to get just the path as a string, without the array container (which is for the case of selecting multiple files at once).
The one tricky thing you might run into with this is that Buffer.loadDialog
gives you the buffer object (with bufnum) Right Now but waits until you answer the dialog to fill it. You might have other code that needs to wait until the buffer number is available. I’d do it this way:
var buffer;
{
var cond = Condition.new;
Dialog.openPanel({ |path|
buffer = Buffer.read(s, path[0]);
cond.unhang; // resume after 'hang'
}, path: "/path/to/starting/folder");
cond.hang; // wait for dialog
s.sync;
// now the buffer is ready
}.fork(AppClock);
FWIW I think that many such convenience methods ought to be deprecated and eventually removed. As you found, it has limitations.
p.s. Why I’m at it can someone tell me why you get the “WARNING: Called from Meta_Buffer:loadDialog, method Meta_File:openDialog is deprecated and will be removed”.
That’s another reason a/ why we as a community should be careful about adding convenience methods in the first place and b/ why we should probably prune some of them away.
Issue 3506 explains why openDialog
and saveDialog
were deprecated (which I think was a good move). However, the change in #3507 didn’t catch other places in the class library where the old methods were used.
That is: Having Buffer.loadDialog
adds a maintenance cost to the project, for (I would argue) little-to-no gain. Usually you don’t see the cost, except in a case like this, where the deprecation was incomplete.
I’ll put in a PR to fix it.
hjh