Please support a feature request for improving the IDE with external tools

I (and hopefully others) have some ideas on how to add features to the IDE with external programs.

To make that work, the IDE needs some improvements.

Please support this feature request if you like that idea: <>

I like the idea very much but I’d rather it not be IDE scripting. Xojo could provide an encrypted class that our apps talk with and the class handles all the IPC comm. The class would have methods like GetProjectItems() As IDEProjectItem(), addMethod(c As IDEClass, m As IDEMethod), replaceSource(method, newSrc). They can manage the classes and make sure it talks with the IDE correctly and it’d be less fiddly than IDE scripting.

Either way any functionality in this direction would be great.

I would prefer if Xojo switches to move the compiler into separated tool and we could write our custom shell file to build stuff.


There is also a request for IDE plugins to intercept the code going to compiler and modify it.
But I can’t find it.

But this one is also interesting:

The Feedback 3215 would be very useful. I totally agree with this proposal of Will (in Feedback 3215) :

[quote=266488:@Will Brokenbourgh ]If REALbasic was released with an external compiler, users would have more flexibility in the type of development environment they could use to develop apps with. The REALbasic IDE could still be used and would still be the primary development environment for RB.

I’m not proposing that the compiler should be a separate product, but just separate from the IDE, this way users could generate source in their favorite environments, then invoke the compiler directly, through scripting or macros.

Of course, the compiler would need to check for proper licensing and generate the appropriate binary for whatever level of license the user has (demo, standard, pro).

The compiler would need to return useful error messages for debugging purposes, either through the command line, through a socket or both. Also, the compiler would need to accept both text source files as well as RB’s binary project file format.

Documentation would also be necessary for the compiler so users and the community could develop full-fledged alternative IDEs or interface with existing community development tools.[/quote]

Finally, I think the most important is that Xojo can use standard text files (only the code entered , no additional tags) . Next, using an external compiler or the IDE.

It would also allow Xojo Inc. to be better known of the younger generations (many young developers hate all IDE) and benefit from the extraordinary current emulation between the language editors (Atom, Brackets, Visual Studio Code, Intellij IDEA, Light Table, SublimText, etc.).

These editors benefit from hundreds of plugins. They are very rich, open, very fast, very pleasant to use. With a Xojo package/plugin for autocompletion and compatibility, that would be great. Many developers are now using these types of tools for code entry. Then they switch on a IDE to compile, debug, deploy. And the development of plugins and external tools is easier.

It is true that this type of editors is more suitable for the flexible and non-compiled languages, but they also have an interest in compiled languages.

Christia and Olivier, they are valid points, even if I don’t fully agree with them, but that’s really off-topic. Please don’t discuss general improvements on this thread here. Those suggestions by Christian are way more involved than the one I proposed, and I don’t want to get the focus off my comparatively easy-to-implement improvement request.

And on Will’s comment: But such a class still needs to talk to the IDE, and IPC sockets are the only way for that, to my knowledge. So, first we need to have working what I’ve proposed, and then we or Xojo can built on top of that.

This was a goal of mine from the day I started working on the “Houdini” compiler project back in 2001. (Before that, even, I suppose - the Object Basic compiler “Oasis” worked the same way.) The compiler engine was always designed to convert plain text source code input into machine code output, independently, without needing to be part of a big complex IDE. There is a sizable IDE apparatus which renders its internal data structures down to text, solely for the compiler’s benefit, because the compiler requires all of its input to be expressed in the form of source code. This isolation created some significant performance issues during the compiler’s early development, and if I had it to do over again I wouldn’t do it the same way - but that is in fact what I did back then, and that means that the architecture necessary to do what you are requesting has existed for a long, long time.

During many periods of my tenure at REAL Software I actually had a private build of the compiler in the form of a standalone command-line executable, which I would use for testing. It was not a shippable tool but it was the same general idea that people are describing in this thread. This capability was never released to the public because I could never make a convincing business case for it. I always hoped that someday we would be able to offer a plain text source code interface to the compiler, so that people would be able to extend the language, IDE, and tooling in any way they pleased and the ecosystem would therefore be able to take off and grow in a way it never can when everything must be implemented by a single organization, but I was never able to persuade the people making these decisions that this was the way we should go.

So far as my experience goes, then, I suggest that you shouldn’t worry about the technical side of things at all. Instead, focus entirely on convincing Xojo that this direction makes good business sense. More than likely the engineers who would be in charge of building such a feature have had plans in their back pockets for years, and need nothing more than permission to move forward - because that’s the way compiler people tend to think about these things.

1 Like


Are you back working for Xojo? You have Xojo Inc next to your name.

  • Karen

No; I work for Synopsys, developing the Coverity static-analysis tools. Not sure what the web site is doing or why it would be suggesting that I am still connected to Xojo.