TweetFollow Us on Twitter

MacApp and Prograph
Volume Number:11
Issue Number:5
Column Tag:Visual Programming

MacApp and Prograph CPX - A Comparison

By Kurt Schmucker, Advanced Technology Group, Apple Computer, Inc.

Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.

Designing and implementing an event-driven application with a sophisticated graphical user interface is a difficult task. Fortunately, a number of years ago Larry Tesler and other researchers at Apple came up with a way of making both the design and the implementation of a Macintosh application considerably easier. What they did was to design a working skeleton application that you could easily customize. Unlike earlier skeleton apps, this new one did much more, was more easily extended, and yet required you to learn much less about its inner workings. The main reason they were able to do this was that they used an object oriented language and designed their skeleton as an interlocking set of classes in that language. The resulting skeleton became known generically as an application framework and resulted in an Apple product called “MacApp - The Expandable Macintosh Application”. [1] Other application frameworks from other companies followed: some were Macintosh application frameworks and others were for other platforms. However, MacApp, as the first and the generally most full featured, remains the standard against which all new application frameworks are measured.

When CPX first came out, I embarked on a project to compare it to MacApp by reimplementing some of the MacApp sample programs in CPX, seeing what could and couldn’t be done, measuring RAM and disk footprints, measuring the performance of the resulting apps, etc. I have gotten far enough on this project to do a fair comparison, and this article will document what I have been able to do, and the conclusions I have reached.

However, not everything in this article will be objective numerical data like RAM footprint measurements. Developers are emotional about their tools, and why shouldn’t they be? You spend a great deal of time and effort learning to use a tool, and once mastered, you rely heavily on that tool for your livelihood. I am no exception to this. While I will present the factual data that I was able to generate in doing this comparison, I will also add my own personal opinions and impressions about MacApp and CPX. In addition, since it is difficult to isolate a tool from the environment it’s used in, I will also compare the total development experience of MacApp and CPX, including programming languages, build times, auxiliary development tools like direct manipulation window layout editors, etc.

Characteristics of an Application Framework

A Macintosh application framework is a set of classes in some object-oriented language designed in such a way that:

• it is a stand-alone, double-clickable, ‘vanilla’ Macintosh application. (Because it is an app, it has a working menu bar, can open multiple windows each of which are movable, resizable, etc., works with the clipboard, prints, and exhibits all the other standard behavior that a Macintosh user expects. It is a vanilla app since all the windows are empty, the menus are blank, and it prints out blank paper.)

• it can easily be extended by subclassing and overriding. (For example, to get a new type of window that draws three-d renderings of a molecule, you subclass the Window class, and override its Draw method (or the Draw method of an auxiliary object) and include the molecule drawing code in that new method.)

• it provides a set of special null methods that enable the framework to access your code. You override these methods to do routine customization like enabling menu items, processing mouse clicks, etc. (These special methods are called ‘hook methods’. [2])

• it provides an architecture that makes adding standard Macintosh UI features like undo, cut & paste, publish & subscribe, standard file dialogs, context-sensitive cursors, etc., very easy to do.

• it provides a widget set of standard Macintosh controls (for example, radio buttons, click boxes, and scroll bars).

With this definition of an application framework, both MacApp and the CPX ABCs are application frameworks, and so are THINK’s TCL [3], Microsoft’s MFC, and MetroWerks’ PowerPlant. A more comprehensive overview of frameworks can be found in [4].

Since the whole point of an application framework is to make the task of building applications easier, the typical measure of a framework’s success is the number of ‘shipping’ applications that have been built with it. (While this seems like such a common sense approach to measuring the success of a tool that it should almost go without saying, I have not always found this to be the case. At an academic conference on User Interface Management Systems - a research approach to generating GUIs automatically that has not yet seen commercial use - one smart aleck remarked that the differences between frameworks and UIMSs is that frameworks measure their success in apps/year whereas UIMSs measure their success in dissertations/decade. The really surprising part is that this remark was intended to poke fun at the lack of real-world UIMS success after many years of research, but the UIMS researchers thought that this measure was an excellent one, and accurately gauged their contributions. There is just no insulting some people.) {OK, OK, I’ll confess. The above-mentioned smart aleck was me.}

Table 1. A quick comparison of the gross characteristics of MacApp and Prograph CPX.

Are MacApp and CPX Comparable?

Table 1 shows the results of a comparison of the gross characteristics of MacApp and CPX. This quick comparison shows that these two frameworks are roughly comparable in size and targets, although MacApp, being more mature, has a considerably larger set of shipping apps.

Detailed Comparisons

Intro to MacApp

