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

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;

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

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;

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

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

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

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):

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.

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":

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.

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.