[Mono-osx] Mono 1.1.0 Cocoa# + MWF

[kangaroo]

All,

> The problem with this approach is that *very* few IT people  
> deliberately write code to be portable. In fact, in most IT  
> departments, developers are _forbidden_ to put
> any significant extra effort into cross-platform portability. At  
> the same time, they will write portable code if they know which  
> classes to avoid, etc.

Mono does give you the portability; slapping on a different GUI layer  
to be able to sell your product into those markets is a must as a  
business case for me; but feel free to disagree.  What I'm saying  
about writing with different user interfaces in line is abstracting  
your core logic from your presentation layer.  There are numerous  
benefits to this aside from just supporting in our specific  
discussion Gtk#/Cocoa#/SWF.

>
> The BIG attraction of Mono is to enable the heterogeneous  
> environment, where Windows, Linux, and Mac systems are all first  
> class citizens. This is why I jumped on the Java bandwagon early  
> on. There are some issues with Java, however (e.g., JNI is not a  
> reasonable way to incorporate unmanaged code). The CLR addresses  
> those issues very nicely and I anticipate has great long term value.
>

I agree with you on the attraction/sexyness of mono wholeheartedly  
otherwise I would be doing none of this work in my spare time.

> But the long term value Mono and the CLR represent is diminished  
> greatly by not having a cross-platform GUI framework. Cocoa# and  
> ObjectiveC# are not really very interesting for me in my work. I am  
> *VERY* pleased that Gtk 2.10 will have a Quartz driver. That really  
> does address my concern and that really does make cross-platform  
> development practical ***From The Point Of View Of IT  
> Management***. I cannot stress that last point enough.
>

Here is where we start to disagree;  Gtk2.10 can "gain" a quartz  
driver from Cairo which is great; its still missing the entire  
windowing system (please see how the cairo quartz driver works) so  
the quartz driver != instant gtk on mac.  In my opinion (and I am in  
"IT Management") this really is pointless anyways.  If you want a  
fully cross-platform UI; deploy a web app.  If you're writing a  
desktop app that you expect windows/mac/linux people to all be able  
to consume; you damn well better have a fully native experience.  Mac  
users are the worst and most notorious for this.  Hastily ported  
windows apps that dont feel "mac-ish" die on the vine and have little  
to no sales into the mac community.

> If we want to see Linux/FOSS/Mac OSX platforms be able to stand  
> along side Windows, we need to be able to offer a standard  
> mechanism that can easily be embraced in corporate environments.  
> With that ready acceptance, our favorite platforms will start  
> making inroads elsewhere. None of us may like the idea that  
> corporate acceptance is what drives school and home usage, but that  
> is what got Windows the dominant position that it currently has.  
> And that dominant position is what has stifled innovation. Mono  
> offers us the opportunity to introduce true innovation again. But  
> that will only happen if there is a truly cross-platform way to  
> develop GUI applications.
>

I'm back to agreeing with you here in some senses.  I think Mono  
provides a fantastic cross-platform solution (today) for middleware  
and backend.  I still firmly stand by my belief that there is no way  
to write a completely cross-platform GUI toolkit that will address  
the needs of the 3 major audiences.  (Alt-F4 on windows maps to what  
on Mac?  Mac users hit Apple-Q for a nitpicky example, yes we could  
map that one; but where does this stop).

>> As for more "users" than "hackers"; since none of these tools are  
>> "prime-time ready"; I personally dont see how any user could truly  
>> be using them.  The OSX MWF driver doesn't even have true keyboard  
>> support, let alone supporting control clipping for overlapping  
>> controls; so how can it be used?  As for Cocoa# 0.2; no one has  
>> piped up and shown me a released app running it; so the same holds  
>> (mostly) true.
>
> Speaking as  a potential user of Mono and not able to be a hacker  
> (I was years ago, but now I have a very busy life outside of my  
> work), my comments are as a potential Mono user developer and not  
> as a Mono "kernel" developer. So please take these comments as  
> suggestions and my rationale for these suggestions.

I'm always open to suggestions / constructive criticism :)
>
> Also, it is theoretically possible for me to be very patient if I  
> understand the long term road map. Knowing *where* the project is  
> going will keep me involved over the long term and later in the  
> game I may be able to contribute some work.

I can't speak for the entire mono project; but the long term road map  
for Cocoa# is to evolve it into a more "first-class" citizen on par  
with Gtk#.  A number of the changes I've instated in it map the Apple- 
esque API to a much more ".NET-esque" API (think EventHandlers;  
instead of action/target selector/object pairs).  This should ease  
the road of moving a presentation layer to it.  I frankly see Cocoa#  
as the solution for windows/linux devs to get onto the mac; and  
objectiveC# as the solution for mac devs to leverage the CLR.  Toss  
in a mix of continuing to make sure everything works well on PowerPC  
OSX for the next few years; and X86 osx going forward as well and you  
have my roadmap :)

-kangaroo/geoff