Workspaces are an illusion that allow users to organize their applications and documents into different virtual screens. By default, application windows open in the current workspace and live solely in a single workspace (though the user, through the Workspaces preference panel, can later position the window in any of the available workspaces).

If the default behavior satisfies the needs of your application, you don't need to add any workspace- specific code. However, if your application supports multiple windows, gratuitous animation, or other processing tasks that can stop when its workspace is deactivated and continue when it is reactivated, there area handful of BWindow and global functions to assist you.

In most cases the user should determine which workspace a given window exists in (use B_CURRENT_WORKSPACE in the BWindow constructor), though there may be cases were it makes sense for the application to set the workspace for a window. To create a window in a specific workspace (or workspaces) the BWindow constructor takes an unsigned int32 bit field. A "1" in any bit position indicates the window should exist in that workspace (with bit 0 corresponding to the first workspace). Using B_ALL_WORKSPACES forces the window to exist in all workspaces. Most applications should not use B_ALL_WORKSPACES since this would rapidly defeat the purpose of workspaces.

To change the current workspace (or workspaces) for a window after construction, there is a BWindow method, SetWorkspaces(), that takes the same bit field parameter. An example of an application that may need to do this is a paint program with an editing window and separate tool palette windows. When the user moves the editing window to another workspace, the palette windows should follow. To do this, override the edit window's WorkspaceChanged() method and call the palette window's SetWorkspaces() function:

void TEditWindow::WorkspacesChanges(uint32 old_ws,
                                    uint32 new_ws)
{
  fPaletteWindow->SetWorkspaces(new_ws);
}

Note

Before creating or moving a window to a given workspace you should first determine that the workspace is valid (the user can set between 1 and 32 workspaces). There is a global function, count_workspaces(), that can be used to determine the number of workspaces.

Some applications may wish to create follow-on windows in the same workspace that the main window resides in. To determine which workspace (or workspaces) the main window is in, use the window's Workspaces() method. An application example might be a compiler that creates a status window:

void TCompilerWindow::ShowStatus(...)
{
  BWindow* status = new BWindow(rect, title, type, flags,
                                Workspaces());
}

An application that can curtail processing when its window's workspace becomes inactive should do so. Obviously, a web browser should not stop a download, but it could stop all animated GIFs. To do this, override the BWindow's WorkspaceActivated() method and stop or start processing tasks according to the state variable:

EyeCandy::WorkspaceActivated(int32 ws, bool active)
{
  (active) ?
    release_sem(process_sem) :
    acquire_sem(process_sem);
}

Applications with windows that live in more than one workspace can do this a bit more efficiently by ignoring the ws variable and instead using the global function current_workspace() to determine if the window lives in the current workspace:

EyeCandy::WorkspaceActivated(int32 ws, bool active)
{
  (Workspaces() & (1 << current_workspace())) ?
    release_sem(process_sem) :
    acquire_sem(process_sem);
}

As you know, the Developer's Workshop is all about answering questions and providing sample code to developers. We get a list of topics and questions developers send in. We look them over and provide the sample code that we think will solve the problem. Well, being the new kid on the block, I brought a question with me. "When is it appropriate to use attributes to store information for your program?"

Making the most of my direct access to the Be engineers, I wandered around asking my question until I got some answers.

The quick and dirty answer is that attributes are appropriate for storing extra information that is inappropriate or impossible to store in the file itself. This information may change frequently, or can be done without if it doesn't exist.

As always, the quick and dirty answer isn't the full story. But the full story needs a little background information.

Attributes are arbitrary name/value pairs associated with a file, which can be indexed by the file system for querying. Attribute names can be up to 255 characters in length, and their values can be of any size. Attribute names and values are stored together, and a file can only have a single value for a given attribute name. Attributes are stored in the order they are added to the file. Queries are limited to indexed attributes whose values are strings, floats, or one of the various integer types.

