[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Info about App Bundles on Mac
From: |
Jeremy Lavergne |
Subject: |
Info about App Bundles on Mac |
Date: |
Sun, 11 Dec 2011 13:36:45 -0500 |
Attached are some emails from various discussions about application bundles.
These may be relevant, especially the ones from ryandesign and jeremyhu, as
they discuss what is needed to properly handle calls to the application for
opening files.
Much like the -psn flag I pointed out previously, several things are passed to
the application so it can hook in and listen for these sorts of requests
(quitting, opening files, is it done launching, etc).
--- Begin Message ---
Subject: |
Re: Packages ignoring applications_dir |
Date: |
Thu, 08 Sep 2011 23:35:38 -0500 |
On Sep 8, 2011, at 21:56, Scott Webster wrote:
> On Thu, Sep 8, 2011 at 7:06 PM, Bryan Blackburn wrote:
>> On Thu, Sep 08, 2011 at 06:52:22PM -0700, Scott Webster said:
>>> It forces a build from source if you use a non-standard prefix? Wouldn't it
>>> be straightforward to just replicate the same files into an alternate
>>> location? The situation here seems slightly more complex since we're
>>> outside the $prefix/ tree...
>>
>> Yup, if your prefix is not /opt/local, port always builds from source.
>> Libraries and executables both have hardcoded paths in them (you can use
>> 'otool -L /some/lib/or/executable' to see) so building to one location then
>> moving will definitely break things.
>>
>> There are also some ports with things like ${prefix}/etc and other paths
>> compiled into binaries, config files with paths, and so on. All of that
>> means relocating would be a mess at best...
>>
>
> Thanks for the explanation! I guess now to complete my education I
> should go look up how Mac OS X deals with moving application bundles
> around...
Application bundles are painstakingly crafted by their developers so that
relocation is possible. They are a completely different animal from the kind of
command-line software most MacPorts ports provide.
_______________________________________________
macports-users mailing list
address@hidden
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
--- End Message ---
--- Begin Message ---
Subject: |
Re: advice on application bundles running unix binaries |
Date: |
Fri, 19 Aug 2011 22:11:57 -0700 |
You need to register with the dock. The easiest way to do this is by using a
runloop. You can have a stub NSApplication call the runloop on the main thread
and have your application "running" on other threads. I don't have much time
right now, but take a look at how we modified the X server to run on a second
thread (look at dix/main.c and hw/xquartz/mach_startup).
--Jeremy
On Aug 19, 2011, at 1:48 PM, Jeremy Lavergne wrote:
> I've made a PSPP application bundle, first using a wrapper script to
> launch the binary and then using the new app PortGroup.
>
> To utilize launching via symlink it can produce, I had the PSPP devs dump
> the -psn_* argv flag that gets passed in by the GUI. This of course,
> leaves the Dock bouncing until the timeout and likely won't accept any
> drag/drop of files and so on.
>
> Do you have any advice or suggested reading material on a proper way to
> handle -psn for non-native apps?
>
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
--- End Message ---
--- Begin Message ---
Subject: |
Re: advice on application bundles running unix binaries |
Date: |
Fri, 19 Aug 2011 22:11:57 -0700 |
You need to register with the dock. The easiest way to do this is by using a
runloop. You can have a stub NSApplication call the runloop on the main thread
and have your application "running" on other threads. I don't have much time
right now, but take a look at how we modified the X server to run on a second
thread (look at dix/main.c and hw/xquartz/mach_startup).
--Jeremy
On Aug 19, 2011, at 1:48 PM, Jeremy Lavergne wrote:
> I've made a PSPP application bundle, first using a wrapper script to
> launch the binary and then using the new app PortGroup.
>
> To utilize launching via symlink it can produce, I had the PSPP devs dump
> the -psn_* argv flag that gets passed in by the GUI. This of course,
> leaves the Dock bouncing until the timeout and likely won't accept any
> drag/drop of files and so on.
>
> Do you have any advice or suggested reading material on a proper way to
> handle -psn for non-native apps?
>
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
--- End Message ---
--- Begin Message ---
Subject: |
Re: handling -psn_X_Y |
Date: |
Thu, 18 Aug 2011 05:07:58 -0500 |
On Aug 17, 2011, at 14:56, Jeremy Lavergne wrote:
> You had said you were doing some dark magic on a port to handle the -psn
> flags. Do you recall what needs to be accomplished to handle the flag,
> other than ignoring it?
>
> I've not done GUI development before so it's new to me :-) and the PSPP
> dev is receptive to doing things like ignoring the flag for now so we can
> just plop the binary into the app bundle until we know how to do it
> properly.
Well I said two things which weren't related:
1) Programs not designed to be launched from an application bundle won't know
what to do with the -psn_* flag Mac OS X passes it. You can write a wrapper
script to bypass this problem: Mac OS X will pass the -psn_* flag to the
wrapper script, which will ignore it completely, and instead call the desired
executable with no arguments (or just the arguments you want).
2) Application bundles are designed to launch programs that show an icon in the
Dock that stays there until the program terminates. Programs that aren't proper
Mac OS X GUI applications don't do this on their own. Putting them in an app
bundle makes them do this, but the icon doesn't behave properly: it never stops
bouncing, clicking on it while the program's running does nothing, the OS
things the app is frozen and gives you the Force Quit option if you click and
hold on it, etc. This is what I tried at great length to combat in the
mystonline-wine port, by having my wrapper script stay open and try to
intercept these OS events while launching the game separately, and waiting
around until the game exits. This didn't work particularly well. Your PSPP app
demonstrates what you get if your wrapper launches the real program
asynchronously with "&": the icon bounces briefly in the Dock, then disappears,
while the app launches. If you click it again, another copy of the app
launches! Also not behavior a user would expect. Dragging document icons onto
the application icon also wouldn't work; this wasn't an issue for me with
mystonline-wine because it is a game and there aren't any document files.
Bottom line is apps that aren't designed to be Mac apps don't behave well if
coerced into an application bundle. It might be possible to do better by
writing an app wrapper of some kind using AppleScript or Cocoa but that's a bit
involved. Possibly some day if I or someone writes such a wrapper that works
well, we can make a port for it, then the app portgroup can expose an option to
allow a port to use it.
--- End Message ---
smime.p7s
Description: S/MIME cryptographic signature
- Info about App Bundles on Mac,
Jeremy Lavergne <=