[Mono-list] Gtk# or the future Windows.Forms Mono

[Jonathan Pryor]

On Sat, 2005-04-16 at 11:44 +0200, Christian Gross wrote:
> Jonathan Pryor wrote:
> >
> >This isn't entirely true; there is also development on Cocoa# for better
> >Mac OS X integration.
> >
> Well, does this not make the argument for something like wx.NET, which
> already has pretty decent OSX integration including native look and feel?

No, because "native look and feel" is a terrible misnomer.  Users claim
they want "native look and feel", but they really don't.  Users want a
Real Native Interface.

The difference?  When the OS vendor changes the look of their UI, Real
Native apps update automatically.  "Native look and feel" apps --
anything written with Qt, for example -- will NOT, at least until the
rendering engine is updated for the *new* look and feel.

See also the change from Windows 3.1 to Windows 95, Mac OS X 10.1 to
10.2 to 10.3 (and presumably 10.4, though I haven't seen it yet), etc.

Qt will *always* be behind, as will GTK+/Gtk#, and EVERYTHING that
depends upon custom rendering.  (This includes Java Swing, except on Mac
OS X since Apple distributes the JRE and can thus make sure the Java Mac
Look And Feel actually matches the current platform.  UI mis-matches
will still be true on Microsoft platforms and Linux; Sun's GTK Look and
Feel *still* looks like Ass.)

wx.NET may be the only one not susceptible to this, as IIRC it uses
native widgets everywhere.  The downside is, from what I've heard, it
offers fewer widgets (the lowest-common-denominator problem), and I
don't see it being used by many actual applications.  I may be biased.

> >So the closest to an "official" position would probably be this: design
> >your code to utilize multiple different front-ends so that you can
> >better integrate with all of your target platforms.  This implies having
> >Gtk#, SWF, and Cocoa# GUIs, if desired.  Is this more work?  Yes.  But
> >your users will prefer it.  (For proof, just see the history of cross-
> >platform toolkits between Mac OS and Windows.  The users tended to
> >prefer Mac-native front-ends in almost all cases.  Even now, I hear
> >grumbling from users that Qt programs don't look "quite right" on the
> >Mac, because buttons are the wrong size and other subtle issues.)
>
> Yes, you are right, and why I point out wx.NET as it is a native look
> and feel.

And why I'll start claiming that "native look and feel" is a misnomer,
as stated above.

> Well, if you are comparing C++ toolkits and their issues, sure you have
> a point.  But Java Swing has managed to create native look and feel
> applications across all platforms.

Ha!  As mentioned above, it has "native look and feel"...  Eventually.
In some cases *years* after the OS shipped.  (Java 1.4 Swing on my XP
box doesn't look like Windows XP, it looks like Windows 2000, and the
menus look *really* funky.  Maybe this was fixed for 1.5, but I haven't
tested it yet.)

Java Swing (and GTK+ and Qt, for that matter) will *always* be playing
"catch-up" with the native platform toolkit.  The only place this won't
be the case is when they *are* the native toolkit (Gnome & KDE).

> I think asking a client to use
> different GUI toolkits on different platforms is asking too much.

It may be, but nothing has changed over the past 20+ years.  The users
*always* want a native UI, and developers want a portable UI.  This is
arguably a reason why Mac OS had fewer apps than Windows -- just porting
a Windows UI to the Mac would NOT result in sales, as the users wanted a
Mac UI, conforming to Mac UI conventions, that looked proper.

Alas, this problem won't go away -- users will *always* want apps that
behave properly, follow their conventions, and fit in with their
desktop.  Time has shown that this problem is too big for a toolkit to
handle, which is why you still don't see many portable toolkits being
used in commercial software...

> Playing devils advocate, I suppose at that point my reaction would be,
> ok, fine, so who pays the software development bills?  Windows!  Hence
> it makes sense to code to only Windows and forget the rest.

Which is the current situation, and why Mono is implementing SWF
support.  Because asking for UI re-writes is asking to be ignored,
unless the platform becomes big enough that you can't ignore it.

With Mono+SWF, you'll be able to run your SWF apps under Mono (perhaps
with some work required, if you app uses P/Invoke for Windows-specific
functionality), and start gaining a user base.  The user base may *hate*
your app's look, but if you start seeing a significant number of users
requesting native platform support, it may be worthwhile creating a
native UI for them.  You certainly DO NOT want to create an entirely
separate code base for them, so having a program design that permits
multiple different UIs from the beginning will make this easier.

Plus, as I mentioned before, separating UI from the core makes it easier
to write unit tests for the core...

>   Which at
> that point raises the question of why Mono?  I suppose an answer would
> be easier development on Linux.  Which is acceptable, but if a Linux app
> does not look and feel good on Windows or OSX, why bother?

Why bother?  Because the *potential* for new users is still higher than
completely ignoring the possibility of new users.  You ignore other
platforms at your peril.

For a related example, look at web browsers.  Microsoft Internet
Explorer had 90% of the market for *years*, then Firefox catches on.
Sites can either support Firefox, or they can lose users.  Many are
opting to support Firefox.

With Mono+SWF, you'll be able to let users run your program on non-
Windows platforms, see if there's a market for your app, and proceed
from there....  The alternative is to ignore everyone else, and not know
if anyone is even interested.

>   I am just
> playing devils advocate here, and find that using an approach like
> wx.NET I avoid all of these problems in the first place.

Which is good for you, but many seem to prefer other toolkits.
Historically, the wx.NET approach hasn't worked, but maybe it will in
the future...

> A question is why not work on making GTK having a native look and feel?
> I was looking at gtk-osx native port and it seemed to have been stopped
> in 2002.  Why did it stop?

It's started up again.  Hubert Figuiere is working on it.  See:

	http://www.figuiere.net/hub/blog/?Gtk-macos-x

As mentioned above, this approach relies on custom rendering (just like
Qt and Java Swing), so the look-and-feel will be out of date as soon as
the OS vendor changes the UI...

 - Jon