- #MONO FOR MAC PATH PORTABLE#
- #MONO FOR MAC PATH PLUS#
- #MONO FOR MAC PATH FREE#
- #MONO FOR MAC PATH MAC#
- #MONO FOR MAC PATH WINDOWS#
#MONO FOR MAC PATH MAC#
As I said in the article, a key factor holding back Mono on the Mac is the lack of support for Cocoa. Unfortunately, that's by no means certain. > wasted, because then Mac users would be happy to > point of view since Cocoa" well, no, it wouldn't be > in a sense, be wasted effort from a portability > feature-complete implementation of Cocoa# would, > "any efforts expended in terms of building a more
#MONO FOR MAC PATH PLUS#
> plus GUIs under X) but not with the proprietary and > standard, open APIs (meaning most non-GUI functions, > You noticed that on Mac it works fine with all the
#MONO FOR MAC PATH FREE#
This technology is aimed SQUARELY at server side development.Įither approach opens the path for hardware and OS platform independence whilst still using a great language and development platform.Ĭonclusion: Especially if you have an investment in skills or IP this is a path which can easily and effectively help free you from being chained to a specific hardware or OS vendor. net apps in to J2EE apps through the compilation process. Grasshopper from Mainsoft is the alternative to Mono for the server side it is a completely different approach and essentially turns.
In fact that was the focus of compatibility efforts in the early days of Mono if I am not mistaken. Mono for web apps is a real and viable alternative to being stuck on Wintel servers using IIS.
#MONO FOR MAC PATH PORTABLE#
net app portable to an XServe or Unix server - either use Mono or Grasshopper. Currently there are two approaches to making a. net development is in the space of server side / web applications. Please just give me a reason to switch to a Mac!Īlso, you missed the point that a LOT of. So Mono and GTK for Cocoa are all good things. Net applications I am already maintaining, then I have a chance of doing at least some of my development work natively on a Mac using Eclipse instead of being stuck using something like BootCamp or Parallels all the time. Now, if I want to be able to use a beautiful machine with a decent operating system - namely a MAC - and still develop the. Net developer, I have many apps that I need to develop and maintain all using the. I would like to offer a reverse perspective.
Like most OSS projects, this one will stand or fall in the straightforward market-place of development investment, wherever it comes from. Equally, more Mac developers could get involved. Apple could help if they wanted, and, as for any minority platform, it would seem to be a big win: they're far more likely to attract than lose devotees by such a move. All that's needed to get there quicker is more effort. What seems to be lacking is sustained effort in that direction. It fits in just like it does on any other desktop platform, and it's obvious where we're going: eventually, Mono will work fine on Mac OS. Read this article, for example:įinally, your conclusion: "in terms of how/where they fit into Mac development, I think it’s time to step back and re-evaluate where we’re going." is nonsense.
Why didn't you ask whether Apple could make X work decently? A rootless X server that starts automatically when required would remove all the objections to running X apps under Aqua except for the "look-and-feel" one, which for many programs is enough.įinally, to describe Cocoa as proprietary is not entirely fair, and you didn't mention the obvious riposte of the Mac-centric open source development, namely to use GNUStep.
#MONO FOR MAC PATH WINDOWS#
Seriously, this is a major part of the point of Mono: you can write one app, and it will run on Windows (where it is simply calling proprietary, platform-specific APIs) or Linux (where it is calling platform-specific APIs that may be open, but certainly aren't as neatly standardised as Mono's), or whatever other system you're on.Īnd then this: "I expect some pundit will be along soon to assure me that if I just added a couple of lines of gobbledegook to this config file". And "What’s the point in writing your application using an ECMA certified, platform-neutral language when all you’re doing is making calls to a proprietary, platform-specific toolkit?" okay, so let's give up writing in C, because all we'm doing is generating proprietary, plaform-specific instructions. You then derail completely: "any efforts expended in terms of building a more feature-complete implementation of Cocoa# would, in a sense, be wasted effort from a portability point of view since Cocoa" well, no, it wouldn't be wasted, because then Mac users would be happy to run Mono GUI apps, and you've already correctly observed that they won't run apps that don't look native. You noticed that on Mac it works fine with all the standard, open APIs (meaning most non-GUI functions, plus GUIs under X) but not with the proprietary and Mac-specific Cocoa. "The real stomping ground of Mono is undoubtedly Linux" Actually, it's open systems. The article misses the point in a couple of ways:
0 kommentar(er)
