|
20 October 2005
Dear A-Shell User/Developer,
I'd like to take a few minutes to bring you up to date on the situation with GUI development under A-Shell. Over the last couple of years, we've put a significant effort into a series of enhancements to A-Shell with
which you can convert your old text-based applications into fully functional Windows XP applications. While people can and will debate just what constitutes a Windows XP application and how hard it is to achieve
(which I'll discuss further in minute), the typical objective is to transform something like this:

into something like this:

Although these kind of comparisons are typically labeled "before" and "after," the above screen shots are from the same
program; both GUI and text modes can be supported at the same time. Although few would argue that the latter was
anything other than a standard Windows XP program, in fact, the program was running on a Linux server (accessed via the ATE terminal emulator). So even this one example gives some hint of the range of possibilities.
How does it work? This simple question requires a multi-part answer, which I will summarize as follows. First, A
-Shell/Windows, being itself a "normal" Windows application, is perfectly capable of creating and using standard Windows
controls (buttons, edit boxes, dialogs, etc.). To allow you to create and use such controls directly from AlphaBasic, we've
implemented several new XCALLs, TAB commands and configuration switches, as well as a new version of INFLD that
supports a Windows edit-box user interface while retaining its historic program interface. With these updates tools and
techniques (which you are already familiar with) you can choose to give your applications a minimal facelift or a complete
new interface without making significant changes to the existing linear logic of your application.
Unlike some GUI toolkits which force you to use a client/server model, the system just described allows you to create native
, single-tier, Windows programs with no need for any additional toolkits or add-on modules. (We do offer a fantastic new integrated program development tool, the A-Shell Editor ( see http://www.ashelleditor.com for details and an evaluation copy
) but it is optional.) However, if you want to continue to run your application on a UNIX server, we also support a client/server
mode, which requires nothing special on the server side beyond the standard A-Shell, while on the PC workstation you run
the GUI-capable A-Shell Terminal Emulator (ATE). ATE is essentially a specialized version of A-Shell/Windows which
includes a telnet client supporting AM6x emulation and the means to allow the server to relocate some or all of the GUI interface to the workstation.
For the most part, the application doesn't need to be aware of whether it is running under A-Shell/Windows directly or on a UNIX server.
How hard is it? Nowadays it seems that everybody is offering some kind of "miracle GUI" product that claims to allow you
to create a new GUI for your app with just a few mouse clicks. As with most things that sound too good to be true, the
reality is generally more complex than the advertising pitch. (You may recall that we programmers were to have been put out
of business by now due to the 4GL program generators that allowed end-users to generate their own applications using
"plain English" commands. Right.) That said, I believe that our approach gives you the best and most flexible trade-off
between effort and results of all the approaches I've seen. The reasons are many but here are a couple worth emphasizing:
- Far from being an all-or-nothing approach, you can do as little or as much interface enhancement as you want,
from adding a header in a special font, or a few buttons, to completely redesigning your interface. This allows you
to incrementally upgrade your user interface as you go on with your normal, never-ending program enhancements
. Perhaps more importantly, it allows you to change the way you think about GUI, from being a purely cosmetic
chore which will distract you from "real" development for months, to being a tool that eliminates many barriers,
allowing you immediately start adding new functionality to existing applications easier than ever before.
- It is built around the traditional programming tools and paradigms that you are already using - primarily XCALLs
like INFLD and PRINT statements for layout out your screens. So instead of having to stop and rethink your
entire interface and set up a new team to re-design your screens on the PC side, which then must communicate
with your AlphaBasic programs and programmers to make it all work, your existing programmers can use their
existing skills to immediately start incorporating GUI technology as part of their on-going program maintenance.
One happy consequence of the above two considerations is that even as you start allowing for Windows-style mouse control
of your applications, you can retain the old keyboard shortcuts and logic which your existing users are familiar with, and
which are typically much more efficient for power users. (In contrast, while the typical GUI looks nicer than text, it is usually
less efficient to use, which is why you don't see any mice at high-volume workstations like at the airport.)
How much does it cost? For the pure A-Shell/Windows environment, there is no extra cost beyond the standard A-Shell
license; this kind of development is part of what you get with A-Shell. In the case of A-Shell/UNIX, the only added cost is that
of the ATE terminal emulator, which is priced similarly to ZTERM and AlphaLAN. For new systems, this doesn't add much, if
anything, since you need some kind of emulator anyway. For conversions, you'll have to swap out your existing emulator for ATE, the cost of which depends on what emulator you currently use.
How to get started:
- Download the latest documentation. In particular, look at AUI.SBR in the XCALL Reference and the GUI topics in the Development Guide.
- Download the current version of A-Shell from the Latest Development Releases page. (If you're not already
using version 4.9, first install the complete 4.9 release/update, using a different directory if you want to preserve
your existing 4.8 base, and then overlay the patched executable on top. Also, make sure your A-Shell license permits an update.)
- Download the library of tools and sample programs from the Shared Open Source library
- Review your application situation and interface goals, make a plan, and get started programming.
- Feel free to contact us to go over your plan, and use the BBS to ask questions and share ideas with other developers.
If such a long-winded letter seems to call for a flowery ending, consider this analogy: Adding a GUI interface to a legacy text
application is something like modernizing an old building. If it's a simple building, like a barn, then maybe you want to cover
it in aluminum siding. Looks nice (from a distance), and can be done in a couple of days. It won't make your barn any more functional, but at least it won't look so old.
Maybe that's not a good analogy. Maybe your application is less like a barn and more like a Second Empire chateau, built
by craftsman over decades, with hundreds of rooms full of treasure. Maybe it's more like the Louvre. When the owners of the
Louvre decided they needed a better user interface, they didn't put up a façade. Instead they hired one of the best architects
in the world, who cut a hole in the middle of the courtyard and built a gleaming new entrance shaped like a pyramid made of
steel and glass, allowing the millions of visitors to pass in and out of the underground lobby with efficiency and style. At first,
the supposed cognoscenti complained; said it lacked unity, violated established traditions. Some probably even said that it
was a cheap retrofit and didn't look anything like a real modern building. If you ask me (and by now, pretty much everyone in
the world agrees), it was a brilliant example of applying just enough of a GUI to solve both an aesthetic and a functional
problem, efficiently and dramatically modernizing the interface while preserving all the things that make the Louvre great.
May your new user interface be beautiful, but above all, may it open the doors for more users to more easily access the treasure within.
Jack
AUI Samples 1 AUI Samples 2
|