Updated mid-July 24
Welcome to the preview of “Fire”, which is currently now open to all licensed Oxygene and RemObjects C# users. To start with i figured it might be a good idea to provide a small summary/introduction to what Fire is.
Fire is a project i have been working on on my spare time, on and off (mostly off) for about two years (but not really seriously until last Fall). Early this year, it has bene promoted to “official project” status and become a team effort.
Simply put, Fire is a place to code using the Elements languages (Oxygene and RemObjects C#), on the Mac. Some might call it an “IDE”, although i prefer to avoid that term,
My goal with Fire was/is three-fold: First, i wanted to create a tool that lets developers (and, most and foremost, myself) use Oxygene and RemObjects C# natively on the Mac, without the need to boot up a VM, and in a pure-Cocoa UI. Secondly, i wanted that application to be lean, mean, fast and “simple” (in a good way). Lastly, i want Fire to be a place where i/we can explore new IDE concepts.
Before Fire, i spend most of my development time in either Visual Studio or Xcode. Both are huge applications, that are slow to start up, and often sluggish to perform — and that often get in the developer’s way. Visual Studio more-so than Xcode, but Xcode has been catching up since version 4 :(. I wanted Fire to be not that. One of the basic principles of Fire is that it’s fast, and that it never blocks (like no good Mac application should).
Fire is a simple IDE. Although the code base is already pretty substantial, it’s designed to be simple and dedicated to the task — writing code using Elements, and running and debugging it. It’s not over-designed with 5 levels of plugin architecture. It’s not overly extensible (though it may get just extensible enough if we find we need that), it’s “hardcoded” to do what’s needed.
The application is designed as pure Cocoa app for all UI, project management and related tasks. It embeds our managed compiler engine for what i call “project smarts” — that is driving stuff like Code Completion, advanced editor features, refactoring, etc. — so all that logic can be shared between VS and Fire (saving me from re-implementing it, but also saving us from bug-fixing and extending on two fronts, in the future. it’s taken us years to get CC & Co to where they are now ;). Right now, this managed infrastructure is hosted inside the app using Mono via a technology Carlo created called Marzipan*. In the long run (probably/hopefully before a “Fire 1.0” would ever ship), we’d eliminate Mono, and host the managed code via InfraRed**.
As i said before, one of the goals Fire is speed, so Fire is designed so that nothing ever blocks, and everything that could take longer, is done asynchronously. (one should be able to take that for granted, but unfortunately that is not the case). For example, all interaction with the managed APIs happens on background threads, so if you e.g. invoke CC and CC take a second to collect itself (it happens), you can just type on, or move elsewhere in Fire. You’re not looking at a beach ball while that happens. Similarly, when you open a project (or, indeed, launch Fire, which may reopen the last 10 projects you had open when you closed it), then — bam — it’s there. It might take a few more seconds to get everything “booted up” behind the scenes (it can take a while, for example, for the CodeModel to process all the code in a large project and to load in all the references), but the IDE is ready for you to use and start coding, while that’s happening.
The second — to me, related — focus is for the Fire to never get in your way. One of my pet peeves with Visual Studio is that when you hit Build, you basically need to take your hands of the keyboard and wait until it’s done. VS might let you do some stuff, but not everything. And eventually, it’s going to steal your keyboard focus from the editor, and focus the Error List. Ugh. When you press Build in Fire, Fire will go off and build (and show you progress in the navigation bar, which also turns blue), but that’s it. It doesn’t even show you a build log (unless you ask it to). Feel free to keep coding. If there are errors, they’ll pop up in the editor as they are found, and the navigation bar will turn red. And you’re still coding away. What’s more, there’s not even an error list that will pop up. Errors will show inline in your code (as they do in our extensions to VS) and in the project tree, and there’s easy keyboard navigation to browse between them, should you want to review them, via the jump bar.
The entire UI of Fire is simple, yet efficient. You have a navigation bar at the top (under the toolbar), a “Solution Explorer” like Solution pane on the left and content on the right. You can get anywhere in the project you want with either the Solution pane, or the navigation bar at the top. In fact, when you go fullscreen (really nice on the 11” Air), the toolbar goes away, you can hide the Solution pane (Cmd-0), and your full screen — minus some 22 pixels at the top for the navigation bar — is dedicated to your code.
There are no tabs to maintain or close. You reach all your files via the Solution Pane or the Navigation Bar — and convenient keyboard shortcuts make navigation easy. For example Cmd-Ctrl-Left/Right let you go back and forth between the files you are working on (like in a browser). Cmd-Ctrl-Up/Down let you navigate between files (or, nodes in general!) on the current level of the navigation bar. In fact, this model lets you easily navigate between build messages, too, or between stack frames, when debugging. Hit Cmd-Ctrl+M (see the system?) navigates to the first error (which selects it in the navigation bar), and now you can use Cmd-Ctrl-Up/Down to jump from error to error.
There’s no file saving, and no concept of opened, closed or modified files. You just go into a file, type code, and that’s it. Fire will automatically save (in the background) as needed; often enough that you never lose anything. When files change externally on disk (maybe you just did a git pull) it will reload whatever it needs, behind the scenes, without bugging you about it.
Fire uses the same .oxygene and .hydrogene project format as Elements does in Visual Studio (of course), and it also uses standard Visual Studio .sln files for project groups. So you can easily switch back and forth between working on your project in Fire or in VS (until Fire is ready for you to dump VS altogether, of course — which it already has been for me, these past couple months)
The final item worth mentioning — Fire uses a brad new code editor engine we’ve written from scratch using 100% Cocoa. I dicked around with a lot of alternatives, but ultimately decided the code editor is so core a piece of an app like Fire, that we needed to have full control. It’s gotten pretty far already, and expect it to be nice to work in in the current builds — but it still has lots of work ahead, and feedback on its “feel” will be appreciated.
(* Marzipan is now open source and available on github: github.com/remobjects/marzipan
(** this one i won’t be able to talk about for a while, but it’s very exciting technology 
It looks awesome