Be Newsletter


Issue 74, May 21, 1997

Table of Contents


BE ENGINEERING INSIGHTS: Customizing the "Open" and "Save" Panels

By Steve Horowitz

By now you're probably starting to absorb the long list of things that have changed for DR9. Among these changes are a new Tracker and a new tracker shared library, which, among other things, contains the implementation for the "Open" and "Save" panels. This might not seem like a big deal but it does represent a significant step forward in the ability to customize and use the file panel. This article will describe, generally, how customization of the file panels can be done. The coming DR9 documentation will include full details for using the BFilePanel object.

In DR8, an application invoked the file panel by sending a "display file panel" message to the Browser. There was a problem with this design: The file panel was actually running inside the Browser's address space. This put significant constraints on your ability to custom the file panel since you didn't have direct access to the file panel window containing the file panel.

In DR9, the file panel implementation is part of a shared library that your applications can link with. When a BFilePanel object is instantiated, it creates a regular window in the caller's address space. A pointer to the window is accessible through a method of the BFilePanel object. With this change, you have full access to the window which is displaying the file panel and can add and remove views, change the window title, and resize things according to your needs.

The BFilePanel object in DR9 has some customizability built right into the class. As examples, the constructor lets you specify...

  • the 'what' of the notification message that's generated by the file panel,
  • the target of the message,
  • the directory that the panel will initially display,
  • a filter object (BRefFilter) that displays only certain items from the directory,
  • whether the user can select multiple items at once,

and so on.

There are, however, other ways in which developers might want to add application-specific functionality to the file panel. Some examples would be a custom menu that lets the user select the type or format of files that show up in the open panel, or maybe a mini-page view of the selected item in the file panel.

Let's look at the add-a-custom-menu example:

