Structure of the BeOS 5
before original applications need major overhauling (as is the case for, say, a Mac-
intosh application written for an early version of the Mac OS).
Structure of the BeOS
Be applications run on hardware driven by either Intel or PowerPC microproces-
sors (check the BeOS Support Guides page at http://www.be.com/support/guides/
for links to lists of exactly which Intel and PowerPC machines are currently sup-
ported). Between the hardware and applications lies the BeOS software. As shown
in Figure 1-1, the operating system software consists of three layers: a microkernel
layer that communicates with the computer’s hardware, a server layer consisting of
a number of servers that each handle the low-level work of common tasks (such
as printing), and a software kit layer that holds several software kits—shared
libraries (known as dynamically linked libraries, or DLLs, to some programmers)
that act as a programmer’s interface to the servers and microkernel.
Microkernel
The bottom layer consists of the microkernel. The microkernel works directly with
the hardware of the host machine, as well as with device drivers. The code that
makes up the microkernel handles low-level tasks critical to the control of the
computer. For instance, the microkernel manages access to memory. The kernel
also provides the building blocks that other programs use: thread scheduling, the
file system tools, and memory-locking primitives.
Servers
Above the microkernel lies the server layer. This layer is composed of a number of
servers—processes that run in the background and carry out tasks for applications
that are currently executing. For example, the purpose of the Input Server is
Figure 1-1. The layers of the BeOS reside between applications and hardware
Application
Software Kits
Server
Microkernel
Hardware
6 Chapter 1: BeOS Programming Overview
to handle access to all the various keyboards, mice, joysticks, and other input
devices that may be connected to a machine running the BeOS. Another server
is the Application Server, a very important server that handles the display of
graphics and application communication. As a programmer you won’t work
directly with servers; instead, you’ll rely on software kits to access the power of
the server software.
Kits
Above the server layer is the software kit layer. A kit consists of a number of
object-oriented classes that a programmer makes use of when writing a BeOS pro-
gram. Collectively the classes in the software kits comprise the BeOS API. You
know that the abbreviation API stands for application programming interface. But
what does the application interface to? Other software. For Be applications, the
kits are the interface to the various servers. For instance, the Application Kit holds
several classes used by programmers in your position who are trying to create
tools for users. The programmer writes code that invokes methods that are a part
of the classes of the Application Kit, and the Application Kit then communicates
with the Application Server to perform the specified task. A couple of the other
servers you’ll encounter in your Be programming endeavors are the Print Server
and the Media Server.
Some kits don’t rely on servers to carry out microkernel-related operations—the
chores they take care of may be simple and straightforward enough that they don’t
need their own server software. Instead, these kits directly invoke microkernel
code. As you can see in Figure 1-1, an application relies directly on the software
kits and indirectly on the servers and microkernel.
As you become more proficient at BeOS programming, you’ll also become more
intimate with the classes that comprise the various software kits. Now that you
know this, you’ll realize that it is no accident that the majority of this book is
devoted to understanding the purpose of, and working with, the various BeOS
kits.
This book is tutorial in nature. Its purpose is to get you acquainted
with the process of developing applications that run on the BeOS
and to provide an overview of the BeOS API. Its purpose isn’t to
document the dozens of classes and hundreds of member functions
that make up the BeOS API. After—or while—reading this book, you
may want such a reference. If you do, consider the books Be Devel-
oper’s Guide and Be Advanced Topics, also by O’Reilly & Associates.
Software Kits and Their Classes 7
Software Kits and Their Classes
The application programming interface of the BeOS is object-oriented—the code
that makes up the software kits is written in C++. If you have experience program-
ming in C++ on any platform, you’re already at the midpoint in your journey to
becoming adept at BeOS programming. Now you just need to become proficient
in the layout and use of the classes that make up the software kits.
Software Kit Overview
The BeOS consists of about a dozen software kits—the number is growing as the
BeOS is enhanced. Don’t panic, though—you won’t be responsible for knowing
about all the classes in all of the kits. Very simple applications require only the
classes from a very few of the kits. For instance, an application that simply dis-
plays a window that holds text uses the Application Kit and the Interface Kit. A
more complex application requires more classes from more kits. Presentation soft-
ware that stores sound and video data in files, for example, might require the use
of classes from the Storage Kit, the Media Kit, and the Network Kit—as well as
classes from the two previously mentioned kits. While it’s unlikely that you’ll ever
write a program that uses all of the BeOS kits, it’s a good idea to at least have an
idea of the purpose of each.
The kits of the BeOS are subject to change. As the BeOS matures,
new functionality will be added. This functionality will be supported
by new classes in existing kits and, perhaps, entirely new software
kits.
Application Kit
The Application Kit is a small but vitally important kit. Because every applica-
tion is based on a class derived from the BApplication class that is defined
in this kit, every application uses the Application Kit.
The Application Kit defines a messaging system (described later in this chap-
ter) that makes applications aware of events (such as a click of a mouse but-
ton by the user). This kit also give applications the power to communicate
with one another.
Interface Kit
The Interface Kit is by far the largest of the software kits. The classes of this
kit exist to supply applications with a graphical user interface that fully sup-
ports user interaction. The definition of windows and the elements that are
contained in windows (such as scrollbars, buttons, lists, and text) are handled
8 Chapter 1: BeOS Programming Overview
by classes in this kit. Any program that opens at least one window uses the
Interface Kit.
Storage Kit
The Storage Kit holds the classes that store and update data on disks. Pro-
grams that work with files will work with the Storage Kit.
Support Kit
As its name suggests, the contents of the Support Kit support the other kits.
Here you’ll find the definitions of datatypes, constants, and a few classes.
Because the Support Kit defines many of the basic elements of the BeOS (such
as the Boolean constants true and false), all applications use this kit.
Media Kit
The Media Kit is responsible for the handling of real-time data. In particular,
this kit defines classes that are used to process audio and video data.
Midi Kit
The Midi Kit is used for applications that process MIDI (Musical Instrument
Digital Interface) data.
Kernel Kit
The Kernel Kit is used by applications that require low-level access to the
BeOS microkernel. This kit defines classes that allow programmers to explic-
itly create and maintain threads.
Device Kit
The Device Kit provides interfaces to hardware connectors (such as the serial
port), and is necessary only for programmers who are developing drivers.
Network Kit
The Network Kit exists to provide TCP/IP services to applications.
OpenGL Kit
The OpenGL Kit provides classes that allow programmers to add 3D capabili-
ties to their programs. The classes aid in the creation and manipulation of
three-dimensional objects.
Translation Kit
The Translation Kit is useful when a program needs to convert data from one
media format to another. For instance, a program that can import an image of
one format (such as a JPEG image) but needs to convert that image to another
format might make use of this kit.
Mail Kit
The Mail Kit assists in adding Internet email services (such as sending mes-
sages using Simple Mail Transfer Protocol (SMTP) to an application).
Software Kits and Their Classes 9
Game Kit
The Game Kit—which is under development as of this writing—consists of
two major classes that support game developers.
BeOS Naming Conventions
Some of the many classes that make up the BeOS are discussed a little later. As
they’re introduced, you’ll notice that each starts with an uppercase letter “B,” as in
BMessage, BApplication, and BControl. This is no accident, of course—the
software of the kits follows a naming convention.
The BeOS software kits consist of classes (which contain member functions and
data members), constants, and global variables. The BeOS imposes a naming con-
vention on each of these types of elements so that anyone reading your code can
readily distinguish between code that is defined by the BeOS and code that is
defined by your own program. Table 1-1 lists these conventions.
Classes of the BeOS always begin with an uppercase “B” (short for “BeOS”, of
course). Following the “B” prefix, the first letter of each word in the class name
appears in uppercase, while the remainder of the class name appears in
lowercase. Examples of class names are BButton, BTextView, BList, and
BScrollBar.
Member functions that are defined by BeOS classes have the first letter of each
word in uppercase and the remainder of the function name in lowercase. Exam-
ples of BeOS class member function names are GetFontInfo(), KeyDown(),
Frame(), and Highlight().
Data members that are defined by BeOS classes have the first letter of each word
in uppercase and the remainder of the data member name in lowercase, with the
exception of the first word—it always begins in lowercase. Examples of BeOS
class data member names are rotation and what.
Table 1-1. BeOS Naming Conventions
Category Prefix Spelling Example
Class name B Begin words with uppercase letter BRect
Member function none Begin words with uppercase letter OffsetBy()
Data member none Begin words (excepting the first) with
uppercase letter
bottom
Constant B_ All uppercase B_LONG_TYPE
Global variable be_ All lowercase be_clipboard
10 Chapter 1: BeOS Programming Overview
I’ve included only a couple of examples of data member names
because I had a hard time finding any! Be engineers went to great
lengths to hide data members. If you peruse the Be header files
you’ll find a number of data members—but most are declared pri-
vate and are used by the classes themselves rather than by you, the
programmer. You’ll typically make things happen in your code by
invoking member functions (which themselves may access or alter
private data members) rather than by working directly with any data
members.
Constants defined by BeOS always begin with an uppercase “B” followed by an
underscore. The remainder of the constant’s name is in uppercase, with an under-
score between words. Examples include: B_WIDTH_FROM_LABEL, B_WARNING_
ALERT, B_CONTROL_ON, and B_BORDER_FRAME.
The BeOS software includes some global variables. Such a variable begins with the
prefix “be_” and is followed by a lowercase name, as in: be_app, be_roster, and
be_clipboard.
Software Kit Inheritance Hierarchies
The relationships between classes of a software kit can be shown in the inherit-
ance hierarchy for that kit. Figure 1-2 shows such an inheritance hierarchy for the
largest kit, the Interface Kit.
The kits that make up the BeOS don’t exist in isolation from one
another. A class from one kit may be derived from a class defined in
a different kit. The BWindow class is one such example. Kits serve as
logical groupings of BeOS classes—they make it easier to categorize
classes and conceptualize class relationships.
Figure 1-2 shows that the object-oriented concept of inheritance—the ability of
one class to inherit the functionality of another class or classes—plays a very large
role in the BeOS. So too does multiple inheritance—the ability of a class to inherit
from multiple classes. In the figure, you see that almost all of the Interface Kit
classes are derived from other classes, and that many of the classes inherit the con-
tents of several classes. As one example, consider the six control classes pictured
together in a column at the far right of Figure 1-2. An object of any of these classes
(such as a BButton object) consists of the member functions defined in that class
as well as the member functions defined by all of the classes from which it is
directly and indirectly derived: the BControl, BInvoker, BView, BHandler, and
Software Kits and Their Classes 11
BArchivable classes. Figure 1-3 isolates the discussed classes for emphasis of this
point. This figure shows that in inheritance hierarchy figures in this book, a class
pictured to the left of another class is higher up in the hierarchy. In Figure 1-3,
BView is derived from BHandler, BControl is derived from BView, and so forth.
Figure 1-2. The inheritance hierarchy for the Interface Kit
Application Kit
Other Be Kit
BRoster
BRoster
BObjects
Support Kit
BRegion
BPolygon
Application Kit Application Kit
BHandler BLooper BWindow BAlert
BView BTextView
BStringView
BBox
BControl BTextControl
BColorControl
BCheckBox
BRadioButton
BPictureButton
BButton
BPopUpMenu
BMenuBar
BScrollBar
BScrollView
BListView
BMenu
BMenu
BPrintJob
BPicture
BBitmap
BMenuItem BSeparationItem
12 Chapter 1: BeOS Programming Overview
Understanding the class hierarchies of the BeOS enables you to
quickly determine which class or classes (and thus which member
functions) you will need to use to implement whatever behavior
you’re adding to your program. Obviously, knowledge of the class
hierarchies is important. Don’t be discouraged, though, if the hierar-
chies shown in Figures 1-2 and 1-3 don’t make complete sense to
you. This chapter only provides an overview of the object-oriented
nature of the BeOS. The remainder of the book fills in the details of
the names, purposes, and uses of the important and commonly used
classes.
The BControl class defines member functions that handle the needs common to
any type of control. For instance, a control should be able to have two states:
enabled or disabled. An enabled control is active, or usable by the user. A dis-
abled control is inactive—and has a greyed-out look to let the user know it is
unusable. To give controls the ability to implement this behavior, the BControl
class includes the SetEnabled() member function. This routine is used to enable
or disable a control—any kind of control. Individual types of controls will have
some needs that aren’t common to all other types of controls and thus can’t be
Figure 1-3. The Interface Kit classes that contribute to the various control classes
Application Kit
Other Be Kit
BObjects
Support Kit
Application Kit
BHandler
BView
BTextControl
BColorControl
BCheckBox
BRadioButton
BPictureButton
BButton
BControl
BeOS Programming Fundamentals 13
implemented by the BControl class. For example, different controls (such as but-
tons and checkboxes) have different looks. To make it possible for each control
type to be able to draw itself, each control class defines its own constructor to ini-
tialize the control and a Draw() member function to handle the drawing of the
control.
Not all BeOS classes are derived from other classes—there are a few
classes that don’t rely on inheritance. Two examples, both of which
happen to be in the Interface Kit, are the BRect and BPoint classes.
The BRect class is used to create objects representing rectangles. A
rectangle is an easily defined, two-dimensional shape that’s consid-
ered a basic datatype. As such, it doesn’t need to inherit the func-
tionality of other classes. The BPoint class is not a derived class for
the same reason.
BeOS Programming Fundamentals
In the previous section, you gained an understanding of how the BeOS is com-
posed of numerous interrelated classes that are defined in software kits. Together
these classes form an application framework from which you build your Be appli-
cations. Your program will create objects that are based on some of the BeOS
classes. These objects will then communicate with one another and with the oper-
ating system itself through the use of messages. In this section, you’ll look at a few
of the most important of these classes, and you’ll see how they’re used. You’ll also
see how messages play a role in a BeOS program. To make the transition from the
theoretical to the practical, I’ll supply you with a few C++ snippets—as well as the
code for a complete Be application. In keeping with the introductory nature of this
chapter, I’ll make this first application a trivial one.
Messages, Threads, and Application Communication
Earlier in this chapter, you read that the BeOS is a multithreaded operating sys-
tem. You also read that the term multithreaded isn’t just bandied about by BeOS
advocates for no good reason—it does in fact play a key role in why the BeOS is a
powerful operating system. Here, you’ll get an introduction as to why that’s true.
In Chapter 4, Windows, Views, and Messages, I’ll have a lot more to say about
multithreading.
Applications and messages
A Be application begins with the creation of an object of a class type derived from
the BApplication class—a class defined in the Application Kit. Figure 1-4 shows
14 Chapter 1: BeOS Programming Overview
how the BApplication class fits into the inheritance hierarchy of the Application
Kit. Creating an application object establishes the application’s main thread, which
serves as a connection between the application and the Application Server. Earlier
in this chapter, you read that a BeOS server is software that provides services to an
application via a software kit. The Application Server takes care of many of the
tasks basic to any application. One such task is reporting user actions to applica-
tions. For instance, if the user clicks the mouse button or presses a key on the
keyboard, the Application Server reports this information to executing applica-
tions. This information is passed in the form of a message, and is received by an
application in its main thread. A message is itself an object—a parcel of data that
holds details about the action being reported. The ability of the operating system
to determine the user’s actions and then use a separate thread to pass detailed
information about that action to a program makes your programming job easier.
An application’s code can explicitly define BMessage objects and use them to pass
information. What I’ve discussed above, however, are system messages that origi-
nate from within the BeOS itself. The movement of the mouse, the pressing of a
keyboard key, a mouse button click in a window’s close button, and a mouse but-
ton click and drag in a window’s resize knob are all examples of system mes-
sages. Each type of system message has a command constant associated with it.
This constant names the type of event the message represents. Examples of com-
mand constants are B_KEY_DOWN, B_MOUSE_DOWN, and B_WINDOW_RESIZED.
Figure 1-4. The inheritance hierarchy for the Application Kit
Application Kit
Other Be Kit
BRoster
BClipboard
BObject
Support Kit
BHandler
BMessage
BMessenger
BMessageFiller
BMessageQueue
BWindow
Interface Kit
BLooper BApplication
Không có nhận xét nào:
Đăng nhận xét