> 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