[Mono-osx] MacOS bindings and MonoDevelop.

[Jesse Jones]

On May 19, 2009, at 11:39 PM, Laurent Etiemble wrote:

> Hello,
>
> My answers below:
>
> Regards, Laurent Etiemble.
>
> 2009/5/19 Miguel de Icaza <miguel at novell.com>:
>>>>
>> Hello,
>>
>>> agreed on Monobjc as the best choice for the base, here.
>>
>> I am still concerned about a few things about MonoObjc:
>>        * The copyrighted material from Apple included in the source.
>
> I will remove the copyright content from the source, and publish it  
> outside.
>
>>        * It seems auto-generated, but the auto-generator is not  
>> public.
>
> The basis of the wrappers has been auto-generated with various
> scripts, but at the end, the result was mixed. So I have started
> cleaning the API by hand, to make sure that the API was usable with
> .NET.
>
> I do consider automatic generation only for getting a starting point,
> and fixing by hand the remaining issues. That is why there is no
> generator bundled with Monobjc.

Depending on what you are doing you may be able to automate this. For  
example, the generator in mcocoa uses an xml file which encodes a  
bunch of special cases. It looks something like this (in trunk):

<Generate>
    <Framework name = "foundation" path = "/System/Library/Frameworks/ 
Foundation.framework/Versions/Current/Headers">
       <!-- Lists the methods for which we do not want to generate
       code. This can be because the generator can't handle the method
       (e.g.mcocoa can't handle variadic methods) or because we
       provide a hand-written version. The reason attribute is included
       in the generated type as a comment. -->
       <Blacklist>
          <Method interface = "NSFileManager" method =  
"defaultManager" reason = "because we assert that the current thread  
is the main thread"/>
          <Method interface = "NSString" method = "getCharacters:"  
reason = "because there is a hand-written version"/>
          ...
       </Blacklist>

       <!-- Types which appear here are decorated with a
       ThreadModelAttribute to make it clear what their threading
       semantics are (and there is an upcoming gendarme rule to
       help verify that user code is using these types correctly.) -->
       <Threading>
       <Type name = "NSArray" model = "concurrent"/>
          <Type name = "NSNotification" model = "concurrent"/>
          <Type name = "NSAssertionHandler" model = "concurrent"/>
          ...

          <!-- This is thread safe in Leopard if you explicitly create
          an instance (and we now have an assert to ensure that it's
          used this way). See http://www.omnigroup.com/mailman/archive/macosx-dev/2008-June/061392.html 
. -->
          <Type name = "NSFileManager" model = "single"/>

          <!-- These are explicitly mentioned as thread unsafe. -->
          <Type name = "NSAppleScript" model = "main"/>
          <Type name = "NSMutableAttributedString" model = "main"/>
          ...
       </Threading>
    </Framework>

    ...

    <!-- A lot of Cocoa methods are typed to return an id which is
    really annoying. To make these methods more pleasant to deal
    with you can add their names here and the generator will type
    them with either the specified type or the interface type. -->
    <TypeResults>
       <TypeResult name = "alphanumericCharacterSet" type =  
"NSCharacterSet"/>
       <TypeResult name = "array" type = "NSArray"/>
       <TypeResult name = "arrayWithCapacity:"/>
       <TypeResult name = "arrayWithObject:"/>
       ...
    </TypeResults>
</Generate>

   -- Jesse