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

[Michael Hutchinson]

On Sat, Jan 29, 2011 at 2:48 AM, kjpou <kjpou at pt.lu> wrote:
> 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.

The thing I have a problem with is that the class is effectively
defined by a nib and the nib's designer code file, yet its other part
is kept completely separate from them. It would be *much* better if it
were grouped under the nib file.

Maybe you could add a context menu command to nib files that would
offer to add a partial class file for any classes defined in the nib
that did not already have non-designer parts. This would be a much
more solid approach IMO, and not very hard to implement.

-- 
Michael Hutchinson
http://mjhutchinson.com