If you've been a member of the Be community for long, you know that we recently redesigned the Be corporate web site. Many people, especially our developers, gave us feedback on what they liked and disliked, and lots of suggestions. To give you some insights into what we did and why, and what we'll do in the future, I thought I'd write about the process we went through, and what happened afterwards.

I took the job of Webmaster this year at the end of March. My second day on the job I was told "We need a new web site. You have 4 weeks." After the paramedics restarted my heart, we got to work.

After some consultation with outside design firms, it became clear that 4 weeks weren't enough to do the job well and at a reasonable cost. We extended our deadline, asked our branding and design firm to handle this project as well, and got to the hard part of the task: creating a new organizational scheme for the site.

The number one complaint about the old design was that it was too hard to figure out what Be did. The Be web site was focused on the existing Be community, and served it well, but tended to turn off people who were visiting for the first time. The site didn't convert casual browsers into customers, because they would quit browsing before they learned what our product was!

Since one of the groups of people we wanted to please with the new site was first time visitors, including potential customers and investors, we knew we had to make significant changes. (This was one of only many considerations we had on our list.)

To reorganize our site, we worked on two different approaches with our design agency, Fitch. One, which we called "The Matrix," was very sophisticated but was also so complicated we couldn't explain it to other people at Be. We took the simpler of the two approaches.

The visual design took less time. Fitch presented us with three different visual looks. We chose one, and then looked at multiple variations on that theme. We picked one of those, made a couple of minor changes, and Fitch's designers turned it over to their web production team.

Fitch's web production group was going to build out a set of base templates: one skeleton page for each section, and all the associated graphics. Then Be's web team (all two of us) would take those, and build out the site to the 20 pages we were planning to complete for launch.

The first iteration of the templates we got used HTML frames for the top navigation area. Somehow we had forgotten to say "don't use frames." (Though we were very clear that the new design could not depend on anything that wasn't supported by NetPositive. And it doesn't, though the JavaScript rollovers are kinda cool if you visit using another browser.)

For those of you who don't already know my attitude towards HTML frames, let me be plain: Frames are Evil. They are the work of the Prince of Darkness. I *hate* frames. I can go into detail as to why, but I'll just link to Jakob Nielsen's two excellent articles on the issue:

• Why Frames Suck (Most of the Time)
  http://www.useit.com/alertbox/9612.html

• "Top Ten Mistakes" Revisited
  http://www.useit.com/alertbox/990502.html

So we kicked the base templates back, and asked Fitch to redo them without frames. This put us a bit over time and over budget, but getting rid of the frames was worth it.

Other flaws were not so easy to fix. At the last moment, we realized that the new site design would unveil the new Be logo three weeks ahead of our planned "debut" at PCExpo. So we quickly hacked out a replacement graphic using the old logo. It looked terrible, but there was no other way to keep the new logo secret.

The awful logo graphic was one of about a dozen visual flaws we could see in the new design. Some others were that the gradient background and the small text in the blue side navigation bar combined to make it very hard to read; the grayed-out "sub-navigation" links looked disabled and unavailable; JPEG artifacts in the Be logo (even the new one) were especially visible in NetPositive; and somewhat inappropriate icons were used in the blue side navigation bar. The Zookeeper icon for the Jobs section was especially unfortunate; rumors that Be chains people to their desks, or flogs them when they get behind schedule, are completely untrue. We haven't done that in almost two years.

We and Fitch knew about these flaws. But with the aggressive development schedule and fairly fixed launch date, we just didn't have the luxury of going back to fix things. At all four stages of the project (architecture, visual design, HTML design, production) we came to a point where we said "it's flawed but the deadline is really important; we'll fix it in version 1.1" (a phrase I'm sure every software developer has heard at one time or another!). We moved on to production.

