[MPlayer-dev-eng] [PATCH] Mac OS X Finder support

[Chris Roccati]

The patch now is disabled by default, because currently there's no 
appwrapper nor resource fork built in the standard Makefile: anyone 
willing to create the appwrapper or the '*.r' file (and compile it) is 
certainly willing to add an --enable-macosx-finder-support to his 
./configure.

On 7 Nov 2004, at 11:06, Reimar Döffinger wrote:

>> That's the carbon Boolean. One could decide to use MPlayer's boolean 
>> if
>> there's one.
> MPlayer's boolean is called int ;-). As I said, do whatever you want, I
> just wanted to give you the choice.

That was done to better match the carbon style, but the code does not 
use any carbon Boolean anyway.
Switched to int.

>> The "real" argv[0] is going to be something like
>> /Applications/MPlayer.app/Contents/MacOS/mplayer which is not what the
>> user expects. The right thing to do is something along:
> Does the user see it? I think he shouldn't. The sense of this parameter

The "normal user" does not see anything inside the appwrapper, unless 
he chooses to do so.

> is usually to enable the application to find out how it was called 
> (e.g.
> when compiled with X + GUI support, MPlayer uses it to find out whether
> it was called as mplayer or gmplayer). As I think it is possible to
> compile MPlayer under OSX with GUI I fear it might make it crash...

No, MPlayer can't be compiled with a GUI under OSX, unless you settle 
for building an X11 application, and have GTK installed (which is *NOT* 
the default under MacOS X). By the way I'm interested in how the gui 
works... So, one day or another, I can port the MPlayer GUI to 
carbon...

>> {
>> ProcessSerialNumber mypsn;
>> CFStringRef name;
>> char *procname;
>> int len;
>>
>> 	GetCurrentProcess(&mypsn);
>> 	CopyProcessName(&mypsn,&name);
>> 	len=CFStringGetLength(name)+1;
>> 	argv[0]=malloc(len);
>> 	CFStringGetCString(name,argv[0],len,kCFStringEncodingISOLatin1);
>> 	argv[0][len-1]=0;
>> }
>>
>> I'm not sure if this can be called "simple".
> No, that's overkill.

Yeah, carbon is very verbose. COBOL verbose, one may say... :)

In MacOS X, an application has atleast three names: the first, the name 
of the binary image, which is provided as argv[0]:
<path>/ApplicationName.app/Content/MacOS/ApplicationName
then the name in the Info.plist:
this may be anything and has nothing to do with the actual filename. 
It's how the application developer decided to call the application, 
this is the name that appears as the "Application menu".
and last the name of the appwrapper directory:
the user may change this at will (well, except for the extension ".app" 
which the user cannot see), this is the name that appers on the 
finder's dock (and ofcourse the ApplicationName.app part in argv[0]).

The "official" name is the one in the Info.plist, obtained by the 
arcane ritual above...

I think that simply passing the constant string "mplayer" as argv[0] 
makes sense and, as soon as this becomes a problem, can be easily 
changed -- I've tagged it with a FIXME, just in case.

>>>> +
>>>> snprintf(myPsnStr,5+10+1+10+1,"-
>>>> psn_%u_%u",myPsn.highLongOfPSN,myPsn.lowLongOfPSN);
>>> call me paranoid, but I'd actually prefer something like
>>> snprintf(myPsnStr, 5+10+1+10, ...);
>>> myPsnStr[5+10+1+10] = 0;
>> There should be actually no chance for an unsigned long to be more 
>> than
>> 10 chars: '4294967296'...
> As I said, I'm probably paranoid. But actually from the consideration 
> of how
> easily it can be broken by future changes I think it is the better
> solution.

Ok.

>> Should I send a fourth version of the patch?
> I would prefer that, it always looks stupid when the CVS log message
> says "modified patch from ...".
> And I forgot to say before: if you can, please set the
> attachment type to text/plain instead of application/octet-stream, 
> makes
> it easier for me to read anid quote.

I know, but Mail.app does not want to. Let me try this...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: macosx_finder.patch
Type: application/text
Size: 6128 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041107/6f927829/attachment.bin>