I assume that all the readers of MacTech have some knowledge of Prograph (the language, the development environment, and the ABCs) from earlier articles (for example, [5]). However, I don’t assume any previous experience with MacApp, so let me give a short intro to MacApp, from the perspective of a Prograph CPX user. (If you want a more detailed intro to MacApp, see [2] or [6].)

MacApp is a C++ Macintosh application framework consisting of over 200 classes and 2100 methods. Since it is a framework supporting the generation of Macintosh applications, many of the classes in the framework reflect the basic Macintosh UI concepts: TApplication, TDocument, TWindow, TButton, TClipboardView, and so on, and the run-time interconnections between these objects reflect the structure of most Macintosh-style apps: the single TApplication object maintains a list of all the TDocument objects which in turn maintain lists of their TWindow objects which also maintain lists of their window widgets. In addition, there are classes that represent common abstractions like views (TView), user requests for action (TCommand), and frequently used building blocks (TList).

Any typical MacApp application will have a single subclass of TApplication, one or more subclasses of TDocument, zero or more subclasses of TWindow, and one or more subclasses of TView and TCommand respectively. These subclasses will override the hook methods - all of which have the common naming convention of starting with “Do”, as in “TDocument.DoMakeWindow” and “TView.DoMouseCommand”. In these regards, MacApp and the CPX ABCs are very similar.

MacApp has always been a Macintosh-only framework: compile on the Macintosh for the Macintosh. Last May (May 94), MacApp 3.1 shipped with support for the generation of PowerPC native applications. And MacApp 3.5, with support for OpenDoc™ container apps, is now in alpha release.

There are about 200 or so shrink-wrapped apps implemented with MacApp. Of these, Adobe PhotoShop is the best known, but others include Ray Dream’s suite of high-end rendering applications, Intelligenetics GeneWorks, Spyglass Dicer, Apps MicroTV, Exis MacDSS, Odesta GeoQuery, MacTerminal, and the Apple developer tools ViewEdit and BalloonWriter. Like other frameworks, MacApp is often used for in-house applications, so its true success is often underrated.

MacApp ships with about ten example applications, all provided in source code. These range in complexity from the smallest possible MacApp application, Nothing, to a full spreadsheet application, and a small structured graphics editor. All MacApp users read, copy, and are influenced by the source code of these samples.

There are a variety of separate development tools associated with MacApp - browsers, window layout tools, source-level debuggers, run-time inspectors, etc. Some of these are provided by Apple (MPW, ViewEdit, SourceBug, and MacBrowse, to name a few) and others, often competing tools, are offered by third parties (e.g., IcePick, Object Master, The Debugger, and CodeWarrior.) Most MacApp developers feel compelled to become proficient in many of these tools. Unfortunately, the languages and user interface conventions of the tools are not uniform.

Re-implementing the MacApp Samples

The project I decided to use to do a detailed comparison between MacApp and CPX was to re-implement some of the MacApp samples. This enabled me to test a wide variety of CPX features in a number of different contexts, yet was a project of reasonable size (especially important in an ‘on-your-own-time’ coding effort). While this project has proven to be very illuminating - both about MacApp and about CPX - it is not a flawless approach for an in-depth comparison. Flaws include:

• Size. The MacApp samples range in size from tiny toy apps to small apps. Even the largest (Calc) is only about 12,000 lines of C++. Thus, this re-implementation project really doesn’t test the ability of CPX to build full size commercial products. (Of course, re-implementing PhotoShop in Prograph just to see if it can be done is a little more than I am willing to do just for fun.)

• Feature coverage. The MacApp samples were designed to demonstrate and test the features of MacApp, and thus they may not necessarily be representative of the types of apps that CPX is designed for. (At the very least, I should attempt the reverse test: re-implementing the CPX samples in MacApp. I have not done this since once I had done a significant amount of Prograph programming, it is very difficult to work up the motivation to return to the murky depths of C++, MPW, or even text-based programming at all. So, my work may be slightly one sided, but it is better than having no data at all.)

I have re-implemented four of the MacApp samples in CPX: Nothing, DemoText, IconEdit, and DemoDialogs. I used the built MacApp samples as runnable specifications for what I would implement in Prograph, and I purposely did not look at the MacApp code to see how some feature was implemented. (I have been a MacApp programmer for years and have studied the implementations of all the MacApp samples to some degree at some time or another. However, I didn’t specifically re-examine the code while I was doing my Prograph re-implementation.)

The first two of these samples, Nothing and DemoText, were extremely easy and the re-implementation effort mainly amounted to re-arranging menu items on the standard Prograph menus to match those of the MacApp samples. Primarily, the re-implementation task for these two samples was easy because the functionality of these apps is so small, and they are direct uses of classes like TTEView (in MacApp) or EditText (in Prograph) so there is very little to do but ‘wrap’ these classes in an application. Secondarily, the re-implementation was easy since there were Prograph samples that were quite similar in functionality, and all I had to do was modify and extend them slightly to match the functionality of their MacApp counterparts.

