+A: When Mono is ready to be shipped Ximian will offer a commercial
+ support and services for Mono.
+
+Q: Does Ximian provide consulting services around Mono?
+
+A: Yes, Ximian does provide consulting services around Mono to
+ make it suitable to your needs. Porting the runtime engine,
+ customizing it, working on specific classes or tuning the code
+ for your particular needs.
+
+Q: Will you wait until Mono is finished?
+
+A: Mono will ship on various stages as they mature. Some people
+ require only a subset of the technologies, those will ship first.
+
+ More advanced features will take more time to develop. A support
+ time line will be available in June 2002.
+
+<a name="gnome"></a>
+** Mono and GNOME
+
+Q: How is Mono related to GNOME?
+
+A: In a number of ways. This project was born out of the need of
+ providing improved tools for the GNOME community, and will use
+ existing components that have been developed for GNOME when they
+ are available. For example, we plan to use Gtk+ and Libart to
+ implement Winforms and the Drawing2D API and are considering
+ GObject support.
+
+Q: Has the GNOME Foundation or the GNOME team adopted Mono?
+
+A: Mono is too new to be adopted by those groups. We hope that the
+ tools that we will provide will be adopted by free software
+ programmers including the GNOME Foundation members and the GNOME
+ project generally.
+
+Q: Should GNOME programmers switch over to Mono now?
+
+A: It is still far to early for discussions of "switching over." No
+ pieces of Mono will be ready within the next six months, and a
+ complete implementation is roughly one year away.
+
+ We encourage GNOME developers to continue using the existing tools,
+ libraries and components. Improvements made to GNOME will have an
+ impact on Mono, as they would be the "back-end" for various classes.
+
+Q: Will Mono include compatibility with Bonobo components? What is the
+ relationship between Mono and Bonobo?
+
+A: Yes, we will provide a set of classes for implementing and using
+ Bonobo components from within Mono. Mono should allow you to write
+ Bonobo components more easily, just like .NET on Windows allows you
+ to export .NET components to COM.
+
+Q: Does Mono depend on GNOME?
+
+A: No, Mono does not depend on GNOME. We use a few packages produced by
+ the GNOME team like the `glib' library.
+
+Q: But will I be able to build GNOME applications?
+
+A: Yes, we will enable people to write GNOME applications using Mono.
+
+Q: Do you have C# bindings for GNOME?.
+
+A: Yes, we currently bind libgnome, libgnomecanvas, and libgnomeui --
+ although I dare say I have no idea how functional the bindings are
+ outside of what I tested in the sample app. I imagine other libraries
+ under the GNOME framework will be added on an as-needed (and as-requested)
+ basis...although a truly good bonobo binding will have to wait on the CORBA
+ remoting support which has been started recently.
+
+<a name="gui"></a>
+** GUI applications
+
+Q: Will Mono enable GUI applications to be authored?
+
+A: Yes, you will be able to build GUI applications. Indeed, that is our
+ main focus. We will provide both the Windows.Forms API and the Gtk# API.
+
+Q: What is the difference between Gtk# and System.Windows.Forms?
+
+A: Gtk# is a set of bindings for the Gtk+ toolkit for C# (and other
+ CIL-enabled languages). System.Windows.Forms is an API defined
+ by Microsoft to build GUI applications.
+
+Q: Why not implement System.Windows.Forms on top of Gtk# or Qt#?
+
+A: There are several reasons for this.
+
+ First of all, Gtk+ and Qt are standard toolkits on Linux, and their
+ proponents want to use their favorite toolkits when writing
+ applications.
+
+ Related to this is the idea that System.Windows.Forms is
+ brain-dead in certain areas, such as internationalization.
+ System.Windows.Forms uses explicit sizes for all controls, as opposed
+ to Gtk+ and Qt which use a box/packing model, which can better deal with
+ the different string lengths different languages will have.
+
+ Next is compatibility. It is not possible to implement
+ System.Windows.Forms on top of Gtk+/Qt and have 100% compatibility,
+ because System.Windows.Forms exposes some Win32-isms, such as the
+ Win32 message loop. In order to maintain compatibility, Wine must be used,
+ and this is being done; see the
+ <a href="/winforms.html">System.Windows.Forms effort page</a>.
+
+ Additionally, Wine apps don't currently fit in -- visually -- with
+ Gtk+ or Qt apps.
+
+Q: Will I be able to run my smart clients on systems powered by Mono?
+
+A: As long as your applications are 100% .NET and do not make use
+ of P/Invoke to call Win32 functions, your smart client applications
+ will run on Mono platforms.
+
+Q: Where can I learn more about Gtk#?
+
+A: The following <a href="http://gtk-sharp.sourceforge.net>link</a> sends you to the page of the project.
+
+Q: What can I do with Gtk#?.
+
+A: Gtk# is becoming very usable and you can create applications and
+ applets like those you see in a GNOME desktop environment. It's
+ easy to install so it's worth a try.
+
+Q: How can I compile my HelloWorld.cs which uses Gtk#?.
+
+A: Try: mcs --unsafe -o HelloWorld.exe -r glib-sharp -r pango-sharp -r
+ atk-sharp -r gdk-sharp -r gtk-sharp -r gdk-imaging-sharp
+ HelloWorld.cs
+
+Q: Is there any way how to connect DataAdapter to some GTK# controls?
+
+A: There is a sample file called `DbClient' in gtk-sharp/samples that you
+ might to look at. It is a sample program in Gtk# that adds/updates/deletes
+ information on a Postgress database. When we have the new table/tree widgets,
+ I am sure someone would write an adapter for System.Data (in Gtk2 the
+ tree/list widgets are written using a view/model, so you only need to write
+ a model that maps to the database). You can have a look at
+ gtk-sharp/sample/DbClient, where there is a GTK# application that uses
+ System.Data. It does not use DataAdapter, but DataReader though.
+
+Q: Do you have an estimate for when Windows.Forms will be released?
+
+A: We do not know, volunteers are working on this, but there is no set
+ date yet. The current approach is using the Wine Library to implement
+ it.
+
+<a name="msft"></a>
+** Mono and Microsoft
+
+Q: Is Microsoft helping Ximian with this project?
+
+A: There is no high level communication between Ximian and Microsoft
+ at this point, but engineers who work on .NET or the ECMA groups
+ have been very friendly, and very nice to answer our questions, or
+ clarify part of the specification for us.
+
+ Microsoft is interested in other implementations of .NET and are
+ willing to help make the ECMA spec more accurate for this purpose.
+
+ Ximian was also invited to participate in the ECMA committee
+ meetings for C# and the CLI.
+
+Q: Is Microsoft or Corel paying Ximian to do this?
+
+A: No.
+
+Q: Do you fear that Microsoft will change the spec and render Mono
+ useless?
+
+A: No. Microsoft proved with the CLI and the C# language that it was
+ possible to create a powerful foundation for many languages to
+ inter-operate. We will always have that.
+
+ Even if changes happened in the platform which were undocumented,
+ the existing platform would a value on its own.
+
+Q: Are you writing Mono from the ECMA specs?
+
+A: Yes, we are writing them from the ECMA specs and the published
+ materials in print about .NET.
+
+Q: If my applications use Mono, will I have to pay a service fee?
projects / mono.git / blobdiff