Nov 96 Factory Floor
- Feb 96 Factory Floor
- Mar 96 Factory Floor
- Apr 96 Factory Floor
- May 96 Factory Floor
- Jun 96 Factory Floor
- Jul 96 Factory Floor
- Aug 96 Factory Floor
- Sep 96 Factory Floor
- Oct 96 Factory Floor
- Dec 96 Factory Floor
- Jan 96 Factory Floor
Volume Number: 12
Issue Number: 11
Column Tag: From The Factory Floor
A Brand New Constructor 
By Dave Mark, Metrowerks
This month’s Factory Floor interview is with Eric Scouten, Robin Mair, and Clint
Popetz, three members of Metrowerks’ Constructor team. In case you’ve never used it
before, Constructor is the visual front end that makes it easy to design interfaces for
your Macintosh and Java applications and applets. With the release of CodeWarrior 10
in September, Constructor sports a new look and offers some new functionality. Read
on to find out more.
Dave: How would you compare the old (CW8) and new (CW10) versions of
Constructor?
Eric: There are now two Constructors: one for PowerPlant (MacOS) and one for
Java. The Java Constructor debuted on CW10 and brings the same
interface-building capabilities to the Java language framework (AWT) that
we’ve been providing for our C++ framework for two years now.
In the PowerPlant Constructor, we’ve added several new resource editors since
CW8. In CW9, we added the ability to edit menu bars. It’s pretty slick. The menu
bar editor relies heavily on the Mac’s drag-and-drop interface. You can drag
menu items around from one menu to another in a single mouse action. In CW10,
we added support for many of the bitmap resource formats that people use in
MacOS applications. You can edit icon suites, PICT resources, pattern resources,
and more.
The other changes you’ll notice are not features, per se, but improvements in the
user experience. In CW9, we began adopting the Apple Grayscale Appearance; this
look is now almost complete in CW10, and is also visible in other parts of the CW
product line (especially the IDE). Also, the CW8 Constructor had a lot of
problems with stability. We’ve tightened up the code quality significantly since
then.
Dave: Why are there two separate Constructors for Java (the AWT) and MacOS
(for PowerPlant)?
Eric: There were two things that motivated this decision: code stability and code
size. Constructor for Java contains a lot of new technology, such as an embedded
copy of the Java virtual machine. This introduces some additional system
requirements (such as the Code Fragment Manager for 68K) and adds quite a bit
to the size of the final application. The Java runtime overhead is unnecessary in
the Constructor for MacOS.
I also wanted to make sure that the development of Constructor for Java did not,
in any way, disrupt the stability of the PowerPlant Constructor. Since the Java
version was finalized fairly late in the CW10 release cycle, this was a significant
concern.
In the future, both versions will be built from the same source files and will
share about 80% common code. However, I expect that they will always remain
separate. The project models are different, and the products will be growing in
different directions.
Clint: As Eric said, embedding the Java runtime in Constructor creates a
noticeable increase in memory footprint and binary size. We didn’t want to foist
this on unsuspecting Constructor users. In addition, we felt that the intersection
of Java programmers and PowerPlant programmers is pretty small at this point,
so keeping the products separate seemed like a good move.
Dave: What is the Code Generation model for Java Constructor?
Eric: It’s pretty transparent, really. When you save a Constructor file, a Java
source file is generated at the same time. It contains all the necessary code to
rebuild the interface that you’ve described in the visual editor.
Clint: The code generation mechanism (which was written completely in Java)
is meant to duplicate as closely as possible the UReanimator functionality in
PowerPlant. So, the generated code consists of a series of classes, one for each
component in the hierarchy, which know how to reanimate the target component.
This source is not meant to be modified, since it is not the actual component
subclass source. The developer can create their own Component subclasses in
separate files, and then invoke the Reanimator methods to build the interface at
runtime. Code to do this might look like:
MyFrame theFrame =
(MyFrame)Reanimator.Reanimate(“MyFrame”,”theFrameName”);
In addition, the developer may wish to grab references to components in the
newly created hierarchy. This functionality, which PowerPlant users will
recognize as similar to the FindPaneByID functionality, is also provided by the
Reanimator. Sample code to locate a TextArea in theFrame might look like:
TextArea theArea =
(TextArea)Reanimator.Locate(“TextArea”,”theArea”,theFrame);
Dave: Over time, more and more resource editing appears to be moving into
Constructor. Will Constructor eventually be able to take advantage of TMPLs?
How much resource editing do you see moving into Constructor?
Eric: Right. Constructor began its life as a special-purpose resource editor,
which knew about only the PowerPlant-specific resources (PPob and Txtr).
We’ve gradually been adding more generic resource editing capabilities to it:
menus, icons, etc.
These features are part of a long-term plan to evolve Constructor into a
general-purpose resource editor and application builder. Editing resources
described by TMPLs is an essential part of this plan, and it should be supported
fairly soon (in either CW11 or CW12). We are also designing a plug-in API for
resource editors, so you can write your own editors for custom resource types.
Dave: What Apple events does Constructor support now (in CW10)? What about
new Apple events for future releases?
Eric: Apple event support in Constructor is pretty minimal. We’ve found that
users view Constructor as an interactive program, and don’t typically want to
script the process of designing a visual interface.
In the future, Constructor may have some Apple event interactions with the
CodeWarrior IDE, to support building and running applications directly from
Constructor.
Dave: Constructor allows you to design a CPPb resource that describes a
“custom display class”, that is, a class derived from an existing PowerPlant
display class. How does this mechanism work?
Eric: The properties (location, size, color, etc.) for each pane or view in a
layout are stored in a bytestream. Constructor has built-in knowledge about all
of the classes that are part of the PowerPlant framework itself.
Invariably, developers need to create their own subclasses of the PowerPlant
building blocks to display the content that is specific to their application. (An
example might be to create a subclass of LTableView that displays the list of
message titles, senders, etc. in an e-mail application.)
The custom display class mechanism allows you to use Constructor to describe
these specialized classes. If the class requires extra data to be in the bytestream,
you create a CPPb resource to tell Constructor what these properties are. These
properties then appear in the property inspector alongside the properties for the
built-in class that you’ve derived from.
Custom display classes are due for a major overhaul in the next release of
Constructor. We’ll be making the process quite a lot easier and less error-prone.
Dave: Products such as WebBurst allow you to build a complete applet or
application using Constructor-like techniques, while Constructor has focused
more on the specification of the user interface. Will Constructor be moving more
into the application building model?
Robin: Constructor really started as a tool that provided easier access to the
capabilities of PowerPlant and its pane/view mechanism, allowing graphical
manipulation of the pane hierarchies. It is certainly our intent to move
Constructor forward into the application building realm in an effort to make it
easier for our customers to build applications. We will start moving in this
direction by allowing the user to handle many of the more mundane aspects of
application building directly from within Constructor. This would include
providing tools for editing the standard resources such as, ‘BNDL’, ‘FREF’, etc.
The inclusion of the new icon editor will also facilitate this by allowing the icons
for the application to be created within Constructor. We don’t necessarily want to
become the next ResEdit, but we want to enable our users to edit the resources
commonly associated with building an application on the Mac.
In addition, we want to be able to provide a tighter integration between
Constructor and the IDE in order to facilitate building an application without
having to continually switch back and forth between the two environments. One of
our goals in this direction is to allow the user to build the UI for their
application, and get it up and running without having too write any code, so that
they can quickly get something working.
Dave: WebBurst allows you to add graphic prettiness and animation to your
applets in a way not currently supported by Constructor. Will Constructor be
moving in this direction?
Robin: Many of these capabilities can be delivered by providing a richer set of
objects that can be manipulated within Constructor. It is certainly one of our
goals to provide a much richer set of objects that can be utilized in the
construction of an application’s UI. Up until now we have been focusing on getting
the core set of functionality in place. Once that task has been accomplished, we
can start to provide richer capabilities that are not in the current versions of
Constructor or PowerPlant.
We also are looking into mechanisms that will allow the user to introduce their
custom classes into Constructor so that they have the ability to extend the set of
capabilities that are available to them. CPPb’s currently allow you to do this but
you cannot see how your classes would render, so the goal is provide a mechanism
that would allow the drawing code from your classes to be available when your
classes are included in a layout, thus allowing the visual manipulation to take on
a more realistic representation than what is currently available in Constructor.
This mechanism could also potentially allow third party developers to create
class libraries that could be used from within Constructor.
Dave: Does this mean that I’ll be able to import my own code into Constructor?
Robin: This has always been one of the thorny issues with Constructor, and any
interface builder written with C++, for that matter.
Up until now we have had the CPPb mechanism which at least allows the user to
setup the values they care about for their custom classes and to manipulate their
layout, but the manipulation process has been a little unsatisfactory because
their classes have only been represented in a layout as a rectangular box, which
doesn’t exactly give you a feel for the appearance of the interface under
construction.
The problem has been that with C++ there really is no clean way to get the users
code included into Constructor, particularly the rendering aspects of the code,
which is what you care about during the layout process.
In order to address this, Eric is working on a mechanism that would allow the
users custom classes to handle the rendering of these classes within a layout,
thereby making the layout process more visual than is currently available. We
hope to make this available in a future version of Constructor in order to
improve the layout process for custom classes.
As part of this effort we would also like to improve the CPPb mechanism so that
it has greater flexibility, particularly in terms of the types that are available
for constructing CPPbs.
Dave: What kind of changes do you see in future versions of Constructor?
Robin: Well as we’ve already mentioned, you can expect to see Constructor move
more towards the application building realm, by allowing the user to perform
many of the operations required to build an application directly from within
Constructor. It is also our intent to establish a tighter integration with the IDE so
that tasks, such as running or building the application, can be initiated from
within Constructor.
We will also continue to develop the feature set of Constructor in order to deliver
more power and flexibility to the application development process.
For example, we are planning on enhancing Constructor’s abilities to manage the
various assets that come into play in the application building process. This
basically can be viewed as a cataloging process that will provide the user with a
centralized location for storing, browsing, and retrieving the various elements
that are used to build both the UI for the application, as well as the application
itself. This cataloging mechanism would be flexible enough to allow the user to
drag elements from a catalog into a layout, or conversely to be able to drag a
collection of elements from a layout back into the catalog for future reuse. The
contents of the catalog would not be restricted to simple widgets, but would
include all of the pieces needed in the construction process.
Another area we intend to improve is the inspection and editing of object
properties, some of which you can get an early glimpse of by looking at the Java
version of Constructor. This mechanism will be used in the PowerPlant version
as well, and will be enhanced to provide a richer set of property editing
capabilities.
As shown in the latest version of Constructor, with the inclusion of the icon
editor, we want to continue delivering more of the resource editing capabilities
that are needed in order to successfully construct an application.
We are definitely not standing still on Constructor. It is our goal to continue
moving the tool forward in an effort to make it more powerful, flexible, and
extensible. We also want to make it more accessible to novice users by continuing
to improve its interface and the set of capabilities it delivers.
Clint: Since we are using live Java objects for displaying the interface, we plan
to allow installation of user classes in Constructor, so that one could build
interfaces with live instances of their classes. Along with this, we would like to
provide a mechanism for added data in Constructor which could be streamed into
user classes at runtime, similar to custom types in the PowerPlant Constructor.
Eric: The major directions for Constructor in the future are to take more of the
gruntwork out of PowerPlant programming and to extend the resource-editing
capabilities of the tool.
In the end, this is a tool to help users write great applications. Many of the
features that you’ve seen implemented or planned are the direct result of user
suggestions or comments. I invite people to contact me directly by e-mail
(scouten@metrowerks.com) if they have new ideas that they’d like to see in future
Constructors.