The first thing you do is get the window object itself by invoking Window() on your BFilePanel. You then get the background view by asking for child 0, and add your menu to that view -- the panel is yours, you can do what you want. (Note that by the time the real DR9 is released, we'll put names on all the views in the panel, so you can get the background view through the friendlier FindView() function.)

Your menu can include items that allow the user to specify the types or sets of files that are displayed in the file panel. Each menu item can be targeted to the object that's controlling your BFilePanel, such as a document window or your application object. When the messages generated by the menu items are received you can use some other methods of BFilePanel to change the displayed items in the file panel. To do this you would find two methods particularly useful:

  • The first is "SetRefFilter()". This method lets you specify a new filter through which all items are sent before being displayed in the file panel. The "RefFilter" can then determine which items it wants to let through and which to filter out. To get the file panel to re-display its contents you simply call the "Refresh()" method of BFilePanel. This forces the currently-displayed directory to run its entire contents back through the filter and display only specific items.

  • Another way to accomplish the same thing would be to create your own BRefFilter subclass, and keep a pointer to the BFilePanel object or your menu. Then, instead of changing the ref filter when the user selects a menu item, you would simply call "Refresh()" and the RefFilter object itself would look at the currently selected menu item and could filter items based on this.

The other customization example described above can be accomplished using some other methods of the BFilePanel class. To add a selection-sensitive mini page view you would probably want to create the file panel in "single-selection" mode, thereby limiting the user to selecting one item at a time. You can then add your custom mini-page view to the file panel window using the technique described above. To get notified about changes to the selection, you would create a subclass of BFilePanel and override the "SelectionChanged()" method. This method is called each time the user has clicked in the file panel window and possibly changed the selected item. Using the "Rewind()" and "GetNextRef()" methods of BFilePanel you can then iterate through the currently selected items in the file panel and generate a mini page view for the selected item.

These are just some of the ways in which you can customize the new DR9 file panel. With the ability to access the file panel window in your applications own address space, you can now use the full power of the Be Kits to customize the file panel according to your needs.


News from the Front

By William Adams

Oh boy what a week! First our own Developers' Conference, and then the Apple World Wide Developers Conference. It was all a bit daunting, but we made it through.

At the Apple WWDC I had the chance to mingle with some of my old NeXT programming buddies. I got into NeXT programming in 1989/90. That's about 7 years ago. At the time, it was hot, exciting, and the programmers were full of a fire to change the world. I ran across one of these programmers and mentioned I was at Be now (I was wearing a Be T-shirt) and that he should consider jumping ship and joining the new rebellion. His response was that he didn't have another leap in him, and it was Rhapsody, or Java (said with a cringe).

Well, this just goes to show that times do change. As professional programmers, we sometimes go with what's new and exciting, and sometimes with what's tried and true. To recover from the long week of conferences, I was lying on the floor in my family room doing situps. Of course Yasmin had to come over and sit on my chest to help the effort. As I was struggling to do those 20 situps, with 28 pounds of wiggling fury on my chest, I couldn't help but consider the parallel between this situation and trying to program in some heavy duty operating systems. Once again I'm grateful that I am programming in the BeOS.

And so, you have DR9 in your hands. Let me point out a few things. The CD contains some sample code. In the optional directory, you should find GNU sources as well as several sample applications. These should help you out while we continue to produce documentation. Also, these samples will be available at:

ftp://ftp.be.com/pub/samples/

Keep a watchful eye here for continued releases of many sample applications. To make good on promises made at the Dev Con, I've put up the VideoCenter application. For those of you who attended the Video on Be session, this is the FireWire/TVTuner demo application. BeTV by Kevin Hendrickson was a clear winner in our Master's program. The VideoCenter application is not his, but our own sample app to help you work the same magic that he does.

For those of you frantically sending mail to Developer Support, with no response this past week, we're back in the saddle again. Of course your patience is greatly appreciated, and you'll be rewarded with documentation, sample apps, and helpful answers to your questions.

Of course by now you've already ported your applications and you have absolutely no problems because the Advanced Access release is the best thing since sliced bread...

Well, at least you're not trying to do situps with dead weight on your chest.


Is the Law Impotent?

By Jean-Louis Gassée

Criticizing Microsoft is a popular and politically correct pastime. Even iftheir actions were totally simon-pure, their size and success would still attract the inevitable jealousy and fear. That's what generating $400 million of cash per month does for you.

The old fear Microsoft would abuse its OS platform position to gain an unfair advantage has been given new energy by the Web battle royale between Netscape and Microsoft. The early, almost forgotten, anti-Microsoft argument was: "In the future the OS won't matter." Using a combination of Java and HTML, the browser's destiny was to become the universal platform on which to build the applications of the future.

There was, and still is, some truth in the gospel. HTML and the browser emerged as wonderful Intranet tools, finally delivering a set of unified building blocks for client-server applications delivering up-to-date, rich information on corporate desks. Microsoft, in effect, said: "Wait a minute, if the browser is so fundamental, we'll make it part of the OS, of the platform, thank you."

As they are doing just that, fear and accusations mount that Microsoft unfairly uses its OS position to dictate the browsing standard. After all, Windows commands about 95% of desktops, your Web page better be readable from those. Similar apprehension and charges float around Java, Microsoft is accused of muscling its way into a controlling position, and servers where Microsoft owns the increasingly successful Windows NT on which a growing number of servers run -- uncomfortably.

We had the oil robber barons, the Glass-Steagall Act for banks, and the little misunderstandings involving AT&T or IBM. When a player, or group of players, threatened to exert too much control over a sector of the economy, we, the people, through our selfless representatives, stepped in. We amended the rules and made sure no little guy would be denied his right to fair competition. It was easy to tell AT&T they couldn't sell local service anymore, or equipment. Or, as in the famous Carterphone decision: "You can sell network services but you cannot force people to use your telephonesets".

Why don't we get similar legislation or court rulings for Microsoft, then?
Because the law is impotent. You can tell a telephone from the network, but it's hard to write an algorithm, a law, drawing an enforceable distinction between the system and an application. Here, common sense doesn't apply. The browser is a good example. If it is truly universal, it needs to be there all the time, so why not make it part of the system. How do you tell an application from the system?

Tomorrow, Microsoft could decide to bundle, sorry, integrate, parts of Microsoft Office into Windows 5.0 and sell the rest separately, or as an upgrade to the system, as they did shortly with Plus! They place their browser on the Windows desktop as The Internet (one wonders when they'll call that on the Mac desktop as well), that's either cheeky or telling, but they have the right to do so and, and, again, it's hard to see an enforceable law against it. The same applies to the integration/bundling of server software on Windows NT.

There is a double irony here. First, the lack of algorithm against the devouring algorithm Windows has become, the lack of legally enforceable categories that would help limit the cancerous growth.

Secondly, it will become increasingly difficult to distinguish between the role played by Microsoft's superb management and hard work, and the increasingly questioned impact of their size and of their irrepressible appetites. It is hard to imagine a company as driven, as competitive as Microsoft suddenly exercising self-restraint, especially when goaded by the likes or Sun, Oracle and Netscape, and their barbed leaders.

So, in the absence of either unthinkable self-restraint or unthinkable laws, what do we do?


BeDevTalk Summary

BeDevTalk is an unmoderated discussion group that's a forum for the exchange of technical information, suggestions, questions, mythology, and suspicions. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the group.

To subscribe to BeDevTalk, visit the mailing list page on our Web site: http://www.be.com/aboutbe/mailinglists.html.

  • ----NEW---------------------------
    Subject: AAAAArrrrrrgghhh!!
    AKA: BE_ACCEPTS_FIRST_CLICK

    "Depth still follows focus in DR9." And with these words the UI battle commenced. Should the active window always be frontmost?

    Although the subject line curse was prompted by the inflexibility of window focus, some folks think that forcing the active window to the front is the most intuitive design and the simplest, least confusing presentation, particularly for new users. But, as Marco Nelissen asked, "should the whole UI be crippled just to accomodate new users?"

  • ----NEW---------------------------
    Subject: Attributes and pathnames

    Many developers are dismayed that with the demise of record_refs so went persistent file IDs. Pathnames are fine for identifying a location, but is there any way to persistently tag the inode portion of a file?

    A number of solutions were suggested and debated, including using attributes, a "file id" server, maintaining the Be B-tree on each mounted volume, and so on. However, none of the suggestions was universally applicable to all (potentially) plugged-in file systems.

  • ----NEW---------------------------
    Subject: 128MB in DR9?

    How much swap space is enough? Now that VM is configurable and has its own preferences panel, should you stick with the default or go for broke? One listener suggested pushing up the swap area to about 250MB, which suggestion blew some valves in certain foreign lands: Isn't that a lot of swap space, particularly if you've only got a 500MB disk?

    Then again, as Jon Watte, observed, "You buy a computer for something like $2,000, and only spend $50 on your hard disk? Where's the logic? 3 GB drives are quite affordable these days."

  • ----NEW---------------------------
    Subject: missing mail

    BeMail isn't part of the AA-DR9 CD. In the meantime, listeners traded ideas about mail utilities: Since mail messages are file-based, is it (now) possible to design good command-line tools that can co-exist with a GUI mail program? There was also talk of an IMAP (Internet Message Access Protocol) system that would support access to remotely-stored messages.

    This raised the issue of canonical URL encoding -- URLs aren't JUST for mail messages in an IMAP. Should developers settle on a general convention for how and where URLs are encoded?



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.