Re-implementing IconEdit was more code, but once I had fixed a small bug in Prograph’s undo handling [7][8], it was not too difficult to get all the IconEdit functionality. One portion of the app that is tricky to implement in both versions is the handling of the editing of the icon, in particular, making sure that the user can mouse down in the fatbits view, move the cursor around while drawing, and then mouse up. Of course, choosing undo should then remove all the drawing added between the mouse down and the mouse up, not just undo the setting of the last drawn bit. Here is the C++ code from the MacApp version:

TIconDrawCommand::TrackMouse: 
#pragma segment ADoCommand

pascal TTracker* TIconDrawCommand::TrackMouse(
 TrackPhase aTrackPhase, VPoint&   /*anchorPoint*/,
 VPoint& previousPoint,
 VPoint& nextPoint, Boolean mouseDidMove)
{
 VPoint fromBit, toBit, iconBit;
 short  lineLength;
 float  deltaH, deltaV;
 float  h, v;

 if (mouseDidMove) // If mouse moved since last time 
 {
    // Convert nextPoint and previousPoint to bit locations in the icon 
 fIconEditView->PointToBit(
 fIconEditView->ViewToQDPt(nextPoint), toBit);
 fIconEditView->PointToBit(
 fIconEditView->ViewToQDPt(previousPoint), fromBit);

 if (aTrackPhase == trackPress)
 {
 fOriginalIcon = fIconBitMap->Copy();
    // Make a copy of the original.
 fTurnBitsOn =!fIconBitMap->GetBit(toBit);   
    // Turn bits on or off?
 }

// The following sets bits in the icon from the bit at previousPoint 
// to the bit at nextPoint.  It is based on a simple line-drawing algorithm.
 lineLength = (short) Max(labs(toBit.h - fromBit.h), 
 labs(toBit.v - fromBit.v));
 lineLength = (short) Max(1,lineLength);     
    // This is on two lines so that Max can be "inlined"
 
 deltaH = (toBit.h - fromBit.h) / lineLength;
 deltaV = (toBit.v - fromBit.v) / lineLength;
 h = fromBit.h + 0.5;
 v = fromBit.v + 0.5;

 for (short i = 0; i < lineLength; i++)
 {
 iconBit.h = h;
 iconBit.v = v;
 fIconBitMap->SetBit(iconBit, fTurnBitsOn);
    // Set the bit in the icon
 fIconEditView->DrawBit(iconBit, fTurnBitsOn);
    //  and draw it in the edit view.
 h = h + deltaH;
 v = v + deltaV;
 }
 }
 return this;  // Return same command object.
} // TIconDrawCommand::TrackMouse 

TIconDrawCommand::TrackConstrain: 
#pragma segment ADoCommand

pascal void TIconDrawCommand::TrackConstrain(
 TrackPhase /*aTrackPhase*/,
 const VPoint&   /*anchorPoint*/ ,
 const VPoint&   /*previousPoint*/ ,
 VPoint&nextPoint,
 Boolean/*mouseDidMove*/)
{
    // This is on several lines so that Max can be "inlined"
 VCoordinate h = Min(nextPoint.h, 
 fIconEditView->fSize.h - kBorder - 1);
 VCoordinate v = Min(nextPoint.v, 
 fIconEditView->fSize.v - kBorder - 1);
 h = Max(h, (long) kBorder);
 v = Max(v, (long) kBorder);
 nextPoint = VPoint(h, v);
} // TIconDrawCommand::TrackConstrain 

TIconDrawCommand::DoIt: 
#pragma segment ADoCommand

pascal void TIconDrawCommand::DoIt()
{
 VRect editViewExtent;

 fIconDocument->SetIcon(fIconBitMap); // Set the document’s bit map.

    // SetIcon invalidates all views of the document, including the one we just drew in. 
    // To avoid flashing, validate the edit view here so it doesn’t get redrawn.

 fIconEditView->GetExtent(editViewExtent);   
 fIconEditView->ValidateVRect(editViewExtent);
} // TIconDrawCommand::DoIt 

and Figure 1 shows the approximately equivalent Prograph code (together with some of its scaffolding, so that you can more easily see what is going on.) Perhaps it is my visual coding bias, but I find the Prograph code much easier to read and quicker to understand.

Figure 1. The implementation of fatbits drawing for the
IconEdit sample program re-implementation in Prograph.

