Put a fork in it
Ok, so the basic Quartex IDE prototype is nearing completion. I am going to polish it as much as I can, but focusing more on the features you expect to be working “as in Delphi” rather than going creative and adding something new. Things like search and replace dialogs need to be fast, accurate, responsive and non-modal. Keyboard shortcuts should not collide, visual appearance should be balanced, exposed features in terms of buttons should be intuitive and not dominating;
And last but not least, I want the IDE to fast, flicker free and responsive. Large Delphi applications can sometimes become a bit sluggish, especially if the GUI deploy an abundance of nested TPanels to force the look and feel of things. So I am sticking to as little TPanels as possible, using only standard and very basic VCL components that are available on all platforms.
And if this is ever going to run under firemonkey I need to set up an enable/disable system which mimics the use of actions. I find it hard to believe that so many programmers havent used (or even heard of) actions under Delphi. It is probably the best RAD feature Delphi has to offer over database management and frames. Which is why I havent even considered using Firemonkey for any of my projects, because it feels like taking a step backwards.
Why a new IDE?
The reason the Quartex IDE is important, is because we (the Delphi community) really don’t have an “out of the box” IDE that can be bought/forked and used for new and exciting projects. There is no public research-sandbox where people can experiment with the language, try out new ideas for object pascal and break the rules (so to speak). Everyone has to roll their own with mixed results. This used to be the case for text-editors, until SynEdit came along and unified and perfected “code editing” once and for all.
So the idea is to polish and make the IDE as solid and well written as possible, making sure it remains as agnostic and oblivious to the compiler architecture as possible.
The hard part is not “getting it to work”, but rather “getting it to work without mixing apples and pears”. I want the compiler sub-system completely separated from the generic IDE. And I want the IDE to provide its services (editing, debugging, package management etc.) without having to care about “who or what” uses them. I need symbol info, ok – here you go. I need syntax proposals, ok – here you go. If a service is registered and implements the interfaces required things should just work.
The bridge between the ide and the compiler is (as it should be), an intermediate class/interface hierarchy and information layer. So all those cool functions like the ability to display a live overview of classes and methods – should be delivered to the IDE in a uniform way. Completely decoupled from whatever compiler is being used.
The final build
Once the prototype is complete, tested and made rock-solid — I will look into getting it ported. Since there is a bug in FPC generics (which eric has reported several times) the DWScript compiler and runtime cannot be ported to freepascal, which is really sad since that would allow us to target linux, unix, osx (which is a variation of unix) and windows straight out of the box. So we are left with Firemonkey. This really is a problem because synEdit have yet to be ported to that platform, and also actions are not implemented under firemonkey (hence my question to pawel at the firemonkey presentation expo in oslo).
A firemonkey port of synEdit is really, really needed at this point (so if anyone is up for a challenge, there you have it).