Be Newsletter

Volume II, Issue 11; March 18, 1998

Table of Contents

• Be Developer Classifieds
• BE EVENTS: BeOS demos in Houston, TX; NAB in Las Vegas, NV
• BE ENGINEERING INSIGHTS: New Windows Of Opportunity (Part I: The New Window Manager), By Pierre Raynaud-Richard
• More of My Favorite Things, by Michael Alderete
• DEVELOPERS' WORKSHOP: How To Get Tracker to See Your Attributes, By Doug Fulton
• More News from Murphy, By Jean-Louis Gassée

Be Developer Classifieds

(For more information, check out the Classified Ads section in the Registered Be Developer area.)

On April 16th Douglas Irving (Be Developer) will be giving a session titled "Audio Tools for the BeOS" at the annual SEAMUS (Society for Electro-Acoustic Music in the US) meeting, being held this year at Dartmouth College.

Some of the "big names" in computer/electronic music will be there (Mob Moog, Max Matthews), as well has the faculty/directors of many of the electronic music and multimedia university programs around the US. This event will be a pretty good opportunity to get Be software into the ears of some interesting people...

Looking mostly for sound processing/synthesis software, or "multimedia" apps that include a sound component. If you have software that you think should be presented, please contact Douglas at: glmrboy@shoko.calarts.edu.

Upcoming Be Events

BeOS Demo in Houston, TX
Tuesday, April 7, 1998

The Be Team will be demonstrating the BeOS for Intel at the HAL-PC meeting in Houston, TX. Presentations start at 7:00 PM.

• Where:
  George R. Brown Convention Center
  Level 3, Auditorium
  Exhibit Hall - Room 302

• Info: http://www.houston-guide.com/facilities/convention/conventionbrown.html

BeOS at NAB
Monday, April 6 to Thursday, April 9

The Be Team will be demonstrating the BeOS at NAB in the Adamation booth (Be third Party Developer)

• Where:
  Booth #M6571
  Upper floor of the Sands Expo Center
  Las Vegas, NV

• Info about Adamation: http://www.adamation.com
• Info about NAB: http://www.nab.com

BE ENGINEERING INSIGHTS: New Windows of Opportunity (Part I: The New Window Manager)

By Pierre Raynaud-Richard

From time to time, you have to say goodbye to an old friend. It's usually pretty sad... And this particular guy had been around way before I started at be. He was a part of the Be spirit. I speak, of course, of the poor Frozen Window, born of a crashed app, the one that never gets to redraw, yet never leaves the screen. I'll miss having to drag the poor fellow over out of the way, and then watching the system become sluggish as updates slow down, as if the app server was crying over the death of one of its children, suffering in silence, still alive but without joy.

I can't count the number of times I ran into this bug -- still, nobody ever pushed to get it fixed. Did our developers restrain themselves from righteous indignation out of geeky consideration for the suffering of the unlucky window? As if the poor bastard had a right to proclaim the unfairness of its fate to the whole world...

In any case, the other day, I was pissed off one more time, so I started tracking down the bug without pity, found the problem and fixed it. Good bye my little sluggish dying window, probably never going to see you again...

A complete app server rewrite is, and will remain, a myth, but a lot has happened recently, nevertheless: the font cache (PR2), the picture mechanism (Release 3), the rendering package (including 15/16 bpp, bezier and sub-pixel precision, Release 3), the window manager and its extensions (Release 3), and a lot more is on schedule for future releases. So I would like to dedicate this article to present the new window manager architecture and API, to help you use them at their best. Then you'll endure a second article next week giving more details about direct frame buffer access in a window (to do live video DMA for example), using the new BDirectWindow class of the Game Kit.

Opening Window.h, you will notice that a couple things have changed (but, note, all the old official API is still supported). First thing, there is a new BWindow constructor:

  BWindow(BRect frame,
      const char *title,
      window_look look,
      window_feel feel,
      uint32 flags,
      uint32 workspace = B_CURRENT_WORKSPACE);