I also took the opportunity while doing the IconEdit re-implementation to add Filters & Sieves to the Prograph application framework - something I had always wanted to do with MacApp, but was never able to work up the courage to delve that deeply into the inner working of MacApp. [9] With Prograph, and especially because of its excellent editor/interpreter/debugger environment, I was able to accomplish this, and enjoyed doing it.

DemoDialogs was a much bigger effort. The MacApp version is about 3500 lines of C++ and is basically a collection of all the window types and widgets that MacApp supports, and demonstrations of how to build your own if MacApp doesn’t provide them directly. DemoDialogs is the kind of sample program that is actually a collection of small samples: you look up a portion of the source code to see how that single feature was implemented. (Other types of sample programs include those that are good starting points for certain types of applications (e.g., DrawShapes or Skeleton), those that are just tours de force of the power of the framework (Nothing), or those that are tutorial in nature (IconEdit)). The MacApp DemoDialogs has example windows of the type that are seen in every Macintosh application (save dialog, print dialog, etc.), commonly used windows (e.g., a font picker like you would see in any word processing application), some windows that you see occasionally (windows with custom controls, windows with arrays of buttons and other widgets), and then some windows that you never see, but show off some feature of MacApp (a View inspector that shows you the internal structure of any other window in DemoDialogs). The feeling that you get after using DemoDialogs for a little while is that MacApp will probably be able to build any type of window that you want, and it may even provide direct support for that kind of window.

The final result of my DemoDialogs re-implementation effort is that I was able to implement all the functionality of DemoDialogs except for only one small, but possibly significant feature: large views. (Discussed in detail below.) Figure 2 shows all the windows of the CPX DemoDialogs. (A similar figure for the MacApp implementation would be exactly the same, so I have not included it here.) The Prograph implementation of DemoDialogs, like the MacApp original, gives you the feeling that you can create any type of window with CPX. The CPX re-implementation of DemoDialogs is perhaps a little bit slower, but comparable in perceived responsiveness to the MacApp version. The Prograph version does have a somewhat little larger RAM footprint. (See the detailed measurements on RAM and disk footprints later in this article.)

Figure 2. The windows of the CPX implementation of DemoDialogs. Note that a similar figure of the windows of the MacApp implementation would be virtually identical.

The single feature of DemoDialogs that is not easily implementable in Prograph is a 10,000 element scrolling list. Like MacApp 1.0, Prograph uses standard 16-bit QuickDraw coordinates for its views. This limits the size of views. MacApp 2.0 (and later) went to 32-bit coordinate representations for all view objects, including scrolling lists. The result was that the biggest scrolling list that I could build in Prograph was about 1,000 elements in length. Whether this is significant to you or not, depends in the types of applications you want to do. Details of the DemoDialogs re-implementation are discussed in [10].

Which is Better, MacApp or CPX?

There is no quick easy answer to the question of which of these two frameworks is better since both products are significant, feature-rich frameworks that provide great utility to their users. In addition, there are many of aspects of both MacApp and CPX that this sample re-implementation test doesn’t stress. For example, both MacApp and CPX support far code and far data - features that will only really be used in larger applications (greater than 4000 methods or more than 32K of global data). However, it is possible to list some of the aspects of each that are better than those of the other framework.

What’s Better in MacApp?

Sample Programs. The MacApp sample programs are significantly broader and deeper than those in Prograph, and there are more of them.

Clipboard View. While both MacApp and CPX support the Macintosh clipboard for copying and pasting of text and pictures, MacApp also implements a clipboard view so that you can trivially add a “Show Clipboard” menu item to your application. I also found the MacApp approach to providing clipboard support for your application’s data types (TApplication.MakeAlienViewforClipboard) to be much easier to understand and to use. (I do wish, however, that MacApp’s clipboard supported more than just text and pictures, but also included QuickTime movies, sound, etc.)

Low memory handling. MacApp’s mechanism for dealing with low memory situations is more robust and more useful than Prograph’s Rainy Day Fund.

Publish and Subscribe. MacApp provides a framework for supporting the Macintosh publish and subscribe mechanism (actually, it is a unified framework for the clipboard as well as P&S). MacApp handles a lot of the details of the P&S user interface (borders, standard dialog boxes, etc.) for you.

Adorners. MacApp’s mechanism for adding some drawing adornments to views is better at this task than the borders mechanism is in CPX. For one thing, the adorners mechanism enables you to add multiple adorners to a single view.

What’s Better in CPX?

