[Mono-devel-list] using mono to write a linux gui

[Jonathan Pryor]

On Fri, 2004-12-17 at 17:29 -0800, Michael Geis wrote:
> Thanks, Jon that was a lot of useful info.
> Let me try to put this together terms of the options this boils down
> to.
>  
> 1) The simple option to stay within C++ and use gtkmm. 
>  
> 2) If I wanted to use mono for gtk# or Qt#, there seem to be two ways:
>  
> a) Keep it all under linux. This means wrapping with swig and using
> DllImport in C#. It may be some effort but pretty much seems to be
> guaranteed to work.
>  
> b)Compile my code into CIL under Windows. Problem: It might contain
> sections of native code, that might not run under linux. Is that still
> possible if my code does not contain any VC++ features (it
> does compile under gcc)? This difficulty would be solved by Whidbey,
> though. Is that correct?

Ensuring that all your code compiles under both VC++ and GCC is the best
way to make this approach *not* work.  Fail dismally, in fact.

The key idea behind approach (2.b) is that you create a managed assembly
in C++ which is then used by C# for the GUI.  Seems simple enough.  The
unfortunate reality is that even if your code compiles down to pure IL
(no native code, etc.), the default visibility for all types created by
VC are "internal".

Translation: sure, you can create a purely managed assembly, but your C#
code wouldn't be able to use that assembly since no types would be
exported.  Oops.

If you want the types to be exported from the assembly, you need to
explicitly specify that, such as with a "public class" declaration.  You
could make the "public" conditional on VC to maintain portability with
GCC.

However, you'll likely also want to simplify your C# code, by
integrating the C++ assembly into the CLI as much as possible (by using
the standard collection interfaces, IDisposable idiom, etc.).  This will
require dropping portability with GCC, since GCC can't do any of that.

You could structure your code so that you have C++/CLI wrapping the
standard C++ code which remains portable between VC and GCC.  I've done
this before, it's not very difficult.  This may or may not be an option
for you, though.

Then you'll have the decision of whether to stick with the currently
shipping Managed Extensions for C++ (ugly as sin), or get a hold of one
of the VS betas and use C++/CLI (which I like the more I read about it).

Also, just because your code doesn't use any VC-specific functionality
doesn't mean that it can be compiled to pure IL.  It's purely dependent
upon how you use the language -- certain language constructs may require
unmanaged code, or use of printf(3).  I'm not an expert, though, and can
only conjecture on this issue.
 
> Suppose I made it that far. If I wanted to develop with C#, both
> Windows and mono are candidates. But mono does not support C++/CIL, so
> if I wanted to stay with C++ only, I
> would have to code under Windows.

This is correct.  If you want managed C++ code, you're stuck on Windows.
 
> Did I understand you properly?
>  
> A final point: Are gtk# and qt# still an option in C++/CIL. In
> otherwords, does that sharp imply that they can only be used withon
> C#?

No, the '#' means "managed".  Gtk# can be used from any managed language
-- C#, VB.NET, Nermerle, JavaScript.NET, etc...  C++/CLI should be able
to use it as well as any other managed language.
 
 - Jon