This is essentially the same as the old constructor, except that the window_type parameter has been split into 2 orthogonal concepts. The "window look"...

 enum window_look {
    B_BORDERED_WINDOW_LOOK = 20,
    B_TITLED_WINDOW_LOOK   =  1,
    B_DOCUMENT_WINDOW_LOOK = 11,
    B_MODAL_WINDOW_LOOK    =  3,
    B_FLOATING_WINDOW_LOOK =  7
  };

...describes the way the window will look on screen -- this is what other OS's call the "window definition" (wdef). And the "window feel"...

  enum window_feel {
    B_NORMAL_WINDOW_FEEL          = 0,
    B_MODAL_SUBSET_WINDOW_FEEL    = 2,
    B_MODAL_APP_WINDOW_FEEL       = 1,
    B_MODAL_ALL_WINDOW_FEEL       = 3,
    B_FLOATING_SUBSET_WINDOW_FEEL = 5,
    B_FLOATING_APP_WINDOW_FEEL    = 4,
    B_FLOATING_ALL_WINDOW_FEEL    = 6
  };

...describes the way the window will behave. The old window_type API, which tied these two concepts together, is now automatically translated, following those rules:

B_TITLED_WINDOW   = B_TITLED_WINDOW_LOOK + B_NORMAL_WINDOW_FEEL
B_MODAL_WINDOW    = B_MODAL_WINDOW_LOOK  + B_MODAL_APP_WINDOW_FEEL
B_DOCUMENT_WINDOW = B_DOCUMENT_WINDOW_LOOK + B_NORMAL_WINDOW_FEEL
B_BORDERED_WINDOW = B_BORDERED_WINDOW_LOOK + B_NORMAL_WINDOW_FEEL

A new window_type was added to describe a "standard" floating window :

B_FLOATING_WINDOW =
  B_FLOATING_WINDOW_LOOK + B_FLOATING_APP_WINDOW_FEEL

The Window Looks Examined

You're already familiar with most of the window_looks:

B_BORDERED_WINDOW_LOOK: Thin (one-pixel wide) dark line around the window; no title bar. It's used for menus.

B_TITLED_WINDOW_LOOK: Thick border; title bar (the infamous yellow tab) with buttons.

B_DOCUMENT_WINDOW_LOOK: Thick border; title bar with buttons; a special area in the right bottom corner area for resizing that's designed to fit between two scrollbars. It looks like the titled window, but with a corner with 10 dots arranged in a triangle.

B_MODAL_WINDOW_LOOK: Thick border; no title bar. These are used for alert panels.

B_FLOATING_WINDOW_LOOK: Thinner border; small title bar and buttons. It looks like a titled window, but on a smaller scale.

The Window Feels Examined

There are far more changes in the window_feel area. Before, there were really only two (normal and modal). Now there are seven; there's the standard...

B_NORMAL_WINDOW_FEEL: Standard, stand-alone window behavior.

...and then there are three modal and three floating feels. The modals are:

B_MODAL_SUBSET_WINDOW_FEEL: A modal window that blocks all windows in its "subset." (You define a window's subset through the BWindow's AddToSubset() and RemoveFromSubset() functions.)

