[Mono-list] Windows forms.

[Ulf Ochsenfahrt]

--=-NKbiP71b+m1p69Hl9+78
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, 2002-07-07 at 14:09, Guenther Roith wrote:
> I disagree with you here.
>=20
> A native look & feel is more important than you might think.

I don't know how gtk looks on windows, but:
custom controls have the same look & feel on every platform.

Even then, saying "Windows.Forms" is probably saying "Windows.Feel". The
range of choices there is very narrow.

> And gtk+ is
> very powerful,=20

I do not doubt that.

> a good foundation to build on and building on it will
> definitivley save time.

That ain't necessarily so. As has been pointed out earlier (by Miguel I
think), it will be very very painful to reemulate Windows.Forms interna
using an existing toolkit. And as I've said before, it may well proove
to be impossible due to the different concepts behind them.


On Sun, 2002-07-07 at 17:56, A Rafael D Teixeira wrote:
> I=B4ve constructed some, here are my thoughts on it:
>=20
> There are 3 types of custom controls:
>=20
> 1 - The agreggated control. They are kind of a mini win.form that can
> be embed into others. This is easy for mono because it builds upon=20
> existing controls and win.forms glueing.
>=20
> 2 - The owner-drawn control. These use base controls specialized=20
> events to render differently, part of themselves (I have one "bitmap=20
> as a thumbnail" selector, done using a mere listbox, in one of my work
> project). Mono won't have big problems here, because you receive a=20
> System.Drawing.Graphics to draw things in each event.

I havn't much experience with gtk#, but I believe it is possible in gtk#
to have owner-drawn controls?

> 3 - The totally-new-widget control. These are almost guaranteed to use
> API and native-code libs, or at least de WndProc hook, because they=20
> want a totally diferent look or more events, and want it with good=20
> performance. Third Party controls fall mostly in this category and=20
> unfortunately are widely used. Here our only hope is to have people=20
> developing open source mono-and-windows-compatible alternatives, that=20
> may be accepted by most (Win) developers.

If the Win32 API is used, no chance. In that case, the developers have
just sacrificed cross-platform development. Yet I think that you don't
need native-code libs for GUI widgets at all. You only need to be able
to write a custom event handler (for which you need to emulate the
WndProc, which might proove impossible with an existing widget set).

Thus my proposal to write a wrapper dll for a new clean windowing
environment. And then re-emulate whatever is needed for Windows.Forms.

That way one can easily port Windows.Forms to other (new) windowing
systems (other than X or Win32). Of course, it is quiet low-level and
some speed is traded for cross-platform portability (at least at first).

If it is cleanly written, you can even allow for pluggable looks. (The
feel is probably fixed if you say Windows.Forms!)

(By the way, I don't like the look of GTK, so I would like to have a
Windows look. This is especially important if you want to mix standard
and custom components!)

> Most custom controls fall in the first 2 categories, and represent=20
> little trouble in the road to mono winforms. But as SharpDevelop use=20
> of Magic show, many good (and sorely needed) controls have heavy=20
> dependences on Win32 APIs.

Mike Krueger wrote:
> SharpDevelop is prepared to dump Windows.Forms when it is neccessary.=20
> I abstracted the GUI layer and I hope that I were careful enough to=20
> have not many Windows.Forms dependencies outside of the code.


-- Ulf

--=-NKbiP71b+m1p69Hl9+78
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9KHMQko6vRMd346ARAuEiAJ4hhe6Cb+DBosMXJgWk6aYkbMSnawCdEVSt
uN3E7DNJplqNNci5TAt1KsM=
=BmdY
-----END PGP SIGNATURE-----

--=-NKbiP71b+m1p69Hl9+78--