[Mono-osx] [MonoMac] MM Add-in templates

[kjpou]

Michael

See below the responses.

On 1/28/11 8:03 PM, Michael Hutchinson wrote:
> I see, so you are defining the class in the nib file, not just using
> it. There are two problems with this:
> * you cannot use your custom view in more than one nib file, since the
> register will be generated in both vases.
> * the C# namespace of the nib's designer class and the the custom view
> will have to match.
> * the class is partial across two locations with no intuitive relationship.
Yes that is correct.  Also for my short samples it was a lot easier to 
do it that way.

> The "correct" solution to this is nonpartial class with register
> attribute, but in order to work completely smoothly it would
> necessitate two nontrivial features:
> * have MD synch classes defined in C# code into the nib files.
This would be more Apple'ish for people coming over to MM from Obj-c.  I 
personally do not see a problem with the way it is implemented now.  
Actually I kind of like it.  It is not as automated as XCode but I 
personally feel more in control.  The only thing I see is the namespace 
problem.  I have not done a large project yet with MM so am limited here.

> * have the MD code generator use the project type database to resolve
> obj-c types to types registered in C# in the project and libraries,
> not just MonoMac.dll (I have some proof of concept code for this if
> anyone else want to take it on).
>
That could be as well.

The problem I see with it is that once you start adding outlets and 
actions on a custom NSView from IB they automatically get registered in 
the designer.  For example a custom NSView called MyBackView  I did not 
define the MyBackView as a subclass of NSView in the Nib file just 
changed the type to be MyBackView.  The following is what is generated 
in the designer class.

     // Should subclass MonoMac.Foundation.NSObject
     [MonoMac.Foundation.Register("MyBackView")]
     public partial class MyBackView {

         private global::MonoMac.AppKit.NSButton __mt_myButton;

         private global::MonoMac.AppKit.NSTextField __mt_myLabel;

         #pragma warning disable 0169
         [MonoMac.Foundation.Export("buttonAction:")]
         partial void buttonAction (MonoMac.AppKit.NSButton sender);

         [MonoMac.Foundation.Export("myButtonAction:")]
         partial void myButtonAction (MonoMac.AppKit.NSButton sender);

         [MonoMac.Foundation.Connect("myButton")]
         private global::MonoMac.AppKit.NSButton myButton {
             get {
                 this.__mt_myButton = 
((global::MonoMac.AppKit.NSButton)(this.GetNativeField("myButton")));
                 return this.__mt_myButton;
             }
             set {
                 this.__mt_myButton = value;
                 this.SetNativeField("myButton", value);
             }
         }

         [MonoMac.Foundation.Connect("myLabel")]
         private global::MonoMac.AppKit.NSTextField myLabel {
             get {
                 this.__mt_myLabel = 
((global::MonoMac.AppKit.NSTextField)(this.GetNativeField("myLabel")));
                 return this.__mt_myLabel;
             }
             set {
                 this.__mt_myLabel = value;
                 this.SetNativeField("myLabel", value);
             }
         }
     }

When you say non trivial in my opinion it is going to take a rethink of 
the whole process.  I do not know how it is all glued together so am not 
able to see the whole picture.

When we start going outside of IB we are going to have to start doing 
all of this in code by hand.

An option could be have two different templates.  One for use cases such 
as this and another for when you want to create a non partial class to 
be used programatically.  Would that be confusing for developers?  Maybe 
maybe not.

Kenneth