B_MODAL_APP_WINDOW_FEEL: A modal window that blocks all windows in its own subset AND all non- modal windows in its own team (this should account for the application's document windows). This is used as the equivalent of the old B_MODAL_WINDOW_TYPE. To support this compatibility, every time you create a new B_MODAL_APP_WINDOW_FEEL window, all existing "app modal" windows in that team are added to the subset of the new window.

B_MODAL_ALL_WINDOW_FEEL: A modal window that blocks all other windows, except for other system-wide feels (B_MODAL_ALL_WINDOW_FEEL and B_FLOATING_ALL_WINDOW_FEEL). This feel should be used only for system-wide announcements, not for normal applications.

All three modal feels share these rules:

• Every time you try to activate a window that's blocked by a modal, the modal is activated and comes to the front, instead. You can move a blocked window, but that's the only interaction allowed with them until the modal is closed.

• A modal is displayed in the workspace where it's needed. For example, if a modal blocks an entire team, then it will appear in every workspace where a window of that team is displayed.

• Modal windows don't show up in the Workspaces application.

Here are the "floating feels":

B_FLOATING_SUBSET_WINDOW_FEEL: Floats above all windows in its own subset.

B_FLOATING_APP_WINDOW_FEEL: Floats above all non-modal, non-floating windows in its team (it *doesn't* float above windows in its own subset).

B_FLOATING_ALL_WINDOW_FEEL: Floats above all other windows, except other B_FLOATING_ALL_WINDOW_FEEL. This feel is typically used for input methods.

Floating window rules:

• A floating window appears only when its "master" (a window that it's supposed to float in front of) is frontmost. If the master isn't frontmost, the floating window is hidden.

• A floating window follows its master between workspaces.

• Like modal windows, floating windows don't appear in the Workspaces application.

• A floating window's master continues to look active while you're using (mousing or typing in) the floating window itself.

The split into look and feel should help us make windows more configurable.

The Window Flags Examined

Another change that you don't want to miss are these additions to the window flags list:

B_AVOID_FRONT: This flag tells the window manager to never "promote" the window to active status when the current one disappears. You use this flag for "background" windows. For example, if you activate a window using Deskbar and then close that window, you probably don't want Deskbar to become active (which, in the old days, it would have due of its "next most recent" status). In Release 3, Deskbar (and Workspaces) set this flag and so avoid being promoted to activity in just such situations. (Note that you can still *explicitly activate* a window that's "avoiding front," it just won't happen through promotion.)

B_AVOID_FOCUS: This is used by windows (primarily floating windows) that don't need keyboard input (i.e. that don't contain a "focus view"). By avoiding focus, a floating window doesn't force you to re-click on the master window after you've dismissed the floater.

B_OUTLINE_RESIZE: Live resizing looks nice, but it generates a lot of redrawing. If your interface looks bad and feels sluggish because of live resizing, then B_OUTLINE_RESIZE can really help. It's not recommended, but it's there if you need it.

B_NOT_ANCHORED_ON_ACTIVATE: When you activate a window that's in another workspace (by using Deskbar or the Tracker, for example), the window manager will, by default, switch to that workspace. But that's not always what you want. This flag tells the window manager to move the window into the current workspace, thus avoiding the annoying "workspace shuffle."

B_NO_WORKSPACE_ACTIVATION: This flag lets the window be activated in another workspace without switching to that workspace. This flag was designed to satisfy apps that spread a number of windows over various workspaces when they start up. Tracker, for example, uses this flag.

New Dynamic and Convenient Window API

These new looks, feels, and flags wouldn't be very useful if they were only settable at construction time. The good news is that now all window flags and attributes are settable on the fly:

  status_t     SetType(window_type type);
  window_type  Type() const;

  status_t     SetLook(window_look look);
  window_look  Look() const;

  status_t     SetFeel(window_feel feel);
  window_feel  Feel() const;

  status_t     SetFlags(uint32);
  uint32       Flags() const;

For example, Tracker set the B_NO_WORKSPACE_ACTIVATION flag when it lays out its windows at boot time, and then unsets the flag and sets B_NOT_ANCHORED_ON_ACTIVATE to allow windows to come to you when beckoned...

Also for your convenience, a couple functions were added:

  bool      IsModal() const;
  bool      IsFloating() const;
  void      Sync();
  status_t  SendBehind(const BWindow *window);

Sync() ensures that all asynchronous window operations have completed. It's useful after calls such as Hide() and Show().

(This function is a replacement for ShowSync(), although the compatibility isn't complete.) SendBehind() is a nicety that was added to give you a little more control on window ordering. The current window will be moved "just behind" the one you specify. Also, in the same spirit, we implemented a nifty "second button title bar click" that will send the window as far back as possible. This allows you to easily uncover other windows, in one click, and without having to close the window in front of them.

Window Content Area Alignment

New API was added to control the alignment of the window content rect. It's typically useful for people wanting to do DMA on screen through BDirectWindows (as described in next week's article), but it can also be helpful in some other cases.

enum window_alignment {
  B_BYTE_ALIGNMENT     = 0,
  B_PIXEL_ALIGNMENT    = 1
};

status_t SetWindowAlignment(window_alignment mode,
                int32 x,
                int32 xOffset = 0,
                int32 width = 0,
                int32 widthOffset = 0,
                int32 y = 0,
                int32 yOffset = 0,
                int32 height = 0,
                int32 heightOffset = 0);

status_t GetWindowAlignment(window_alignment *mode = NULL,
                int32 *x = NULL,
                int32 *xOffset = NULL,
                int32 *width = NULL,
                int32 *widthOffset = NULL,
                int32 *y = NULL,
                int32 *yOffset = NULL,
                int32 *height = NULL,
                int32 *heightOffset = NULL) const;

In B_PIXEL_ALIGNMENT mode, window moving and resizing will snap to independent "pixel grids." For example, you can tell a window to move in 5 pixel increments, and resize in 7 pixel increments at the same time:

SetWindowAlignment(B_PIXEL_ALIGNMENT,
                    5, 0, // x origin increment
                    7, 0, // width increment
                    5, 0, // y origin increment
                    7, 0);  // height increment

You can "elongate" either grid; here we tell a window to move in 5 pixel increments horizontally, 6 pixels vertically, and to resize in 7 pixel increments horizontally and 8 pixels vertically:

SetWindowAlignment(B_PIXEL_ALIGNMENT,
                    5, 0, // x origin increment
                    7, 0, // width increment
                    6, 0, // y origin increment
                    8, 0);  // height increment

(The intervening parameters let you offset the grids with respect to the screen origin.) The B_BYTE_ALIGNMENT aligns the window's content area within the frame buffer. It's effective on the x origin and the width only. The dimensions of the grid that byte alignment yields in pixels depends on the frame buffer's depth. For example, with a setting of...

SetWindowAlignment(B_BYTE_ALIGNMENT,
                    4, 0,   // x origin increment
                    0, 0);  // width increment

...the window's origin would snap to every 4 pixels in 8 bpp, every 2 in 16 bpp, and every pixel in 32 bpp. It's very useful to be able to align a BDirectWindow that's doing DMA or direct access. When B_BYTE_ALIGNMENT is set, the vertical origin and the height can still be aligned, but they will be controlled by B_PIXEL_ALIGNMENT mode, as byte alignment doesn't make any sense on the vertical axis.

Focus Follows Cindy

As any good rewrite should do, we came up with a cleaner and stronger architecture than before, so we tried to use it to perfect the implementation of focus follows mouse. This time, the result seemed good enough to become a public option, so you will notice a new checkbox in the Mouse preference panel. The main principles are:

• Having the focus means being the main receiver for keyboard events. (The yellow title bar indicates the focused window.)

• If the window pointed at by the mouse accepts focus and isn't blocked by any modal window, then it will get the focus. Focus is updated in real time after any window changes or cursor moves.

• If the window is a floating window that doesn't accept focus, then the focus goes to its frontmost master window, if any is currently visible. If there are no visible master, focus stays where it was before.

• Sending focus to a non-front window will *not* display that window's floaters. This was done to avoid excessive window flashing while dragging the mouse across the screen.

• You can move a background window without bringing it to the front by dragging its title bar or border.

But even better than reading this article, just try to play with it and you'll get it. It's hard at first, but probably more efficient than the old way once you get used to it. In any case, it's just an option...

Under the Windows

Now, for those of you who are interested in more details about how the new window manager really works, here are the sourc-- (Oops sorry :-) here are a few details:

Windows are sorted into 9 layers of visibility; a window in a higher layer is displayed in front of a window in a lower layer (e.g., a layer 5 window is display in front of a layer 4 window):

• layer 0 - hidden windows (including Workspaces visibility).
• layer 1 - minimized windows.
• layer 2 - background window (the desktop of the Tracker).
• layer 3 - "normal" document windows (i.e., windows that aren't in any other category).
• layer 4 - floating windows attached to the current frontmost window.
• layer 5 - modal windows blocking the current frontmost window.
• layer 6 - system-wide modal windows.
• layer 7 - system-wide floating windows.
• layer 8 - full-screen windows (from the Game Kit).

Some rules:

• The first 2 layers are not drawn for now (that could change for layer 1 in the future).

• If a group of windows switches from one layer to another layer in the same transaction (workspace switch for example), the windows stay in the same order relative to each other.

• A window that's demoted from a higher layer to a lower layer is added to the front of the lower layer.

• A window that's promoted to a higher layer is added to the back of that layer, except...

• A window that's being activated is sent to the very front of the layer.

• Only one window can be in layer 8 at any time.

To select focus and window activation, windows respect the following rules, in order of priority:

• the ordering rules given above are always enforced first

• a window in layer 8 always gets the focus and is the only active window.

• A window in layer 0 or 1 is never a potential focus nor is it ever active

• a visible floating window is always active.

• A window that refuses focus is never a potential focus.

• User interaction (using focus_follows_mouse or not) will select new windows as potential focus. If the chosen window is a non system- wide floating window and doesn't accept focus, then its frontmost master window is selected as a potential focus.

• Programmatic API calls like Show() will bring a window to front, making it a potential focus. Other API may affect the process in their own way.

• A workspace change cancels the last focus owner.

• If the last focus owner has not been canceled by a workspace change, it's automatically a potential focus.

• If the frontmost potential focus is a system-wide modal, then it's the focus and the only active window.

• If the frontmost potential focus is a floating window, then it's the focus. Also, its frontmost master window is active.

• If the frontmost potential focus is blocked by a modal, then the topmost modal blocking that window is the focus and the only active window.

• If the frontmost potential focus is not blocked by a modal, then its the focus and the only active window.

• If there is no potential focus, then the frontmost window that is not a system-wide floater and doesn't dislike becoming front is brought to front and set as a potential focus, and all rules are applied again.

• If there is no potential focus, then the frontmost window is brought to front and set as a potential focus, and all rules are applied again.

• There is no focus, nor any active window.

Hmmm, I probably forgot a couple details, but mainly that's it.

Finally, the last advantage, but not the least, of the new window manager architecture is that now all changes of state that are triggered by a single external stimulus (user interaction or programmatic API call) is processed in one atomic transaction. That was the key feature that allowed an efficient implementation of BDirectWindow. But that's next week's story...

More of My Favorite Things

By Michael Alderete
In my last Newsletter article, http://www.be.com/aboutbe/benewsletter/Issue95.html#Insight2, I described a few of my favorite things in the BeOS Preview Release 2. By a great stroke of luck, my latest article deadline coincides almost perfectly with the current BeOS release, Release 3, saving me the agony of finding a new topic to write about.

My favorite thing in Release 3 is BDirectWindow. In a nutshell, it's an extension to the Game Kit that allows extremely processor-efficient direct access to the graphics card frame buffer. It makes video and animation -- full screen or in a window -- smoother, without soaking up all your processor's power. Streaming video from a digitizing card or from a hard drive is very smooth and efficient; I predict that all of the BeOS' "tractor" applications will use BDirectWindow.

Pierre Raynaud-Richard will describe it in greater detail in next week's Newsletter, so I'll leave it by saying that if you're coming to the BeDC, you'll see BDirectWindow's advantages demonstrated in the Media Kit Overview and in Pierre's presentation on BDirectWindow. Be sure you see one or both!

A number of Tracker improvements tickle my fancy. Probably the coolest is what happens when you right-click on a Query. In the context menu, you can "open" the query in the submenu, just as you can by right-clicking on a folder. What's new is that the Query is live -- it executes before displaying the menu.

I'm sure you can think of a few clever tricks for this. Here's one of mine (and I'm going to cheat, and reuse it in this week's Tip of the Week):

1. Create a new Query, by searching for Bookmark by Attribute; size is 0.

   You want to search on this specific criterion, because it will find all your NetPositive bookmarks very quickly. You could search for all Bookmarks by searching for Name is * (wildcard), but that goes much more slowly.

2. Find the Query you just created in your /home/queries directory. Rename it something like "Bookmarks." Move it to your desktop, or any place that's convenient.

3. Now all your favorite web sites are just a right-click away. Just right-click on the Query on your desktop, select the URL, and away you go!

The Open With menu is pretty nice, too. This new feature lets you open your documents with any application which is capable of opening the file's type, not just the default application that opens when you double-click the file. I use this most when editing and testing HTML documents, going back and forth between Eddie (a cool text editor) and NetPositive.

It's not strictly a Tracker improvement, but I love the new status area in the Deskbar. You know how the mail_daemon adds the mailbox icon to the status area at the bottom of the Deskbar? Well, now any application can add a Replicant to that area, providing it's small enough and there's room left (the status area is not resizable, so there's limited real estate -- we'll probably fix this in R4).

PPP status is a natural, and we've got a very-mini-Pulse, uh, thingie here, too. I'll bet it'll be a matter of weeks before there are dozens of choices of what to add to this area. Get there fast!

Two of our Internet applications got big improvements. NetPositive now does frames, has a bunch of bugs fixed, is faster at some things, and opens Bookmark files from the Tracker correctly. PoorMan got a totally new interface, one that I think is a great improvement. It's now a very usable personal web server. Maybe we should rename it!

Of course, the biggest thing in Release 3 is support for Intel hardware. It was a huge amount of work, but the result is that the BeOS now runs on the two most popular computer platforms on the planet.

One of the things that gets me really jazzed about running on Intel hardware is the cost of the systems. We've put together some example systems, known affectionately as "Ming Specials," that can give you an idea of the hardware values available today. You can check out all three Ming Specials on our web site at: http://www.be.com/support/guides/ming-specials.html

Here's the system that really rouses my enthusiasm, because it represents 600 MHz of screaming silicon for just over $2,500. You can't get that anywhere except on a PC, and you can't take advantage of both processors with any other operating system like you can with the BeOS:

Ming Special #3 -- $2,539

  Tyan S-1692DL Dual Pentium II motherboard
  Dual Intel Pentium II 300 MHz CPU
  128 MB SDRAM memory
  Western Digital 6.4 GB Ultra IDE hard drive
  Toshiba 32x CD-ROM drive
  Sony 1.44 floppy disk drive
  Matrox Millennium II 4 MB video card
  Keytronic 104 PS/2 keyboard
  Logitec 3-button Combo Mouseman
  ATX Mid-tower case w/ 230 W power supply

What's most exciting to me is that just four months ago this system cost $3,154 (and had a smaller hard drive). That's a price drop of $615, over $150 a month! Is it any wonder this is one of my favorite things?

Release 3 will be shipping soon, and when you get your hands on it, be sure to tell us what *your* favorite things are.

DEVELOPERS' WORKSHOP: How To Get Tracker to See Your Attributes

By Doug Fulton

"Developers' Workshop" is a new weekly feature that provides answers to our developers' questions. Each week, a Be technical support or documentation professional will choose a question (or two) sent in by an actual developer and provide an answer.

We've created a new section on our web site. Please send us your Newsletter topic suggestions by visiting the web site at: http://www.be.com/developers/suggestion_box.html.

Q: I've got my own database files that contain a hogshead of custom attributes. I indexed the attributes before adding them to the files (just like the good book told me to do), and I have my own app that creates new attributed files, modifies the attributes as needed, and deletes old files. The thing it doesn't do -- and that I don't want to have to write -- is simply *display* the attributes. I want Tracker to recognize and display my attributes in its windows, like it does for e-mail. How do I do this?

-- Jean-Phillipe Toussaud de Renard Sousa
Flaxhandle, Louisiana

A: Tres bon interrogation, garcon. But before we give you an answer, let's make sure that you're up on the latest Be Book-as-disinformation news (regarding attributes and queries):

The (pre-Release 3) Be Book erroneously reported that ONLY indexed attributes can be queried. The truth is that a query must include at least ONE indexed attribute, but it can search for any number of other, unindexed attributes. Of course, the unindexed search won't be as fast as the indexed search, but the indexed search is performed first, which should, in many cases, sufficiently narrow the domain for the unindexed search. What this means for you, M. de Renard Sousa, is that you might want to reconsider the "hogshead of custom attributes" that you currently have indexed. You might want to unindex the attributes that you don't ever use in a query (or that you rarely use).

Also, note that if the length of the value of an indexed attribute exceeds 255 bytes, it will fall out of the index. The value itself won't be lost (the attribute will retain the prolix value), but the index will no longer "see" that attribute. This little fact was also neglected in the Be Book, and has since been corrected (thanks to an astute BeDevTalk participant).

But back to the original question. What Jean-Phillipe wants to do is safe, easy, and uncontroversial, even in states with a stricter definition of acceptable leisure activity than Louisiana. Here's the full story on "How To Get Tracker to See Your Attributes":

1. Create some attributes. (Jean-Phillipe has already done this, but we're starting from scratch.) To "create" an attribute, you simply write it to a file through BNode's WriteAttr() function; you can get the details from the Be Book, but here's a wee example:

     aFile.WriteAttr("SOUSA:Name", B_STRING_TYPE, 0, "Bub", 4);
   

   Note that we write the NULL terminator by declaring the data length to be strlen()+1. Tracker depends on this NULL termination.

2. Create a MIME type for your files and install it in the system-wide MIME type database. You do this through BMimeType's Install() function. You may want to check to see if it's already installed before installing it:

     BMimeType mime("text/x-Sousa");
     if (!mime.IsInstalled())
       mime.Install();
   

3. Assign the file type to the files you create. You do this through BNodeInfo's SetType() function:

     BNodeInfo ni(&aFile);
     ni.SetType("text/x-Sousa");
   

4. Now here's the part that you really want to know about: The MIME info that Tracker looks for when compiling column candidates. Unfortunately, the names of the MIME info fields aren't currently published (when we do publish them, we'll undoubtedly provide handy constants and all that) so what I'm about to disclose is a BIG SECRET. If you agree to change your code to the published names when that day comes, you can continue reading. If you can't hold yourself to this little promise, then go over there for awhile; I'll let you know when you can rejoin us.

Here's what Tracker looks for (or some of it, anyway):

• "attr:name"
  The name of some attribute.

• "attr:public_name"
  The name you want Tracker to call this attribute.

• "attr:type"
  The type (B_INT32_TYPE, B_STRING_TYPE, etc.) of the attribute data.

• "attr:viewable"
  A bool that you set to true if you want Tracker to display the attribute.

• "attr:editable"
  A bool that you set to true if you want users to be able to edit the attribute.

• "attr:width"
  An int32 that gives the width of a default column, in units of something. Probably pixels.

• "attr:alignment"
  A code (B_ALIGN_LEFT, ...RIGHT, or ...CENTER) that declares how the values are aligned in the Tracker column.

You bundle this information into a BMessage, and tack the message onto a MIME type through BMimeType's SetAttrInfo() function.

For example, let's say our Jean-Phillipe wants Tracker to exhibit -- and allow editing of -- the "SOUSA:Name" values of his "text/x-Sousa" files, but he wants the (attribute) column to be named "Sousa Name". He would do something like this:

  BMessage msg;
  msg.AddString("attr:name", "SOUSA:Name");
  msg.AddString("attr:public_name", "Sousa Name");
  msg.AddInt32("attr:type", B_STRING_TYPE);
  msg.AddBool("attr:viewable", true);
  msg.AddBool("attr:editable", true);
  msg.AddInt32("attr:width", 50);
  msg.AddInt32("attr:alignment", B_ALIGN_LEFT);

  /* 'mime' is the BMimeType from above */
  mime.SetAttrInfo(&msg);

The message fields correspond to a particular attribute purely by index into the message. In other words, the 0'th "attr:public_name" field corresponds to the 0'th "attr:name" field (and so on for the other fields). If you want to add Tracker-recognized parameters for a second attribute, you add a second set of "attr:*" values AFTER you've added the first set. (Admittedly, this isn't a very flexible interface, but this is all under-the-counter stuff anyway, so stop griping.)

That's it. Note that...

• We didn't mention indexing. That's because none of this depends on indexing: You can ask Tracker to display ANY attribute, indexed or not.

• The order of these operations isn't important. You can do them in the reverse order and it will come to the same thing.

The rest of you can come back now.

More News from Murphy

By Jean-Louis Gassée

Last week I recounted some of our teething pains with the Intel Release 3 release of the BeOS, the product we'll discuss at great length starting Thursday at our Be DC developer's conference in Santa Clara. This week, I know a little bit more about one of the problems we encountered, and even have some good news, courtesy of Garrett Gruener, the courageous Be, Inc. director who watched the BeOS installation vaporize data on his spouse's hard disk. Fortunately, the data was not really destroyed, only transmogrified into FAT 32 files, and thereby made incomprehensible to a version of Windows only fluent in the DOS FAT 16 standard.

We know now the metamorphosis is easily reversed: you just tell the partitioning utility to do it. In fact, if you use the aptly named Deluxe version of System Commander, it tells you about the FAT 16 vs. FAT 32 problem and indicates the right procedure. In my opinion, System Commander is the best boot manager in the business. The Deluxe version comes with a good set of partitioning tools offering a one-stop complete solution for the hardy multiple OS explorer. Not surprisingly, Frank van Gilluwe, one of the founders of V Communications, System Commander's publisher, is also the author of "The Undocumented PC," a highly recommended book for the fearless experimenters just mentioned.

There is more good news. In discussing the problems BeOS users might face or fear when repartitioning their hard disk and installing the BeOS, Garrett Gruener reminded me of a simple, executive-proof solution: one of his companies, @Backup http://www.atbackup.com, makes a business of backing up your data over the net, with a modem or a LAN connection. Imagine your system automatically backed up every night. Effortless, therefore effective.

On the BIOS front, the news isn't so good. We've discovered that the most recent versions (ending in PO5, 06, and 07) of the BIOS on the Intel Atlanta LX440 motherboard cause the installation problem I experienced last week. If you have one of these motherboards, please check the BIOS version before installing the BeOS. There are two ways to do this: you can catch it during the boot process as it scrolls by; or you can enter the set-up routine by pressing F2 early in the boot sequence, which displays the BIOS revision string on the set-up utility's main screen.

Why didn't we discover the problem earlier? Because it didn't exist on the motherboards we acquired a while ago for development and test purposes. It only showed up on one of our latest purchases, which happened to be for my use as the Intel Release 3 all-purpose guinea pig.

BIOS problems are a way of life in the Intel-based PC world. Intel's excellent web site,

http://support.intel.com/support/motherboards/desktop/

provides support information on their motherboards and the conundrums they may pose. In particular,

http://developer.intel.com/design/motherbd/al/al_bios.htm

gives details on the latest LX440 BIOS and a procedure for updating the flash memory on your motherboard.

BIOS blues are not a new occurrence. In 1995, I bought an Atlantis motherboard, installed Windows 95, and promptly encountered two problems. First, the system insisted I had two mice, a serial mouse and a PS/2 mouse. Second, detecting what it diplomatically referred to as "legacy sound hardware," it always insisted on several attempts each time I reinstalled Windows 95 (a frequent occurrence in my early days of exploring this product).

I learned that deleting one of the two mice made the system unstable, but I got used to the idiosyncrasies. Later, I saw the BIOS update information on the Intel site and, despite trepidation built on my proven ability to find the wrong way to do something, I nevertheless succumbed to the attraction of a manly undertaking sure to grow more hair on my chest.

I downloaded the new BIOS, printed the instructions _before_ attempting the update (I'm not that virile), made a boot floppy, copied the update program on it, rebooted, followed instructions, rebooted and noted the new BIOS revision string, reintroduced my old settings (don't forget to write them down prior to the transplant), and my system looked intact.

Actually, it had healed: the phantom mouse had disappeared and the sound hardware detection problem never manifested itself again. Flush with success, I tried the same operation on a dual-processor Pentium Pro system at the office. This procedure was a little more daunting when the first reboot failed to restart the system, though another reset did the trick. Unfortunately, that BIOS update didn't cure the instabilities presented by my installation of NT 4.0. Sometimes it's the BIOS, sometimes it's the system. And, of course, sometimes it's neither, or both.

Back to Release 3 on Atlanta LX440 motherboards: please check the BIOS revision and call or e-mail if you have one of the later P05, 06, or 07 revisions. We'll post more info on our web site this week. We have a fix -- I'm writing on it, so to speak -- and we want to make sure it is well-tested and reasonably simple and safe to apply.

As my personal experiences testify, these problems are fairly prevalent in the fast-evolving context of the PC architecture and its many independent implementations. This early BIOS problem is a useful reminder to be en garde for the negative consequences of well-meaning upgrades, and of the need to work as closely as possible with BIOS companies such as Phoenix and AMI.