[Mono-list] Why GTK#?

[Jonathan Pryor]

Response inline...

Please note that I'm no expert in Win32 or Gtk+, so I may mis-speak
below.  However, all information is as best I currently know. :-)

On Tue, 2003-04-22 at 11:31, Maurizio Colucci wrote:
<snip/>
> > Next is compatibility.  It is not possible to implement Windows.Forms on
> > top of Gtk+/Qt and have 100% compatibility, because Windows.Forms
> > exposes *lots* of Win32-isms, such as the Win32 message loop. 
> 
> I don't understand very well what it means "to expose the message
> loop".  I guess I need to read again "Programming Windows with C#" by
> charles Petzold. :-P
> 
> If you could be so kind as to be more precise about which
> construct/function of Windows Forms is dependent on win32...

I'm no expert, but I can point out the obvious things.  First of all is
the System.Windows.Forms.Msg enumeration, which is all the messages that
a Win32 message loop would be expected to respond to.  Win32 combines
several separate Unix concepts.  For example, X-Window programs
typically have two parts: the window controls, displayed by the Window
Manager, and the application itself, which uses its own toolkit. 
(There's also the X Server, which displays both of these to the screen.)

The WM_NCCREAT, WM_NCDESTROY, etc. functions would all map to Window
Manager functions (they're non-client area messages), and thus would
form an odd coupling between Window Manager and Toolkit, or (could)
place a dependency on the Window Manager to use.

WM_POWER is (IIRC) a message sent when the system is being turned off. 
I'm not aware of any Unix equivalent message (though I suppose D-BUS
would fit here).

Then there are the WM_MDICREATE, etc. functions, which are for MDI
(Multiple Document Interface) support.  AFAIK, Gtk+ doesn't support MDI.

Win32 also allows the user to create their own messages, of the form
WM_USER+constant.  I'm not aware of any similar mechanisms under X.

Please note that I'm more familiar with the Win32 API than X-Window, so
I may be confused about certain things.  I'm just trying to point out
that there are no direct, clean mappings for some Win32 messages.

These messages are important because they're used in the
System.Windows.Forms.Message structure, which itself is used by:

	protected void 
	System.Windows.Forms.Control.WndProc (ref Message m)

As such, they form a critical binding.

> (just a thought: doesn't GTK+ have message loop to which those
> functions could be mapped?)

Does it have a message loop?  Yes.  Dose the Gtk+ message loop permit
users to look at every message that goes through?  Not that I know of.

> In order to maintain compatibility, Wine must be used, and this is
> > being done.
> 
> 
> MUST be used?
> 
> It was my understanding that any .NET application which does call
> win32 functions explicitely (i.e. use Pinvoke, I think it's the same)
> would have been supported by mono, even without wine.
<snip winforms quote/>

Just because a .NET application DOES NOT P/Invoke to a Win32 API DOES
NOT mean that it doesn't *require* Win32.  What if an application stays
within .NET but hooks into WndProc?  Plus, You have public ``IntPtr
Handle'' properties throughout the class library, assuming Win32
semantics for lots of things.

If we implemented System.Windows.Forms atop Gtk+, we couldn't say "Don't
use DllImported functions and you'll be safe," we'd have to say "Don't
use DllImported functions, and don't use these methods either: <insert
method list/>."  It's a non-trivial proposition.

Hence my statement that Wine MUST be used to permit FULL
System.Windows.Forms compatibility.  S.W.F is a very "leaky" API, not
really intended for cross-platform development, and it shows.

> Is this no longer true? I am really concerned about that because I
> feel that interoperability between Windows and GNU/LInux is of the
> utmost importance.

Many feel that interoperability is important.  Hence the Wine
implementation, which will provide full compatibility.  See above.

However, I do believe someone is still working on a S.W.F implementation
using only Gtk+, not Wine, but I'm not sure what the progress of their
work is.  The main effort is behind Wine.

> (On the other hand, If the application "cheats" (i.e. uses Pinvoke) it
> is not a big deal if it doesn't run under linux. )
> 
> > As for SharpDevelop, I have no idea when that'll be complete.  Last I
> > heard they were porting SWT (the Ecplipse toolkit from IBM) to C#, after
> > which they'll re-write SharpDevelop to use SWT.
> 
> So the current version (which uses windows forms) will never run on
> linux without wine?

That's why someone was still working on a S.W.F Gtk+ implementation,
solely to support SharpDevelop.  Again, I don't know what their progress
has been; I only heard about it through #mono on IRC.

 - Jon