501 lines
36 KiB
HTML
501 lines
36 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 3: 1998</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume3.html" title="Volume 3: 1998" /><link rel="prev" href="Issue3-6.html" title="Issue 3-6, February 11, 1998" /><link rel="next" href="Issue3-8.html" title="Issue 3-8, February 25, 1998" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue3-6.html" title="Issue 3-6, February 11, 1998"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume3.html" title="Volume 3: 1998"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue3-8.html" title="Issue 3-8, February 25, 1998"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 3: 1998</div></div><div id="headerB">Prev: <a href="Issue3-6.html">Issue 3-6, February 11, 1998</a> Up: <a href="volume3.html">Volume 3: 1998</a> Next: <a href="Issue3-8.html">Issue 3-8, February 25, 1998</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue3-7"></a>Issue 3-7, February 18, 1998</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering3-7"></a>Be Engineering Insights: Repositioning Yourself!</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Erich</span> <span class="surname">Ringewald</span></span></div></div></div><p>
|
||
This week, two separate articles caught my eye. They were about companies
|
||
repositioning technologies they have already spent a lot of time and
|
||
effort on over the last few years. First was Java, the all-singing,
|
||
all-dancing programming language that would break down the Babelian
|
||
barriers amongst all the varied client platforms in the world. With total
|
||
portability and write once run everywhere going for it, all (or all but
|
||
the most performance critical) applications would be written in Java,
|
||
once.
|
||
</p><p>
|
||
But now, with Netscape and others announcing their abandonment of
|
||
client-side Java development entirely, Java is being repositioned as a
|
||
"server-side technology." While the value of platform neutral, easily
|
||
distributable, interpreted binaries for server applications is eluding me
|
||
at present, I watch with interest for further news.
|
||
</p><p>
|
||
Second was the mumbled repositioning by Apple of Rhapsody as a "server
|
||
OS." I'll admit, we've heard with decreasing frequency about the future
|
||
of Rhapsody since the keynote session at Macworld Expo in January 1997
|
||
where Gil Amelio introduced Rhapsody as the future OS for Apple, and
|
||
Steve Jobs and Steve Wozniak as "founder-advisors" returned to provide
|
||
occasional direction to the company.
|
||
</p><p>
|
||
A lot *has* happened since then (anybody heard more from Woz?), but even
|
||
I was surprised to see Apple's announcement of the future of Rhapsody as
|
||
a server OS, intended to complement and not to replace the aging Mac OS.
|
||
When Russell Brady, Apple's spokesman delivering this information was
|
||
questioned about the apparent change in plans, he responded, "We've never
|
||
positioned Rhapsody as anything but a server OS; anything else was made
|
||
up by the press." Hello?
|
||
</p><p>
|
||
Anyway, these repositionings got me to thinking about how we're doing
|
||
over the past few years as far as keeping to our original business
|
||
objectives. And I'm pleased to say that I think we've repositioned very
|
||
little. Our goal of providing a next generation operating system for use
|
||
with digital media (e.g. audio, video) has gone unchanged. Which is not
|
||
to say we haven't course corrected a little.
|
||
</p><p>
|
||
We did start in the hardware business as well as the software business.
|
||
Because two processors are better than one, especially when dealing with
|
||
streaming media, we built our OS to efficiently use more than one CPU. At
|
||
that time (the era of Mac OS and pre-NT), however, no one was building
|
||
inexpensive multiprocessor machines, so we built the BeBox, a dual
|
||
PowerPC desktop machine. A little while later, others began building
|
||
multiprocessor machines, so wasting as little time and money as possible,
|
||
we ported the BeOS to their platforms and got out of the hardware
|
||
business.
|
||
</p><p>
|
||
When we realized that a high performance, 64-bit file system is critical
|
||
to any OS wanting to call itself a media OS, we scrapped our original
|
||
file system and replaced it with one designed for digital video. And when
|
||
it seemed that Steve Jobs was hell bent on widening the gap between the
|
||
Intel installed base and the PowerPC installed base, we ported the OS
|
||
again.
|
||
</p><p>
|
||
We've come a long way by being responsive to the changing market
|
||
conditions around us, all the while holding true to our original goals.
|
||
Next month's Be Developer Conference gives us another opportunity to
|
||
listen to what is probably the most savvy segment of our customers and
|
||
colleagues, the developers. I'm looking forward to seeing you there and
|
||
collecting suggestions for next year's course corrections.
|
||
</p><p>
|
||
Just don't ask us to become a server OS.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering3-7-2"></a>Be Engineering Insights: BeWare 101</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Melanie</span> <span class="surname">Walker</span></span></div></div></div><p>
|
||
I have a confession. I live for BeWare. The best part of my day is when I
|
||
sit down at my BeBox with a cup of tea to ftp the incoming apps to my
|
||
machine. My job is to test them. I unzip them, install them, give them a
|
||
go. If they pass the "pretty indestructible" test, I add them to the
|
||
BeWare area of the Be web site http://www.be.com/beware/index.html.
|
||
</p><p>
|
||
For those of you who are new to the BeOS, I thought I'd explain briefly
|
||
how BeWare works. And some of you "old hands" might be interested in
|
||
hearing about recent changes in BeWare. I'll also give you pointers on
|
||
how to find the BeWare you're looking for, and where to go for tips and
|
||
recommendations.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id663202"></a>BeWare Is...</h3></div></div></div><p>
|
||
BeWare is an area on the Be web site where you'll find freeware,
|
||
shareware, and commercial applications and utilities to download. There's
|
||
a wide variety of BeWare apps, that run the gamut from games and audio
|
||
players to development languages and utilities. This makes BeWare a great
|
||
resource for both users and developers. Developers have an added benefit
|
||
—many BeWare developers include their source code with their
|
||
applications.
|
||
</p><p>
|
||
Within BeWare, you can peruse available applications alphabetically, by
|
||
category ("Audio," "Video," "Utilities," etc.), or by selecting "What's
|
||
New" for a list of recent arrivals. For each application you'll find a
|
||
description of the app, file size information, alternate download sites,
|
||
links to related web pages, and sometimes screen shots.
|
||
</p><p>
|
||
To download an item from BeWare, you can either click on the download
|
||
link, or once you know the file name, you can ftp it directly from
|
||
ftp://ftp.be.com. Once you've downloaded the app successfully and
|
||
expanded it, you're set to go.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id663237"></a>Uploading BeWare</h3></div></div></div><p>
|
||
You must be a registered Be Developer to upload BeWare. (For more
|
||
information on becoming a registered developer, see
|
||
http://www.be.com/developers/.) Once you've registered, the upload
|
||
process is simple and direct. You'll find the complete guidelines for
|
||
uploading BeWare at http://www.be.com/developers/ftp/, but here's a
|
||
summary:
|
||
</p><p>
|
||
Fill out the "Add BeWare" form in the Registered Developer Area
|
||
http://www.be.com/developers/, upload your app, and send e-mail to
|
||
ftparchive@be.com with the name of your app in the subject field. Within
|
||
the day, your app should be up on BeWare.
|
||
</p><p>
|
||
Just one caveat: Since the BeWare section is generated by scripts that
|
||
manipulate the information in the BeWare record you create, it is very
|
||
important to fill out your BeWare record accurately. For example, if you
|
||
list your application as "foobar.zip", when you upload your app, make
|
||
sure it's called "foobar.zip", and not "foo_bar.zip", "Foobar.zip," or
|
||
some other variant.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id663271"></a>Recent Changes in the BeWare Area</h3></div></div></div><p>
|
||
If you haven't visited BeWare for a while, you'll discover that it's been
|
||
reorganized. Applications and utilities are now classified within each
|
||
category according to their function. For example, within the Audio
|
||
category, sub-categories include "Editing," "Playback," and "Recording."
|
||
You'll also notice that when you click on an application's name, you go
|
||
to a page dedicated to that BeWare application. Giving each app its own
|
||
page cuts down on loading time and gives the author more space to include
|
||
a description or links to screen shots and other related URLs. All in the
|
||
name of better service!
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id663283"></a>Looking for New BeWare?</h3></div></div></div><p>
|
||
If you're eager to try new BeWare, but don't know where to begin, there
|
||
are several places to look for recommendations. Be hosts the BeWare Gem
|
||
of the Day on the front page of the web site. Other sources for reviews
|
||
and recommendations include BeOS Central, Be Leading Edge, and Be Dope.
|
||
</p></div></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="DevWorkshop3-7"></a>Developers' Workshop: BeOS Programming Basics: Part 1</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Eric</span> <span class="surname">Shepherd</span></span></div></div></div><p>
|
||
<span class="bold"><strong>[Webmaster's Note:</strong></span> This article has been corrected since its original
|
||
publication. Eric's next article will discuss the BeOS's coordinate
|
||
system in more detail, along with how to set up and respond to user
|
||
interaction in a menu bar.<span class="bold"><strong>]</strong></span>
|
||
</p><p>
|
||
As we draw closer to the first release of BeOS for Intel, a whole new
|
||
generation of BeOS programmers is preparing to enter unknown territory.
|
||
In order to help introduce them to writing BeOS applications (and to help
|
||
PowerPC programmers get started with the BeOS), my next few articles for
|
||
the Be Newsletter will comprise a brief introductory course on BeOS
|
||
programming.
|
||
</p><p>
|
||
This week, we're going to build a very basic application. Can you say
|
||
"Hello, world?" This article and the sample application we'll create will
|
||
show you how to do that.
|
||
</p><p>
|
||
Yes, that's right, we'll be writing "Hello World" as a BeOS application.
|
||
We'll create application, window, and view objects, and draw text into a
|
||
view. This article won't tell you everything you'll ever need to know,
|
||
but it should at least get you up and running with your first application
|
||
so you can start experimenting. In fact, you should keep a copy of the
|
||
<a class="link" href="http://www.amazon.com/gp/product/1565922875/ref=sr_11_1/102-6761474-6780910?%5Fencoding=UTF8">Be Developer's Guide</a>
|
||
or the online <a class="link bebook" href="../BeBook/index.html">Be Book</a>
|
||
handy as you read this article.
|
||
</p><p>
|
||
For this project, you'll need the following header files included in your
|
||
source code:
|
||
</p><pre class="programlisting cpp">
|
||
#include <Application.h>
|
||
#include <Window.h>
|
||
#include <View.h>
|
||
</pre><p>
|
||
Let's begin at the beginning: The <code class="classname">BApplication</code> class. This class defines
|
||
a BeOS application. In essence, the <code class="classname">BApplication</code> class represents the
|
||
link between your application and the Application Server. The Application
|
||
Server handles messaging, imaging, and other good stuff that most
|
||
applications need to do. So before you can draw on the screen or accept
|
||
or transmit messages, you have to create a <code class="classname">BApplication</code> object.
|
||
</p><p>
|
||
Typically, you'll do this by creating your own class, derived from
|
||
<code class="classname">BApplication</code>, so you can augment or override certain methods to customize
|
||
the behavior of your application. In our Hello World program, we'll be
|
||
creating a class called <span class="application">HelloApp</span> to serve this purpose. An application's
|
||
<code class="function">main()</code> function's primary duty is to create
|
||
the <code class="classname">BApplication</code> (or an
|
||
object of a class derived from <code class="classname">BApplication</code>) and to invoke it. Before we
|
||
create <span class="application">HelloApp</span>, let's look at a typical
|
||
<code class="function">main()</code> function (in fact, this
|
||
is the <code class="function">main()</code> our Hello World program will use):
|
||
</p><pre class="programlisting cpp">
|
||
<span class="type">void</span> <code class="function">main</code>(<span class="type">void</span>) {
|
||
<span class="type"><code class="classname">HelloApp</code> *</span><code class="varname">theApp</code>; <span class="comment">// Pointer to our application object</span>
|
||
<code class="varname">theApp</code> = new <code class="classname">HelloApp</code>;
|
||
|
||
<code class="varname">theApp</code>-><code class="methodname">Run</code>();
|
||
|
||
delete <code class="varname">theApp</code>;
|
||
}
|
||
</pre><p>
|
||
All <code class="function">main()</code> does here is create a new
|
||
<code class="classname">HelloApp</code> object, which is derived
|
||
from <code class="classname">BApplication</code>, as we'll see in a few moments. Once that's done, the
|
||
application's <code class="methodname">Run()</code> method is invoked.
|
||
The <code class="methodname">Run()</code> method is the
|
||
application's event loop. It won't return until the application is
|
||
terminated.
|
||
</p><p>
|
||
Once the <code class="methodname">Run()</code> method returns, we delete the application object, since
|
||
our program is about to terminate, so we don't need the object anymore.
|
||
</p><p>
|
||
It's useful to remember that the global variable <code class="varname">be_app</code> always points to
|
||
your application's <code class="classname">BApplication</code> object. That means you don't have to keep
|
||
a pointer to your application object around if you don't want to,
|
||
although if you call any custom methods added to the object, you'll need
|
||
to cast <code class="varname">be_app</code> to your class.
|
||
</p><p>
|
||
Now let's look at the <code class="classname">HelloApp</code> class:
|
||
</p><pre class="programlisting cpp">
|
||
class <code class="classname">HelloApp</code> : public <code class="classname">BApplication</code> {
|
||
public:
|
||
<code class="methodname">HelloApp</code>();
|
||
|
||
private:
|
||
<span class="type"><code class="classname">HelloWindow</code> *</span><code class="varname">theWindow</code>;
|
||
};
|
||
</pre><p>
|
||
As mentioned earlier, <code class="classname">HelloApp</code> is derived
|
||
from <code class="classname">BApplication</code>. We only need
|
||
the constructor to get done what we need to do, so that's the only public
|
||
method we define. A single private variable, <code class="varname">theWindow</code>, is used to store
|
||
a pointer to our application's window.
|
||
</p><p>
|
||
Let's check out the <code class="classname">HelloApp</code> constructor:
|
||
</p><pre class="programlisting cpp">
|
||
<code class="classname">HelloApp</code>::<code class="methodname">HelloApp</code>()
|
||
: <code class="classname">BApplication</code>("application/x-vnd.Be-HelloWorld")
|
||
{
|
||
<code class="classname">BRect</code> <code class="varname">windowRect</code>;
|
||
|
||
<code class="varname">windowRect</code>.<code class="methodname">Set</code>(50,50,200,200);
|
||
<code class="varname">theWindow</code> = new <code class="classname">HelloWindow</code>(<code class="varname">windowRect</code>);
|
||
}
|
||
</pre><p>
|
||
The <code class="classname">HelloApp</code> constructor defers to the
|
||
<code class="classname">BApplication</code> constructor, passing
|
||
the string "application/x-vnd.Be-HelloWorld". This odd-looking string is
|
||
the application's signature. It specifies that the application is an
|
||
application, and that the vendor is Be, Incorporated. The application's
|
||
name is "HelloWorld". This is the standard way we identify applications;
|
||
this string can be used by other programs to locate your application and
|
||
pass messages to it.
|
||
</p><p>
|
||
Once the object has been constructed, we create a <code class="classname">BRect</code>.
|
||
<code class="classname">BRect</code> is a
|
||
rectangle object (described in the Interface Kit chapter of the Be
|
||
Developer's Guide). It's used to define a rectangular area on the screen,
|
||
given the top, left, right, and bottom edges of the rectangle, and it has
|
||
several methods for setting and retrieving the position and size of the
|
||
rectangle.
|
||
</p><p>
|
||
One of these methods is <code class="methodname">Set()</code>, which we use to set
|
||
the rectangle to occupy the area from <code class="literal">(50,50)</code> to
|
||
<code class="literal">(200,200)</code> in space. This establishes a rectangle 151
|
||
pixels wide and 151 pixels tall. The arguments to
|
||
<code class="methodname">Set()</code> are in the order: left, top, right, bottom.
|
||
</p><p>
|
||
That <code class="classname">BRect</code> object is then passed to the
|
||
<code class="classname">HelloWindow</code> constructor when we
|
||
create our window object; this rectangle is used to position and size the
|
||
window on the screen when it is created. Note that we save the window
|
||
pointer in the <code class="classname">HelloApp</code>'s <code class="varname">theWindow</code>
|
||
field. That must mean it's time to
|
||
look over the <code class="classname">HelloWindow</code> class:
|
||
</p><pre class="programlisting cpp">
|
||
class <code class="classname">HelloWindow</code> : public <code class="classname">BWindow</code> {
|
||
public:
|
||
<code class="methodname">HelloWindow</code>(<code class="classname">BRect</code> <code class="parameter">frame</code>);
|
||
virtual <span class="type">bool</span> <code class="methodname">QuitRequested</code>();
|
||
};
|
||
</pre><p>
|
||
The <code class="classname">HelloWindow</code> class has a constructor, which
|
||
accepts a <code class="classname">BRect</code> object as
|
||
an argument (as discussed previously), and a <code class="methodname">QuitRequested()</code> method. Note
|
||
that <code class="classname">HelloWindow</code> is derived from <code class="classname">BWindow</code>,
|
||
which is the class from which
|
||
all windows are derived on the BeOS.
|
||
</p><pre class="programlisting cpp">
|
||
<code class="classname">HelloWindow</code>::<code class="methodname">HelloWindow</code>(<code class="classname">BRect</code> <code class="parameter">frame</code>)
|
||
: <code class="classname">BWindow</code>(<code class="parameter">frame</code>, "Hello World", <code class="constant">B_TITLED_WINDOW</code>,
|
||
<code class="constant">B_NOT_RESIZABLE</code>|<code class="constant">B_NOT_ZOOMABLE</code>)
|
||
{
|
||
<code class="methodname">AddChild</code>(new <code class="classname">HelloView</code>(<code class="methodname">Bounds</code>()));
|
||
<code class="methodname">Show</code>();
|
||
}
|
||
</pre><p>
|
||
The constructor, shown above, defers to the <code class="classname">BWindow</code> constructor to set up
|
||
the window. The frame rectangle specified as the argument to the
|
||
constructor is passed through, and the window's name is specified by the
|
||
string "Hello World". <code class="constant">B_TITLED_WINDOW</code> is a flag indicating the type of
|
||
window to create: A standard window with a tab at the top where the title
|
||
and close box should draw.
|
||
</p><p>
|
||
<code class="constant">B_NOT_RESIZABLE</code> and <code class="constant">B_NOT_ZOOMABLE</code>
|
||
are flags that indicate that the
|
||
window can't be zoomed (it won't have a zoom box) or resized.
|
||
</p><p>
|
||
Once the window is constructed, we need to add a view to the window.
|
||
Views are containers for other views. This is an interesting concept, and
|
||
it's an important one to understand. Windows are containers for views.
|
||
You typically can't draw directly into a window. You have to create a
|
||
view and attach it to the window first.
|
||
</p><p>
|
||
A window can have as many or as few views attached to it as you want, and
|
||
each view can have subviews. We'll develop this further in my next
|
||
article. For now, our application's window has a single view.
|
||
</p><p>
|
||
In our case, we want the view to be the exact size of the window, and
|
||
fill the window completely. So when we instantiate our <code class="classname">HelloView</code> (which
|
||
we'll look at shortly), we pass the <code class="classname">BRect</code>
|
||
returned by the <code class="methodname">Bounds()</code>
|
||
method. <code class="methodname">Bounds()</code> is a method of the
|
||
<code class="classname">BWindow</code> class that returns the
|
||
"bounds rectangle" of the window.
|
||
</p><p>
|
||
The bounds rectangle is a rectangle that indicates the area occupied by a
|
||
window, but in coordinates local to the window. This is another important
|
||
concept to grasp.
|
||
</p><p>
|
||
If your computer has a 640 x 480 screen, the top-left corner of the
|
||
screen has the coordinates <code class="literal">(0,0)</code> and the bottom-right corner of the
|
||
screen is at <code class="literal">(639,479)</code>. These are called "screen coordinates." When you
|
||
create a window, you specify the location of the window on the screen
|
||
using screen coordinates.
|
||
</p><p>
|
||
Once the window has been created, anything you do inside that window is
|
||
done in "local coordinates." Just as screen coordinates have the top-left
|
||
corner of the screen at <code class="literal">(0,0)</code>, local coordinates have the top-left corner
|
||
of the window at <code class="literal">(0,0)</code>.
|
||
</p><p>
|
||
The <code class="methodname">Bounds()</code> method in the <code class="classname">BWindow</code>
|
||
class returns the window's rectangle
|
||
in local coordinates, so in our program's case, this rectangle will be
|
||
<code class="literal">(0,0)-(150,150)</code>, which is exactly what we want.
|
||
</p><p>
|
||
We pass this <code class="classname">BRect</code> to the <code class="classname">HelloView</code>
|
||
constructor so the view will fill the
|
||
entire window. We'll study the <code class="classname">HelloView</code> class next.
|
||
</p><p>
|
||
The <code class="classname">HelloView</code> pointer that's returned by new
|
||
is then passed to <code class="classname">BWindow</code>'s
|
||
<code class="methodname">AddChild()</code> method. As we already learned, windows are containers for
|
||
views. The views that a window contains are called "children." The
|
||
<code class="methodname">AddChild()</code> method, then, adds a view to a window, thereby making that
|
||
view a child of the window. Once a view is added to a window, any drawing
|
||
done inside the view is visible in the window (assuming both the view and
|
||
the window are visible, but we'll get into that another time).
|
||
</p><p>
|
||
Once the child view has been added to the window, we call <code class="methodname">Show()</code>. This
|
||
<code class="classname">BWindow</code> method makes the window
|
||
visible—all <code class="classname">BWindow</code>s are hidden until
|
||
you call this method.
|
||
</p><p>
|
||
The other method we define for the <code class="classname">HelloWindow</code>
|
||
class, <code class="methodname">QuitRequested()</code>, is
|
||
called whenever someone attempts to close our window. This happens if the
|
||
user clicks the close box, for example. Here's the code:
|
||
</p><pre class="programlisting cpp">
|
||
<span class="type">bool</span> <code class="classname">HelloWindow</code>::<code class="methodname">QuitRequested</code>() {
|
||
<code class="varname">be_app</code>-><code class="methodname">PostMessage</code>(<code class="constant">B_QUIT_REQUESTED</code>);
|
||
return <code class="constant">true</code>;
|
||
}
|
||
</pre><p>
|
||
This is very simple. We simply post a <code class="constant">B_QUIT_REQUESTED</code> message to the
|
||
application. By default, when a <code class="classname">BApplication</code> object receives this
|
||
message, its <code class="methodname">Run()</code> method simply exits (which then returns control to our
|
||
<code class="function">main()</code> function, which deletes the application object and exits).
|
||
</p><p>
|
||
Then we return true to indicate that we're granting permission to close
|
||
the window. If <code class="methodname">QuitRequested()</code> returns <code class="constant">false</code>,
|
||
this indicates to the
|
||
caller that for whatever reason, they shouldn't close the window. An
|
||
obvious application of this would be to present an alert reminding the
|
||
user they haven't saved their work yet, with the option for the user
|
||
cancel whatever operation was about to close the window.
|
||
</p><p>
|
||
Finally, let's see the <code class="classname">HelloView</code> class, which
|
||
is derived from <code class="classname">BView</code>.
|
||
Views are the contexts in which all drawing is done.
|
||
</p><pre class="programlisting cpp">
|
||
class <code class="classname">HelloView</code> : public <code class="classname">BView</code> {
|
||
public:
|
||
<code class="methodname">HelloView</code>(<code class="classname">BRect</code> <code class="parameter">frame</code>);
|
||
virtual <span class="type">void</span> <code class="methodname">Draw</code>(<code class="classname">BRect</code> <code class="parameter">updateRect</code>);
|
||
};
|
||
</pre><p>
|
||
Our <code class="classname">HelloView</code> class has a constructor, which
|
||
accepts a <code class="classname">BRect</code> identifying
|
||
the size and position the view should occupy within its parent, and a
|
||
<code class="methodname">Draw()</code> method, which is called by the Application Server to update the
|
||
contents of the view.
|
||
</p><p>
|
||
The constructor looks like this:
|
||
</p><pre class="programlisting cpp">
|
||
<code class="classname">HelloView</code>::<code class="methodname">HelloView</code>(<code class="classname">BRect</code> <code class="parameter">frame</code>)
|
||
: <code class="classname">BView</code>(<code class="parameter">frame</code>, "HelloView", <code class="constant">B_FOLLOW_ALL_SIDES</code>,
|
||
<code class="constant">B_WILL_DRAW</code>) {
|
||
}
|
||
</pre><p>
|
||
As you can tell, we don't do anything in the constructor: We simply defer
|
||
to the <code class="classname">BView</code> constructor, passing through the frame rectangle. The view's
|
||
name is "HelloView". We specify the <code class="constant">B_FOLLOW_ALL_SIDES</code> flag for our
|
||
resizing mode, which indicates that the view will always fill the
|
||
complete window, even if the window is moved or resized, and the
|
||
<code class="constant">B_WILL_DRAW</code> flag, which tells the Application Server that we're
|
||
implementing a <code class="methodname">Draw()</code> method that needs to be called for updates.
|
||
</p><p>
|
||
The Application Server calls <code class="methodname">Draw()</code> whenever the window's contents need
|
||
to be updated. This occurs if another window passes in front of ours, or
|
||
when the window is initially shown. A <code class="classname">BRect</code> is passed to the method,
|
||
indicating the area of the view that needs to be redrawn.
|
||
</p><pre class="programlisting cpp">
|
||
<span class="type">void</span> <code class="classname">HelloView</code>::<code class="methodname">Draw</code>(<code class="classname">BRect</code> <code class="parameter">updateRect</code>) {
|
||
<code class="methodname">MovePenTo</code>(<code class="classname">BPoint</code>(20,75)); <span class="comment">// Move pen</span>
|
||
<code class="methodname">DrawString</code>("Hello, world!");
|
||
}
|
||
</pre><p>
|
||
As you can see, in Hello World, we're ignoring the <code class="varname">updateRect</code>. We
|
||
position the pen at coordinates <code class="literal">(20,75)</code> by creating a <code class="classname">BPoint</code> object
|
||
(which represents a point on the screen) with those coordinates, then
|
||
passing that point to the <code class="methodname">MovePenTo()</code> method.
|
||
</p><p>
|
||
Once the pen has been positioned where we want it, we call <code class="methodname">DrawString()</code>
|
||
to draw the message "Hello, world!" into the view.
|
||
</p><p>
|
||
The sample code for my article will be on the Be FTP site in:
|
||
ftp://ftp.be.com/pub/samples/intro/obsolete/helloworld_article.zip
|
||
</p><p>
|
||
In my next article, we'll investigate how you can use multiple views in a
|
||
window, and begin looking at some basic user interface features. For now,
|
||
poke through the Be Developer's Guide and the
|
||
<code class="filename">Application.h</code>,
|
||
<code class="filename">Window.h</code>,
|
||
and <code class="filename">View.h</code>
|
||
header files and do some exploring on your own.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee3-7"></a>BeDC, Be Dope, and Be Europe</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
It's a laundry list, but let's start with Be Europe. Last week, in
|
||
telling how we "paved the runway," i.e., raised the funds needed to
|
||
launch the BeOS platform in the Intel space, I left a significant pothole
|
||
in my story. I forgot to credit the Be Europe team for its contribution
|
||
to this successful financing round. At the last tally, slightly less than
|
||
25% of the funds raised came from Europe, and we couldn't have done it
|
||
without Jean Calmon and his team. I'm red-faced for my slip of the
|
||
electric pencil.
|
||
</p><p>
|
||
Now Be Dope, which attentive readers of our Web site have noticed a
|
||
reference to. Check it out, it is good entertainment and, occasionally,
|
||
good information—http://www.geocities.com/SiliconValley/Bay/7587/.
|
||
</p><p>
|
||
However, I must take exception to an item that offers an ingenious
|
||
explanation for my name. Among other twists, the story alleges that I was
|
||
actually born in New Jersey. I guess I should be flattered, right?
|
||
</p><p>
|
||
Since my past is under scrutiny, I might as well confess. I wasn't born
|
||
in New Jersey. As always though, there is a grain of truth: I once worked
|
||
in New Jersey. During a lapse in sanity, because I believed what was
|
||
printed in Fortune magazine before Stewart Alsop started contributing,
|
||
and because I listened to a headhunter, I ended up working for a company
|
||
based in the charming locale of Florham Park, NJ. That company was Exxon
|
||
Office Systems.
|
||
</p><p>
|
||
Exxon misexecuted a belief in the right idea: Information as the oil of
|
||
the 21st century. They were right—we know who the new Standard Oil is
|
||
and who the new Rockefellers are—but their concept of a bit wasn't
|
||
helpful in the computer business. So, all right, I did it, in New Jersey,
|
||
but it was a genuine misunderstanding on both sides.
|
||
</p><p>
|
||
I'm indisputably French, as John Dvorak attested. Feeling my pain, he
|
||
once introduced me as the mind of a Frenchman unfortunately trapped in
|
||
the body of a Frenchman. Too true. In any case, read Be Dope, even more
|
||
fun and relevant than Wired—and a lot easier on the eye.
|
||
</p><p>
|
||
As for my e-mail .sig, I'll have to drop the Dvorak quotation soon, it's
|
||
getting old. I'm taking suggestions, you know where to find me. I could
|
||
use "a French farmer abducted by aliens and raised in California by VCs,"
|
||
but that could be construed as slander by the venture community whose
|
||
existence I cherish and whose name I only invoke with the greatest
|
||
respect. Suggestions should be mindful of family values (this
|
||
recommendation is meant particularly for a certain Be engineer whose
|
||
T-shirts would cause HR to faint, if we had an HR department).
|
||
</p><p>
|
||
Lastly, the Be Developers' Conference.<br />
|
||
http://www.be.com/developers/BeDC_schedule.html is the link to the
|
||
program of the event. Contrary to our previous conferences, we're not
|
||
holding it on a weekend, or preceding or following another industry
|
||
event, and we are even charging $95 for it, a little less if you
|
||
registered early.
|
||
</p><p>
|
||
Beyond the "free" T-shirt and the wonderful buffet lunches, we intend to
|
||
make the content and delivery of the sessions worth your time and money.
|
||
Much has evolved in the BeOS, beyond and because of the move to
|
||
Intel-based hardware—new applications, more function in the OS, new
|
||
tools and utilities. Please come and see what the Be engineers and your
|
||
colleagues and competitors have done. I look forward to seeing you in
|
||
four weeks.
|
||
</p></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue3-6.html">Issue 3-6, February 11, 1998</a> Up: <a href="volume3.html">Volume 3: 1998</a> Next: <a href="Issue3-8.html">Issue 3-8, February 25, 1998</a> </div><div id="footerB"><div id="footerBL"><a href="Issue3-6.html" title="Issue 3-6, February 11, 1998"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume3.html" title="Volume 3: 1998"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue3-8.html" title="Issue 3-8, February 25, 1998"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|