[Mono-devel-list] Windows.Forms schemes.

[Michael L Torrie]

On Wed, 2003-08-27 at 09:22, Moore, Paul wrote:
> Its not simply a case of 'eventually the best solution will win' (or solutions).
> 
> Some of us have to place bets now and changing horses late is a tough thing to do (look at #develop)
> 
> I REALLY like the idea of cross platform dev using CLR (fabulous job done by mono and dotgnu teams), but I cant convince myself to bet my farm on it until the GUI toolkit issue has a solution with an empty 'cons' column.
> 
> I don't care about p/invoke and windows procs, I am looking to create new apps. I just want a way to
> 
> A) write portable GUI code

This is simply a matter of choosing a good libary.  I would argue that
SWF is one of the less portable APIs (although it will soon be portable
enough to run reliably using winelib).

Personally, I think it a better idea to completely separate the GUI
frontend from the logical backend.  (Model-view-controller).  This way
you can use a non-portable UI, and replace it when you need to on
various platforms.  All without changing anything internally.

> B) painlessley if possible (ie a GUI designer)

GUI's lend themselves well to object-oriented design, and as such,
constructing a gui from raw source code using an OO language such as C#
is actually quite fast and efficient, even without a gui designer. 
Every GUI designer has its weaknesses, and most of these weaknesses
cause me to simply prototype my gui and then use the generated code to
handcraft my own gui.

> C) that uses (not looks like) the native widgets

Unfortunately this is something that's not easily obtained in any
programming language or environment.  The closest I've seen to this on
C++ and C# is wxWindows (wx.NET for c#).  Even then, by trying to
implement a consistant API and behavior across diseparate UI designs and
APIs is very difficult.  wxWindows is close, but still craps out in some
areas.  

As has been discussed before, the only wayt to make your gui truly
portable is to take all the drawing and event handling upon yourself,
such as what GTK, Swing, and QT do.  (Many developers are under the
misconception that QT is a natively-drawn win32 toolkit.  It is not.  it
is simply themed to look like windows on win32).  

SWF cannot be considered truly portable either, unless you bring a whole
windows emulation layer with you, which is being done currently.  But
then on non-windows platforms you end up with a win32-drawn gui that has
to be themed to fit into some other desktop

Again, this will most likely never be possible, at least to meet your
expectations.  QT manages to do well using just theming (Adobe used it
for one of their main products, Adobe Photoshop Album
http://www.trolltech.com/images/screenshots/photoshop.jpg ).

Furthermore, Microsoft themselves no longer uses win32 native widgets
for their main office products.  For the last several versions, every
version of MS Office has used a different custom-drawn widget set
(themed, if you will), sometimes even altering the behavior of the
widgets.  This is essentially theming.  We can do the same thing with
GTK and pull in system colors and fonts and make the app look right at
home.

Personally, I think gtk# with the gtk-wimp theme gets you integrated
into the windows desktop good enough.  The problems that you have with
gtk# in this area are the same problems I would have with SWF running on
my linux box.

Furthering my point in question B, the best way to make an application
portable but look great and fit in on all your supported platforms is to
separate the UI from the business logic.  Then craft a native GUI (a la
abiword).  Personally, I try to keep this separation in my programs but
then usually just stick with the GTK fronted for linux and win32.  

Michael


> 
> 
> 
> -----Original Message-----
> From: Miguel de Icaza [mailto:miguel at ximian.com] 
> Sent: Wednesday, August 27, 2003 6:39 AM
> To: Thong (Tum) Nguyen
> Cc: 'Neil Cawse'; mono-devel-list at lists.ximian.com
> Subject: [Mono-devel-list] Windows.Forms schemes.
> 
> 
> Hello,
> 
> > Itÿs worth nothing there are many .NET controls are written in 100%
> > managed code.  Iÿm pretty sure the major toolkits (Infragistics,
> > Syncfusion, etc) are 100% managed.
> 
> Am sure they are all written in C#, nobody said they were not.
> 
> They just happen to P/Invoke a lot, and hook up to WndProc, and do
> extensive processing in WndProc.
> 
> > People using P/Invoke have already given up their ´cross platform¡
> > compatibility and those applications will become 100% managed over
> > time.  Catering for them isnÿt (IMO) important when you consider the
> > ´ugliness¡ of having to integrate with wine.
> 
> That is fine.  We have now three efforts aiming at different scenarios:
> 
> 	* Full compat.
> 	* Mid-compat using Gtk.
> 	* Mid-compat without toolkit.
> 
> Thats why I like research: we get to try all the options.  Some
> assumptions we make will turn out to be wrong, some will turn out to be
> right.  Its hard to predict.
> 
> We have a diverging opinion about what real applications will look like,
> and thats why we are using different models.  In the end, since its all
> C# anyways, end users get to choose the implementation that suits their
> needs.
> 
> Miguel.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-- 
Michael L Torrie <torriem at chem.byu.edu>