Grateful for the Xojo IDE

I use Xojo every day and it’s almost my exclusive development tool.  I’m so close to the product it is easy to see the warts of the product but in reality it’s a pretty stable and easy-to-use system that’s mostly good for beginners and experts alike.  The documentation, while not perfect is useful and the example projects are decent as well.

I came to this conclusion after a couple of recent projects have taken me into xCode and Eclipse.  Where to even begin comparing these IDEs to Xojo is challenging because they are both similar and so different than Xojo.  In xCode I was porting some iOS Objective-C code to Xojo and working with a hardware library.  Eclipse is used by my son’s FRC robotics team to develop software for their robot.  In each case I’ve wanted to pull (what’s left of) my hair out.

I guess one of the biggest differences is that sheer number of options you have in both xCode and Eclipse.  So many options, I posit, that it’s difficult to figure out what they all do, and make it hard for beginners (like I was a few weeks ago) to get going.  I don’t make any claims in knowing them any better now than I did a few weeks ago either.  I got them to work and I simply left them in that state with the hopes that no future update wipes them out.

Don’t get me wrong, I’m still not the biggest fan of the Xojo IDE in comparison to the old Real Studio IDE.  This is mainly because of the Navigator and how spastic it’s been since it’s initial release.  Thankfully it’s working pretty well in the latest releases and I find myself not swearing at the IDE much.

I also know the plan is to make the Navigator work closer to the old project tab in Real Studio.  Truthfully, I’m looking forward to it and dreading it at the same time.  I *think* it will work better than the current system but I won’t know until I use it.  And by the time we use it, it will already be too late to make any significant changes.  I dread that we’ll be faced with some awful bugs that will take time to work out and I also dread that the workflow might actually be worse than it is now.  We just won’t know until it’s put in front of us.

Are there other things that I wish the Xojo IDE did differently?  Sure.  I despise defining methods in the tiny Inspector whereas in the Real Studio IDE it took up the entire width of the Code Editor.  I also wish there were faster ways to define methods since I’m forced to use the UI to do so.  You figure after 15 years of doing this I pretty much know how to do it by now.  Alas, I have no other option than to use the UI.

Some of the other editors are like this too.  The Constants Editor requires too many mouse clicks to work right.  I want more “hands off the mouse” options.  As far as I can tell, the Menu Editor has no keyboard shortcuts as well as FileTypes editor.  In both cases, I would almost prefer a Plist type editor.

From a simplicity standpoint, though, Xojo is easy to use and doesn’t let you do too many stupid things.  I wish some other IDEs would take that approach for newbies, but then I guess their approach is to throw people into the deep end and let them sink or swim.  Xojo  tries to be helpful in that regard.

Other IDEs have some cool features.  What features would you like to see copied from other IDEs into Xojo?

Remote Debugging Enhancement Idea

Remote Debugging in Xojo is perhaps one of my favorite features in Xojo because it lets me work in the environment of my choice (macOS) and run it on any Windows, Linux, or even another Mac on my network, or in my many VM environments.  One of the things that’s always bugged me about remote debugging is the cycle time.  Every time you do a remote debug the IDE sends everything (executable, libraries, resources), again, to the remote debugger.  Even a simple change requires that the entire package is transferred to the remote debugger.  Every.  Single.  Time.

Xojo improved the cycle time for deploying web apps to Xojo Cloud in 2016 Release 4.  They did this by caching the framework and plugin libraries on the Xojo Cloud server.  When connecting to the Xojo Cloud server it tells the IDE what frameworks and plugin libraries it has and the IDE then decides what to upload.  So your first upload may take four or five minutes but subsequent uploads using the same version of Xojo take considerably less time.  In my case it’s about a minute.  It’s a welcome speed up.

In remote debugging, large projects can often take a LONG time to send simply due to their size.  I find myself debating on whether to install the IDE in that environment (along with prerequisite plugins), or to simply wait through the remote debug cycle.  Sometimes it’s a wash, but, I’ll be honest, it’s irritating to spend the three minutes transmitting to the remote debugger only to have to quit almost right away and change a label or a single line of code, only to have to sit through the transmit time again.

Why can’t they do the same thing for Remote Debugging that they did for deploying to Xojo Cloud?  Think of the time savings this change could do for someone that does a LOT of remote debugging like I do!

Time savings aside, there ARE some drawbacks.  The first is that the Remote Debugger becomes a much more complicated mechanism than it already is.  Since much of the code is (presumably) portable from Xojo Cloud to the Remote Debugger this might be a moot issue.  However, converting from whatever they’re using on Xojo Cloud (presumably Xojo) to desktop use may not be trivial.  It’s hard to say without asking that question.

Secondly, it would have to store all of these libraries and frameworks in a cache and then what would you do for cleanup?  When it quits delete these caches or keep them around?  I could argue for both ways.  Perhaps that’s a preference setting with maybe a quick calculation on how large the current cache is?

Third, it distracts from 64-bit Remote Debugging.  Maybe.  If I had the choice I’d love both, but if it meant delaying 64-bit for six months I’d rather have 64-bit now.  This is a wish list item, after all.

I created Feedback ID 46848 to get this idea into circulation.

What do you think about this idea, Xojo Developers?  What other pain points do you have with Remote Debugging?