Reviving the native PC app

An IDE that makes it very simple to produce native PC apps. Apps use the InterUnit UI design paradigm to create the UI, and wxWidgets, a widely used platform library (C++) for Windows, OSX and Linux to access platform features.

The InterUnit UI design paradigm
This UI paradigm is near the opposite of the WIMP paradigm. It does not organize the screen using windows. A window is a spatial screen organization construct. InterUnit organizes the time spent interacting with the UI into monolithic interface units called InterUnits. An InterUnit has access to the entire screen for painting and gets most of its input from the keyboard although the mouse may be used as an additional user input modality. At any given time the user is interacting with a single InterUnit. There is always a primary InterUnit that the user interacts with. Within the course of this interaction "accessory" InterUnits may pop up, be interacted with and then go away to give control back to the primary InterUnit. 2 or more InterUnits may also be "synched" or synchronized which means they share the screen at the same time but only one of these has access to user input at a time.

Implementation of the InterUnit API for wxWidgets
The API is implemented as 2 simple constructs.
1. A struct representing a SessionManager
that manages the active InterUnits in an inetraction session and across interaction sessions. This struct interfaces with the wxWidgets wxFrame class. It is contained by a subclass of wxFrame. OS events received by wxFrame such Paint, Keyboard and Mouse events are forwarded to this struct. The SessionManager also makes request to wxFrame to refresh all or parts of itself depending on the drawing requirements of the InterUnits the SessionManager contains.
2. A struct representing an InterUnit.
The SessionManager forwards paint, keyboard and mouse events to the currently active InterUnit. The InterUnit may also request a refresh of all or part of the screen it is displaying to. These requests are forwarded by the SessionManager to the wxFrame and result in Paint messages being sent down later to the wxFrame by the OS as a result. These are dispatched to the currently active InterUnit via the wxFrame and the SessionMananger.

Being prepared.

The OSVs View: Platform Proliferation, the role of the web, web apps -- a convenient side-step, app stores.
Microsoft was the dominant Operating System Vendor (OSV) till the late 1990s. With the return of Steve Jobs at Apple, Apple picked up a big enough chunk of the 2nd spot to make it a 2 horse race and Linux claimed a distant third. In effect from one OS the PC went to 3 OSs, each with a different developer story. Around the same time the web proliferated and web apps came to be a way for distributing apps that were not tied to a particular OS. All OSVs started working on web apps and a lot of growth happened in back end platforms. Native apps or apps written to a particular OS and its associated developer tools took a back seat and OSVs started promoting building back-end services connected to web servers with HTML and Javascript to provide the front-end interface. From the OSVs point of view Web apps served as a convenient side step from promoting native apps. They continued to promote native apps through app stores. Apple's app store was a big success and Microsoft followed suit. Google created their own app store for Android.

The developer's view: better safe than sorry, the downfall of native apps.
From the developer's standpoint, once platforms proliferated, writing native apps became a big risk. 3 different versions of the same app had to be writted in 3 different languages targeting 3 different development platforms. It was a lot safer to develop a single web app that could run on any of the 3 platforms via a browser. Native apps therefore suffered a big downfall.

WIMP: a constraint that binds
WIMP stands for Windows, Icons, Menus and Pointers. It is a GUI paradigm that was invented to replace the character based DOS operating system UI. All 3 platforms -- Windows, OSX and Linux use this paradigm to organize screen space using a desktop metaphor into a collection of overlapping or tiled "Windows". Each app that is launched is associated with a set of Windows. After DOS, all operating systems used pre-emptive multi-tasking and organising the screen as a set of windows and associating an app with its windows fit in well with the need for multi-tasking. The window, which is a spatial screen-space organization construct is central to the idea of WIMP. The use of a mouse or pointer also becomes neccessary in WIMP. WIMP is a constraint since it neccessarily uses windows but since it used across all 3 platforms, it binds the 3 platforms with a common UI methaphor.

wxWidgets, still hanging in there
Around the time OS platforms started proliferating, a cross-platform library was created that took advantage of the fact that all 3 platfroms used WIMP as a basis for the UI. This library was called wxWidgets and after about 30 years it still exists, is robust, well maintained and has a small set of active developers that use this library to develop native apps for all 3 platfrom based on a single C++ codebase. The library is still not officially supported by any of the 3 platforms.

not-WIMP -- the InterUnit UI design paradigm
Simple, native and cross-platform.
The InterUnit design paradigm that is a departure from WIMP coupled with wxWidgets creates a way for app developers to produce native apps for all 3 platforms using a much simpler UI and still writing a single codebase in C++. One language, a common platform access framework and a simple UI paradigm.