XDC 2014: Future Hints

In my last post I talked about what version 1 of the new compiler is going to accomplish in the first quarter of 2015.  It’s a great first step and with any switch to a newer, better technology it means some things will become easier to accomplish.

In Joe Raneri’s Compiler session he talked about several new things that the new compiler might be able to do.  I will stress the might bit.  If it doesn’t happen don’t say they promised it.  🙂

Autocomplete:  The current autocomplete mechanism in Xojo is completely separate from the compiler.  It’s possible with the new compiler these are unified.  This would be great because the autocomplete code pretty much duplicates what the compiler does since it needs to process the same level of information.  I’ve been told there are dozens of autocomplete classes in Xojo.  If the compiler can process some of this information perhaps autocomplete will be even faster and more reliable.

Debugger Tooltips:  I’ve wanted this one ever since I moved to Xojo from Visual Basic.  While in the debugger it would be very cool to get the value of the variable you’re hovering over to get displayed in a tooltip.  The current object viewer in the debugger is less than ideal and I really despise using it.  I always seem to be fighting it so being able to hover over the variable to get its value would be a very welcome addition.

Xojo Plugins:  This is the long term, and only, approach to getting plugins on iOS.  Currently iOS does not allow dynamic libraries so until Xojo can create plugins, developers will have to use declares into the iOS frameworks.  This is less than ideal so the new compiler will allow iOS developers to create plugins entirely in Xojo code.

I believe that, at least for iOS, Xojo plugins is a definite.  How this affects desktop remains to be seen but what it would mean is that developers would not have to create plugins using C.  What we don’t know is what happens to the current plugin SDK.  Does it get deprecated or does the new way get more/better support over time until no one’s using the old SDK?  Only time will tell.

Other:  A few of the other possibilities that Joe shared that the new compiler might be able to do for us:  better refactoring tools, source indexing (e.g. finding the callers of a method), and more platforms or architectures.

The new compiler is a big deal and it’s been many years in the making.  Some of things that might come out of it are exciting.  It’s my opinion that if Joe is saying these things at lease some preliminary work has been done, or at least some preliminary proof-of-concept code has been completed.

What are you most excited about?

The Real Studio Debugger

We all know by now that Real Software is redesigning the Real Studio IDE. For better or worse it’s coming whether we want it or not. It would really be nice if they changed the debugger to be more useful. Real Software last changed the IDE for the 2005 release and, in my opinion and many others, the debugger was a huge step backwards in usability.

In my opinion, and the feedback I get from other users, is that the Stack popup menu is not intuitive at all. In the old IDE it was a listbox which let you see, at a glance, what the call stack was that got you to the current breakpoint or exception. The popup menu is not intuitive. It confuses users. I say bring back the listbox.

As Merv pointed out in my last blog post, setting a breakpoint is sometimes an exercise in futility. The area to set the break point is maybe 8 pixels wide? Why not double the size? The UI shouldn’t be designed for 800 x 600 windows any more. Most monitors have much more width space than they used to. Make this more user friendly.

Many, many people have begged for Watchpoints in the debugger. In fact, the Feedback <feedback://showreport?report_id=1095> is currently at #13 and was entered in 2008.

An even bigger request is to have the debugger show a value tooltip while debugging. This means that if you hover your mouse over the variable ‘i’ the tooltip will show the current value. This one is at #7 and was entered in 2009.  <feedback://showreport?report_id=10536>

Make these feedback items part of your Top Cases and show Real Software we really need them.  My bitching about it won’t change it.  Only your votes can give them any indication what you want.

Now, I have no idea what changes they have in store for the debugger. What I do know is that they’ve already said the first release will not have ANY changes to it.  This is too bad but I don’t want to wait five years for a better debugger!

So my question is why do we have to wait for so long to get needed and wanted changes? What else do you think should be part of the debugger?