Our vision for Xojo has always been to make it fast and easy for people of varying programming skill levels to create applications. The primary way we do this is by keeping the process of creating Desktop, Web and Mobile apps as similar as possible.
If you use Xojo to create projects for more than just one of these targets, you’ve probably noticed that for the most part, controls are very similar across different project types. A button works much the same way in a Web app as it does in a Desktop or Mobile app. While there are some differences, controls share most of their events, properties and methods. Given that, you may have wondered why isn’t a button just a button? There are both historical and technical reasons why Xojo has DesktopButton (the new replacement for PushButton), WebButton and MobileButton classes.
When Xojo was initially developed in the mid-1990s, we were only thinking about cross-platform in terms of the desktop. While we started with Mac, we planned to support Windows and eventually Linux. It was obvious then that it was illogical have MacButton, WindowsButton and LinuxButton since we wanted you to be able to select the desktop operating systems you wished to support and then press Build. But at that time we weren’t considering Web, let alone Mobile apps. Thus the underlying framework and the Xojo IDE were designed with the assumption that control classes were for the Desktop only.
In 2011 we introduced the ability to create Web apps. At that time we could have decided to simply add the Web functionality to the existing Desktop control classes. Designing and building the Web framework was already an enormous task which would have only become significantly larger had we decided to design it around the existing set of Desktop classes. This would also have required extensive changes to the Xojo IDE because it also assumes the controls are Desktop controls. There would have been benefits to doing it. Occasionally when you write code that has to deal with something specific to a particular control class such as the Pushbutton’s MacButtonStyle, you do so by referencing the class name of the control. You also must deal with it when writing code that passes controls around in a generic way where you use typecasting to convert an object back into the specific control type it is. This latter case is one that is typically encountered only be very advanced users and fortunately, they can write that code in a way that makes it useful to other users by abstracting them from the details of how it’s done. Fortunately, most of you don’t deal with the control classes directly. You instead write code that deals with instances of controls (Button1, TextField2, etc.) using the names of the controls rather than the class names.
When we added support for iOS and later the Mobile framework, we continued this design. Controls would have as similar an API as we can provide while still being separate classes. Web controls are prefixed with Web. Mobile controls are prefixed with Mobile. We have designed the Mobile framework so that it’s API can be shared by both iOS and Android apps.
Now to talk about the technical reasons. Could we change it? Could we merge them all (Desktop, Web and Mobile) all into a single set of control classes? After all, we have already done with this the non-user interface-related classes. The desktop shares the same classes across operating systems as does the Web and Mobile too. Yes, we almost certainly could. However, that would be an enormous project likely taking two years or more. The gain would be that in the rare cases where a user writes code requiring a control class name, they would always use the same name (Button instead of PushButton, WebButton and MobileButton for example). Given that this is uncommon and that users who need to write code like this are very comfortable with their understanding that the class names are different for each project type, we do not not feel that it is worth the effort and time to combine them.
Having said that, if you find yourself in need of creating classes that will interact with controls and need to support multiple project types, you absolutely can do it. Xojo provides you with everything you need.
The one part of the control classes that has in the past not shared a common naming scheme was the events. While the Web and Mobile control classes have common events names they share, the Desktop did not. We rectified this in Xojo 2021r3, available now, with a new set of Desktop controls. These controls are nearly identical to the original Desktop controls you’ve been using. One big difference is that they have event names that match their Web and Mobile counterparts. This provides the best user experience because a user learning how to use Xojo to build apps for one project type can then utilize nearly all of that experience building apps for another. For consistency and to avoid conflicts with the original controls, the new controls are prefixed with Desktop.
Over the long history of Xojo, we have mostly abstracted you from the often significant changes that have occurred in computing. From the Motorola 68000 processor to the PowerPC to the Intel processor to the ARM processor, from classic MacOS to MacOS X, from Windows 6 to Windows 10, from 32 bit to 64 bit, and more. It is always our goal to make these changes have as little impact on you as possible. When we developed Web Framework 2.0, that continued to be our goal. Unfortunately, the underlying web technologies have changed too much over nearly a decade and made it impractical to allow you to combine Web 1.0 and Web 2.0 frameworks in the same project. That made transitioning some projects challenging and why we recommended only transitioning existing projects if it was necessary.
That was not the case with our transition from iOS to the new Mobile framework. Both can be utilized in the same project. This will be the case with our new Desktop controls as well. You will be able to use both sets of controls in the same project and even on the same window or container. The controls can interact with each other as well. We will also be providing a simple tool you can use to convert with a single click a control, an entire window of controls or an entire project from the classic Desktop controls to the new Desktop controls. Autocomplete will continue to work as always with the old controls and they will still appear in the Language Reference as well (though they will be marked as deprecated). The old and new controls share most of this same underlying implementation as well. There are some small behavior changes here and there but mostly they work just the same as the existing controls today. The primary benefits of the new controls are that their events match the other project types and that we were able to make some API and behavior changes without impacting existing projects and you can read more about that in this post: New Desktop Controls.
As we move forward, we will continue to implement our vision of making Xojo the fastest and easiest way to build apps for the platforms you care about. If any of this has raised new questions for you, please feel free to reach out to us.