BeOS Plug In Translators
Volume Number: 13
Issue Number: 1
Column Tag: Betech™
BeOS Plug-ins
By William Adams, Be, Inc.
Easy image import using the BeOS plug-in architecture
The computer software industry is prone to intergalactic paradigm shifts. When a
company comes out with something new, and they want to make a lot of money, they
call it a paradigm shift. This is often a code word that says: we have something that is
so different from everything else, it's actually difficult to learn, but we spent a lot of
money producing it, so we are calling it a new paradigm.
Paradigm shifts are not always difficult. When Xerox invented a windows based
interface that utilized a mouse, you could call this a paradigm shift. It sharply
diverged from the traditional text-based, keyboard bound interface of the day and
provided a method of interaction with computers that was easier and faster for many
users. If you cannot get a paradigm adopted, (it becomes too expensive due to
learnability or other factors) it is worth about $0.20.
PC's and mainstream operating systems have been around for about 15 years. This is
also true for some of the hardware that supports them. The operating system is a
crafty little piece of software that most end users should not care much about beyond
the extent that it enables them to go about doing their work efficiently. To a
programmer, the operating system should make it easy to create compelling and useful
software with the least amount of effort. It should run the software as efficiently as
possible on any targeted hardware platform. It must be flexible and dynamic enough to
adapt and change as time progresses so applications do not begin to run slower with
each release.
The commodity software market is still very young, with only 15 years of real
commercial growth. This youth is most evident in the systems that were available at
the beginning of that period. The machines of the day were pitifully slow and very
constrained by resources such as RAM and disk space. At the time, a network
connection was a 300 baud modem linked to a timesharing system. TCP/IP protocol
stacks and Ethernet cards were merely chalk dust. Given this crucible of development,
it's no wonder that when these new technologies began to show up, the OS and
programming tools began to grow warts. Tack on a device driver here, an Ethernet card
there, and pray that it all still works. If you are a developer, pray that the end user is
utilizing hardware for which you have a driver.
Thankfully, systems adapt, standards emerge, drivers are written, abstraction layers
are added, and paradigms are shifted. The Be Operating System (BeOS) is not so much a
paradigm shift as it is a convergence, consolidation, and re-alignment. The engineers
at Be are all students of OS design and API production. Be presents the opportunity to
do it all over again. In "doing it right," we are not necessarily seeking to re-invent the
wheel, only to get the right balance. You can view us as OS chiropractors. Current OS
offerings are like elderly gentlemen sagging under their own weight. Things are just a
little misaligned in most commodity OS's, and the BeOS straightens things out.
We can look at two vertebrae of the typical misaligned OS - one is data sharing, the
other is command processing. First, let's look at data sharing. I have one application,
or portion of an application, and I want to share data with another application. A
typical method of sharing is the copy/paste combination. I might select a piece of an
image in a paint program and paste it into another. Another method is to drag a file
representation from a file browser onto the paint canvas. Alternately, I may receive
an image from a server process, or from across a network.
For many programmers, these various operations would each be represented by a
distinctly different API in a misaligned OS. Since there are many APIs to learn,
programmers will not implement all of the operations. Without continuous support for
many common operations, the road a user must travel to get to the end of any
particular task becomes rutted and bent.
The other major misaligned vertebrae have to do with data processing. From the
resource constrained crucibles of software development of 15 years ago emerged
coding styles and techniques that should seem like quaint anachronisms in the blinding
light of today's resource heavy devices. Another Xerox invention, the SmallTalk
language, provided what is not really a paradigm shift as much as it is a sanity check.
Computers are not yet artificial life forms that we expect to work and learn
independently for the betterment of the universe. They are generally clunky, noisy
boxes that we shove endless amounts of data into and have them transform it into a
different form, then spit it back out. Computer's process data - no matter what form
that data takes, there are methodologies that can be adhered to in order to maintain
consistency and generate expected results. We expect good software to perform this
way. It will do you no good if the computer in your car decides to turn on your lights
instead of deploy your airbag in an accident.
The SmallTalk environment introduced a programming methodology known as Model,
View, Controller. In this methodology, the model is the data of the system. This is true
for a word processing system, a game, or an accounting package. The view is simply
the interface through which a user interacts with the system. This includes all
external influences such as displays, mice, keyboards, printers, speakers, etc. The
controller is the mechanism by which the view (interface) can affect changes on the
data. For exeample, we press the delete key to delete the selected text in a word
processor. It is extremely beneficial to the developer if the programming environment
provides a mechanism adhering to this model. A misaligned system provides no such
mechanism, and thus leaves it to all developers to re-invent the same mechanism.
Such a programming community is not working efficiently, and could be more
innovative.
Enough Misalignment, What About Be?
One of the primary target markets for the BeOS is multimedia authors and editors.
This crowd generally uses products such as PhotoShop, Premiere, Fractal Design
Painter and the like. One of the biggest problems encountered by this set of users is
inter-operability between applications. Sharing files and effects across applications is
sometimes time consuming and frustrating. To solve this problem, we present
Rraster, an image viewer with a window. You can drag and drop files onto the icon and
the application will open up and display the image. You can also copy and paste a
selection between applications, or onto the same canvas.
In our sample code we will demonstrate how to extend an application to support a wide
variety of graphics file formats, without having to wait for the original manufacturer
to do so. This capability is similar to PhotoShop plug-ins, as well as in other products.
We start with a general specification of what the program should do:
• Give the user a way of dragging and dropping graphic images from the file
browser onto the interface and have them displayed.
• Provide a mechanism to support drag and drop pasting from another
source.
• Provide the ability to accept any file format for which a codec is
available.
The last point is the most important, and the rest is the supporting framework. An
image codec translates an image from one format to another. For example, a GIF codec