How about primitives, drawing images, loading images (e.g.. png's from a
embedded resource).
Regards,
Ben Martin
TruStorm Software
Website: http://www.trustorm.com.au
Mobile: 0407 256 072
----- Original Message -----
From: "Laurent Etiemble" <laurent.etiem...@monobjc.net>
To: <users@lists.monobjc.net>
Sent: Friday, April 24, 2009 11:59 PM
Subject: Re: [us...@lists.monobjc.net] Re: Monobjc and System.Drawing
Hello,
What kind of samples are you thinking at ? If you (or somebody else)
give me enough topics (let's say 5), I will be able to set up a
documentation page or a tutorial.
Regards, Laurent Etiemble.
2009/4/24 Ben Martin <b...@trustorm.com.au>:
Hi Laurent,
For my projects, being able to use System.Drawing is the main benefit for
using monobjc.
A way to help move code could be to provide more samples of converting
System.Drawing to Cocoa.
Ben Martin
-----Original Message-----
From: laurent.etiem...@gmail.com [mailto:laurent.etiem...@gmail.com] On
Behalf Of Laurent Etiemble
Sent: Friday, 24 April 2009 5:47 PM
To: Mac Programmer; Monobjc User List
Subject: [us...@lists.monobjc.net] Re: Monobjc and System.Drawing
Hello,
(Note: Cross posting to the user list)
For historical reasons, NSColor and NSImage were made to be implicitly
usable with the Color and Image classes. It was a quick way to make
existing code works (image loading, various colors, etc). Now, Monobjc
contains everything needed to replace all the code linked to the
colors, images or drawing.
Moreover, it seems that on Tiger, the X11 installation is a
show-stopper. So my question is: "Shall we drop the System.Drawing
dependency ?". This will mean no more Color and Image implicit
conversion, no more access to System.Drawing drawing methods, etc.
Please comment on the list.
Regards, Laurent Etiemble.
2009/4/22 Mac Programmer <macp...@fastermac.net>:
Is there any particular reason why Monobjc needs to be dependent on
System.Drawing? Monobjc uses System.Drawing in a few places for
converting,
say, between NSColor and System.Drawing.Color and these uses appear to be
safe. However, if one uses, say, System.Drawing.SystemColors.ButtonFace,
this results in the following exception on a computer that does not have
Mono installed:
Unhandled Exception: System.TypeInitializationException: An exception was
thrown by the type initializer for System.Drawing.KnownColors --->
System.TypeInitializationException: An exception was thrown by the type
initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException:
/Library/Frameworks/Mono.framework/Versions/2.4/lib/libgdiplus.dylib
at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup
(ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOut
put&)
at System.Drawing.GDIPlus..cctor () [0x00000]
--- End of inner exception stack trace ---
at System.Drawing.KnownColors..cctor () [0x00000]
--- End of inner exception stack trace ---
at System.Drawing.SystemColors.get_ButtonFace () [0x00000]
I would rather not include any assembly in my mkbundle2-generated
executable
that depends on libgdiplus.dylib, which in turn requires that X11 being
installed, as well as having all the other .dylib's that libgdiplus.dylib
depends on (libtiff.dylib, libjpeg.dylib, etc.). This is akin to
late-binding, where you won't know if any given System.Drawing reference
will work until it's been tested, meaning all possible paths to that code
needs to be tested.
Thanks.
-Phil
