Be Newsletter


Issue 47, October 30, 1996

Table of Contents


European Be Demo Tour

  • October 31 throught November 2, 1996

    Apple Expo Benelux in Amsterdam

    Thanks to our Be geek correspondent teams in Belgium (Allen Lee) and France (Jean-Marc Ouvré), the BeOS(TM) for PowerMac and the BeBox will be presented in the Macworld magazine booth during the exhibition at:

    RAI Exhibition Halls
    Amsterdam, The Netherlands

    Demonstrations of the BeOS for PowerMac will also be held at the Spierings booth.

    For more information, visit http://www.holland.euro.apple.com/events/apple_expo/index.html.


Be Demo Tour: BeBox Demo in Nashville

  • Monday, November 4, 1996, 6:30 pm

    Nashville MUG / BeBox Demo Meeting

    Nashville Tech
    Clement Auditorium
    White Bridge Road
    Nashville, TN

    Contact name: Clark Thomas
    Tel: (615) 269-6936

  • Tuesday, November 5, 1996, 7:00 pm

    Vanderbilt ACM / BeBox Demo General Meeting

    Stevenson Center, Room 5326
    Vanderbilt University
    Nashville, TN

    For a map of the Vanderbilt campus and a map showing how to get to Vanterbilt from Nashville, see the Be Events page (http://www.be.com/events/schedule/index.html).

REGISTRATION FOR BE DEMO TOUR EVENTS: E-mail bedemotour@be.com to register for any event. Please tell us your name, the names of the people coming with you, and the meeting name (UW-Seattle or FireBUG-Seattle). Admission for unregistered guests will be on a first-come, first-served basis.


BE ENGINEERING INSIGHTS: Filtering Out the Noise

By Peter Potrebic

One of the new features in DR8 is message filtering, which is based on the BMessageFilter class. This class, along with associated functions in BLooper and BHandler, gives developers a powerful tool for filtering messages. Prior to DR8, the BeOS allowed you to filter only a few system-defined messages, such as B_MOUSE_DOWN and B_KEY_DOWN. This old-style filtering was part of the BWindow class (see the sections on BWindow::FilterMouseDown, FilterKeyDown, and so on in The Be Book). The new filtering system is much improved.

It's worth noting that the old style of filtering still exists in DR8, but it's on the chopping block, and one day soon it will be gone. So now's the time to learn about the new filtering mechanism and to update your code.

BMessageFilter provides two styles of filtering. The first is based on a built-in hook function, which you can override in your subclass:

  virtual filter_result
    BMessageFilter::Filter(BMessage *msg, BHandler **target)
The Filter() function is then called for any message that matches the "filter" criteria. The target parameter indicates which handler is destined to receive the message. By passing a pointer to a pointer, you're allowed to alter the target. The hook function returns a filter_result that is either B_SKIP_MESSAGE or B_DISPATCH_MESSAGE. The latter tells the system to continue processing the message, while the former says to stop, the message should be discarded.

BMessageFilter also supports a function pointer interface, removing the need for subclassing (this ought to make some of you out there happy). With this style you can define a filter function like so:

  filter_result
    my_filter_func(BMessage *msg, BHandler **target,
        BLooper *looper)
You can then pass a pointer to this function to the BMessageFilter constructor:

  new BMessageFilter(... <other arguments> ...,
       my_filter_func)
What's with "<other arguments>" you might ask? Let me explain. The BMessageFilter class is designed to filter messages using various criteria, specified using these <other arguments>. Are you interested in a filtering a particular kind of message, for example, the B_MOUSE_DOWN message, or are you interested in any message sent by a particular party, for example, any third party? Maybe you're interested in some combination? BMessageFilters give you all this power and more.

There are three distinct characteristics of a message that can be used to define the filter criteria:

  • "How" How did the message arrive. Was it dropped by a user or programatically delivered using PostMessage or SendMessage. The options are B_ANY_DELIVERY, B_DROPPED_DELIVERY, or B_PROGRAMMED_DELIVERY.

  • "Who" Who originated the message. Was it the app itself or was it some other application. The options are B_ANY_SOURCE, B_LOCAL_SOURCE, or B_REMOTE_SOURCE.

  • "What" What type of message is it. This is the "what" field of a BMessage and can be any value.

Now the "<other arguments>" will make sense:

  new BMessageFilter(message_delivery how,
                     message_source   who,
                     ulong            what)
These three criteria can be combined in arbitrary ways. Here are several examples:

  • You want to filter a particular message, say B_KEY_DOWN, but you're not interested in how the message was delivered or who sent the message. Here's the filter to want:
      new TMyMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE,
           B_KEY_DOWN)
    
    This example is basically mimics the old-style BWindow::FilterKeyDown() function.

  • You want to filter any dropped message that came from another application, and instead of subclassing and overriding the Filter() function, you've decided to write your own filter function:

      new BMessageFilter(B_DROPPED_DELIVERY, B_REMOTE_SOURCE,
          my_filter)
    
    By not specifying a particular "what" field, all dropped messages will be filtered, regardless of the "what" field.

  • You're really nosy and want to peak at every stinking message. Here's what you would do:
      new TNosyMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE)
    