Some implementation details suggest ways to optimize attribute storage. These details are subject to change, but the suggestions I'll make shouldn't negatively affect future performance. In any case, these details will be completely invisible to users.

While attributes can store any amount of information, each file has a small "fast attribute" area that is accessible at little cost whenever the file is referenced. This "fast attribute" area is about 700 bytes in size, and is the first place attribute information is stored. As soon as it fills up, the file system creates additional areas to store attributes. The additional areas impose some file system access costs, making them considerably slower than the "fast" area.

So, what can a developer do to maximize the performance of retrieving attribute information? Try and get as much information into the "fast" attribute area as possible. Although there are no specific methods to guarantee that an attribute exists inside of the fast attribute area, we can suggest guidelines that should increase the likelihood of having your attributes accessed in the fastest method possible:

With these optimization guidelines in mind, let's look to the BeOS for some appropriate uses for attributes. Perhaps the best overall example is using attributes to store information about e-mail files. The mail_daemon saves each message to a file and adds the following attribute information:

Information      Attribute Name
-----------      --------------
Name             MAIL:name
Subject          MAIL:subject
To               MAIL:to
From             MAIL:from
ReplyTo          MAIL:reply
Status           MAIL:status
Priority         MAIL:priority
When             MAIL:when
Header Length    MAIL:header_length
Content Length   MAIL:content_length

Most of these are self explanatory, and are simply the record of information contained in the file in the attribute system for querying purposes.

The header_length attribute, however, is worthy of special note, as it shows an efficient use of attributes. Header information is not normally needed when displaying a message to the user, but since it's at the beginning of the file it's important to know its length to make it easier to jump to the real contents of the file. Similarly, when the headers are specifically requested, having the length available makes it easy to read that amount of data from the file. This makes parsing the file to get to the end of the headers every time the file is accessed unnecessary.

Other BeOS uses of attributes can be found in StyledEdit and the Tracker. StyledEdit stores all of its style information in attributes. This allows the actual data of the file to be stored as plain text, making it easy to read the file in applications that don't care about the styled information. The Tracker uses attributes to store icon and position information for files and folders.

The People app also uses attributes for information storage. Person files contain only attributes; there is no other data in the file itself. This raises the question of whether it is appropriate to use attributes as a kind of built-in database. The answer is that it really depends on the type of information you want to store. The drawback of such a system is that it is inefficient in terms of storage. Every record would exist as an individual file, taking up a minimum of a block on the drive. Each file must live in some directory somewhere.

While in theory this method should work for nearly any amount of information, as a practical matter a "database" with hundreds of thousands of records would be inefficient both in terms of storage space and speed of accessing information. On the other hand, it can be useful for storing contact information in a place where it's easily accessed by any application.

There are many uses for attributes in addition to those we've touched on in this article. Attributes could be used to store the URL of a downloaded document; the last backup date for a file; the keywords of a document; or gamma correction, color depth and dimensions of an image. We'd like to hear about the uses that developers are putting attributes to. If you have an interesting use, drop us a line at the online support form in the Registered Developers Area. We're curious.

Finally, there are a few things to be aware of when dealing with attributes. Currently, only direct Tracker copying to another Be File System disk or archiving your files with zip preserves attribute information. Most of the other common storage and transfer formats do not save that information (including tar, cp, ftp and mail attachments.) This means that you need to take extra care when transferring files that contain attributes. Also, applications should be aware that a file might not contain the attributes they expect, and be prepared to rebuild them, if possible.

Well, I've gone over many things to consider when using attributes, but I've not touched on how to actually use them. I'll cover that in four weeks, along with some sample code that shows how to read and write files in the BeOS.

Last week, Steve Sakoman and I took time off MacWorld to go to Las Vegas. This wasn't a desperation financing trip, but an attempt to survey the scene at the Consumer Electronics Show. It didn't start well. Steve tried to register electronically and the server promptly got stuck leaving him in registration limbo for a while.