With the templates and graphics in hand, the Web Team got to work building out the site. We implemented the actual site templates in a mix of HTML and the outstanding PHP (http://www.php.net/), a server-side processing language (someone please port this to BeOS!). These templates are "smart," in that they know what page they're displaying and adjust elements accordingly. All the work of keeping the navigational links, highlighted graphics, and JavaScript code correct is done by those templates, making it *vastly* easier to add new pages to sections, etc.

With production basically finished (we were just waiting for a few pieces of content to trickle in), we examined our handiwork. It wasn't perfect by a long shot, but it didn't suck completely either. At some point, you just have to STFP ("ship the product"—the "f" is silent). So we did.

Uh, well, we wanted to. But at the last moment, we realized that the new server hardware, a much beefier—and physically larger—system than its predecessor, would not fit in the cage at our co-location facility. We'd have to wait three days until they could rewire a nearby rack to receive our box. "Three days" turned out to be a week...

In the end we launched the new site on June 2nd, a week and a day late. Not bad, all things considered—our schedule had not allowed us to add "padding" for delays at all; we'd barely had time to do QA.

The various delays had an upside, though. They and the smart templates allowed the Web Team to expand the number of pages on the site when it launched. Instead of the original target of 20 pages on the new site, we ended up with 42 (we're well over 100 now).

Next week, I'll return and talk about the feedback we've received, additional issues we've uncovered—and what we're going to do about it, very soon.

Before I dive into the subject of this week's newsletter article, I'd like to claim the title for working in the "hardest programming environment for programming the BeOS framework..."

One of my regular programming environments is my garden. I connect my faithful dual 300 Mhz PC running BeOS to my telescope, and under the curious gaze of Molly or Zippy (two wonderful dogs! See www.zippydog.com), I happily program under the stars.

Now this is a pleasant environment. But with the comfort of my home/DSL/refrigerator at hand, I can't really claim it as the hardest environment for programming BeOS. So last week I went one step farther -- I programmed the same machine (still connected to the telescope) near the summit of White Mountain in eastern California.

The altitude was about 11,000 feet, the wind speed about 30 mph, and the temperature was low enough that I had to add some rum to my Diet Coke to keep it from freezing. A Honda generator provided the power—the fuel-efficient BeOS burns about 0.8 gallon of supreme unleaded a day.

Amazingly, even under something like wilderness survival conditions, further attenuated by my highly diminished mental abilities, the Be programming framework is still simple enough that I could program with ease. That's the magic of BeOS!

Now, lets talk about something more "down to earth"...

A while back I wanted to add a little animated gizmo to 3dsound -- something I thought was very simple but which turned out to be a bit more difficult to implement than I expected. I'm talking about the little black triangle at the top left of the content window.

If you click on that triangle (or hit the tab key), the panel containing the vu-meters, etc., will show/hide. I wanted this triangle to rotate smoothly.

At first, I did a trivial implementation of just drawing a triangle at the different rotations, but I wasn't very happy with the result. The edges of the triangle were pretty huggly (that's "ugly" to you) at most angles!

The best solution would be anti-aliasing, but I wanted to try something different: using the framework to render the triangle, then blurring the result before blitting it to the screen.

In this case, blurring works like a simple low-pass filter. It removes the offending high frequency (jaggies). In general, when you do fast animation, adding blurring tends to make the result look much better.

The result looks really nice (I think it's as good as real anti-aliasing) and can be applied to many kinds of rendering.

Here is the code:

//------------------------------------------------------

class   TCtrlView : public BView {
    BBitmap         *b;
    BView           *bv;
    float           rot;

public:
                TCtrlView(BRect frame, char *name);
                ~TCtrlView();
virtual void    Draw(BRect ur);
        BPoint  transform(BPoint in);
        void    SetRotation(float r);
        void    blur();
};

//------------------------------------------------------

    TCtrlView::TCtrlView(BRect frame, char *name)
    : BView(frame, name, B_FOLLOW_NONE, B_WILL_DRAW)
{
    SetViewColor(backgr);

    b = new BBitmap(BRect(0,0,31,31),
                          B_COLOR_8_BIT,
                          TRUE);

    b->AddChild(bv = new BView(BRect(0, 0, 31,
        31),"",B_FOLLOW_ALL,B_WILL_DRAW));
    rot = 3.1415926;

    SetRotation(rot);
}

//------------------------------------------------------

    TCtrlView::~TCtrlView()
{
    delete b;
}

//------------------------------------------------------

// 2d transform routine

BPoint  TCtrlView::transform(BPoint p)
{
    float   sina = sin(rot);
    float   cosa = cos(rot);
    float   x0,y0;

    p.x -= 9;
        //offset from the rotation center
    p.y -= 17;

    x0 = p.x * cosa - p.y * sina;
    y0 = p.x * sina + p.y * cosa;

    x0 += 9;
        //offset back
    y0 += 17;

    p.x = x0;
    p.y = y0;

    return p;
}

//------------------------------------------------------
// very simple blurring routine, also pretty fast!

void    TCtrlView::blur()
{
    uchar   *c;
    long    x,y;
    uchar   tmp[32][32];
    long    acc;

    c = (uchar *)b->Bits();

    for (y = 1; y < 29;y++)
    for (x = 2; x < 20;x++) {
        acc = c[(x+y*32)];
        acc = acc + acc + acc + acc;

        acc += c[(x+y*32)+1];
        acc += c[(x+y*32)-1];
        acc += c[(x+y*32)+32];
        acc += c[(x+y*32)-32];
        acc /= 8;
        tmp[y][x] = acc;
    }
    for (y = 1; y < 29;y++)
    for (x = 2; x < 20;x++) {
        c[x+y*32] = tmp[y][x];
    }
}

//------------------------------------------------------
// Set the rotation of the arrow and draw the arrow to the
// screen.

void    TCtrlView::SetRotation(float r)
{
    rot = r;

    b->Lock();
    bv->SetHighColor(backgr);
    bv->FillRect(BRect(0,0,32000,32000));
    bv->SetHighColor(32,32,32);

    bv->FillTriangle(transform(BPoint(5,10)),
                     transform(BPoint(5,24)),
                     transform(BPoint(12,17)));
    bv->Sync();
    blur();
    b->Unlock();

    DrawBitmap(b, BRect(1, 1, 1 + 14, 1 +
    30),BRect(0,3,14,33));
}

//------------------------------------------------------
void    TCtrlView::Draw(BRect ur)
{
    BRect       r;
    long        i;
    rgb_color   c;

    DrawBitmap(b, BRect(1, 1, 15, 31),BRect(0,3,14,33));
}

//------------------------------------------------------

And a final bonus...

In the 3dsound timeline, the selection is represented by a darker area. Here's the routine I use to darken an 8-bit bitmap. The idea is to build whatever lookup tables you want which will perform the color change you need, in this case darkening by 25%.

You could easily modify the "init dark table" for any other purpose you want, like darkening everything but bright red, or remapping an image to gray scale, etc. This is really simple but gives you a lot of flexibility in the graphic effects of your program.

//------------------------------------------------------

char    dark_table_inited = 0;
uchar   dark_table[256];

//------------------------------------------------------

void    init_dark_table()
{
    ushort      v;
    uchar       ov;
    rgb_color   c;
    BScreen     s;

    for (v = 0; v < 256; v++) {
        c = s.ColorForIndex(v);
        c.red = (int)(c.red*0.75);
        c.green = (int)(c.green*0.75);
        c.blue = (int)(c.blue*0.75);

        ov = s.IndexForColor(c);
        dark_table[v] = ov;
    }
    dark_table_inited = 1;
}

//------------------------------------------------------

void    TrackViewer::darken_rect(BRect r)
{
    long    rowbyte = TRACK_B_H;
    char    *base;
    long    y1,y2;
    long    x1,x2;
    long    dx,dy;

    if (dark_table_inited == 0) {
        init_dark_table();
    }

    y1 = (int)r.top;
    y2 = (int)r.bottom;
    if (r.right < r.left)
        return;

    if (y1 >= TRACK_HEIGHT)
        return;

    if (y2 < 0)
        return;

    if (y1 < 0) {
        y1 = 0;
    }

    if (y2 > (TRACK_HEIGHT - 1)) {
        y2 = TRACK_HEIGHT - 1;
    }

    dy = (y2-y1);

    x1 = (int)(r.left);
    x2 = (int)(r.right);

    if (x1 > (TRACK_WIDTH))
        return;
    if (x2 < 0)
        return;

    if (x1 < 0)
        x1 = 0;
    if (x2 > (TRACK_WIDTH))
        x2 = TRACK_WIDTH;

    if (r.top >= 0) {
        while(y1 <= y2) {
            dx = x2 - x1;
            base = (char *)the_off->Bits() + y1*rowbyte+x1;
            y1++;

            while(dx>=0) {
                *base = dark_table[*base];
                base++;
                dx--;
            }
        }
    }
}

//------------------------------------------------------

Simple!

So, my final question. Would anybody like to challenge my claim of finding the "most hostile environment for programming BeOS?"

One of the most important issues that comes up in porting apps from other OSes is adjusting to BeOS's pervasively threaded world. In today's article, I'll show you an easy way to make apps that you're porting happy, as well as demonstrate a sometimes-overlooked class that you can make good use of in your BeOS-native programs as well.

while (::PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) {
    if (/* is a quit msg */) {
        break;
    } else {
        ::TranslateMessage(&msg);
        ::DispatchMessage(&msg);
    }
}

BMessageQueue theQueue;

MyWindow::MessageReceived(BMessage* msg) {
    theQueue.AddMessage(msg);
}

MyWindow::MessageReceived(BMessage* msg) {
    DetachCurrentMessage();
    theQueue.AddMessage(msg);
}

status_t RunMyMessageThread(void* /* obj */) {
    while (true) {
        // Peek until we see a message and remove it
        while (theQueue.IsEmpty()) snooze(1000);
        BMessage* msg = theQueue.NextMessage();

        if (/* is a quit message */) {
            delete msg; // almost forgot, didn't you?
            break;
        } else {
            // translate and dispatch the message
            delete msg;
        }
    }
    return B_OK;
}

// semaphore is created with an initial count of 0
// the count indicates the number of messages in the queue
sem_id queueHasMessages;
BMessageQueue theQueue;

MyWindow::MessageReceived(BMessage* msg) {
    DetachCurrentMessage();
    theQueue.AddMessage(msg);
    release_sem(queueHasMessages); // signals thread to
                                   // wake up
}

status_t RunMyMessageThread(void* /* obj */) {
    while (true) {
        // Peek until we see a message and remove it
        acquire_sem(queueHasMessages);
        BMessage* msg = theQueue.NextMessage();
        if (/* is a quit message */) {
            delete msg;
            break;
        } else {
            // translate and dispatch the message
            delete msg;
        }
    }
    return B_OK;
}

I hope these simple snippets will give you even more ideas about how you can distribute message handling responsibilities in your application in a flexible and simple way.

In this installment, Rephrase becomes a usable basic plain text editor with the introduction of file open and save capabilities.

You'll find this version of Rephrase at:

<ftp://ftp.be.com/pub/samples/tutorials/rephrase/rephrase0.1d4.zip>

Rephrase 0.1d4
New Features
Create new phrases.
Open existing phrases.
Save phrases.

This version of Rephrase introduces too many programming concepts to cover in one article. Therefore, next week's article will not introduce any new sample code.

There is considerably more going on in this week's sample code. This extra code deals with properly quitting the application, and will be covered in detail next week.

Now that IBM has announced the availability of a PPC motherboard, why doesn't Be jump on the bandwagon and commit to this hardware? My apologies for not doing full justice to the number, variations, or eloquence of the messages sent to info@be.com or directly to me. You get the idea, though. Something is happening in the PPC world and Be ought to support it. One correspondent expressed it as a brutal Wall Street reduction: "I would even be willing to bet that this would cause the most dramatic rise in Be stock since the IPO."

The stock price is not a topic for me to comment on, but the sentiment regarding the PowerPC needs to be addressed (immediately, which is why I've postponed the next installment of the IPO story, "Going Public: Part II"). The processor itself is a fine one, as the benchmarks prove. We've had versions of BeOS on the PowerPC since 1994, including our current 4.5 release (whose package clearly states "For x86 and PowerPC"). So, what we're dealing with is not really a processor dilemma. Is it then a question not of chips but of chipsets? Setting aside a possible oversimplification for the moment, this turns out to be a better lead to the real issues.

Look at the evolution of PC motherboards. More and more functions get integrated, as opposed to implemented on plug-in cards. In the process, the "chipset," the chip or chips interposed between the faster and faster CPU and slower devices such as the PCI bus, memory, frame buffers and the like, become richer and richer mediators. The complexity of the better chipsets now rivals or exceeds that of the CPU itself.

The operating system, in turn, needs to support these mediating devices; otherwise, the hardware, or the OS, or both aren't going anywhere. Take Silicon Graphics' recent decision to de-emphasize their low-end workstations based on Intel processors and Windows NT. These workstations required two proprietary objects, a physical one and a logical one. On the physical side, Silicon Graphics decided to use ASICs to express their knowledge of the application space. Together, these Application Specific Integrated Circuits constituted a "chipset" providing high-performance I/O for graphics, video, and audio applications in SGI's heritage. The idea was to achieve a level of performance higher than that offered by the standard PC clone organ bank. This, in turn, required a logical object, NT software, drivers and, perhaps, modifications to NT itself. Meanwhile, the relentless clone industry continued to drive the price of standard organs down and the performance up. The clone drive reached a point where the SGI solution became less likely to achieve its original goals.

If that example isn't enough, recall recent announcements regarding high-end chipsets for servers. Two camps were ready to make war over a standard, one led by Intel and, if memory serves, the other by Compaq. But the cost of the conflict and the benefits of having only one standard led to peace. We can now expect organ bank support for eight-way multiprocessing, coming soon from your favorite motherboard supplier.

To return to PowerPC hardware, we need to know more about chipsets that support the PowerPC. Who builds them, how competitive are they, which I/O devices are supported, how is the technical documentation accessed, who fixes bugs in the product and the documentation? As far as the IBM PPC hardware is concerned, other questions arise. Where can I buy it and where can I get it fixed, for instance? As answers emerge, it will be easy for us to make a decision.

That said, I still haven't answered the Apple question. If Apple is selling respectable quantities of PowerPC hardware, how come we don't support the latest G3 and G4 machines? As I said above, it boils down to a chipset issue. Intel doesn't have an operating system to defend. In their best interest, they profess to be "OS-agnostic," the more options, the better. In Apple's case, it's different. They own and operate an OS and, like Microsoft, see no reason to help a competitor. Linux provides access to classical Unix applications and, therefore, is little competition for Apple's multimedia heritage. The same can't be said of BeOS, and I can see the logic in Apple's decision not to help us with access to chipset technical data for a G3/G4 BeOS port.

Some have suggested that we look into the Linux sources for such data. Perhaps, but I see little reason to open ourselves to possible accusations of reverse-engineering. We're welcome on x-86 hardware, we're not welcome on Apple G3/G4. We respect the logic and that settles it for us.