Creating $prefix/bin/foo and Foo.app at the same time
mojca at macports.org
Tue Jul 16 18:07:10 PDT 2013
On Wed, Jul 17, 2013 at 1:32 AM, Ryan Schmidt wrote:
> On Jul 16, 2013, at 18:22, Mojca Miklavec wrote:
>> The bundle created by Jérôme Suhard
>> (http://jerome.suhard.fr/gate/#Info.plist) also contains
>> CFBundleDocumentTypes to register *.mac files with the program. I'm
>> not sure if this is really needed or not, but I'm still curious
>> whether I could add this in some easy way with the app bundle.
> This has been requested once or twice before, but the app portgroup does not currently support this.
> I created the app portgroup mainly for ports using frameworks such as libsdl that can create real Mac applications from source code that was not specifically designed for the Mac.
> My expectation was that software developers who develop Mac apps that integrate with the Mac OS to the extent that they support document types would go to the further effort to ship a working app bundle in their source code.
I just checked the version of Gate.app as bundled by Jérôme. While it
assigns the icon to all *.mac files, it doesn't do anything if I try
to open such a file with the app.
I need to stress that Gate (or Geant4) isn't anywhere near being an
advanced Mac application. But as long as it uses Qt GUI, it has a
potential to work nicely. I don't know of any Mac developers of Gate,
but since they made their repository public recently (as opposed to
releasing every 1,5 years), it became easy to request or submit
patches. To begin with, I will request a patch to remove "-psn_*"
arguments as a step towards avoiding the need for an extra
layer/script that calls the real binary.
I have now found this:
I'm looking at what wxWidgets do
and started wondering how many other arguments should be filtered out.
I also see how to add FileOpen events now:
but this needs some modifications in Geant4 as well.
So yes, what you say makes sense. It will take a bit of effort to
implement enough functionality before advance app PortGroup features
would make sense.
(For me MacPorts is at least a nice playground to help me test new
patches for the software. Useful patches can go upstream. Creating the
app and meeting all the dependencies outside of MacPorts is more
demanding and more difficult to reproduce.)
More information about the macports-dev