Language. Prograph is a more readable, simpler language than C++, yet it is just as powerful. In fact, it isn’t possible to write syntactically incorrect Prograph code, and semantic errors often jump out at you in even the most casual examination. The clarity of code expressed in Prograph is due, in part, to the fact that algorithms, by their very nature, have an inherent internal structure. Often, implementing an algorithm in a textual, and thus necessarily linear fashion, hides this structure. In contrast, the Prograph language brings this structure to the surface and enables the Prograph-literate programmer to grasp this structure in a single gestalt. Prograph programmers also don’t need to spend time thinking up descriptive names for temporary variables in their code, they just draw a data flow line between the point where the data is generated and where it is used. Data is typed dynamically and this makes both prototyping and significant architectural changes easier.

Environment. Prograph has a fast garbage collector, an integrated source-level debugger - which lets you change code or data while your application is running - and an extensible window and view editor.

Behaviors. Behaviors provide a much easier to use, and much more flexible way for your code to be accessed by the framework than MacApp’s hook methods. With a behavior, you are no longer constrained to the parameter list of the hook method. In addition, CPX will retrieve some data for you (like getting values out of text items in dialog boxes.) Consider, for example, the task of responding to a click on a button in a dialog box. Here is what you have to write in MacApp:

TModelessBeepDialog::DoEvent: 
#pragma segment ARes

pascal void TModelessBeepDialog::DoEvent(
 EventNumbereventNumber,
 TEventHandler*  source,
 TEvent*event)// override 
{
 long i;
 long maxi;

 switch (eventNumber)
 {
 case mButtonHit:  // Default button and Enter or Return key
 {
 maxi = ((TNumberText *)
 (FindSubView('numb')))->GetValue();
 if (this->IsHierarchyValid())
 for (i = 1; i <= maxi; i++)
 gApplication->Beep(2);
 break;
 }
 default:
 inherited::DoEvent(eventNumber, source, event);
 }
} // TModelessBeepDialog::DoEvent 


Figure 3 shows the simple dialog you have to fill out, and the small amount of code that you have to write to achieve the same result in CPX.

Figure 3. Handling a mouse down in a button is easy because of Prograph Behaviors.

Menus. For the MacApp programmer, menus exist at the boundary between the object world of MacApp and the lower-level world of the Toolbox. Some of the programming tasks are in one world and language (DoSetupMenus) and some in another (“Arrow”, noIcon, noKey, noMark, plain, cArrow). Having taught many MacApp classes, I can testify that this can be a considerable stumbling block to the new MacApp user. Thus, in the total task of adding a new menu or menu item to a MacApp application, you have to constantly flit back and forth between a number of different programming tools each with its associated language(s) and style of usage. You code in an object language to implement the main functionality of your app, in a strange C-like language (Rez) to describe your menus, and in even stranger language (MPW Shell) to build your application. Along the way you have to use separate applications (e.g., ViewEdit and ResEdit) to build in a direct manipulation style some of the objects that your menus will operate with or on.

CPX changes this dramatically by making menus and the menubar into objects that you deal with in exactly the same way that you deal with other objects like windows and views. The Menus section in the CPX ABCs provides you with eight classes associated with menus, with the classes Menu, Menubar, and Menu Behavior among them. These classes provide you with methods that add or remove menus from the menubar, add or remove items from an individual menu, enable a menu item, test to see if a menu item is checked or enabled, and find an individual menu or menu item, among other things. You invoke direct manipulation object editors for the menubar and menu objects in exactly the same way that as for windows or views or any other object. There isn’t any need to use another separate tool to accomplish a critical portion of the basic task of implementing the menu functionality of your app. Internally, CPX still deals with the Toolbox Menu Manager and uses the Macintosh ROM to implement menus. However, all the Toolbox details are abstracted for you by CPX and you deal with menus as objects.

This small change of moving menus from the Toolbox to the framework dramatically simplifies both the programmer’s model and the task of getting that first application up and running. Just as important, abstracting away the Toolbox details simplifies porting your CPX source code to other platforms.

Offscreens. Getting smooth screen refreshes in MacApp is tricky and involves buying a third party product (OSImage) or rolling your own code in support of GWorld and offscreens. In CPX, all you have to do is allocate an Offscreen object (part of the CPX class library) and attach it to a window. Nothing could be simpler.

Simple tasks are simpler. I have found on many occasions that a number of conceptually easy tasks (opening a window, responding to a menu item choice, etc.) are just much easier in CPX than in MacApp. Here is a case in point that brings together many of these: posing a dialog. First the MacApp way:

TTestApplication::MakeModalBeepDialog: 