Now that you know how to create filters, you need to know how to attach them to loopers and handlers in order to actually do anything. You've got a couple of options here. You can filter messages targeted for a specific handler, for example, a specific view in a window. Or you can filter all messages that go through a particular looper, for example, all messages being dispatched by a window. You chose between these alternative by adding the filter to the appropriate object:

  BLooper::AddCommonFilter(BMessageFilter *filter)
or
  BHandler::AddFilter(BMessageFilter *filter)
Filters added to a handler only apply to that handler, while filters added to a looper using AddCommonFilter apply to all messages dispatched by that looper.

That's about all there is to filtering. Until next time, happy filtering.


News from the Front

By William Adams

I'll admit it. I didn't have enough time to spend on this week's article. I was off in Seattle giving demos and writing articles for magazines. So those of you who are very astute will notice that I'm treading water this week and only offering what amounts to a lot of filler. But I want to stay in your face and on your mind lest you forget how nifty and neat the BeOS is to program and use.

First of all, although I've been very busy, I still have a coding sample.

ftp://ftp.be.com/pub/samples/game_kit/obsolete/Multipede.tgz

Multipede is a very minimalist port of the xcentipede game. This is an arcade classic. The primary feature of this little app is that it demonstrates how to use the following:

Of particular interest might be the ATicker class. This is a simple thread-based ticker, which can generate a Tick() at any given interval, or rate, using any units of time. It's used by the GameStick object to periodically poll the joystick position.

You may also find the AThread object (oskernel.h) useful as a simple encapsulation of the thread functions of the BeOS. This is very useful in many different areas when you may not feel comfortable with the standard 'C' interface to threads the OS provides.

The original X-based code was all in one file. It was compact and pretty straightforward. The Multipede release consists of many files, it's more modular, and, I believe, easily understood. I tried to create a sample that was first, a native implementation of the BeOS, and second, easy to understand and useful for subclassing. So there you have it.

FROM YOUR BENCH

Title: BetMap
Location: ftp.be.com/pub/contrib/gfx/editors/BetMap.tgz
Author: CHAUT Pierre-Emmanuel (pierre@ina.fr)

This is a funky paint program that shows great spirit. The general concept is that everything is a plug in. You drag and drop tools from browser windows to make them active; then you use them. The interface is not what you typically expect of a paint program, and some have commented that it is harder to use. But the author has made what I would classify as a valiant effort in producing an architecture that makes extreme use of components. It's in the same vein as the AudioElements program mentioned earlier.

Whether you like the interface this program uses or not, every developer could stand to win by adopting such an open extension to their application by way of add-on support.

GOOD NEWS

Well the good news is we'll be releasing some more of the code to the applications found in the /apps folder. The bad news is, some of the apps don't have what we would call 'pretty' code. These apps will take some time to release. We want to release them in a little bit better form than as raw, uncommented shovel ware, but the tutorials will take some time. The general criteria for release will be:

  • Is the code commented and readable.
  • Does the code demonstrate sound coding style for the BeOS

On the early release list will be:

  • Clock
  • Edit
  • FontDemo
  • Kaleidoscope
  • Mandelbrot
  • ImageViewer
  • PlaySound
  • PoorMan
  • Pulse

Later arrivals will be:

  • CDPlayer
  • Edit
  • IconWorld
  • MiniPlayer
  • MineSweeper

All the others were not fit for human consumption, or are so out of date that they are not relevant, or have a license agreement that prevents source from being released.

I would like to get them up on the ftp site as quickly as possible before they become irrelevant in the face of the DR9 release, at which time they will be updated and released again, or a new crop of more tintillating examples will be developed.

LAST WORD

So there you have it. No pontification or cheerleading this week. Just some code samples and promises of more code samples.


BE DEVELOPER TALK: AppSketcher Available Now for Free!

By Marc Verstaen, International Lorienne Inc. [Now BeatWare, Inc.]
E-mail: verstaen@beatware.com

While the AppModeler development toolkit never came out with DR8 as announced, AppSketcher replaces it now. A few more weeks were needed to make it solid and robust, ready to increase Be developers' productivity. Many Be developers have been helping us to enhance AppSketcher, with relevant comments in the comp.sys.be newsgroup and the BeDevTalk mailing list. Beta testers were also very helpful in our efforts to design an object development tool that provides benefits to the whole Be developer community.

Why and What Is AppSketcher?

Although Be Interface Kit is very easy to use and to program with, most of us prefer to concentrate on the development of specific parts of our applications, rather than spending time generating a coherent user interface.

