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

Jonathan Pryor jonpryor at vt.edu
Fri Dec 17 07:19:32 EST 2004


On Thu, 2004-12-16 at 20:37 -0800, Michael Geis wrote:
<snip/>
> The idea of CLR and CIL is still new to me: My so far understanding of
> it suggests that once a C#  app has been compiled you can run it on
> any platform if you have the required virtual machine(just as python
> runs everywhere provided you have a python interpreter)?

This is mostly correct, though Microsoft's original C++ compiler greatly
complicates matters.  The complication is that there is no guarantee
that assemblies contain *only* CIL code -- they can contain a mix of CIL
and native code, which (1) the original Managed Extensions for C++ did
by default, and (2) isn't portable to non-x86 Windows platforms.

Then there's the DllImport issue, but it's equivalent to using a Python
library which only runs on Windows (say a Registry API).

>  If this is correct, it seems I could choose the following approach:
> Compile my C++ code under windows with the \clr switch (hoping that It
> (really) Just Works) into the managed universe .The GUI app to be
> written in C#  then should be able to use these modules naturally
> (i.e. without P/Invoke etc.). Finally, I would compile the C#  with
> mcs and run the whole thing with mono.

In order to get something that runs on Mono, you'd need to use
"Whidbey" (which will probably become Visual Studio 2005; betas
currently exist for it), and use the /clr:pure or /clr:safe options when
compiling your C++ code.

You could then use C# to write your GUI code, but you could also use 
C++/CLI, and keep everything in C++, since C++/CLI permits full use of
managed assemblies.

In theory this should work properly under Mono.  In practice you'll have
two issues:

(1) Since you're using C++ you'll have to use Microsoft's tools.  This 
    may not be a problem for you, and the resulting assemblies can be 
    copied and executed under Mono.
(2) You'll have to decide which GUI toolkit to use.  
    System.Windows.Forms, for which Microsoft has the best support, is 
    not well supported under Mono.  Support should be available with 
    Mono 1.2, currently expected in the first half of next year.
    Gtk# is the preferred toolkit to use with Mono, but it requires 
    GTK+, so you'd have to provide an installer which installs Gtk#
    and GTK+ in addition to your app.

If you want to be able to build on Linux without using any Microsoft
tools, then you'll have to do something else.  Mono doesn't currently
support C++/CLI, so you'd have to (1) port your C++ code to GCC; 
(2) write a C wrapper for your C++ code; and (3) write C# DllImport
declarations to use the C wrapper.  Tools exist to automate steps (2)
and (3) -- see http://www.swig.org.

Alternatively you can skip managed code, keep everything in C++, and use
GTK+ directly or use Gtk--, the C++ wrapper for GTK+.

> As fasr as the actual GUI is concerned. On go-mono.com is this quote
> that gtk# is so much more productive than Gtk+. Is that the general
> opinion?

The general opinion is that *anything* is more productive than GTK+. :-)
Something about a C API...  Which is why the Python wrappers are so
popular.  Gtk-- should be pretty stable by now as well, and will likely
require less of a learning curve as it wouldn't require any
managed/unmanaged interaction, or a dependence on Microsoft tools.

>  What kinds of things can gtk# do (or do better) than gtk+? Is there
> an advantage going down the mono/gtk# path if I could just create a
> GUI with gtk+ that would fit with my existing C++ code seemlessly.

Gtk#'s advantages are that it's a nice OO API, requires less typing, is
garbage collected, and integrates fairly nicely with C#.

Gtk-- is similar but for C++ (OO API, less typing, integrates well with
C++ and the standard library, wrapper classes to simplify memory
management).

Which should you use?  I would guess that Gtk-- is the better solution
for you, but I haven't actually used Gtk--, nor have I written a GUI in
GTK+ or Python for that matter...
 
 - Jon





More information about the Mono-devel-list mailing list