pascal void TTestApplication::MakeModalBeepDialog(
 CommandNumber aCommandNumber)
{
 TWindow *aWindow;
 IDType dismisser;
 long   n;

 FailNIL(aWindow = gViewServer->NewTemplateWindow(
 (short)aCommandNumber, NULL));
 dismisser = aWindow->PoseModally();
 if (dismisser == 'ok  ')
 n = ((TNumberText *)
 (aWindow->FindSubView('numb')))->GetValue();
 else
 n = 0;
 aWindow->Close();
 for (long i = 1; i <= n; i++)
 gApplication->Beep(2);
} // TTestApplication::MakeModalBeepDialog 

Notice how many concepts are buried in the main line:

FailNIL(aWindow = gViewServer->NewTemplateWindow(
 (short)aCommandNumber, NULL));

The view server, window templates, the MacApp failure handling mechanism must be understood, and you have to tell the C++ compiler again that the first parameter to a standard MacApp utility routine is an integer. Contrast this with the CPX way shown in figure 4. Much simpler. However, even this code is not the simplest possible. Dan Shafer suggested to me an even simpler way shown in Figure 5 in which you write no code at all. What could be easier?

Figure 4. Displaying a modal dialog in the Prograph CPX framework.
The equivalent code in MacApp is:

FailNIL(aWindow = gViewServer->NewTemplateWindow(
 (short)aCommandNumber, NULL));
dismisser = aWindow->PoseModally();

Figure 5. While the Prograph code in figure 4 looks simple,
here’s an even simpler way.

Measurements

I have been able to gather some objective data about RAM and disk footprints, and performance of one easily timed interaction.

RAM and Disk Footprints

Figures 6 and 7 show the RAM and disk footprint comparisons of four of the MacApp samples and my re-implementations of them. Note that there is a constant increment for the Prograph versions of about 200-300K in the case of disk footprints and 300-400K in the case of RAM footprints. A little more than half of this increase can be accounted for by the additional symbol tables that Prograph must maintain so that it can do by name dispatching at run-time (‘inject’ in Prograph terminology).

Figure 6. A comparison of the RAM footprints for four of the MacApp samples,
and their re-implementations in Prograph.

Figure 7. A comparison of the disk footprints for four of the MacApp samples,
and their re-implementations in Prograph.

What can’t be determined from this data is whether these increments will be remain constant as the size of the application grows, or whether they too will grow. If they are constant, then an additional 400K memory hit is not too significant when the app is expected to require a 6MB RAM partition. An examination of the RAM footprint of shipping Prograph applications shows that they do not have exorbitant RAM requirements, which suggests that the Prograph RAM increase is a constant, or a very slowly growing function.

Performance

Measuring interaction performance objectively can be difficult. Subjectively, as I already noted above, MacApp apps seem slightly snappier but approximately comparable with their Prograph counterparts.

I was able to find one interaction where objective timing data could be gathered. In the DemoDialogs application, there is a Celsius-Fahrenheit control in which the user can dial in a temperature on one scale and see the value in the other scale displayed. (See figure 8.) The dialing controls respond to mouse clicks with single increments or decrements, or if the mouse button is held down, the numbers increment as quickly as possible with all intermediate numbers displayed. This suggested to me the following test: Hold the mouse button down for five seconds in the increment Celsius control and see how large the Celsius edit text value gets in that fixed amount of time. This test measures ToolBox access (StillDown), conditional evaluation, integer arithmetic, integer to string conversion, and view refreshing. Table 2 shows the surprising results of this test. Does this mean that Prograph is ten times the speed of C++? No, it doesn’t. What this means is that language speed differences are dominated by better algorithmic choices, especially for time-consuming operations like screen refreshing, and in this particular case Prograph has the better algorithm.

Figure 8. The custom temperature conversion control, from the DemoDialogs sample, that was used for a speed test between MacApp and Prograph.

Table 2. Timing test results between MacApp and Prograph.

In this test, the mouse button is pressed for 5 seconds over the Celsius increment control, and the Celsius edit text field increase as quickly as it can, displaying all intermediate values. The table record how many degrees were incremented in the 5 seconds. The surprising result is that interpreted Prograph is about four times as fast as compiled MacApp, and compiled Prograph is about nine times as fast as compiled MacApp. Note that this does not mean that overall a Prograph app will be nine times as fast as a MacApp one, but that some computations can be.

Overall

What more can I say than that Prograph CPX is has been my development environment of choice for producing applications for the past two years or so, and will probably remain so for the foreseeable future.

References

[1] Ken Doyle, Barry Haines, Mark Lentczner, and Larry Rosenstein, “An Object Oriented Approach to Macintosh Application Development”, Journées Langages Orientés Objet, BIGRE + GLOBULE, Nov. 1984, pp. 46-54.

[2] Schmucker, Kurt. Object Oriented Programming for the Macintosh, Hayden Book Company, 1986.

