[Mono-osx] Re: Mono-osx Digest, Vol 7, Issue 8
tim at mowlem.eclipse.co.uk
Mon Oct 31 15:44:51 EST 2005
> Message: 4
> Date: Mon, 31 Oct 2005 12:00:36 -0800
> From: Peter Loron <peterl at standingwave.org>
> Subject: Re: [Mono-osx] (no subject)
> To: Andrew Satori <dru at druware.com>
> Cc: Mono-osx at lists.ximian.com
> Message-ID: <436677E4.6030801 at standingwave.org>
> Content-Type: text/plain; charset=ISO-8859-1
> Andrew Satori wrote:
> [stuff snipped]
>> Just because it isn't easy, doesn't mean it's not the right way.
>> seem to be two camps regarding Xcode. Those that hate it, this is
>> predominantly the CodeWarrior user base, with a fair number of
>> switchers being among this group. Then there are those that are
>> comfortable with it. There really isn't a love fest with it, it
>> 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
>> 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
>> has been retooled within XCode. These are all implemented as
>> 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
>> 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
>>> in the modern OO languages as a developer platform for OSX.
>>> 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
>> 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
>> 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
>> 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
>> 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.
> Ok, this probably has been hashed out before...
> Andy, do you (or anybody else) have an idea of how we can bend the
> 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
Peter yes this is the key point. An opinion given recently was that
Apple will listen if people start saying they can't/won't release
software or sales drop, which is a no brainer. Unfortunately getting
the message across seems not to be easy.
I suspect that many of the software management team at Apple are ex-
NextStep Cocoa experts (and experts don't normally like change cos
they cease to be experts) - many top scientists poo-poo big advances
by lesser known scientists for this reason - we are all human!
Do you have any ideas? Perhaps the platform envangelists - there is
one for Java:
bluker1 at apple.com
Java, Dashboard & .MacSDK Evangelist
This was taken from the Apple Java mailing list.
> Given Apple's somewhat open stance with OSS, I'd hope we could get
> 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
> works under the covers".
Obviously XCode being Apple's own IDE makes it top choice. But
considering how far short of Eclipse and IDEA it is in many ways it
would be a long road or need some serious resource expenditure. By
refinement thinks like the colour coded bar on the RHS of the window
which shows the position of errors and warnings, icon to click on in
left margin to take you to superclass or subclass implementation, as
well as the more obvious things like excellent refactoring support, etc.
Apple are much more open to outside ideas and OSS these days; so lets
hope that applies even to MS. Personally I don't care if MS is the
'creator' of C#/.NET/Mono - bottom line they copied Java and made an
excellent alternative, Mono will hopefully stop MS from making it MS
only as they would no doubt like.
The API looks bloated (again so Microsoft) - I think I read 5,000
methods - but the basic classes that I have used are usable and easy
Sorry but one more point:
An awful lot of software (most?) is bespoke software written in-house
by company developers to do specific tasks required by their employer
(commercial companies, universities, hospitals, etc). Of course it
goes mainly unnoticed since they don't sell the software, but rather
use it themselves.
It is this (hidden) market where many Java and C#/.NET/Mono
developers work, and without good support from Apple for both Java
and C#/.NET/Mono the Mac is less likely to be considered for purchase
in these areas.
If C#/.NET becomes the main dev environment on Windows as no doubt it
will then having a good toolchain for such development on MacOSX can
only really benefit Apple
e.g. employee wants a Mac, most users have PCs, company develops S/W
package on PC, but thats cool cos the Mac can run it as well,
employee gets a Mac rather than being forced to buy a Wintel.
More information about the Mono-osx