Section 1 Behind the Scenes Section 2 Behind the Scenes, continued In This Section: Behind the Scenes, continued The Interface Kit Kernel Kit Media Kit Network Kit Game Kit The Support Kit The Translation Kit The Mail Kit Chapter Summary The Interface Kit Because it's central to the construction and operation of almost all aspects of the BeOS GUI--especially for applications--the Interface Kit is the Big Kahuna: the largest and most complex of all the Kits. The Interface Kit works in close conjunction with the Application Kit to provide your applications' most commonly used objects. At the bare minimum, every application consists of a window and a "view" (views are containers inside windows, and play host to text spaces, image spaces, buttons and sliders, slider controls, oscilloscope readouts, backgrounds, etcetera). Providing windows, views, and all of the common interface elements you're accustomed to using in your applications is the job of the Interface Kit. This Kit also takes on all responsibilities related to drawing to the screen. The relationship of views to windows is hierarchical, much like the filesystem. Whenever a window is created, it simultaneously creates a "top view" of exactly the same dimensions as the window, filling it completely. Everything filling the space of the application window exists as a "child" of the top view. The top view doesn't "do" anything, but acts as an umbrella for all the views it contains. Figure 3 The window-to-view relationship in a hypothetical application. Note that the parent window hosts all of the views it contains, and that views can contain other views. Every application window includes a top view, which acts as an umbrella object for everything else going on in the window. The children of the top view may or may not overlap one another within the window, and may or may not contain child views of their own. Figure 3 diagrams a hypothetical application. The top (or parent) view is shown containing two major views (one where the user works and another that displays various status and reporting outputs representing the current state of that work). The work view contains a variety of control objects (slider, dial, text input, and button). The report view, in turn, is a parent to three more views, which will be laid out in the application space according to the developer's placement instructions. Boundaries between views may or may not be visible to the user. All child views inherit certain properties from their parents. For example, if the work view is defined as being 400 pixels wide, then text view, list view, and image view will inherit that 400-pixel "bounding box"--they won't be visible outside of that boundary no matter what the programmer does. Drawing In order for anything to be situated inside a view, it must be drawn there. Drawing is the function of several subclasses of the Interface Kit, including the "pen," which establishes pixel coordinates and stroke widths, color management calls, drawing modes such as copy, erase, invert, transparency, and select, and an updating function that redraws screen areas to reflect changed information. Interface Messages Another important responsibility of the Interface Kit is responding to the user's keyboard and mouse actions. When you press a letter on your keyboard, you want to see that letter onscreen immediately. When you double-click an application's title tab, you want that app to minimize. When you drag the "grippy dots" at the bottom right of a window, you want that window to be resized smoothly and instantly, the contents of its window reflowing if necessary. When you tap a menu trigger hotkey, you want to see that pulldown menu. All of these actions are known as "interface messages," and must be intercepted and responded to by code in the Interface Kit. Character Encoding Meditate for a moment on what it would take to get BeOS working in French or German. Now imagine extending that translation job to Hebrew or Korean, where entirely different character sets are used. Obviously, this is a job much larger than simple translation--you can't simply pick a Hebrew font, hire a human translator, and expect everything to work like magic. Because of their complexity, foreign character sets require more bits of information per character than do languages using the standard ASCII set. ASCII encodes characters with eight bits, while complex character sets require 16 bits. The 16-bit encoding scheme agreed upon by international committee is called Unicode, and BeOS is fully Unicode aware. While everything in the ASCII set can, of course, be encoded in the 16-bit system, the drawback to this is that you end up with a lot of wasted space when each character unnecessarily takes up 16 bits of memory. The solution to this dilemma is an encoding (which is sort of like a translation map) of Unicode called UTF-8 (UCS Transformation Format, where UCS stands for Universal Multiple-Octet Character Set, which is, in turn, simply longhand for Unicode). UTF-8 represents a multilingual encoding solution for BeOS by allowing complex character sets to be handled at the operating system level, while still retaining backward compatibility with the standard ASCII character set. Eight-bit encoding is actually somewhat more complex than that, but this is the gist of it. All Unicode encoding and decoding is handled by the Interface Kit. Coordinate Spaces Determining where windows and objects are placed onscreen is another biggie for the Interface Kit. The system must know at all times where the top-left and bottom-right corners of every window and object are onscreen, and be able to place objects where the programmer wants them (initially) and where the user later moves them. This task is made somewhat more complex by the fact that users run their systems at different resolutions (Chapter 9, Preferences), and may opt to print at varying resolutions as well. Text Views There are dozens of ways for text to manifest on your screen: in the main window of your word processor, in lists, on menu bars, on buttons, in dialog box fields, and so on. Each of these has a separate API call defining individual characteristics, such as how many characters lines should wrap after, whether there's a limit on how much text can be entered into a space, whether the text is editable by the user, how to jump to a certain line, how to find text strings, whether it's OK to paste text into the view ... all of this is handled by the Interface Kit. Miscellany The more you study the BeOS interface, the more you realize how many different widgets are part of it, and how many considerations there are in accommodating applications no matter what they want to accomplish. Should a section of a dialog box be bounded with a fancy, raised border, or with a plain, "line" border? How should alert boxes look and behave? Should sliders have hash marks beneath them or not? Should the slider buttons be square, triangular, or some other shape? Should windows by resizable or not? How should your paint application's color picker appear? How should dialog boxes respond when the user changes the system font size? (This last question is not well-handled by BeOS R4, as you'll discover if you use system-wide fonts larger than a certain size--you'll notice that some of the text on buttons and in dialogs will be "clipped." Expect this to be fixed system-wide in a future release.) How can a program present a list of only monospaced fonts? How do developers get those little icons into your applications' toolbars? How should progress indicators appear, and how should they behave? How does the program bring a given view into focus, making it the target of the user's actions? The list goes on and on, and every little detail of every option related to everything in the user interface is made possible by the global codebase of the Interface Kit. It's a real doozy. In fact, the Interface Kit consumes the bulk of dead-tree mass in The Be Developer's Guide. Kernel Kit At the opposite end of the spectrum from the Interface Kit, which defines all the stuff the user sees and interacts with, is the Kernel Kit, which defines very low-level kernel services which are only experienced by the user indirectly. Threads and Teams We've discussed BeOS's multithreadedness at several points in this book. Developers control threads and their communication with one another via the Kernel Kit. While threads function more or less as free agents (independently of one another), the group of threads that belong to a given application is referred to as a "team," and all of the threads in a team can work in conjunction with one another. Any time developers want to make their application more "fine-grained," they can spawn new threads to handle specific tasks. For instance, an Internet application that needs to check a Web site for updates might spawn a dedicated thread that does nothing but keep a watchful eye on a given URL, reporting its findings back to the application. Because an application can't exist without threads, killing off a team (see Chapter 6, The Terminal, for thread- and team-killing techniques) has the result of killing the application. It's worth pointing out that threads are very "inexpensive" on BeOS. That means that creating and destroying threads barely consumes any of the computer's resources at all. "When in doubt, spawn another thread" is a phrase that gets tossed around amongst developers occasionally. Just how cheap are threads? One real-time video demo created by Be engineers creates and destroys 60 threads per second. While few (if any) real-world applications call for that level of threading, it does demonstrate the fact that BeOS handles threads like nobody's business. If you see an application calling itself "heavily multithreaded," don't think for a moment that it means that the application is a resource hog! Ports With all the messages moving around beneath the surface of your system at any given time, it becomes necessary to have some place for the threads to call home. A port is sort of like a mailbox for threads--they can deposit their messages in these virtual harbors so that other threads can come and pick them up for further processing. Ports are owned by the teams that create them. When the team dies or is killed off, they take their ports with them into the bit bucket. Semaphores When studio musicians lay down independent tracks to be mixed together later, they need a way to synchronize their efforts. The most common way of doing this is via something called a "click track," a sort of metronome used to keep everyone working at the same tempo. The click track is used during the mixing stage to make sure all of the tracks are stored on the final recording in perfect synchronization. Semaphores perform a similar function for threads, and are a sort of abstraction of the Kernel Kit. Any time a program needs to synchronize threads with one another, it uses a semaphore to "lock" the running function until the semaphore has been acquired. In other words, semaphores are sort of like guard dogs, blocking a thread's progress until it's safe to pass. Areas As described in Chapter 9, Preferences, BeOS makes heavy use of virtual memory to cache parts of application code that are likely to be used again. Efficient use of virtual memory is one of the things that makes BeOS so fast. An "area" is a chunk of virtual memory roped off by the running application. If useful or necessary, an area can be made shareable so the data it contains is available to other applications. Alternatively, an area can be locked into RAM and optionally read/write protected. Images To the Kernel Kit, images have nothing to do with graphics. Instead, they refer to chunks of compiled code that can be linked to a running application. Every application has a single "app image," while dynamically linked libraries have "library images," and all of your add-ons have "add-on images." Most developers don't need to think about images; for most uses, the automatically created app image is all that's needed. Media Kit Figure 4 Like all of the Kits, the Media Kit is structured modularly. The application communicates with a media library and all of its add-ons, while the library communicates through the system's memory protection barrier with the media server and media add-ons. The whole structure sits on top of the system's kernel-level drivers (the driver for your video capture card, for example). The youngest member of the Kit family is the newly revamped Media Kit, which was almost completely rewritten from scratch for BeOS R4. The new Media Kit is a cornerstone in Be's ongoing strategy to become the "SGI for the rest of us" and to make BeOS excel at creating and consuming professional digital content on consumer-level computers. The rewrite of the Media Kit also consolidated a number of services previously spread across various other Kits, such as the audio server (which continues to exist for backward-compatibility, but is officially "deprecated" by the new media server). The appearance of the new Media Kit also introduced a brand-new media server, which provides services to all types of timed media (with the primary emphasis being on audio and video in R4). The Media Kit provides support for all forms of media, including the recording and playback of audio/visual signals, as well as access to a wide array of input/output media cards and devices. The Kit is structured around the concept of "nodes," which are like media modules available to the system on which an application is running (you can think of a node as a sort of bridge between an application and a given driver). The Media Kit's nodes are unrelated to the filesystem's nodes, described earlier. A node in the filesystem is an aread sketched out on the platter of your hard disk, while a media node is an abstract entity, existing in memory alone, and relating only to media functions. In turn, there are two types of nodes: consumers and producers. Consumers accept media input and producers create it. Any node that is both a consumer and a producer can also be consider a "filter" because it can be used to alter the state of an audio or visual signal. BeOS maintains an internal roster (BMediaRoster) on each running system so that applications can easily discover which nodes are available to them for use. These nodes can be tied together into a virtual "web" of controls (also known as a "parameter web"), which is then accessible as a single entity from other applications. One of the great things about this arrangement is that the developer has to do very little work to tap into BeOS's media capabilities. Rather than writing code to invoke an audio or video stream, a program just grabs onto a live node (or "instantiates" a dormant node from an installed add-on), connects it to a web, and requests a view in an application window to encapsulate whatever is moving through the web. The new Media Kit also provides extremely tight timing functions that developers can use to synchronize audio soundtracks with video footage (for example). A program can optionally tell all of its nodes that they're "slaves" to a master timing signal, so that concurrently running audio and video streams stay in sync. Because BeOS is so efficient, sound card latencies are far shorter than they are for the same sound card running under Windows or Linux. While latencies of up to 30 milliseconds are not uncommon under Windows, BeOS is capable of addressing sound cards at latencies of around six milliseconds. It's going to get even better than that, too. Be engineers are working toward a goal of one to two millisecond latencies, and early tests indicate that they should be able to reach this goal--on standard, consumer-level audio hardware no less. This efficiency, combined with the ease of development offered by the BeOS Media Kit, is seen as a great relief by many developers who have spent tedious hours trying to talk to audio hardware on other platforms at a low level. Finally, the new Media Kit introduces a handful of codecs (compression/decompression algorithms--drivers that allow for the creation and translation of audio and video streams). As of R5, MIDI functions will also make their home in the Media Kit, rather than living in the previously separate MIDI Kit. The MIDI kit no longer exists a separate entity. Network Kit Obviously, the Network Kit provides all of the functions necessary to implement BeOS networking, whether over TCP/IP or UDP (UDP is a less common Internet protocol often used for Internet gaming or Webcast audio/video--it dispenses with error checking in favor of some speed gains). In addition, the Network Kit provides a mechanism by which add-ons can be written to enable BeOS support for common non-Internet protocols such as AppleTalk, NetBEUI, IPX, and others. TCP/IP networking in BeOS is based on the open Berkeley Sockets (BSD) model. While the Network Kit once upon a time handled e-mail functions as well, that responsibility has been broken out into the separate Mail Kit. The Network Kit works in conjunction with the net_server to establish communications with various network protocols. It handles incoming and outgoing packets, IP addresses, and communication with network devices such as your PPP connection and/or network interface cards. Game Kit Any time you launch a game that takes over your entire screen, you know you're looking at the Game Kit in action. The Game Kit exists to offer maximum speed and direct access to underlying hardware. Since most games are hardware- and OS-intensive, this Kit provides developers with the means to maximize the overall quality of the user's gaming experience. While nothing in the Game Kit restricts its use to gaming, the BeBook coyly notes that even when the Kit is used for non-gaming purposes, "the user will have to deposit another 50 cents every three minutes." Of course, one of the big benefits of the Game Kit is access to the BDirectWindow and BWindowScreen system calls, which allow applications to write massive amounts of video instructions straight to the guts of the video card, simultaneously bypassing most operating system overhead--an ideal state of affairs for intensive gaming action. BDirectWindow is also used for tasks like capturing or processing video streams, allowing tons of data to be written to the screen quickly. Read more about BDirectWindow on page 20 in Chapter 1, The MediaOS. Remember: Any time an application has launched into Game Kit mode and doesn't provide an obvious escape hatch, you can quit by pressing Alt+Q or by toggling to another workspace and quitting the app from the Deskbar. The Support Kit While most of the Kits apply to specific categories of applications, the Support Kit is available to all applications, and contains a number of classes and utilities that provide extra functionality, such as the ability to turn applications into Replicants. One of the most interesting aspects of the Support Kit is the BArchivable class, which allows objects to be copied into a static ("freeze-dried") form and handed off to another application, stored in memory cache, or saved out to a file. One of the most common implementations of the BArchivable class is to create Replicants (page 74 in Chapter 2, Meet the System)--application objects that are saved into a current state for indefinite hibernation (while your computer is off, for instance) and rehydrated later (when you reboot). As you know, Replicants can be embedded in other applications as well as in the Desktop; this is what "handing the object off to another application" means. The Support Kit is also responsible for helping programmers to "lock" specific chunks of code, to make sure they remain safe from marauding bands of wild threads. All of the error codes presented to developers in the debugging process are stored in the Support Kit, as are various and sundry other items of interest only to programmers. The Translation Kit One of the really cool aspects of BeOS's object-oriented design is its use of "Translators" to negotiate between differing file formats, and to allow applications to open and save files and documents in any format for which a Translator is present. For example, a generic image-viewing application that starts life by supporting only GIF and JPEG images could be extended to also handle TIFF, TGA, PICT, BMP, and dozens of other formats with no intervention whatsoever from the author of the program, so long as the developer built Translator support into her application. Similarly, a text editor could be extended to handle HTML, PostScript, or Word documents with the simple addition of a few new Translators to the appropriate folder (/boot/home/add-ons/Translators). Translation isn't limited to open/save operations, however--its scope is more general than that. It can, for example, also be used to load objects directly into or out of system memory, or to read and write specific data formats to and from network connections. To save developers the work of dealing with nitty-gritty details, all the major services of the Translation Kit are fed to the application by the translation roster, which queries the installed Translators as to their specific capabilities and performs the specific implementation details of initialization, gathering information, running translation, and configuration. Like other system add-ons in BeOS, Translators live in two separate directories--one at the system level and one at the user level: /boot/beos/system/add-ons/translators /boot/home/config/add-ons/translators See Chapter 5, Files and the Tracker, for more on the user/system directory distinction. System-level add-ons are preinstalled by BeOS and should not be tampered with, while you're free to add and remove Translators to and from the user-level directory. The two directories are read as a single unit by the system, and any Translators in the user directory that conflict with those in the system directory will override them. The Mail Kit Because email is such a critical component of our everyday computing lives, Be embeds mail services into the operating system much as it does with network services--another telling indication that BeOS is truly a modern operating system. Because of this, email services are not limited to dedicated email clients; for example, many programs allow you to send e-mail to the developer by clicking a button in the program's About box. Similarly, it would be possible for, say, a word processor to be extended to handle incoming and outgoing email messages. There's an old saying in the Unix world that every application will grow until it's able to send and receive email. Fortunately, BeOS applications don't have to grow (in size) to acquire this capability--they can just open the door to the system's built-in services! The Mail Kit allows for the configuration of POP and SMTP (incoming and outgoing) mail servers, scheduled mailbox checking, and the encoding and decoding of base-64 data used in some mail transfers. Each message created or stored via the Mail Kit is stored in the BeMail format, as a single file with an array of attributes for the sender, status, subject line, etcetera (see Chapter 4, Get Online Fast, for details). Crucial to the operation of the Mail Kit is the system mail_daemon, which sits in the background waiting to be kicked into action by calls from other programs (such as mail clients). The mail_daemon, in turn, makes sure that every email message file has the appropriate filetype (text/x-email) so that it will open in the preferred mail client when double-clicked. Developers don't have to use the Mail Kit to make their programs send and receive email messages--they can wade through the standard piles of documentation and do it all by hand via the Network Kit if they want to. But if they're willing to have all messages stored in the BeMail format, they can use the Mail Kit as a shortcut, as Be has encapsulated all the nitty-gritty of message sending into a compact, ready-to-use package. This is especially a boon to developers who specialize in other areas. For example, if the developer of a paint and imaging application wants you to be able to send him support questions by clicking an icon in his program's toolbar, he shouldn't have to also learn the entire networking API just to email-enable his application--the Mail Kit makes it a piece of cake. Chapter Summary The collection of Kits in BeOS is an exceptional example of many of the principles of object-orientation that developers have worked toward for years. BeOS's API isn't the first object-oriented API, but it is clean, logical, thoroughly modern, and makes programming for BeOS a pleasant experience in many ways. The layout of--and services provided by--the Kits means that developers can bring their software products to market faster than with other operating systems, and that those products will have less "cruft," or baggage, than is commonly carried around by similar programs on other operating systems. The object-oriented nature of the Kits mean that it's much simpler to extend applications into domains that would traditionally have required programmers to first sit down and read another stack of manuals. Because of the well-defined boundaries and interfaces provided by the Kits, extending an application to perform a new service is a little like snapping another LEGO onto an existing structure. I over-simplify here, but this is the general idea. All of this means an all-around better experience for users. It also means that if you're interested in learning to program in C++, BeOS is an excellent place to start, because the BeOS APIs are not overburdening. For more information on learning to program BeOS applications, see Appendix X. <<previous ^ top ^