We went in looking for signs of the convergence between consumer electronics and computing. We saw black boxes and silver boxes and titanium colored boxes, but not much convergence. Still, WebTV Plus, the latest version, is really good, TV and the Web coexist nicely, even if they don't merge yet and this product will make Microsoft look very smart.

Smart is an adjective that becomes harder to place when contemplating the latest TCI machinations. John Malone gives a layer of the mille-feuilles to Scott McNealy's Personal Java and another one to Windows CE. But the hardware layer is still to be defined, the microprocessor is to be anointed in the Spring, all the while NextLevel nee and born again General Instruments (the NextLevel name didn't work) claims billions in orders for their next generation set-top boxes.

I guess John Malone is the smartest right now for wringing money out of Sun and Microsoft. Sun is rumored to provide about $10 per box to "compensate" for the hardware penalty required to run Personal Java and Microsoft is rumored to have made similar concessions in excess of the WinCE royalty, while pointing out Java, unlike Win CE, won't run on all boxes, only higher-end ones. The "happy" processor manufacturer knows what to expect.

Will this yield a nice product? The developments will be interesting to watch with each player bringing up hardware or debugging code while watching the other guys trying to create some kind of toll gate in order to recoup their "advance payment" and, at the same time, rereading the legal paperwork looking for loopholes in the contracts.

With this in mind, the un-second-guessed approach pursued by WebTV looks even more attractive, in a different domain for the time being.

We watched with great interest the PalmPC demos (I'm a Palm Pilot user and a director of 3Com, the owner of Palm Computing—so you know the possible biases in my opinions). Same physical size as the Pilot, and running a version of Windows CE, with Microsoft's might, it could become tough competition.

The PalmPC demo involved a man and a woman. The woman played the role of the "conventional" user of paper organizers, big purse, you see the picture, and the man inside the little demo booth was the more enlightened user of a PDA.

On top of the booth, a big screen reproduced the small PalmPC screen for a large audience—I thought, until Steve Sakoman's sharper eyes and elbow brought me back to reality. "They're running a tape," said Steve. Indeed, this was a karaoke demo, the two actors were saying their lines as the video tape of the demo ran. I went around the booth, the male "demonstrator" followed the tape on a small screen and kept flipping his neat little cue cards with yellow highlights as he went along.

Just to acquire more data about WinCE, I bought a Sharp 2.0 device, grayscale display, 12MB of RAM, integrated (soft) modem, and took it on an overseas trip along with my Hitachi portable, my Pilot, my Swiss-Army knife, my screw-pull (don't want to face a bottle of fine Bordeaux without it) and other unmentionables. Without getting into a detailed review of the Sharp hardware nor of Windows CE 2.0, the whole system looks to me as too big, too slow, too unreliable and too battery-hungry (one set of two AAs per day) to compete in the smaller, lighter, more nimble Pilot category.

HDTV was everywhere and looked pretty real. Yes, the sets are horribly expensive. But imagine the following situation: two sports bars in town, one shows football and basketball on HDTV, one on a current set. The beer costs 50 cents more, which bar will get more volume and better margins? Joe, where did you get that set? Sports sells ads, somehow a way will be found to prime this better pump for commercials.

For the rest, wireless devices continue to proliferate happily, GPS devices can now be had for less than $100 and slightly more expensive ones acquire better displays, store maps—they'll be and take us everywhere.

The rest was either unmentionable or too hilarious for this family newsletter, or too sad. In this latter case, I'm referring to the "very high-end" audio with Russian mil-spec 12AX7 triodes, gold-plated everything and oxygen-free copper crystal cables.

We grabbed a cab, ran through the airport, caught a just-boarding Southwest flight to San Jose. The peanuts and the diet coke never tasted better. Comdex looks even better now.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.

'unattended':bool—don't pop up any dialogs,
                     take the default action.
'force':bool     —message demands immediate action

class MyButton: public BButton, public MyBase;

MyBase *thing=new MyButton();

... dynamic_cast<MyBase*>((BButton*)thing);