As many of you have noticed, we've upgraded the look-and-feel of BeWare, and moved it to the main Be web site:

<http://www.be.com/software/beware/>

The changes are all with the look-and-feel, the presentation, of BeWare. We hope you, and the thousands of people who download your software from BeWare each month, will find the new design easier to look at and use.

We're not quite finished with the changes. In the next week or so we will be reorganizing the categories and subcategories for BeWare, to try to make things easier to find, as well as to reflect the state of software for BeOS today, rather than the DR8 days when the categories were first designed. We'll also continue to tweak the templates that build the pages. And there's at least one surprise still up our sleeves. ;-)

If you haven't done so in a while, you should visit the Registered Developer section and update the information for each of your applications:

<http://www.be.com/developers/registered_entry.html>

You might also take a quick look at each of your application entries in the new BeWare, and make sure things are displaying as you expect.

To answer a few questions before they're asked, this redesign is NOT a change in the systems that handle BeWare. We're definitely going to do that, too, but that will take a few months, because it is intimately tied into all our other Developer databases and systems. Replacing the back end will let us add lots of new features to BeWare, like better searching and immediate updating, instead of the 24 hour or longer waiting period that still exists today.

If your application prints, chances are that you send BViews directly to the BPrintJob class without any modification. This what-you-see-is-what-you-get style of printing is ideal for word processors and graphic design applications, but for applications where printing is not an end in itself, there might be a lot of meta- information about the document which could enhance your printed output.

Obvious examples of such meta-information include document title, page numbers, date and time, and the application which printed the document. You needn't be limited and use only text: if you've written a mail program, for example, you might consider putting an icon on the page which indicates if the mail is in the inbox or outbox.

To do this, you could modify your BView::Draw() functions to check IsPrinting() is true, and behave accordingly. A better approach is to subclass BPrintJob, and have the derived class print your meta-information. To see how to do this, take a look at the BorderPrint class:

<ftp://ftp.be.com/pub/samples/interface_kit/BorderPrint.zip>

Adding this class to your application is trivial: just add it to your makefile or project file, and change BPrintJob definitions in your code to BorderPrint definitions. Now when your application prints, there will be a small banner on the top of the page with the name of print job centered, and a banner on the bottom of the page with the date and time flushed right, and page number flushed right. There will be a thick border around the entire document, with your application's contents indented inside.

The heart of this trick lies in the BorderPrint::DrawView() function. The first time this function is called, it calls BPrintJob::DrawView(), passing in its own BorderView view. With the banners and borders now on the spool page, BPrintJob::DrawView() is called with the actual BView argument, but with the BPoint argument offset to account for the border height and width.

Naturally, this wouldn't work if the PrintableRect() function hadn't been overridden to return a smaller BRect, one that fits inside the border.

There is one potential snag that you need to be aware of: most of the functions in the BPrintJob class are not declared as virtual. Consequently, in the unlikely event that your application passes BPrintJob pointers around, you'll instead need to pass BorderPrint pointers.

There's plenty of fun to be had with this trick, some useful, some purely ornamental. Think unconventionally and experiment!

In last week's Developer Workshop article, Developers' Workshop: TranslatorPanel: The Revenge, Daniel presented a method for starting a drag and drop session using a one-shot BMessageRunner. The goal was to ignore extraneous mouse clicks and inadvertent mouse drags. A potential disadvantage is that this imposes a delay on the start of the drag process.

This week's sample code offers an alternate method for starting a drag process based on the distance the mouse travels while a button is down.

You can find QuickDrag at

<ftp://ftp.be.com/pub/samples/intro/QuickDrag.zip>

QuickDrag creates a window with a single view that slowly cycles colors through a very uninteresting algorithm. A drag is initiated when a user clicks in the window and drags more than 10 pixels horizontally or vertically from the click point. When a drag and drop session starts, a transparent bitmap of the window's current color will be dragged and the window will stop cycling colors.

The implementation is straightforward. The view caches the click point when the mouse has moved 10 pixels and initiates the dragging process. The code is self-explanatory, so I'll only point out two things here:

You've heard it here, more than once: our goal on x-86 is peaceful coexistence with Windows, not replacing it. Unlike OS/2's claim of "better DOS than DOS, better Windows than Windows" we aim to please by complementing the dominant OS. BeOS specializes in media-intensive applications, while Windows provides traditional services such as office productivity. In other words, add value and fun to your PC by loading BeOS next to Windows, not instead of Windows.

I'm told this sounds reasonable. However, as we discovered reading the transcript of the almost-forgotten anti-trust trial, Microsoft doesn't like that story. One of their senior executives, Paul Maritz, argued that BeOS was in fact a much more sinister threat. In his view, we only masquerade as a specialized, complementary OS. Once having established a foothold in the marketplace, though, we'd try to put his employer out of business. BeOS, Be-ing such a threat, clearly established the fragility of Microsoft's position; our existence proved beyond doubt they were not a monopoly.

Ah well. I wonder what Microsoft will say to the fact that we're demonstrating what BeOS can do for media-rich Web appliances, especially in applications where broadband pipes allow for a heady mixture of information and entertainment. And for transactions, a space where Windows is too complicated and fragile, and where CE lacks the ability to handle the media streams and the bandwidth.

Fortunately, customers have a sunnier perspective on peaceful coexistence. You've probably read various columns criticizing Windows 98 for its size, complexity, and fragility. Recently, Walt Mossberg, the Personal Computing Technology columnist at the Wall Street Journal, wrote a fairly tart piece on his struggles with Win 98. Last August, if memory serves, Stewart Alsop, speaking as both venture investor with NEA and columnist for Fortune Magazine, wrote a "Why I hate Windows" piece detailing his negative experiences. I could add my own registry of stories but I'd rather let one of our customers tell his:

As stated above, this is a much sunnier perspective on peaceful coexistence. Perhaps we ought to reposition BeOS as a companion utility for Windows users. I still have a minimal DOS disk with Norton Commander, a mouse driver, and a CD-ROM driver—I use it to reanimate my PC when Windows crashes real hard. I'm red-faced, since I use System Commander and BeOS on the same system. I should have thought of using our own product.