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

[kjpou]

Michael

For my understanding.

So instead of creating the MyCustomView.cs directly in project structure 
itself that is then overridden we will create an MyCustomView.cs file 
within the NIB file structure?  So to actually see the MyCustomView.cs 
file you would have the following:

 >MainWindow.xib
-->MainWindow.cs
-->MainWindow.xib.designer.cs
-->MainWindowController.cs
-->MyCustomView.cs

Like that?

Kenneth


On 1/31/11 8:05 PM, Michael Hutchinson wrote:
> 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.
>