because it doesn't?
Sorry-- I'm describing the pd-extended 0.42 Debian package, which AFAICT is leveraged by Pd-l2ork's build scripts. That's what I'm using to test my GUI port. I can confirm that clicking the menu (or double-clicking on a Pd file) starts the program from core->GUI. I can easily confirm this because I haven't written the function to do the opposite. But if OSX app bundles actually requires it to go the other way in order to work properly, I suppose I'll have to implement that anyway. -Jonathan
On Monday, November 16, 2015 3:38 PM, IOhannes m zmölnig <zmoelnig@iem.at> wrote:
On 11/16/2015 09:03 PM, Jonathan Wilkes via Pd-list wrote:
In the Pd-extended app bundle for OSX, why does wish start the pd binary,
because that is the only way to make the Pd.app behave as a "proper" OSX App (with a nix menu that displays a proper application name)
while on Debian it is the pd binary which starts wish?
because it doesn't?
if you start Pd via the menu (or the file association), it will start the GUI which will launch the core. this is mainly to open additional files (via file association) in an already running instance of Pd.
if you start Pd from the cmdline (e.g. by running "pd") it will start the core which will launch the GUI - which is most likely the expected way to start Pd and all it's cmdline args. if - on OSX - you start Pd from the cmdline (e.g. by running "Pd.app/Contents/Resources/bin/pd") it will start the core which will launch the GUI.
so the reason why Pd is sometimes launched from the core and sometimes from the GUI is that there are different use-cases.
gfmsadr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list