As you will discover, AppSketcher is more or less a nutshell: All it knows is that a world can be described with windows, views, controls, and menus. But no particular object is loaded the first time you launch AppSketcher, so the first step is to parse the header files corresponding to the kits provided by our favorite Be engineers. Then AppSketcher knows more: It can manipulate objects from the Interface Kit and even create applications. You can now design your interface graphically, connect control objects to your functions, even test your user interface. What comes next depends only on you: If the objects provided by Be fulfill your needs, you don't need to read more. But if you want to implement your own objects, with their own look and feel, or if you want to set some parameters for objects directly in AppSketcher, then you will have to teach it about your own classes. As part of this process, you will modify AppSketcher and increase the range of its features. Our job is done now, and we're waiting for you to take care of our child and to help him become a grown-up.

What Can You Expect from AppSketcher?

AppSketcher offers:

  • A graphical interface design tool, which can be used interactively

  • The capability to add C++ objects, either as interface elements or simply as objects that applications create

  • A way to connect interface items (controls) with the member functions of the objects that have been added

  • A process for initializing object members with the pointer to other application components

  • A tool you can use throughout a project's lifetime

All you have to do now is connected to the Be web site, download AppSketcher, and read its documentation. (AppSketcher will be available in the Developer area of the Be web site this week. Watch the What's New page for the announcement.)

We'd like to thank Be, Inc., whose BeOS has made the one- year-old AppSketcher application possible. All of us at Lorienne [Now BeatWare] were very pleased to work with talented Be team.


A Pretty Embrace

By Jean-Louis Gassée

Once again, we're treated to a great show. Fortunately, there's also substance behind the verbal pyrotechnics and the demos. I'm referring to the most recent Network Computer announcements -- of course. And I'm betting we'll all benefit in the end from the sometimes raucous conflict between the advocates of the NC and the defenders of the PC.

But let's start with the basics. Ostensibly, the NC is a way to fight the ever-increasing cost of ownership of a PC. A number of studies by the Gartner Group or Forrester Research agree corporations spend around $10,000 per year, per PC. The culprit is the growing disorder and fat afflicting hardware and software configurations.

For years, Sun has claimed the newtwork _is_ the computer, and they built a nice business on that claim. They also transmogrified their set-top box language, OAK, into Java, a way to design and deliver platform-independent applications. Et voila, all the ingredients for NC. Just a processor, memory, and network connection and you have a machine that's both less expensive to purchase and to own. Less expensive to purchase because you get rid of unnecessary organs, such as the floppy, the hard disk, or a bus. Less expensive to own because all the data and programs are centrally (and thus more safely and economically) managed. When you need it, you invoke the Java word processor from the server. When you're done, it disappears without cluttering your system. Clean computing.

We know, of course, life is never that simple. Nagging questions arose immediately. Such as the need for some caching device. A hard disk, perhaps. But then, what's the difference with a PC? The fact Microsoft doesn't control the architecture? Unfortunately, the argument degenerated into an anti-Microsoft one, confusing what the NC does for the customer with what it does against Microsoft.

In the early days of the NC battle of words, Bill Gates openly derided the concept, pointing to the weak difference in hardware costs between a PC and an NC. But the issue of cost of ownership did not go away, especially with the sometimes painful transition from Windows 3.1 to Windows 95 and Windows NT. Larry Ellison and Scott McNealy are powerful ideologues and very successful businessmen. Their advocacy of the NC carries weight, and Java gained traction, now assured of becoming a mainstream language.

So what did Bill Gates do? Last week, at the Agenda Conference in Phoenix, Arizona, Larry Ellison had an off day. His pitch for the NC wasn't as calm and statesmanlike as we were used to expect from him. Bill Gates, on the contrary, decided to embrace the key NC concepts and, by pure coincidence, the official announcement came yesterday, right on the eve of Sun's official NC intro. There are some good ideas there, some real problems, said Bill. We'll have a simplified PC architecture supported by Compaq, Hewlett- Packard, Dell, and other noted players. It will be less expensive to purchase and to own because we'll offer the capability to centrally manage data and application software.

Critics say it's a mere retooling of the SIPC, the Simple Interactive PC architecture previewed in February. It doesn't matter. What counts is what will be delivered, by whom, and when. In the end, we're likely to get in the healthy habit of delivering and updating software automatically over the network, the Internet or the intranet, thus making users and software developers happier. Plus it will make a couple of companies, such as Marimba, who've already thought of that business, richer.




Copyright ©1997 Be, Inc. Be is a registered trademark, and BeOS, BeBox, BeWare, GeekPort, the Be logo and the BeOS logo are trademarks of Be, Inc. All other trademarks mentioned are the property of their respective owners. Comments about this site? Please write us at webmaster@be.com.