|
Be Newsletter
Issue 92, September 23, 1997
Table of Contents
BE DEMO TOUR: BeOS demo in Orange County, Ca
- Saturday October 4, 1997
BeOS demo at the Orange Apple Computer Club
When: 9:30am
Where:
Orange Coast College
Chemistry Building, Room 214
Costa Mesa, CA
For directions, please check: http://www.oacc.org/
BE JOB: Hot Shot Graphics Engineer
You were 15 years old when you wrote your first computer
game in assembly code.
At 18 you created a graphics library so you could design
sprites more easily.
Four years later you received a B.S. in Computer Science but
missed the graduation ceremony because you had to get one
more feature into your networked 3D game server.
The balance of your twenties were spent working odd hours
and wearing odder clothes as you created action titles, font
renderers, and image processors, for game and production
houses.
Now you're into your fifth bit, and you want a real job.
You're the ideal candidate to work for Be as a graphics
engineer.
You know graphics from the ground up: How to write your own
code and how to tweak someone else's. You know your renderer
from your rasterizer. You know when and where to cut
corners.
Maybe you know everything about 3D (great!) -- or maybe you
don't (there's plenty of 2D work). Just as long as you know
what you're doing.
To apply, please send your plain text (ASCII) resume
included in the *body* of your e-mail to jobs@be.com
(enclosed documents will not be considered), or fax your
resume to us at (650) 462-4137.
BE ENGINEERING INSIGHTS: Getting Your Applications Ready For Preview Release 2 and Other Topics
By Pavel Cisler
With the next release of the BeOS almost out of the door,
here are some tips on things to do to take advantage of
Preview Release 2's (PR2) features.
First of all, there aren't a lot of major changes, since the
goal was to be for Preview Release (PR) apps to stay
compatible and for PR2 apps to be backwards compatible, and
to focus on stability. There are still a fair number of
tweaks we made, though, that refine the BeOS considerably.
Here is how you can take advantage of some of them:
Versioning
Versions were made available through the BAppFileInfo API,
and the FileTypes application lets you set versions for an
application. However that was pretty much it; even our own
applications did not have any versions set in the last two
releases.
This is changing. In PR2 everything, including apps,
preferences, system components, etc. has a version. You can
now find out, for instance, what version of the Tracker you
are running:
BPath path;
if (find_directory(B_BEOS_SYSTEM_DIRECTORY, &path)
== B_NO_ERROR) {
path.Append("Tracker");
BFile tracker(path.Path(), O_RDONLY);
if (tracker.InitCheck() == B_NO_ERROR) {
BAppFileInfo info(&tracker);
if (info.InitCheck() == B_NO_ERROR) {
version_info version;
if (info.GetVersionInfo(&version, B_APP_VERSION_KIND)
== B_NO_ERROR)
printf("the tracker short version is %s\n",
version.short_info)
}
}
}
Under the original Preview Release, version will return no
version info. Under PR2, version will return "PR2".
The long version string is now displayed in the Get Info
panel in the Tracker -- make sure your app has its version
set. You can do that using FileTypes -- you can either set it
on your final application or you can set it in the .rsrc
file that is appended to your binary during the make.
In addition, when you receive PR2, there is a new version of
the setversion tool that you can use if you are doing
makefile builds and want to be able to set the version from
a makefile. The new setversion tool needs to be run after
any copyres, addres, mergeres (insert your favorite
resource- copying tool here), because it sets the version in
the resource and if run before copyres, it might get
overwritten.
You can have one or two version structures in your
application. The main version structure is accessed using
the B_APP_VERSION_KIND selector, the secondary using the
B_SYSTEM_VERSION_KIND. You do not necessarily need the
system version kind; in fact, currently FileTypes doesn't
even let you edit it (the new setversion does).
Its purpose is to hold version information about a whole
revision of a number of components, where the
B_APP_VERSION_KIND contains version information about the
one specific component. You can have, for example,
SoundCrafter release 2.1 that contains a new add-on
Distortion 1.0. The application version of Distortion would
be 1.0, while the system version would be 2.1, because it's
a part of SoundCrafter 2.1. Yes, we copied the Mac's vers
resources.
Tracker Add-Ons
There are quite a few Tracker add-ons out there, my favorite
being TermHire. In PR2, Tracker add-ons can have keyboard
shortcuts. The way you assign a keyboard shortcut is by
appending the letter to the add-on name, for instance
"FileTypes-F".
The modifier key combination for add-ons was changed to
Command-Option (on Mac keyboards), since using only the
Command key was a little limiting, since add-ons would have
to share the space with all the other pre-existing Tracker
shortcuts.
If you have an add-on, make sure you ship it to users with a
meaningful shortcut already predefined. No programming
involved here, just edit the name appropriately. This of
course is convenient for users because they can edit
shortcuts any way they want.
If you have an installer for your add-on or ship it with
installation instructions, here is another PR2 tweak -- the
/home/config/add-ons/Tracker folder is now active. You should
place, or have the user place, your Tracker add-on there.
The /system/add-ons/Tracker is reserved for Be add-ons. When
the Tracker looks for add-ons, it does a uniqueness check to
deal with the case where a user has an add-on with the same
name in both the /system/add-ons/Tracker and in
/home/config/add-ons/Tracker. In the case of a conflict,
only the system (i.e., from Be) one gets loaded.
Finally, don't forget Tracker add-ons can have an icon, and
that icon will show up in the Tracker's add-on menu.
Supporting Color Drag & Drop
On an unrelated topic, here is a tip about how to support a
neat way of setting colors in your app. I really like
roDesign's roColour color picker. The drag & drop message
format is pretty flexible, and it took just a few lines of
code to make the Desktop handle color changes by supporting
part of the message format.
In the new release you will find a new about box feeding the
egos of all the folks here at Be that worked on the release,
mentioning the names of their favorite pets, etc. The text
view that displays all these rantings can be recolored via a
drag & drop from roColour, and here is the code that supports
it:
void
AboutScrollView::MessageReceived(BMessage *message)
{
if (message->WasDropped()) {
rgb_color *color;
long size;
if (message->FindData("RGBColor", 'RGBC', &color,
&size) == B_NO_ERROR) {
int32 modifs = modifiers();
if (modifs & B_OPTION_KEY)
textView->SetFontAndColor(0,
textView->TextLength(), 0, 0, color);
else
textView->SetViewColor(*color);
textView->Invalidate();
return;
}
}
inherited::MessageReceived(message);
}
As you can see, it's pretty straightforward. If you are
writing a color picker or any other user interface element
that can initiate a drag of a color, make sure you put
RGB color data in the above format into your drag message.
If your application contains user interface elements that
can be recolored, adding this drop handler is one of the
easiest ways to do it.
By now you probably figured out that I'm desperately trying
to figure out what to write about in this article. I think
the following can get me over the length minimum, so I can
go back to hacking on the Tracker.
Interacting between a Terminal window and the Tracker
I already mentioned my favorite add-on, Term-Hire. It lets
you open a new Tracker window and have it cd to the same
directory as the Tracker window from which you activated the
add-on. As described above, now you can use a keyboard
shortcut to do it, which makes it even more useful.
The PR2 Tracker has a feature which is the opposite of what
Term-Hire does -- it lets you open a Tracker window from the
Terminal. If you type "/system/Tracker /boot/home" in
Terminal, a window with your home directory will open up,
etc.
If you like this feature, you might want to
add an alias to your .profile file:
alias t='/system/Tracker'
which will let you use the much shorter "t" for the
"/system/Tracker" part of the command. Note that passing a
document name or an application name to the Tracker this way
is identical to double-clicking on the file, so you can also
launch apps, with or without documents, all from the command
line.
News from the Front
By William Adams
When you were a youngin, did you ever ask your parents to
borrow the car? Of course you did. And compared to your
bike or skateboard it was a lot faster and much more of an
attractor of the opposite sex. You giddily drive down the
street with your arm perched on the window looking as cool
as can be. Then, reality sets in, you have to return it,
and since you dinged it, you're grounded and won't get to
drive it again...ever.
Well...have you ever installed a new OS on your machine and
found that it was quite a joy to drive, and that all the
apps ran that much faster. It's quite the geek magnet. You
sit back confidently clicking away on your apps with a smug
wry smile on your face, then you wake up and you realize
that you fell asleep using the BeOS and you're overjoyed
because the reality was every bit as good as the dream. OK,
maybe I've been programming this stuff a little bit too
long, but every time I lay fingers to keys, I'm excited. And
with our upcoming release, I'm even more excited because the
system just gets more solid and feature rich all the time.
One thing that I've enjoyed all my life is learning new
things. As my wife can tell you, I have books by the dozens,
and my head is a sponge, maybe a bit leaky at times, but I
like to absorb new things nonetheless.
I was reading Eric Berdahl's latest Betelgeuse library and I
noticed a couple of new things. Two C++ keywords that I had
never seen before: "mutable" and "explicit".
What the heck are these? So I went out and bought the latest
and greatest Bjarne Stroustrup book: "The C++ Programming
Language -- Third Edition" and I looked them up.
First "mutable". If you tend to do things like this:
class myobj {
public:
doit() const;
int myint;
};
myobj::doit() {
((myobj *)this)->myint = 3;
}
This is known as casting away const. Why would you do it?
Because the doit() method is declared const, which means
that there is a contract with the user that says this method
will not modify the state of the object. But as the
implementer, you simply must change the value of myint.
Well, if you do this:
class myobj {
public:
doit() const;
mutable int myint;
};
Then you can safely change the myint variable without having
to cast away const and without a compiler error. This seems
to be safer than the cast away const trick, which is
compiler implementation dependent and breaks the const
contract completely.
The other thing I learned was the use of the "explicit"
constructor
class myobj {
public:
explicit myobj(const myobj &);
};
How many times is your object's copy constructor used behind
your back? Would you like that to not happen? Well, when you
use the explicit keyword, your constructor can only be
called explicitly and not behind your back. This is a good
thing to keep straight in cases where an implied use of a
constructor may be a bad thing:
class string {
public:
string(int nElements);
string(char *initial);
};
string aString = 'a';
This will essentially amount to creating a string object
with storage for 65 characters. This probably is not what
you want, but the single character was converted to a int,
and the constructor that takes an int was implicitly used.
Using the explicit keyword on the constructor will prevent
this implied usage and force you to implement what you mean
instead.
class string {
public:
explicit string(int nElements);
string(char initialChar);
string(char *initialString);
};
All in all, this just goes to show you that an old dog can
learn new tricks. C++, and most other languages, gives you
plenty of rope to hang yourself with. But there are plenty
of things in the language the make practicing safe HEX
relatively easy.
More (Or Less) on Modularity
By Jean-Louis Gassée
Some columns generate more e-mail than others, our honorable
correspondents react in ways that are sure to keep us honest
or, at least, awake.
The column on modularity, http://www.be.com/aboutbe/benewsletter/Issue89.html#Gassee,
did excite a little more reaction than usual, with responses
ranging from the very supportive, "Go for it, you're doing
the right thing, NCs are the future!", to the scathingly
critical, "You're pandering to the NC PC (if one can forgive
the pun), NCs are a fraud, who wants them and, in any case,
how are you going to compete against Oracle, Sun and IBM and
make money?" And now we hear Apple, too, is poised to enter
the NC fray.
Let's back up a little bit. Said column on modularity vs.
scalability merely draws attention to the fact that our
operating system is unusually modular. Most systems only
"scale" upwards, they bleed to death when a cut is attempted
in order to downscale them; ours scales up nicely when
adding processors, and it responds nicely to the system
programmer's knife when targeting smaller platforms. We have
demonstrated the BeOS running on 4-processor machines; now
we fit a slimmed-down version on a 1.44 MB floppy, boot from
said floppy and browse the Net with a $350 Pentium clone
sans hard disk.
We're trying to make the point that the BeOS is unusually
modular and, as result, can be used in a wider range of
applications than just as a specialized desktop operating
system targeted at creative digital media applications. And,
in making that point we indeed invite some controversy
regarding our role in the NC space as well as the future of
NCs themselves.
Let's start with the latter point. Is the NC a viable life
form? If I must answer in one word or less: Yes. If I'm
allowed a little more space: It depends -- for what, for
where, for whom.
I was born in a statist culture that, in the early eighties,
naturally engendered the Minitel, a home and business
information terminal the monopoly telephone company gave
away in return for forfeiting carbon-based phone books. The
Minitel microprocessor runs a communications protocol and an
interpreter for a page description language. Move to the
late nineties, make the communications protocol TCP/IP and
the page description language HTML, add the BASIC of our
times, Java, and you can roam the Internet or deploy
client-server applications on your company's intranet.
Do these capabilities make the NC a life form? Not yet. To
become viable it needs to cost less than a Windows PC and,
in some ways, do more. The purchase price is still unclear.
In theory, NCs, with less components, should cost less, but
PC advocates point to the economies of scale and the
competitive forces relentlessly driving their prices down.
But the main argument for NCs isn't the purchase price, it
is the cost of ownership. Anyone owning or operating a PC
knows how much time is "invested" in dealing with
configurations, updates and other technical endeavors. NCs
promise to do away with these expenses, and reduce the
acquisition and maintenance cost of system and application
software as well.
We'll see. In the mean time, we have to guess and the
divining is made harder by the commingling of technical and
geopolitical arguments. In other words, is the NC a good
idea because it's a good idea, or because it is
anti-Microsoft?
Guessing along, I personally believe the NC will gain
traction in two incarnations, as a New Age intelligent
terminal, fulfilling the age-old IBM dream of CUA, Common
User Access, and as a home information appliance. In the
latter respect, WebTV and its growing roster of competitors
attest to the desire for PC-less Web browsing. Some will
argue these are not NCs, I respect that position. I realize
I use "NC" loosely and, in my opinion, so will the
marketplace.
Does all this mean we have any role to play in the NC world?
We don't know yet. And, in any case, not by ourselves, not
in the way we're playing the desktop digital Media OS game.
In the desktop market, we don't need to worry about the
platform; hardware vendors kindly take care of that. Mostly,
we need to worry about applications. In the nascent NC
space, "applications" come with the languages the NC
interprets, HTML and Java, but the hardware platforms are
still coalescing and are likely to be very different from
one another.
Put another way, hardware and system software will be tied
more closely together than they are in the PC space. If we
do anything in that space, it will be as a supplier to
information and entertainment (infotainment?) appliance
manufacturers. In that space, the good news for Be is the
insatiable demand for digital media. For text-based
applications, more mature embedded systems are very
adequate. Conversely, the more these appliances respond to
market demands by deploying enriched multi-media content,
the better the modern media capabilities built in the BeOS
come into play.
This is highly speculative as we are still in the very early
days of these new appliances and of their fight against PCs.
In any event, we have no need to take sides as we no longer
make hardware.
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.
- Subject: Alpha port
AKA: BeOS for Alpha ?
AKA: C++ and the FBC issue
Would a BeOS port to DEC's Alpha chip be possible and
prudent? In a grass roots campaign, a number of developers
showed interest in contributing to a communal port, while
others think it would be a wasted effort. As Jos van
Roosmalen pointed out:
"BeOS is a consumer-OS...how many consumers will have a Dec
Alpha? ... The server market is going down -- exotic
processors are not required anymore..."
So should the BeOS avoid "non-consumer"? No, says Stuart
Mackinnon...
"...should BeOS limit itself to just consumer-level
machines? BeOS is supposed to be the Media OS. ... Media
content workers need as much power as they can get. Many of
the post-production houses that use [high-end multimedia
software] don't bother with Intel machines -- they're too
slow. They use Alphas... I do realise this is a very
specific case I have outlined here, but this is part of the
market that I would have thought a Media OS would be partly
aimed at."
Back in the technology corral, developers discussed the
technical requirements for an Alpha port (64-bit addresses
in particular). Would this be an opportunity for Be to break
binary compatibility? What compiler would one use? And is
the Alpha really as fast as everyone says? Steve B. says...
"I have been looking into getting an Alpha and the numbers
I've seen show for integer operations the Alpha isn't much
faster than PPro II of similar speed. Where the Alpha runs
away is in floating point operations. Trouble is most code
is integer based."
Christopher Tate was unbowed:
"First off, there *are* no PPros of similar speed; the
fastest they run is about 300 MHz. Second, the assertion
that 'most code is integer based' is rapidly becoming less
true."
Other first-hand testimonials vouch for Alpha's white-hot
speed.
Back to the business of porting: If binary compatibility
must be broken to migrate to 64-bit, should the FBC solution
be revisited? And whose "fault" is the FBC problem anyway:
The OS? The compiler? The language? The FBC dilemma spawned
a healthy, if Alpha-unrelated, sub-thread.
So, is an Alpha port a good idea or not? Dave Haynie had
this to say:
"Perhaps the most interesting thing about the notion of BeOS
on Alpha is just the fact that NT seems to be rapidly
becoming the choice OS for video work over Windows in the
mainstream, and Alpha machines are clearly the high-end in
NT systems. If Be's going for the content market, they could
do worse than show up on hardware compatible with what's
really kicking, and still emerging, in that market."
- Subject: Determining screen resolution
The initial question and answer about retrieving screen size
and resolution led to a discussion of the proper use of
stack-based and temporary objects. For example, the Be Book
states (in the BScreen docs, for example) that temporaries
are scoped to the enclosing brackets.
Not so, says Brian Stern: Temporaries are scoped to their
call. Using a temporary BScreen to get the screen's frame
that initializes a BRect introduces a subtle race condition
(between the get and the init).
Moreover, some of the Be classes don't implement copy
constructors properly. Jon Watte:
"The correct fix is for all programmers to either write
assignment and copy operators/constructors, OR to declare
them as private without implementing them so you can't
accidentally use them."
- Subject: Interface considerations
An on-going discussion of how and where to store resources.
Is it better to store app resources in the executable
itself, or as separate files? Many developer like the former
approach because it's more compact and makes transporting an
app much easier. However, as Osma Ahvenlampi pointed out...
"A separate file is always easier to upgrade... I don't
understand this "clutter" argument at all. In most
environments where resources need to be shared somehow, the
tendency is to move from one file to directories with many
small files. Maintaining them is much easier that way."
So, asks Thorsten Seitz, how about having executable
("runnable") folders a la NextStep? The best of both worlds:
You double-click the folder, and the enclosed app is
launched; you drag the folder and the app and all its
resources are copied.
The "correct" response to drag & drop data was also
discussed. An app should be able to interpret dropped data
according to its own needs, but how does the app tell the
user what its behaviour will be? Jon Watte puts the shoe on
the other foot -- and app *shouldn't* behave arbitrarily, no
matter how appropriate for its own needs:
"This is EXACTLY what the user interface guidelines are
supposed to tell us. A developer can dream up an arbitrary
number of possible actions in response to a user gesture.
However, if all apps did the same things in response to the
same user gestures, it would make the overall system much
more usable, NO MATTER which particular interpretation is
standardized upon."
- Subject: GUI suggestions
The single button mouse...is it a retarded subspecies that
should be ignored, or a tradition that should be respected?
Many developers strike a middle ground. Ian Russell Ollmann:
"...let us assume that we will not allow the one-buttoners
to hold up the platform and direct our concern towards how
we can still allow these hardware cripples to participate in
advances in the desktop metaphor. The one button solution
will not be as elegant as the two button case probably, but
it would be nice to find one just the same."
Mr. Ollman suggests the following mouse->action
correspondence:
"Contextual pop-up menus could correspond to the right mouse
button. Direct manipulation (pressing a button, dragging a
file, highlighting text, etc.) might always take the left
button. Secondary actions done to the same object (rotate in
space rather than move, select text from the current cursor
position to the point of click rather than just move the
cursor, make a link rather than copy in the tracker, etc.)
might use either both mouse buttons for the two button case
or the middle button for the three button case."
- Subject: Musings (ramblings?) of a tired NA
A certain Kuraiken has been using NT as a server, and is not
displeased with the interface, the ease of transition from
other systems, and its reliability. What does this have to
do with the BeOS? Our Kuraiken sees similar qualities, yet
heightened, in Be:
"Okay, now we have the BeOS. Brand spanking new -- so new
that it's not even version 1 yet. Unbelievably simple to
use, simple to program for and powerful while still managing
to stay lightweight. So, what is it, exactly, about the BeOS
that's 'preventing' it from being a powerful server OS? Is
there some technical issue that I'm not aware of? It's got
good SMP support, native TCP/IP, solid journaling file
system, able to handle monster hard-disks...apart from the
lack of server components (I would love to be proven wrong)
I don't really understand why it's not being given a chance
to...serve."
Many of our listeners offered their opinions: The BeOS *is*
an ideal server OS...the Media OS tag is simply a red
herring. The BeOS *will be* a server OS, but it's using the
Media tag to get started. The BeOS *isn't* a server OS
because it's not multi-user. Jon Watte wrote in to dispel
the must-be-multiuser myth:
"The server has to support whatever authentication and user
characteristics that the protocol being served requires.
However, the server OS itself does not need to have native
multi-user capabilities. You can write an FTP server with
its own user/password list file, and it'd look like a multi-
user FTP server to anyone on the network. "
- Subject: Networking Latency
AKA: Network flakiness...
Is networking under the BeOS (particularly connecting)
slower than on, say, a Mac? Brandon Itkowitz finds this to
be so, and wonders what the problem is. Other folks have
found connecting to be quite zippy and suggest that the
slowdown is probably due to name server lookup troubles.
Larry Daniel pointed out that the network server may not
reconnect as efficiently as possible if a first attempt
fails.
If you're interested in such matters, you may want to visit
the "BeOS Networking Concerns" Web page at
http://www.purity.com/be/concerns.html.
- Subject: Intel development system question
Planning ahead: What's the best Intel platform to buy in
anticipation of the BeOS Intel release? Not many answers to
this direct question, but a lot of Intel stabbing and
(begrudged) defense.
Intel's FPU is slow and memory intensive; granted it isn't
as fast as PPC, but it *isn't* memory intensive. MMX is
"marketing silicon"; the pipelining in MMX is great for (as
an example) image processing. But you can't use MMX and FPU
at the same time (no defense here). Dave Haynie offered an
amusing, backhanded explanation of MMX's existence. He
began...
"What you have to do is realize where MMX comes from, and
how Intel works. The bottom line at Intel is, really, that
the CPU always needs more work to do. If they can't keep
finding new problems to put the CPU on, they can't keep this
crazy growth schedule, or some joker will get a genuinely
useful co-processor chip in enough PCs to create some kind
of a standard. So the goal, as always, is to do more..."
...and rolled along thusly until the fires died down and we
all went to back to our tents.
|
