> The basic Structure of the Class library should be the same > on a Platform by platform basis. > system.windows.forms > system.gnome.forms
I think Douglas hits it right on the head here. My use of windows.forms and just straight win32 UI programming, Microsoft never intended this (by design) to be a cross platform UI toolkit, so a lot of steam is potentially wasted coercing it to be so. Nothing is preventing anyone from coming to market (either open source or otherwise) a cross platform kit for .net/mono. If the kits are able to maintain a close appearance in terms of classes, then moving a gui app should be a lot less effort. It makes the most sense to me, as a UI designer, to approach GUI based apps from the environment they're intended to run on. I've done a couple of cross platform applications, and the end result - targetting maximum usability - is matching the interface to the ways users are used to accomplishing tasks in that particular environment. Trying to achieve platform agnostic UI usually means cutting out functionality that might otherwise accelerate the user's learning curve and/or function of the application. > The Swing UI is half the reason you don't see alot of java > implementation on the client side. It doesn't have the look > and feel of the client. I always thought it was speed that stopped Swing from getting anywhere. To this day, I can get up and grab a cup of coffee before several Swing based apps I have to use are loaded and running. > Also it should be noted that MS (according to rumors), will > be making GDI+ a direct graphics accelerated object in > longhorn. And how this influences the different libraries in > windows.forms (if it is still called that) in the framework > that is released with Longhorn will be interesting to say the That would be cool. Jon Gilkison //interfacelab.com/ _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
