[Mono-osx] (no subject)

[Peter Loron]

Andrew Satori wrote:
[stuff snipped]

> Just because it isn't easy, doesn't mean it's not the right way.  There
> seem to be two camps regarding Xcode.  Those that hate it, this  is
> predominantly the CodeWarrior user base, with a fair number of  Windows
> switchers being among this group.  Then there are those that  are
> comfortable with it.  There really isn't a love fest with it, it  still
> lacks to many features that power users want to make it a love  fest. 
> Don't let these things divert you from the important things.
> 
> Xcode _is_ for better or worse, the development platform for the  MacOS
> X.  Every new Mac comes with it as an optional install, and as  such, it
> is going to be around and it's on the cheap.
> 
> Xcode has an incredible amount of power under the hood, and given 
> documented, publicly available access to the information to extend 
> Xcode, it would be easier to plug Mono and C# (and others) into Xcode 
> to turn it into a Visual Studio like toolset. The foundations are 
> already there, you can see it by looking at how AppleScript Studio, 
> WebObjects, and most imporantly the Core Data data modeler  (EOModeler)
> has been retooled within XCode.  These are all  implemented as plugins.
> 
> What would be required? ( these are rough, there is some detail in  this
> that I'm not covering )
> 
> Syntax Styling for C#.  ( initial pass done, doesn't support code 
> completion from the library )
> Code Completion Plugin.  ( need documentation, or class dump the 
> interface and creative hacking )
> CompilerSpec Plugin for mcs ( need documentation, or class dump the 
> interface )
> Lexical Parser for mcs error message ( time consuming, not done )
> Spec files for integration into native build system ( currently using 
> makefiles )
> Installer to put the pieces in place ( fairly easy once the other 
> things are done )
> 
> Once those things are done, you really only need one additional hack  or
> documentation to add another set of goodies, and that is to class  dump
> and hack how to add custom editors / viewers like the data  modeler into
> the Xcode.  With that, it would then be feasible to  build a data
> browser and as(p|c|m|a)x editor using a mixture of  WebCore and some
> grisly custom code to convert prepocessed code into  layout elements in
> design mode.
> 
> So, we aren't talking impossible, we are talking a big task, and one 
> that I personally think has a commercially viable market if an OSS 
> group isn't willing to step up.
> 
>> Main issue for me is that Apple is not interested, at least  publicly,
>> in the modern OO languages as a developer platform for  OSX. Objective
>> C and Cocoa is what they want people to use.
> 
> 
> Apple can't afford to be interested right now, at least not 
> officially.  They don't have the resources, and there is the  potential
> for a legal mess until Novell finishes it's legal  assessment of the
> vulnerability to Microsoft.  I can't help but think  that this
> discussion has been had at fairly high levels within Apple,  which we
> tend to forget is smaller than it may sometimes appear.
> 
>> ObjC-Cocoa is very good but unfortunately for Apple many developers 
>> know and like Java and/or C# and aren't willing to learn Objective  C
>> and Cocoa.
> 
> 
> I think you are correct, however, I don't think that's a huge concern 
> for them right now, there are enough people who are willing to learn, 
> in addition to the ability to continue to use C and C++ behind the 
> scenes that Apple doesn't see the need.  What they are saying is that 
> future User Interface development shall be in IB/ObjC, but you are 
> welcomed and encouraged to use your preexisting code in it's current 
> form from there, and that includes Java via the bridge.
> 
>> I posted a reply to John Siracusa's post at Ars Technica on the 
>> subject and wrote to jobs at apple.com (never got a reply!)
>>
>> I hope somehow that Apple realise that they are badly behind other 
>> platforms in this respect but I fear that the high management at 
>> Apple in this area are Cocoa veterans and being open to new ideas 
>> when you are an expert is very difficult psychologically.
> 
> 
> It's not an issue of behind, they aren't, in reality, they are  *still*
> ahead.  the IB + Objective C approach is still far ahead of  the Forms /
> Event designs of Windows and X-Windows.  Avalon and all  the
> Longhorn/Vista changes in the model don't change this at all.   What
> Apple does have is a paradigm shift that is a little tough for  switcher
> developer to wrap their heads around.  It took me a full  year before I
> got around to really sitting down with IB and Objective  C.  Today, my
> frustration is that I *can't* use the same paradigm on  Windows and
> Linux (and the person that says Gorm & GnuStep gets a  slimy wet trout
> to the head, see my above statements about native LnF  and usability)

[stuff snipped]

> Sorry for being so verbose, but I have strong opinions on this, and 
> yes, I *really* like Mono on the Mac, and I simply feel that Xcode 
> should be the environment for Mac dev, regardless of language, and  that
> the basics are in place for it to be a top notch C# dev  environment,
> where we can focus on C# and Mono plugins and let Apple  work on the
> things that make Xcode better for everyone.
> 
> 
> Andy

Ok, this probably has been hashed out before...

Andy, do you (or anybody else) have an idea of how we can bend the right
peoples' ears in the Apple Dev tools group? Random users howling about
it on mailing lists hasn't produced what we need, but somebody in the
community probably has the connections to talk seriously with Apple's
management...

Given Apple's somewhat open stance with OSS, I'd hope we could get some
help with extending XCode. I can see them not being ready to spend the
resources to come up with a nice polished XCode SDK, but they ought to
be willing to devote a bit of time to a few registered, NDA'd external
people. "Here's the class dumps and a quickie writeup on how this stuff
works under the covers".

-Pete