Xojo 2013 Release 1

XojoXojo 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 ProjectChooser

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.



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.


The main Xojo toolbar contains commonly used commands.  The toolbar is not customizable yet so you’re stuck with the big icons with text.


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.


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.


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.


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.


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.


The Library button shows/hides the Library pane.  If the Inspector is visible it will replace it.


The Inspector button shows/hides the Inspector Pane.  If the Library is visible it will replace it.


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.


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.


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 ErrorPane

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.


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.


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.


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.


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

InlineEditorLike 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.

AddEventHandlerThe 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

CodeEditorThe 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 WETabEditor

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.

DesktopTabEditorDesktop 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.


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.


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


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.


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.


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.


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!

23 thoughts on “Xojo 2013 Release 1

  1. So, is there any way to dismiss the Find/Errors/Messages panel once it has been opened? I can’t seem to find one.

    Great review and intro to the new IDE. Thanks.

  2. A fair and balanced review, Bob. Regarding adding events, in fact, that came before the Navigator. The problem with the old IDE was that when scrolling through controls in the Code Editor, most of the rows were empty events that you’d probably never implement. So we changed it so that you add the events you want.

    As you pointed out, the new UI is a big change and I’m sure we will continue tweaking and improving it over time.

  3. Geoff Perlman :

    Regarding adding events, in fact, that came before the Navigator. The problem with the old IDE was that when scrolling through controls in the Code Editor, most of the rows were empty events that you’d probably never implement. So we changed it so that you add the events you want.

    Thanks for the clarification. I will admit scrolling through all the empty events was annoying in Real Studio. However, I’ve heard from quite a few people that said they learned the events *because* all of those events were there and in your face. I could see some people being rather upset about this change (I am not one of them).

    You have to admit that having all of the events shown in the new Navigator would make it impossibly large. The Navigator is hard enough to ‘find’ things as it is without making it even longer with unused events.

  4. Geoff Perlman :

    A fair and balanced review, Bob.

    Thanks. I tried to be fair knowing that some things in Xojo are going to evolve over time. Hopefully the things that are most annoying (all the dang scrolling and mouse-only stuff) will be dealt with quickly. If not, then it might get ugly. 😛

  5. Thanks for an excellent blog article!

    To me Xojo is designed for Cocoa and the Apple platform. Xojo looks like something the cat has dragged into Windows. Sorry for not being happy about it.

    I was also surprised to see Xojo lack a chart and datagrid control. I had the impression that it was on the to-do list.

    Despite the above, I congratulation the team to port the business to Xojo and go all in. I think that’s the right move in order to be competitive!

    (Please remove this comment in the RBReport article)

  6. Dennis Wallentin :

    I was also surprised to see Xojo lack a chart and datagrid control. I had the impression that it was on the to-do list.

    I’ve heard various rumblings over the years about an improved datagrid control but I’ve not heard ANYTHING about a charting control. I would highly recommend looking at ChartDirector from Monkeybread. We use it quite a bit and it’s hard to beat since it does almost any type of chart you can imagine.

  7. Geoff Perlman :

    The problem with the old IDE was that when scrolling through controls in the Code Editor, most of the rows were empty events that you’d probably never implement. So we changed it so that you add the events you want.

    Upon further reflection on this I think your logic is flawed. The scrolling in the Code Editor was sometimes an issue with empty events. You could have implemented the exact same Add Event Handler in the old Code Editor for the same effect (of cutting down scrolling).

    Instead, we now have the Navigator that can turn into a freakishly huge list with every single object, method, property, etc. The stated intent was to eliminate tab management. Instead, I’d argue that scrolling in the Navigator is way more confusing and harder than the tab management ever was.

    To manage my tabs I simply closed the ones I wasn’t using which generally were the ones on the left I wasn’t immediately working with. Scrolling requires a lot more thought. And like I, and many others have reported, I get ‘lost’ in the Navigator a LOT. Productivity suffers.

  8. @Geoff Perlman
    I am thankful that the events are selected from a list. When I was starting I did learn a lot of the events from seeing them in view form.

    @Dennis Wallentin
    You know, I’ve read a lot of similar responses about the appearance in Windows. While I agree as far as various sizes are concerned (e.g. inspector), I disagree as far as the overall appearance is concerned. I’m not particularly in love with the standard appearance of any Windows shell. I don’t like it when it’s a strange combination of generic and custom controls. But a unique GUI can be refreshing.

  9. Bob Keeney :

    Geoff Perlman :
    The problem with the old IDE was that when scrolling through controls in the Code Editor, most of the rows were empty events that you’d probably never implement. So we changed it so that you add the events you want.

    Upon further reflection on this I think your logic is flawed. The scrolling in the Code Editor was sometimes an issue with empty events. You could have implemented the exact same Add Event Handler in the old Code Editor for the same effect (of cutting down scrolling).
    Instead, we now have the Navigator that can turn into a freakishly huge list with every single object, method, property, etc. The stated intent was to eliminate tab management. Instead, I’d argue that scrolling in the Navigator is way more confusing and harder than the tab management ever was.
    To manage my tabs I simply closed the ones I wasn’t using which generally were the ones on the left I wasn’t immediately working with. Scrolling requires a lot more thought. And like I, and many others have reported, I get ‘lost’ in the Navigator a LOT. Productivity suffers.

    I agree with Bob on this one. As I have been updating my legacy applications for cocoa, the number one problem in the IDE is the Navigator. It is a mess. It is not scalable and for a lack of a better term it mixes metaphors. In the old project tab you knew what you were looking at in that they were project items and you could open what you wanted in a new tab which would provide instant context for all the items within it. In the Navigator it is all smashed together and you can quickly lose context of what you are editing and this will lead to user errors. The Navigator looks like a solution looking for a problem. The old project metaphor is clearly superior to the Navigator and didn’t need fixing.

  10. Despite all the teeth gnashing about the GUI in the Xojo IDE I’ve found built apps to be solid. I’ve not had any issues (that I can remember at least) that affect built applications. So from *that* aspect I am happy.

    If the underlying framework had issues it would be a disaster. They can fix the GUI issues relatively quickly (I think). Framework issues seem like they would be harder to fix (more regressions testing?) and take longer to release.

  11. I’ve only briefly tested Xojo on my work notebook, which is a 64-Bit Win7 machine. Xojo, which can’t hide the fact that it was made for Macs, felt completely alien on Windows. While I could live with that, I could not live with the fact that the new IDE was unbearably slow. The last version of REALstudio wasn’t the fastest either, but at least it was usable on that machine. “Glacial” is the word that some users already have used to describe the performance of the new Xojo IDE, and I think that word describes it perfectly. Compared to Xojo, even old versions of eclipse or Netbeans felt fast. I don’t know what it’s like on Ubuntu or OS X; since I no longer use Macs, I don’t care much for the countless iMmprovements that they’ve brought to Mac users. I use Xubuntu on my machines at home, but have not yet had the time to install the IDE and give it a test run. But since the Windows version already was such a major disappointment, I’m not sure if I even want to invest the time into looking at the Linux version.
    The pricing is another topic. In a time where the mostly widely used development tools and programming languages are Open Source and Free, people who do not make their living by using one specific tool full time will find the product completely overpriced — especially when you have to add the hidden cost of a bunch of third party libraries that one will probably need to make the tool useful (or to work around the many bugs).
    Personally, I think that the web edition is the most attractive piece of the product. But at least in the previous version it lacked A LOT of features that I needed and the support for Microsoft SQL Server (which I also needed) was so buggy that I had to rely on external Python skripts for the database queries. The uselessness of the SQL Server module made me wonder if they even have a QA team at Realsoftware/Xojo.
    Anyway. This COULD be a very attractive and useful product. But not at this price, not with the horrible performance on Windows and not with the traditional high amount of bugs.

  12. Geoff Perlman :
    The problem with the old IDE was that when scrolling through controls in the Code Editor, most of the rows were empty events that you’d probably never implement. So we changed it so that you add the events you want.

    In the old IDE you could just hit CTRL+- to hide the empty(unused) events. It was very easy and straightforward…not a problem for me at least.

  13. Bob Keeney :
    .The stated intent was to eliminate tab management. Instead, I’d argue that scrolling in the Navigator is way more confusing and harder than the tab management ever was..

    I would hide empty events and only show them when I was looking for the right event to put my code in. Tabs were a nice way of keeping thinks that belong together in one easily accessed place.

  14. Some of my perceived usability issues may just evaporate as I get used to the new interface for example to add event handlers, properties etc I’m finding using the hot keys are the way to go. For example if you click on the event handlers dropdown within an object the add new code button disappears but you can still right click this event handlers item to add a handler. However I’d expect the first item on the context menu to be “add event handler” but no the context menu is generic to the object within project menu .. a “generic menu” perhaps. There’s just too many clicks to perform common tasks this way.

    I mostly work on Macs but out of interest I installed the IDE on a windows machine running an 8 core piledriver chip, a radeon hd 7850, 8gb of ram and a sandisk ssd … so no slouch. The IDE loads fine but resizing anything is pretty flickery, scrolling the property list is amazingly flickery and a bit sluggish. Now I have to say applications that exhibit some flicker on earlier versions of windows in my experience generally don’t exhibit this problem on win 8 so I’m not sure what’s going on.

  15. @Mark Dolan
    I’ve been using Xojo since December. Yes, some of the usability issues get better with time. However, getting ‘lost’ in the Navigator has been the one consistent thing that drives me batty every time I use it.

    I remain unconvinced that the Navigator is a better solution than the Project Tab. If anything, I tend to think that having a second column in the Navigator to show object children (i.e. controls, source code items, etc) *might* be a better solution. But it’s not my product and I have little, if no sway, in that area. I can complain but in the long run they’ll do what they want.

  16. When using Microsoft Windows Xojo looks way too much like OS X. I’m sure if this were the other way around and Xojo looked like it was styled more towards Windows then OS X users would complain that it looks tacky, and that’s exactly how I feel about it right now. Literally everything is styled to favour OS X, even down to the search box, buttons and icons. So as far as I’m concerned it’s a huge step backwards in terms of it’s appearance. And I would say that these changes even effect how user friendly Xojo is. I mean you can’t even view exactly what a control looks like at a glance, nor can you double click a control to view all of it’s possible event handlers. Instead you need to perform more clicks and look through a list of what the control offers. And that’s supposed to be easier for people, how? You spend more time clicking through menus and having to discover things than clicking on a control and seeing exactly what you can do with it.

    The bottom line here is that OS X users don’t like Windows themed applications on their operating system, and the same applies to Windows users. I don’t want to use an application that looks like it was designed around OS X, so for that reason I’m sticking with 2012 R2.1 and Visual Studio.

  17. Bob Keeney :
    I remain unconvinced that the Navigator is a better solution than the Project Tab. If anything, I tend to think that having a second column in the Navigator to show object children (i.e. controls, source code items, etc) *might* be a better solution. But it’s not my product and I have little, if no sway, in that area. I can complain but in the long run they’ll do what they want.

    I agree with this by the way. The navigator is horrible and project tabs were much better at handling things.

  18. Winfried Maus :
    “Glacial” is the word that some users already have used to describe the performance of the new Xojo IDE, and I think that word describes it perfectly.

    I use a Windows 7 64 bit laptop and netbook for development and I can say the interface has been anything but glacial. Performance of the IDE is tied to the quality of your GPU. I’m using a second generation i5 chipset with Intel 3000 GPU and it is quite snappy on both machines. As some people in the community have seen I can be quite a whiner and if the IDE was glacial, I would be quite vocal.

  19. @Mark Jones
    I think it’s obvious that the designers at Xojo are Mac users. In my opinion, this is one of the big weaknesses of the company. Lot’s of Mac users and not many Windows users.

  20. @Bob Keeney
    I’ve always noticed that they seem to favour Mac, but I didn’t think that they would redesign the new UI around it and force it onto Windows users too. They could still fix that though by getting a few Windows designers on board. Change some of the icons, the button styles and even the remove the OS X background.

  21. The whole selling point of Xojo is the ability to create cross platform applications that look/feel/work the same with minimal changes. Using Xojo itself as an example of this is valuable. If you are doing only Windows development and not interested in Mac/Linux then honestly you should not be using Xojo. For what Xojo is it is unmatched in my opinion.

    That being said the Navigator is trash.

Comments are closed.