It’s been suggested that this should be easy to do. Just make threads preemptive (so that they will then run on any available core) and voila! Unfortunately, it’s not that simple. Let’s look at why the current threads are not preemptive. It’s hard for you, the developer, to work with preemptive threads. Some languages, like Java, have language features built in to them to try and help make this less work, but it is still hard to get right and very hard to debug when you don’t. Much of the framework would need updating to be thread safe and your application’s user interface is not thread safe on any platform because the operating systems themselves don’t have thread-safe user interface code. If you access something from a pre-emptive thread and that something is not thread-safe, there’s a very good chance your application is going to crash. We have had to go to a lot of extra work just to make the threads you have today work without causing problems.

The Xojo language already has functions like mutex and semaphores that help you make a multi-threaded program. But you have to protect every place you might set a value that could be shared by many threads. This would mean protecting any globals and pretty much anything that is not local to the method or the thread being executed. That’s very different than what you have to do today and a lot more work. It’s just not simple or easy to use the way most of Xojo is designed to be.

The end goal is to use all cores and thereby make your software more responsive, faster, or able to handle more data, or do more things all at the same time. There’s been a way to do this for as long as Xojo has supported building console applications. The design is to create a main application (GUI or not) and use other helper applications to run separate tasks. The main application and the helpers can communicate in any one of several ways: IPCSockets, TCPSockets, UDPSockets, XML, files, or just about any other way you can dream of. The upside to this way of solving the problem is you can design and implement the main application and the helpers independently and use the debugger to debug each independently. You can use any data in either program in the same way you always have. You don’t have to worry about the framework being thread safe as the helper and main application run as completely separate processes with their own memory space. Most importantly, you can do this today.

I’m not going to say it’s simple. You have to think about what portion of your application can be segmented out into a helper console application. You have to design the communications between the main and helper applications. You have to write, test and debug them. But you don’t have to worry about variables changing mysteriously because some other thread changed the value. You don’t have to use lots of mutexs or sempahores to block other threads from altering things when you least expect them. And you can use the entire framework that is available to console applications. Last but not least, you can run as many instances of these helper applications as your computer (or all the computers available to you) can run.

If you think you need preemptive threads today, try the helper application approach and I think you’ll be pleasantly surprised at how well it works.

For more information: Take advantage of your multi-core processor

In the Beginning

In 1984 when the original Macintosh was introduced, as advanced as its interface was at the time, its graphics capabilities were extremely weak, at least by today’s standards. It could only manage a black and white, 1 bit interface.

Almost 2 years later, Microsoft Windows 1.0 was released and it added color but was laboring under many of the same technological restrictions.

The whole idea behind the GUI was to make the interface use elements that were similar to things the user already understood. For example, pushbuttons already existed in the real world. The idea of a window as a place to view things was an analogy but it connected the user with something they already understood.

Over time, the graphics capabilities of personal computers became stronger. Processors, memory and displays all became better, faster and less expensive. Consider Windows 95 (released in 1995) and Mac OS 8 (released in 1997):

Both took a big leap forward. With better graphics and color, the user interface felt more realistic. I know that may be hard to imagine if you never used these versions of Mac OS or Windows but remember and consider what users had been using up to this point. Over time, user interfaces became more skeuomorphic, though this was certainly true more for OS X than it was for Windows. Apple made the Address Book and Calendar   look somewhat like their real world counterparts.

The Mobile User Experience

When the iPhone came along, it took the mobile interface to an entirely new level. One of the things Apple realized is that when using an interface on a much smaller screen, you have to simplify. The busier the user interface, the harder it is to use. This meant fewer lines and simpler graphics. It also meant being more choosy about the functions apps would perform because of the limited space available in such a small screen (among other things). The simpler user interface allowed the user to focus.

Android has gone through the same transition over the years, from Cupcake yo KitKat.

The Changing Desktop

In some ways, this didn’t start with iPhone and Android. For example, for years many graphics and photo-editing applications have used a dark theme so that the application’s interface fades into the background helping the user focus on their content.

Microsoft Windows 8 offered a radically different user interface. While the change has certainly been contraversial, it’s clearly meant to simplify the desktop user experience. Microsoft’s motivation was to provide a single user experience for desktop and mobile. It’s clear now that this was not a complete success and it seems they are going to make a new attempt with Windows 9.

Now Apple, with the upcoming release of OS X 10.10 Yosemite, is simplifying the user interface as well. You can click to enlarge the picture below.

But in Apple’s case, I believe the motivation is more about simplifying for two reasons:

1) The simpler the visual aspects are, the more the user can focus on their content. Apple is not removing functionality. The change is more about how they render the user interface itself. There are fewer lines and fewer colors.

2) While Apple firmly (and rightly, IMHO) believes that you can’t have the exact same user experience on a mobile device as a desktop, there are visual cues that can be shared which make it easier for the user to switch between devices- icons for sharing, etc. Switching between desktop and mobile devices is a behavior that is very common and only becoming more so.

Coming Full Circle

In some ways we have come full circle. We started with simple user interfaces that were skeuomorphic and became even more so over time. At the time, they had to be because the user needed to relate the user interface to the real world. The Graphical User Interface has been around long enough now that it no longer needs to be skeuomorphic. Today, user interfaces need to make sense to users who already have experience with a graphical user interface. The simplified user interface makes the user experience more friendly and allows the user to stay more focused on what they are trying to accomplish. In subtle ways it increases productivity which, after all, is why we use computing devices in the first place.