I saw this interesting thread when I got back after a vacation. In
response to the original questions/comments:
> AFAIK, most APL vendors interface to the standard Windows GUI objects.
> Is there a possibility of using "Java GUI Modules" instead ?
> i.e. Java Classes etc etc.
> ... and if so, is it possible without much effort ?
As far as APLX is concerned, yes we interface directly to the
underlying OS GUI objects under both Windows and MacOS. This is a
deliberate design decision, as we want the GUI objects to have the
'correct' look-and-feel for the platform. At the same time, we try
very hard to make the programming interface to the GUI objects both
portable and easy-to-use (and if possible also compatible with APL
+Win's []WI). Clearly there are trade-offs in this, but I hope we've
got the balance about right.
Of course, we can't provide natural APL interfaces to every possible
feature of every possible GUI element of a modern operating system;
there are simply too many even to document, let alone implement! If
something which you need is missing, you can often get access it using
low-level programming ([]NA, for example). But this shouldn't
normally be necessary, and we ask our users to let us know if they
need to resort to low-level programming, so that we can look at the
possibility of providing the missing feature in a portable, easy-to-
use way.
An interesting development of the last couple of years (at least in
APLX and Dyalog) is the possibility of programming the user interface
under Windows using the .Net frameworks directly from APL, using the
new object-oriented APL language features. It is easy to do, and has
the advantage that all the features available to (say) a C# programmer
are immediately available to the APL programmer, without the APL
vendor having to do anything, and with an easy-to-use syntax. The
disadvantages of this approach are:
(a) it is more complex than using the built-in APL GUI objects (which
we now call 'System Classes'). This is mainly because programming
the .Net classes tends to require an understanding of huge numbers of
small utility classes, and you often end up burrowing down lots of
documentation to find out how to do something very simple.
(b) it is Windows-specific (although the open-source Mono frameworks
are developing nicely and in the near future should provide fully-
functional, portable equivalents to all of the most important .Net GUI
classes).
My hunch is that most of our users will continue to use the built-in
APLX System Classes for GUI programming, but a few who really need to
take full advantage of the .Net GUI frameworks will think it
worthwhile to put in the extra programming effort to use them
directly.
As for Java, APLX v4 also allows you to make direct use of Java
classes, just as you can use .Net classes. So in theory, you can use
Java GUI classes directly if you want to. (There are some issues with
event handling, which for complex technical reasons is easier
in .Net). It will be interesting to see if our users want to explore
this option. I believe that Java implements all of its own GUI
elements, in the interests of portability; for example, it draws its
own buttons. As a result, many people think that Java applications
often do not look very good. (I'll admit it, I'm one of them. In
fact, my heart sinks when I see the Java logo on an application, as in
my experience it often seems to mean that the application is slow and
clunky. Just my personal opinion, you understand...). The strength
of Java is more, I believe, at the Server end, where it is very
heavily used in 'enterprise' applications, and this is the area where
we expect our users to want use Java classes from APLX. But if people
want to use Java GUI classes from APLX, that's fine, and we'll provide
help and support if necessary.
The other thing I would say is that I believe that (at least for
simpler applications) APL is an excellent language for designing and
programming GUI applications. Of course, Visual Studio and other
modern development tools have very good interactive design tools,
which we lack. I have been using such tools from many different
vendors in many different programming languages for around twenty
years, and I fully recognise their usefulness. However, the
interactive nature of APL provides an alternative apporach which, on
balance, I often prefer. In APL you can just write a function (or
class) to create, display, test, amd tweak a dialog directly, without
having to run the whole application as you typically have to do in
other environments, and I find that a big advantage. Just varying the
position or size of a button (by typing into the session window) until
the dialog looks right is often easier than using the design tool,
especially if you're trying to align a set of controls or adjust their
sizes. It's also often easier to make stuctural changes (for example,
if you decide to move a set of buttons, list boxes and text fields on
to a new Tab control).
Richard Nabavi
MicroAPL Ltd
|
