Library: libbe.so
Most Be applications have an interactive and graphical user interface. When they start up, they present themselves to the user on-screen in one or more windows. The windows display areas where the user can do something--there may be menus to open, buttons to click, text fields to type in, images to drag, and so on. Each user action on the keyboard or mouse is packaged as an interface message and reported to the application. The application responds to each message as it's received. At least part of the response is always a change in what the window displays--so that users can see the results of their work.
To run this kind of user interface, an application has to do three things. It must:
The application, in effect, carries on a conversation with the user. It draws to present itself on-screen, the user does something with the keyboard or mouse, the event is reported to the application in a message, and the application draws in response, prompting more user actions and more messages.
The Interface Kit structures this interaction with the user. It defines a set of C++ classes that give applications the ability to manage windows, draw in them, and efficiently respond to the user's instructions. Taken together, these classes define a framework for interactive applications. By programming with the kit, you'll be able to construct an application that effectively uses the capabilities of the Be operating system.
This chapter first introduces the conceptual framework for the user interface, then describes all the classes, functions, types, and constants the kit defines. The reference material that follows this introduction assumes the concepts and terminology presented here.
A graphical user interface is organized around windows. Each window has a particular role to play in an application and is more or less independent of other windows. While working on the computer, users think in terms of windows--what's in them and what can be done with them--perhaps more than in terms of applications.
The design of the software mirrors the way the user interface works: it's also organized around windows. Within an application, each window runs in its own thread and is represented by a separate BWindow object. The object is the application's interface to the window the system provides; the thread is where all the work that's centered on the window takes place.
Because every window has its own thread, the user can, for example, scroll the contents of one window while watching an animation in another, or start a time-consuming computation in an application and still be able to use the application's other windows. In its interaction with the user, each window acts on its own, independently of other windows. A window won't stop working when the user turns to another window.
In a multitasking environment, any number of applications might be running at the same time, each with its own set of windows on-screen. The windows of all running applications must cooperate in a common interface. For example, there can be only one active window at a time--not one per application, but one per machine. A window that comes to the front must jump over every other window, not just those belonging to the same application.
Because it would be difficult for each application to manage the interaction of its windows with every other application, windows are assigned, at the lowest level of the operating system, to a separate entity, the Application Server. The server's principal role in the user interface is to provide applications with the windows they require.
Everything a program or a user does is centered on the windows the Application Server provides. Users type into windows, click buttons in windows, drag images to windows, and so on; applications draw in windows to display the text users type, the buttons they can click, and the images they drag.
The Application Server, therefore, is the conduit for an application's message input and drawing output:
The server relieves applications of much of the burden of basic user-interface work. The Interface Kit organizes application's interaction with the server and further simplifies the work of building a user interface.
Every window in an application is represented by a separate BWindow object. Constructing the BWindow establishes a connection to the Application Server--one separate from, but initially dependent on, the connection previously established by the BApplication object. The server creates a window for the new object and dedicates a separate thread to it.
The BWindow object is a kind of BLooper--so, when it's first shown on-screen, it spawns a thread for the window in the application's address space and begins running a message loop where it receives and responds to interface messages from the server. The window thread in the application is directly connected to the dedicated thread in the server.
The BWindow object, therefore, is in position to serve three crucial roles:
All other Interface Kit objects play roles that depend on a BWindow. They draw in a window, respond to interface messages received by a window, or act in support of other objects that draw and respond to messages.
For purposes of drawing and message handling, a window can be divided up into smaller rectangular areas called views. Each view corresponds to one part of what the window displays--a scroll bar, a document, a list, a button, or some other more or less self- contained portion of the window's contents.
An application sets up a view by constructing a BView object and associating it with a particular BWindow. The BView object is responsible for drawing within the view rectangle and for handling interface messages directed at that area.
A window is a tablet that can retain and display rendered images, but it can't draw them; for that it needs a set of BViews. A BView is an agent for drawing, but it can't render the images it creates; for that it needs a BWindow. The two kinds of objects work hand in hand.
Each BView object is an autonomous graphics environment for drawing. Some aspects of the environment, such as the list of possible colors, are shared by all BViews and all applications. But within those broad limits, every BView maintains an independent graphics state. It has its own coordinate system, current colors, drawing mode, clipping region, font, pen position, and so on.
The BView class defines the functions that applications call to carry out elemental drawing tasks--such as stroking lines, filling shapes, drawing characters, and imaging bitmaps. These functions are typically used to implement another function--called Draw()--in a class derived from BView. This view-specific function draws what is shown in the view rectangle.