Xojo 2013 Release 1 is the biggest change to the Real Studio IDE since 2005 when the modern REALbasic/Real Studio IDE was introduced. The User Interface, while still relatively familiar, has been changed throughout the IDE. Some changes are blatantly evident and some look almost exactly as their Real Studio counterparts but regardless of looks almost everything was rewritten.
In addition to the major UI changes the Cocoa framework has been worked on extensively. The Xojo IDE is compiled for Cocoa (on Mac OS X) and the beta tag has been lifted from Cocoa (yay!). For many applications you will have to make few if any changes but if you’re a heavy user of threads it’s likely you’ll have your work cut out for you with the new ThreadAccessingUIException.
Without further ado, here is my review of Xojo 2013 Release 1. I have some opinions and some pretty strong ones. Expect a few in this review. 
Project Chooser 
Starting up Xojo is a bit faster than Real Studio. Optimizations were made with the documentation and a new plugin format makes this a less onerous task. When you start Xojo you’re presented with a new Project Chooser that lets you select the type of build (Desktop/Web/Console) you want. You have the ability to input some data up front but it’s not mandatory. The project chooser also has a way to quickly get to the example projects.
Workspace
Navigator
Gone from the IDE is the Project Tab. In its place is a new Navigator that contains every item in the project as well a Build Settings. These two groups can be collapsed and expanded independently. When run your app in the IDE an additional section called Run is added that contains the debugger interface. Once you stop this section disappears.
Content Section
The Content Section contains all of your project items. This hierarchal list shows everything. Every window, class, control, subclass, module, method, event, property, constant, structure, menubar, menu item (and more!) can be found in this list. Open a Window to see the sections it contains whether that be constants, controls, methods, properties and events (more on events later). Expand the individual sections to drill down into their contents.
As you select the various objects the appropriate editor is loaded into the center pane. Click on a window and the layout editor appears. Click on a menubar the menu editor appears. Click on a constant the constants editor appears. Click on a Method and the code editor appear. You quickly get used to the right editor showing up at any given time. As with Real Studio there are some funny things happening with the focus so to select an item in the Navigator it sometimes takes two clicks.
At the top of the Navigator are several controls to aid you in the search of your project items. In the Filter field you can start typing the name of the item you’re looking for. This is convenient if you already know the name of the item, but not so good if you don’t.
Double clicking on an item will drill down into that item and only that item is shown in the list. Just below the Filter field is a Jump Bar that allows you to do a couple of things. On the far right is a set of left and right arrays that let you navigate the hierarchy of the object you’re in. On the left the current item is named and has a disclosure triangle next to it that displays a popup menu of the hierarchy allowing you to quickly navigate back to the top level or any level in between.
One of the goals in Xojo was to eliminate tab management. If you really want a tab you can easily open the entire Navigator/editor structure into a new tab. Simply right click on any item in the Navigator and select the Open in New Tab command. There is also a Preference setting to allow a double click of any object to open in a new tab. Some users may find this a more comfortable transition (I know I did).
The Navigator has some very handy features that the old Real Studio IDE didn’t do. For one, you can select multiple items at the same time. Have ten methods you want to copy and paste into another object? Simply select the items you want, copy them, and paste in the new location.
One item of note here. Keyboard handling can be tricky with copying of objects so I’ve gotten into the habit during the beta period to use right-click to copy items. It is my belief that as this UI matures most of these inconsistencies will disappear.
Drag and drop from the Navigator is also possible in some editors. For example, if you had a subclassed control (say a listbox) and found it in the Navigator you can drag and drop the subclass into your layout editor. Since the Library doesn’t contain your project items this is the best way of adding subclassed controls to our layout (though you can always drag the original and then change the super).
One of the more annoying things the Navigator left out from Real Studio is that it doesn’t display super or data type information or interfaces. You can get that information by selecting the item and looking at it in the Inspector (assuming the Inspector is open). You can also see this by hovering your mouse over the item until the tooltip appears which gives you the missing information. Regardless, both methods require additional work and are less than ideal.
Build Settings Section
Gone in Xojo is the Build Settings dialog. The replacement is access through the Build Settings section of the Navigator. In its place there are now 4 new sections allow you to access various settings. The Shared settings replace much of what was in the Application object in Real Studio. The Mac OS X, Windows, Linux, and This Computer sections let you change the settings for their respective platforms. The platform options look like CheckBoxes in the list and, indeed, are checkboxes that tell Xojo which platforms to build for.
Run Section
If you decide to run the project from the IDE a new section appears on the Navigator called Run that contains one entry and that’s the debug instance of the application. This is where you’ll see the slightly redefined runtime debugger. The debugger is really just another editor and to start, stop, step into and out of code you have to go find the Run section and select the running application.
If you have multiple tabs open the debugger will always run in the first tab. If you happen to close that tab the debug application is killed. If you profile your application, the profiler instance will reside in the Run section. More on Profiling later.
Toolbar
The main Xojo toolbar contains commonly used commands. The toolbar is not customizable yet so you’re stuck with the big icons with text.
Insert
The Insert toolbar button is a menu button that mirrors the menu items in the Insert menu that’s located in the MenuBar. This is the primary way to add things into your project. You’ll use this button (and menu) quite a lot as you’re developing your applications. In addition to adding objects, it’s also another way of adding events to objects (more on this later).
Another place the insert menu is available is in the right-click (Contextual Menu) of the Navigator. Right click and along with numerous other options the Insert menu is available. If you don’t want to move the mouse to the toolbar or menubar this is a good option.
Back/Forward Buttons
The back and forward buttons let you quickly navigate the history of each tab. So if you look at the application object, then drill down to the App.Open event, and then go view a window the back button will take you to each of those. This was a rather late addition to Xojo since so many people had complaints of ‘getting lost’ in the Navigator. The history buttons definitely help out in this regard.
Run
As with the Real Studio IDE, the Run button starts a debug session. The compiler will start up and if no errors the Debug panel is loaded waiting for an exception or breakpoint. At this point this is also when the Run Section is added to the Navigation list.
Build
The Build button creates non-debug builds based on settings. It will invoke the compiler as well. Errors will be shown in the Errors pane (if there are any). The Errors pane appears at the bottom of the screen.
Help
The Help button invokes the Xojo online documentation that lets you access the Language Reference and all other documentation. A preferences setting lets you choose On-Line or Local documentation.
Feedback
The Feedback button opens the Feedback application. Feedback is THE way to report bugs to Xojo Inc (after searching for existing reports) and to put votes toward those reports you want Xojo Inc to implement faster than others.
Library
The Library button shows/hides the Library pane. If the Inspector is visible it will replace it.
Inspector
The Inspector button shows/hides the Inspector Pane. If the Library is visible it will replace it.
Library
In the Real Studio IDE the control palette was available for Layout Editor. In Xojo it has been replaced with the Library panel and you get to choose when this is visible. In the Xojo toolbar is a Library button that shows and hides the Library. As with many things in Xojo this area has been completely redesigned with a number of options.
The first option is that you can view all controls or a subset at any given time. Subsets are things like buttons, controllers, decor, indicators, etc. Moving the mouse over any of the items in the list loads a brief description of that control into an information pane located at the bottom of the Library pane.
This Library list itself has a number of options that allow you change the view. You can see the list as large or small icons with or without labels. You also have the option of grouping them by category and sorting them alphabetically or not. In addition to all that there is also a search field at the bottom of the Library that filters out controls based on name.
After playing around with settings for a while I settled on Small Icons with Labels, No grouping, but sorting alphabetically. This as close as I come to the Real Studio control palettes. I’ve also been finding myself using the Library search rather than trying to find it in the list.
One of the major things that the Library does not do that the old Real Studio control palette did is show you any subclassed controls. Instead, the thought is that you can find any subclassed control in the Navigator and drag and drop it into the layout editor.
Inspector
Properties Panel
The old Real Studio properties list was very powerful. It let you change and and all properties via the keyboard and you never had to touch the mouse. In Xojo, the properties list has been replaced by the Inspector. It is not keyboard friendly so expect to use the mouse to set some of the non-text properties (checkboxes, sliders, color pickers, lock positions, popup menus, etc).
Another missing feature is the ability to use dynamic constants for certain properties. In Real Studio you could make a dynamic constant for a color and use that constant in the properties list. In Xojo this is impossible and to do something similar you’ll have to resort to the open event of the control. This seems to be a huge oversight in the design of the Inspector.
The Inspector, in my opinion, is one of the big weaknesses in Xojo. So much power and functionality was removed that I hope they really rethink their decisions. Among some of the UI faux pas in my opinion was the use of sliders for boolean values. They look cool (with animation!) but they don’t really add much to the product. They take up more vertical room than a regular checkbox and thus require more vertical spacing so they don’t look crowded. Their usage is inconsistent as well even in the Inspector. Some boolean properties use a slider and some use checkboxes. I’d prefer one or the other but not both.
The vertical spacing used in the Inspector makes large lists hard to deal with. For example, the desktop Listbox control has a lot of properties and it is impossible to see the entire property list without scrolling even on a large display. I expect this issue to be even more glaring on a laptop with limited vertical real estate.
Attributes Panel
The second part of the Inspector is the Attributes panel. Attributes are a more advanced feature that most developers won’t use. It has a simple interface to add attributes as well as boolean sliders to mark whether to include the object in Desktop/Web/Console builds.
Library/Inspector
One odd feature in Xojo is that the Library and Inspector cannot be open at the same time in the main Xojo window. There is a preference setting to make them palette windows but that’s not exactly ideal for many people. The reason I find this so distasteful is that in Real Studio I put a control on the layout and then immediately name it (we never use the default names except for labels that are never referenced in code).
To do the same thing in Xojo I have to open the Library, place the control, and then Open the Inspector. Then I have to place my cursor in the Name field which usually requires two clicks to select the entire name and then put the new name in.
This change isn’t a huge deal but it is irritating because it changes my workflow. What I have to do now is put all my controls on the layout and then open the Inspector and rename the controls. Like I said, it’s a simple thing but I’d love to have the ability to have the Library and Inspector be open at the same time (not in palette windows). I’d also love to have the option to put the Library or Inspector on the left side next to the Navigator.
Panels 
At the bottom of the Xojo IDE is a new area for panels. These panels let you search the project, see error messages, and to show system messages. The panes can be resized to some extent but there’s a vertical limit that can be kind of annoying.
Find
The Find panel takes the place of the Real Studio Find dialog. It allows you to search and replace anything defined in the scope which depends on the item selected in the Navigator. Otherwise it is very similar to the Real Studio find and replace mechanism. Doing find and replace in the current method requires selecting that option from the control widget. Again, not very onerous but it is yet another mouse event.
Errors
When you compile your project or use the Check function any errors or warnings are displayed in the Errors pane. It is displayed automatically when it is needed. The functionality of the Errors pane is nearly identical to the Real Studio errors tab.
Messages
New in Xojo is the Messages pane that shows you any System messages your app may have generated. This includes anything sent to the System.DebugLog which is handy. A convenient search field lets you find specific messages quickly.
Layout Editor
The Xojo layout editor does not have many new changes other than both Web and Desktop editors look and feel like the Real Studio Web Edition layout editor. Despite it working there are some changes that you’ll have to get used to.
Shelf
One of the more welcome changes was the addition of the Shelf where non User Interface controls, such as the Timer, or Socket controls live. No longer do you have to figure out where to put those pesky controls. The IDE now puts them there automatically.
Non-UI controls also included Toolbars. Adding one to a Window places it on the Shelf. This might be the one control I really want shown at the top of the window as a visual aid. After all it HAS a user interface and see what it contains is sometimes important. Not a huge thing but as someone who uses toolbars a lot this is a drag.
Inline Editors
Like the older Real Studio Web Edition layout editor, both the Desktop and Web layout editors for Xojo have new inline editors. The inline editors are small editors you invoke directly on the layout that let you manipulate the control. For example, if you place a pushbutton on a window there is a small circular button with a pencil icon on the right side. Click that and an editor appears right next to the control allowing you to change the button caption. More complex controls like the Listbox have more complex inline editors.
This is another instance where some functionality was taken away. In Real Studio if you placed a pushbutton on a window and started typing, whatever you typed would become the caption. This was a very convenient way to get things done. In Xojo you can’t do that and you’re forced to either use the Inspector or use the Inline editor.
Adding Events
Perhaps the biggest change in the Layout Editor is how you access events to an object. Recall that in Real Studio every event for every control/object is available at all times. This is no longer the case in Xojo and you have to add the events you want to use.
The mechanism for adding events is a little weird because it depends on if the control already has an event handler or not already. If it has no event handlers yet, double clicking on the control will invoke the Add Event Handler dialog. The dialog then displays a list of all the available events for the object. If you need more than one event you can select one or more events by holding the modifier key or shift key to select the ones you need.
However, if you already have an event handler for the object double clicking on the control drops you down into the Code Editor for the event (which one seems to not always be clear). To add another event you have multiple options. The Insert toolbar, menu, or contextual menu all have Add Event Handler options. Selecting it invokes the dialog again.
The dialog itself has some interesting features in that as you highlight events a brief description shows up on the right. If you select multiple events (whatever the standard platform modifier keys are for list boxes) the dialog will attempt to display descriptions for all the events selected.
I see this area as being the most controversial and perhaps generating a ton of questions from those new to Xojo. Adding and using events was always one of the most appealing things in Real Studio and that now takes extra work to use them in Xojo. It’s not a lot of extra work but I can see it generating some questions.
In my opinion the biggest reasoning for forcing the user to add events in this fashion was because of the Navigator. Since the Navigator list can get rather large on even small projects having every event available for every object would just make the Navigator worse. So the obvious solution to help the Navigator was to limit the events it shows. Voila! Force the user to pick which events they want.
To be honest for some controls I absolutely love this decision. Label’s are one of those controls that has 18 events that I rarely ever use. However, some controls, like the timer have only one event and to use it I absolutely have to add that one event. So the dilemma for Xojo going forward is to how to make this feature more useful and smarter for all of us.
Code Editor
The Xojo code editor is mostly the same as the Real Studio code editor in appearance and functionality. In reality it’s a completely rewritten editor mainly because the entire IDE is a Cocoa application (on Mac OS X, of course). The code editor is a canvas subclass and in Cocoa applications the canvas control cannot get the same keyboard input as regular text fields. This led to the creation of the Text Input Canvas plugin that lets Cocoa applications get the same level of keyboard information (more on this later) for non-text controls (i.e. the canvas).
The one big change in the Code Editor is that to define a new Method you absolutely must have the Inspector visible. In Real Studio you defined the method name, parameters, scope, and return value at the top of the Code Editor. Now those are defined in the Inspector. Moving all this to the Inspector makes sense from a consistency standpoint but the Inspector is generally a much smaller area so now long parameter lists are cramped into a much smaller and less usable text area.
When you define a new method the Inspector shows if it’s not already shown. The method name field is highlighted allowing you to type the new method name. Hitting tab takes it to the Parameters text area. Hitting tab again *should* take you to the Return type but at the time of this writing it inexplicably puts the focus in the text editor.
Moving the definition into the Inspector one of the more annoying changes. Moving my eyes from the Navigator where I’ve decided I need a new method to the extreme right to the Inspector (or wherever it’s at as a Palette window) is a bad design. Not only is there massive eye movement but moving the mouse from one edge of the screen to the other just seems silly (the tab control bug withstanding).
Tab Editors
Web Edition Tab editor 
The tab editor for Web Edition is using the same tab editor used in Real Studio Web Edition. It’s an easy editor to figure out but if you have a ton of controls it can quickly become a mess. Otherwise, it’s exactly the same.
Desktop Tab Editor
For many people the existing Tab Editor for Real Studio (desktop) was a capable editor. It’s one big deficiency was that if you had to add a control at the beginning of the tab order you ended up renumbering a lot of controls. The Web Edition tab editor doesn’t work very well in desktop since Web Edition applications have no concept of parent controls. So Xojo takes an alternative approach by using a hierarchical list to display the contents of the window. The user can then simply drag reorder the controls in the order they want. Non-tabbable controls do not appear in the list. It’s simple but it works.
Menu Editor
The Xojo menu editor has been modified to fit in the Navigator. Besides having the menubar itself in the Navigator each individual Menu and each individual Menu Item is also in the Navigator letting you select it directly from there or through the editor itself.
Having items in the Navigator *should* make it easier to copy/paste/duplicate menu items but as I write this review that functionality is currently not working.
Database Editor
I was not a fan of the Real Studio database editor. I recommended that you don’t use it because it led to some bad practices because it wouldn’t let you define your own auto increment primary key for a table you created.
The Xojo Database Editor is different though I still can’t say it’s improved. It still has most of the same flaws as the Real Studio database editor. So until Xojo, Inc. decides to get serious about the DB editor I recommend not bothering to use it. There are much better free or inexpensive tools to manipulate your databases and I’d recommend using them rather than the Xojo Database Editor.
Constants, Enums, Structure Editors
Much like the Code Editor the constants, enums, and structures editor has changed so that the definition is forced into the Inspector. Editing individual items then takes place in the center editor. I have no problem with the editors in and of themselves but forcing them to use the Inspector seems like a solution waiting for a problem to fix.
Profiler
The Xojo Profiler was rewritten for Xojo and now handles threads much better. The Profiler has some nice features to make it easier to figure out what code in your app is taking the longest.
Invoking the Profiler is different than in Real Studio where it was a menu option. In Xojo it is a boolean option in the Shared Build Settings section that is reached via the Navigator
Project Formats
The file extensions in Xojo have changed to accommodate the new name change and to help avoid collisions in the future (how many times did you double click on an .rb project file in Mac OS X and it opened Xcode?) with other languages. So now the default file extension starts with xojo and then an identifier with which type it is.
The three formats available to Xojo are Project, Binary, and XML. If you have any valid license you can use any format. If you are using the IDE without a license you can only save in the binary format (though read any of them).
Xojo Project (text)
The new default project type is the Xojo Project file type. It is the Real Studio version control format and a file is created on disk for every object in your project. This is awesome for version control systems that scan the files for changes and then save ONLY the changes it detects.
Xojo Binary
The Xojo Binary format is similar to the old Real Studio binary format. Many people use this format for the ease in transporting projects.
Xojo XML
The Xojo XML format is similar to the old Real Studio xml format.
Cocoa Framework
The Cocoa framework is finally done and the beta status is ready to be taken off the build option. Why am I so confident of this? Because there is somewhere in the neighborhood of 125 Cocoa bugs that have been fixed for Release 1 and Xojo itself is a Cocoa application when running on Mac OS X. Building for Carbon is still an option but don’t expect a whole lot of fixes for Carbon going forward and part of that is simply because Apple is not fixing many Carbon bugs. Cocoa is the wave of the future so you should really start using it and, to be honest, in my testing it’s been solid. I should note that the carbon build option isn’t going away anytime soon but the clock is ticking.
Not everything is a perfect in-place upgrade. A new runtime exception has been added to Xojo for any thread (other than the main thread) that accesses a user interface object. The new UIException is thrown whenever you try to access literally any part of the UI. Trying to create menu items at startup in a thread? You can no longer simply create new MenuItem objects and add them to a menu because it will generate the UI exception. You can generate the exception even by simply accessing the properties of a control at runtime.
For years Real Software (now Xojo, Inc.) said that doing so wasn’t safe but most of us did it anyway. Now Xojo enforces the limitation. The workaround is to add events to a thread object which fire timers. The timer action events fire on the main thread letting you do your UI work there. There is a new example project under Projects -> Desktop -> Threading -> Tasks that you should probably take a look at.
SQLiteDatabase
The REALSQLDatabase class has always really used SQLite in the background. However, based on decisions that were made many years ago, the REALSQLDatabase class did a number of things that were less than ideal. For one, it inserted the rowid into many of the SQL queries. While most queries never noticed the addition there were occasions where it really messed up the underlying query.
In Xojo 2013 Release 1 the REALSQLDatabase has been deprecated and a new SQLiteDatabase class has been added. The new class no longer inserts the RowID into queries for you. If you were relying upon this (I highly recommend you do NOT) you can insert it yourself.
Another change in the new class is that it no longer has the AutoCommit property. Xojo will treat all database actions as an implicit transaction which means that the commit will happen automatically unless the user specifically starts a new transaction.
Also new in the SQLiteDatabase class is the ability to backup your SQLite database while it is open. This is a convenient way back up your database during runtime without having to close connections and copying the file. While the backup is occurring it will block other database operations but otherwise it won’t throw an error.
Remote Debuggers
Desktop
Xojo comes with an updated Remote Debugger (GUI) application. It is now at version 2.0 and has the same functionality is the Real Studio version.
Console
New in Xojo is a Remote Debugger Console application. The new console debugger can be used to remote debug console and Web Edition applications on headless servers. In my initial testing the UserGuides aren’t quite as helpful as they could be on how to setup and use it in conjunction with Xojo. I’m sure the documentation will get better but in the meantime good luck in getting this working!
New Licensing
If you have not heard, Xojo is now free until you want to build a final executable. Then you need a license for the what you’re building for. I won’t go into much detail on this since it’s been documented at http://www.realsoftwareblog.com/2013/04/coming-soon-new-pricing-recap.html
For many developers their license costs will go down. For those that are current Enterprise owners the price will most likely go up a little.
Control Sets
One thing that’s changed in Xojo is that Control Arrays are replaced with Control Sets. They are really the same thing but the naming threw people off (myself included for many years) because we heard ‘array’ so we expected that we could use them like a normal code array. Since you couldn’t the switch was made to rename them control sets.
The change has caused a few minor changes to the Inspector so that you can tell Xojo which control set it’s a part of and what its index is in the set. Naming a 2nd control the same name as another control invokes a dialog asking if you want to create a control set.
Plugin Format
Xojo plugins are now really zip files. The old format used the considerably slower Virtual Volume. This speeds up the startup of Xojo drastically. You can use old style .rbx and new style .xojo_plugin at the same time. Monkeybread users will want to migrate to the newer xojo plugins to take care of incompatibilities. Most of the major plugin vendors have migrated to the new format.
Text Input Canvas Plugin
Cocoa is a different beast in many ways when it comes to text and keyboard handling. Carbon applications give you a bunch of additional information for free as part of Apple Text Services that gives you (for free) special character handling. Unfortunately in Cocoa this mechanism is completely gone.
We’ve already talked about how the Code Editor is a special canvas subclass. It was suffering from the lack of information and there was no way around it. Xojo Inc has produced a new open source plugin that allows you get all of the events you need to capture special text handling. It does this by introducing a number of new events that your canvas subclass will have to take care of.
We, BKeeney Software, have been beta testing the Text Input Canvas plugin in the Formatted Text Control with great success. Once Xojo Inc. releases the plugin we will release version 3.1 of the FTC. It will also prove to be an ideal example of how to parse the new events and commands that the plugin requires and uses. Expect this plugin to be released soon after the Xojo release.
One Click Hosting
Xojo Inc announced the June 4th release date at the Xojo Developer Conference. This was roughly 24 hours before their web server got hacked. The hack caused them some delay in getting those services back online and forced their migration to their new Xojo Cloud server. Delaying the release again was out of the question so the One Click hosting has been delayed and it will enter beta at some point after Xojo Release 1.
Documentation
Xojo has completely new example projects and completely new documentation. All of the example projects have been rewritten to use the file formats as well as the new Xojo classes. The examples have also been reorganized to make things easier to find.
The documentation for Xojo is quite impressive. The standard download package has 9 PDF guides ranging from QuickStart guides for Desktop and Web, to Tutorials for Desktop and Wb, and UserGuides for Development, Framework, Fundamentals, and UserInterface. In addition to all of that Xojo comes with a PDF and iBooks version of the Upgrade Guide.
If you read no other documentation about Xojo I highly recommend reading this book. It contains more in-depth description of many of the items I’ve talked about today and contains additional screenshots.
Conclusions
There are many, many reasons to like Xojo. A lot of thought and care has gone into many of the design changes. There are some areas of improvement such as keyboard handling and some workflow issues that they’ll have to change to satisfy Real Studio old-timers such as myself.
For Windows and Linux users there is less to be happy with. The UI is identical on those platforms (minus animations) and looks even more foreign on those platforms. Linux and Windows users should not expect many changes to the frameworks for those platforms. This release all about Cocoa and the new UI.
Xojo Inc. has put a lot of time and effort into this release. I admit that I am, and will continue to be, critical of the product. It is, after all, what supports me and my employees. I will say this though: Xojo is much better than I had feared but not as good as I had hoped. For my own consulting company all new projects going forward are using Xojo. Existing projects will move forward under Carbon in Xojo unless they use no threads in which case they’ll be converted to Cocoa.
Please let me know your thoughts about Xojo!
