FWD » Core Development » User Interface

The original ChUI support was written using CHARVA. CHARVA provided a library of widgets and UI functionality mapped to the native NCURSES terminal support. The CHARVA design was inspired by and heavily influenced by the AWT/Swing event-processing model. As such, it had this event model built into the deepest levels of all support.

The Progress 4GL UI (ChUI and GUI) in contrast, does NOT have an asynchronous event-processing model. Although both ChUI and GUI supports event processing, these are simply synchronous callouts to user-defined triggers, based on high-level events. There is no asynchonous behavior. Everything occurs in a deterministic and sequential manner. There is no concept of the low level events that may be implemented in the native platform. For ChUI there is no low level event model in NCURSES or other terminal support libraries. But for GUI, the 4GL directly implements using the Windows native GUI controls and application model. This means that the Windows implementation hides the low level message queue and all of the low level details of Windows GUI apps.

Having the event model in our code is not helpful. It provides no features that we need for 4GL support and worse yet, it makes the code much more complicated than necessary. This task is meant to rewrite the core of the client to eliminate this design and cleanup the mess that was left behind.

From a conversation between SIY and GES on November 15, 2010:

Although I agree with the goal, I must admit that implementation will not be
simple nor easy. Too much logic depends on postponed event processing.

The key point is this: today we do have a single-threaded synchronous implementation. But it is written as an asynchronous multi-threaded implementation, which means that the real ordering of events is hidden/obscured inside a much more complex implementation than is necessary. And that complexity has been the cause of problems, such as OOME issues on the client side.

I don't want to introduce new problems, but generally I can think of no good reason to keep it asynchronous in the long term. I know we have discussed this before (back in 2005 or 2006 I think). At the time, we made the decision to leave CHARVA and the architecture as it was, fearing that the rewrite would delay getting this into production.

In the end, in my estimation, it would have been better to take the step back then and make things right. It still took at least 2 more years to get into production. Had I known this at the time, I would have made a different decision.