[Mono-list] Why GTK#?

[Maurizio Colucci]

On Tuesday 22 April 2003 17:17, Jonathan Pryor wrote:
> Possibly related to this is the idea that Windows.Forms is brain-dead in
> certain areas, such as internationalization.  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.


This is very interesting, thank you.

> 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.=20

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...

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

> 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.

=46rom the page

  http://www.go-mono.org/winforms.html

you can read:

<<
The System.Windows.Forms effort is taking two paths:=20


Win32/Wine-based: This effort will use the Win32 API, and use a stub
program to run the with Wine. This allows applications that use
P/Invoke to function, and event delivery through the Wndproc method to
work for the most advanced and custom applications. This is the path
of best compatibility. Also, work on a Gtk-based rendered for Wine
will be done, to make the user interface integrate with your desktop
look.


Gtk# based: This effort will build a subset of Windows.Forms that uses
Gtk#. This gives a better integration with the desktop, but will not
be completely compatible with the Windows edition. In particular code
that uses P/Invoke to call into Win32 or overwrite the Wndproc method
to achieve special effects will not work.

>>

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.

(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?