[3] Parker, Richard O. Easy Object Programming for the Macintosh using AppMaker and THINK Pascal, Prentice-Hall, 1993

[4] Lewis, Ted (ed.). Application Frameworks, Prentice-Hall, 1995.

[5] Schmucker, Kurt. “Prograph CPX”, in Application Frameworks, Ted Lewis (ed.), Prentice-Hall, 1995; reprinted in MacTech Magazine, November, 1994, pp.69-80.

[6] Wilson, David A., Rosenstein, Larry S., and Shafer, Dan, Programming with MacApp, Addison-Wesley, 1990.

[7] Schmucker, Kurt. “A Tutorial on ‘Undo’ in CPX”, Visual News, July 1994, pp. 7-12.

[8] Schmucker, Kurt. “Commands and Undo in Prograph CPX”, MacTech Magazine, January 1995, pp. 18-31.

[9] Schmucker, Kurt. “Filters and Sieves in Prograph CPX”, MacTech Magazine, March 1995.

[10] Schmucker, Kurt. “DemoDialogs in Prograph CPX”, FrameWorks, Volume 8, Number 2, (March/April 1994), pp. 8-13.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

VLC Media Player 2.2.0 - Popular multime...
VLC Media Player is a highly portable multimedia player for various audio and video formats (MPEG-1, MPEG-2, MPEG-4, DivX, MP3, OGG, ...) as well as DVDs, VCDs, and various streaming protocols. It... Read more
Sound Studio 4.7.8 - Robust audio record...
Sound Studio lets you easily record and professionally edit audio on your Mac. Easily rip vinyls and digitize cassette tapes, or record lectures and voice memos. Prepare for live shows with live... Read more
LibreOffice 4.4.1.2 - Free, open-source...
LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more
Freeway Pro 7.0.3 - Drag-and-drop Web de...
Freeway Pro lets you build websites with speed and precision... without writing a line of code! With its user-oriented drag-and-drop interface, Freeway Pro helps you piece together the website of... Read more
Cloud 3.3.0 - File sharing from your men...
Cloud is simple file sharing for the Mac. Drag a file from your Mac to the CloudApp icon in the menubar and we take care of the rest. A link to the file will automatically be copied to your clipboard... Read more
Cyberduck 4.6.5 - FTP and SFTP browser....
Cyberduck is a robust FTP/FTP-TLS/SFTP browser for the Mac whose lack of visual clutter and cleverly intuitive features make it easy to use. Support for external editors and system technologies such... Read more
Firefox 36.0 - Fast, safe Web browser. (...
Firefox for Mac offers a fast, safe Web browsing experience. Browse quickly, securely, and effortlessly. With its industry-leading features, Firefox is the choice of Web development professionals and... Read more
Thunderbird 31.5.0 - Email client from M...
As of July 2012, Thunderbird has transitioned to a new governance model, with new features being developed by the broader free software and open source community, and security fixes and improvements... Read more
VOX 2.4 - Music player that supports man...
VoxIt just sounds better! The beauty is in its simplicity, yet behind the minimal exterior lies a powerful music player with a ton of features & support for all audio formats you should ever need... Read more
A Better Finder Rename 9.46 - File, phot...
A Better Finder Rename is the most complete renaming solution available on the market today. That's why, since 1996, tens of thousands of hobbyists, professionals and businesses depend on A Better... Read more

Get The Whole Story – Lone Wolf Complete...
Get The Whole Story – Lone Wolf Complete is Now Available and On Sale Posted by Jessica Fisher on February 27th, 2015 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Check Out the Trailer for the Upcoming F...
Check Out the Trailer for the Upcoming FINAL FANTASY: Record Keeper Posted by Jessica Fisher on February 26th, 2015 [ permalink ] DeNA and Square Enix have announced that | Read more »
Legacy Quest is an Upcoming Rouge-like T...
Legacy Quest is an Upcoming Rouge-like That’ll Kill the Whole Family Posted by Jessica Fisher on February 26th, 2015 [ permalink ] Nexon Co. | Read more »
Grudgeball: Enter the Chaosphere Review
Grudgeball: Enter the Chaosphere Review By Jordan Minor on February 26th, 2015 Our Rating: :: MUSCLE MENUniversal App - Designed for iPhone and iPad Regular Show gets an above average game.   | Read more »
Action RPG League of Angels – Fire Raide...
Gaia is being invaded by the Devil Prince and the demonic Devil Army at his disposal, and it’s up to you and your avatar to defeat him in League of Angels – Fire Raiders. Raise a mighty army from hundreds of recruitable angel heroes and take the... | Read more »
Burn Rubber on the Ice With a New Cars:...
Burn Rubber on the Ice With a New Cars: Fast as Lightning Update Posted by Jessica Fisher on February 26th, 2015 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
AdVenture Capitalist Review
AdVenture Capitalist Review By Jordan Minor on February 26th, 2015 Our Rating: :: DAS KAPITALUniversal App - Designed for iPhone and iPad An inadvertent Marxist manifesto.   | Read more »
Monster vs Sheep Review
Monster vs Sheep Review By Jennifer Allen on February 25th, 2015 Our Rating: :: SAMEY FUNUniversal App - Designed for iPhone and iPad What Monster vs Sheep lacks in variety it makes up for with stress relieving fun. At least, for a... | Read more »
Is Your Face Ready for the New Outwitter...
Is Your Face Ready for the New Outwitters 2.0 Trailer? Posted by Jessica Fisher on February 25th, 2015 [ permalink ] One Man Left Studios has announced that their turn-based strategy game, | Read more »
HowToFormat Review
HowToFormat Review By Jennifer Allen on February 25th, 2015 Our Rating: :: USEFUL TIPSiPhone App - Designed for the iPhone, compatible with the iPad Making a presentation and want to get it just right? HowToFormat teaches you how... | Read more »

Price Scanner via MacPrices.net

Save up to $50 on iPad Air 2s, NY tax only, f...
 B&H Photo has iPad Air 2s on sale for $50 off MSRP including free shipping plus NY sales tax only: - 16GB iPad Air 2 WiFi: $469.99 $30 off - 64GB iPad Air 2 WiFi: $549 $50 off - 128GB iPad Air 2... Read more
16GB iPad Air 2 on sale for $447, save $52
Walmart has the 16GB iPad Air 2 WiFi on sale for $446.99 on their online store for a limited time. Choose free shipping or free local store pickup (if available). Sale price for online orders only,... Read more
iMacs on sale for up to $205 off MSRP
B&H Photo has 21″ and 27″ iMacs on sale for up to $205 off MSRP including free shipping plus NY sales tax only: - 21″ 1.4GHz iMac: $1029 $70 off - 21″ 2.7GHz iMac: $1199 $100 off - 21″ 2.9GHz... Read more
Apple Takes 89 Percent Share of Global Smartp...
According to the latest research from Strategy Analytics, global smartphone operating profit reached US$21 billion in Q4 2014. The Android operating system captured a record-low 11 percent global... Read more
New Travel Health App “My Travel Health” iOS...
Rochester, Minnesota based Travel Health and Wellness LLC has announced that its new iOS app help safeguard the user’s health when traveling abroad — “My Travel Health” is now available on the Apple... Read more
Sale! MacBook Airs for up to $115 off MSRP
B&H Photo has MacBook Airs on sale for up to $100 off MSRP. Shipping is free, and B&H charges NY sales tax only: - 11″ 128GB MacBook Air: $799 100 off MSRP - 11″ 256GB MacBook Air: $999 $100... Read more
15-inch 2.0GHz Retina MacBook Pro (refurbishe...
The Apple Store has Apple Certified Refurbished previous-generation 15″ 2.0GHz Retina MacBook Pros available for $1489 including free shipping plus Apple’s standard one-year warranty. Their price is... Read more
Wither The iPad mini? End Of The Road Imminen...
AppleDailyReport’s Dennis Sellers predicts that the iPad mini is going to be left to wither on the vine, as it were, and then just allowed to fade away — a casualty of the IPhone 6 Plus and other... Read more
Android and iOS Duopoly Owns 96.3% of Smartph...
IDC reports that Android and iOS inched closer to total domination of the worldwide smartphone market in both the fourth quarter (4Q14) and the calendar year 2014 (CY14). According to data from the... Read more
13-inch 2.4GHz Retina MacBook Pro available f...
MacMall has the 2013 13″ 2.4GHz/128GB Retina MacBook Pro available for $999.99 for a limited time. Shipping is free. Their price is $300 off original MSRP, and it’s the only sub-$1000 new Retina... Read more

Jobs Board

Sr. Technical Services Consultant, *Apple*...
**Job Summary** Apple Professional Services (APS) has an opening for a senior technical position that contributes to Apple 's efforts for strategic and transactional Read more
Event Director, *Apple* Retail Marketing -...
…This senior level position is responsible for leading and imagining the Apple Retail Team's global engagement strategy and team. Delivering an overarching brand Read more
*Apple* Pay - Site Reliability Engineer - Ap...
**Job Summary** Imagine what you could do here. At Apple , great ideas have a way of becoming great products, services, and customer experiences very quickly. Bring Read more
*Apple* Solutions Consultant - Retail Sales...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
*Apple* Solutions Consultant - Retail Sales...
**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.