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_ref s 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?
|