[Mono-osx] Mono 1.1.0 Cocoa# + MWF

Gareth Baker g.j.baker at dl.ac.uk
Tue Nov 22 06:29:50 EST 2005


Firstly "kangaroo" thanks for the information AND thanks for the work on
cocoa#.

Now my "two penneth", I think the problem may be that mono on OSX has
attracted "users" rather than "hackers" (and with the choice of C, C++ or
objC - who can blame them for turning to c#/mono!). I am also beginning to
wonder if MWF should be the cross-platform GUI of choice for mono-OSX
developers. There does seem to be a lot of activity on the GTK front lately
(native gtk libraries; GTK 2.10 projected to have a quartz driver; ...). May
be that will be the way to go? OSX only - cocoa#, cross-platform -
gtk-sharp.

Anyway - as I said, thanks for the information (I actually had not noticed
libgdiplus was not included!).

Gareth Baker



On 11/22/05 6:11 AM, "kangaroo" <grompf at sublimeintervention.com> wrote:

> Cocoa# and libgdiplus were not included in the 1.1.10 release.  If
> you need these features you are urged to stay on 1.1.9.1
> 
> I probably should have communicated this earlier and for that I
> apologize.  This was a strategic decision made for a number of
> reasons, that if you care enough about to actually help with and
> submit patches; feel free to contact me.
> 
> I will talk more about the Cocoa# situation tho.  Some of you may or
> may not know that 0.2 had the entire toolkit automatically
> generated.  Some time ago I did an audit of the classes that were
> generated and was unsatisfied with the result.  I investigated the
> labour involved to fix the countless edge cases to make the generator
> maintainable and decided to go in another direction.
> 
> Cocoa# 0.9 (probably what I will version it; not 100% sure yet) is on
> my harddrive and almost ready to go on SVN.  The runtime has been
> reworked to require no glue whatsoever, but there is also no more
> generator.  All of the classes that will be commited by me will have
> been hand bound under a new set of rules (trust me; it wont be hard
> to bind new methods/classes and submit me patches).  The delay
> getting this into SVN is a timing problem on my side; as with the new
> Cocoa# there will be a rule that no patch will go in adding/modifying/
> removing methods without a corresponding documentation update.  This
> will ensure that we have up to date documentation of all class methods.
> 
> This may come at the expense of some immediate functionality; but if
> you are using Cocoa# or want to see it succeed the 5 minutes it takes
> to bind the class you need should not be a problem; and contributing
> documentation goes to the future of us all.
> 
> On the MWF side; yes; it no longer works in 1.1.10.  This was at my
> behest.  I am the sole contributor and maintainer of the driver and
> have yet to recieve a patch.  I asked the MWF maintainers that if
> they add features to the driver to make them throw
> NotImplementedException's so that they wouldn't get lost.  As a
> result, and some internal time pressures on me, MWF-OSX has bitrotted
> slightly.
> 
> The summation of all this is fairly simple.  If these features are
> incredibly important to you personally/professionally/etc get
> involved.  I welcome anyone who is willing to help.  To be frank
> seeing nothing but complaints with no action taken by anyone on this
> list is daunting at times and I tend to let the mails build up.  This
> is definately not the ideal action on my side, but this isn't my full
> time job.
> 
> -kangaroo
> 
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx



More information about the Mono-osx mailing list