nephele
/
haiku-website
0
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
haiku-website/static/legacy-docs/benewsletter/Issue2-38.html

562 lines
40 KiB
HTML
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?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 2: 1997</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="volume2.html" title="Volume 2: 1997" /><link rel="prev" href="Issue2-37.html" title="Issue 2-37, September 17, 1997" /><link rel="next" href="Issue2-39.html" title="Issue 3-39, October 1, 1997" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue2-37.html" title="Issue 2-37, September 17, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue2-39.html" title="Issue 3-39, October 1, 1997"><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 2: 1997</div></div><div id="headerB">Prev: <a href="Issue2-37.html">Issue 2-37, September 17, 1997</a>  Up: <a href="volume2.html">Volume 2: 1997</a>  Next: <a href="Issue2-39.html">Issue 3-39, October 1, 1997</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="Issue2-38"></a>Issue 2-38, September 24, 1997</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="Engineering2-38"></a>Be Engineering Insights: Getting Your Applications Ready For Preview
Release 2 and Other Topics</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Pavel</span> <span class="surname">Cisler</span></span></div></div></div><p>
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.
</p><p>
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:
</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="id587480"></a>Versioning</h3></div></div></div><p>
Versions were made available through the <code class="classname">BAppFileInfo</code> API, and the
<span class="application">FileTypes</span> 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.
</p><p>
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 <span class="application">Tracker</span> you are running:
</p><pre class="programlisting cpp">
<code class="classname">BPath</code> <code class="varname">path</code>;
if (<code class="function">find_directory</code>(<code class="constant">B_BEOS_SYSTEM_DIRECTORY</code>, &amp;<code class="varname">path</code>)
== <code class="constant">B_NO_ERROR</code>) {
<code class="varname">path</code>.<code class="methodname">Append</code>("Tracker");
<code class="classname">BFile</code> <code class="varname">tracker</code>(<code class="varname">path</code>.<code class="methodname">Path</code>(), <code class="constant">O_RDONLY</code>);
if (<code class="varname">tracker</code>.<code class="methodname">InitCheck</code>() == <code class="constant">B_NO_ERROR</code>) {
<code class="classname">BAppFileInfo</code> <code class="varname">info</code>(&amp;<code class="varname">tracker</code>);
if (<code class="varname">info</code>.<code class="methodname">InitCheck</code>() == <code class="constant">B_NO_ERROR</code>) {
<span class="type">version_info</span> <code class="varname">version</code>;
if (<code class="varname">info</code>.<code class="methodname">GetVersionInfo</code>(&amp;<code class="varname">version</code>, <code class="constant">B_APP_VERSION_KIND</code>)
== <code class="constant">B_NO_ERROR</code>)
<code class="function">printf</code>("the tracker short version is %s\n",
<code class="varname">version</code>.<code class="varname">short_info</code>)
}
}
}
</pre><p>
Under the original Preview Release, version will return no version info.
Under PR2, version will return "PR2".
</p><p>
The long version string is now displayed in the Get Info panel in the
<span class="application">Tracker</span>—make sure your app has its version set. You can do that using
<span class="application">FileTypes</span>—you can either set it on your final application or you can
set it in the <code class="filename">.rsrc</code> file that is appended to your binary during the make.
</p><p>
In addition, when you receive PR2, there is a new version of the
<code class="command">setversion</code> 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 <code class="command">setversion</code>
tool needs to be run after any <code class="command">copyres</code>,
<code class="command">addres</code>, <code class="command">mergeres</code> (insert your
favorite resource- copying tool here), because it sets the version in the
resource and if run before <code class="command">copyres</code>, it might get overwritten.
</p><p>
You can have one or two version structures in your application. The main
version structure is accessed using the <code class="constant">B_APP_VERSION_KIND</code> selector, the
secondary using the <code class="constant">B_SYSTEM_VERSION_KIND</code>. You do not necessarily need
the system version kind; in fact, currently <span class="application">FileTypes</span> doesn't even let
you edit it (the new setversion does).
</p><p>
Its purpose is to hold version information about a whole revision of a
number of components, where the <code class="constant">B_APP_VERSION_KIND</code> 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.
</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="id587730"></a>Tracker Add-Ons</h3></div></div></div><p>
There are quite a few Tracker add-ons out there, my favorite being
<span class="application">TermHire</span>. 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".
</p><p>
The modifier key combination for add-ons was changed to
<span class="keysym">Command</span>+<span class="keysym">Option</span>
(on Mac keyboards), since using only the <span class="keysym">Command</span> key was a little
limiting, since add-ons would have to share the space with all the other
pre-existing <span class="application">Tracker</span> shortcuts.
</p><p>
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.
</p><p>
If you have an installer for your add-on or ship it with installation
instructions, here is another PR2 tweak—the
<code class="filename">/home/config/add-ons/Tracker</code>
folder is now active. You should place, or
have the user place, your <span class="application">Tracker</span> add-on there.
</p><p>
The <code class="filename">/system/add-ons/Tracker</code>
is reserved for Be add-ons. When the <span class="application">Tracker</span>
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
<code class="filename">/system/add-ons/Tracker</code> and in
<code class="filename">/home/config/add-ons/Tracker</code>. In the case
of a conflict, only the system (i.e., from Be) one gets loaded.
</p><p>
Finally, don't forget <span class="application">Tracker</span> add-ons can have an icon, and that icon
will show up in the <span class="application">Tracker</span>'s add-on menu.
</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="id587838"></a>Supporting Color Drag &amp; Drop</h3></div></div></div><p>
On an unrelated topic, here is a tip about how to support a neat way of
setting colors in your app. I really like <span class="orgname">roDesign</span>'s
<span class="application">roColour</span> color
picker. The drag &amp; 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.
</p><p>
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 &amp; drop from <span class="application">roColour</span>, and here is the code
that supports it:
</p><pre class="programlisting cpp">
<span class="type">void</span>
<code class="classname">AboutScrollView</code>::<code class="methodname">MessageReceived</code>(<span class="type"><code class="classname">BMessage</code> *</span><code class="parameter">message</code>)
{
if (<code class="parameter">message</code>-&gt;<code class="methodname">WasDropped</code>()) {
<span class="type">rgb_color *</span><code class="varname">color</code>;
<span class="type">long</span> <code class="varname">size</code>;
if (<code class="varname">message</code>-&gt;<code class="methodname">FindData</code>("RGBColor", 'RGBC', &amp;<code class="varname">color</code>,
&amp;<code class="varname">size</code>) == <code class="constant">B_NO_ERROR</code>) {
<span class="type">int32</span> <code class="varname">modifs</code> = <code class="function">modifiers</code>();
if (<code class="varname">modifs</code> &amp; <code class="constant">B_OPTION_KEY</code>)
<code class="varname">textView</code>-&gt;<code class="varname">SetFontAndColor</code>(0,
<code class="varname">textView</code>-&gt;<code class="methodname">TextLength</code>(), 0, 0, <code class="varname">color</code>);
else
<code class="varname">textView</code>-&gt;<code class="methodname">SetViewColor</code>(*<code class="varname">color</code>);
<code class="varname">textView</code>-&gt;<code class="methodname">Invalidate</code>();
return;
}
}
inherited::<code class="methodname">MessageReceived</code>(<code class="varname">message</code>);
}
</pre><p>
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 <acronym class="acronym">RGB</acronym> 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.
</p><p>
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 <span class="application">Tracker</span>.
</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="id588028"></a>Interacting between a Terminal window and the Tracker</h3></div></div></div><p>
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.
</p><p>
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
<code class="code">/system/Tracker /boot/home</code> in Terminal, a window with your home
directory will open up, etc.
</p><p>
If you like this feature, you might want to add an alias to your
<code class="filename">.profile</code> file:
</p><pre class="programlisting sh">
alias t='/system/Tracker'
</pre><p>
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 <span class="application">Tracker</span> 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.
</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="News2-38"></a>News From The Front</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">William</span> <span class="surname">Adams</span></span></div></div></div><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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".
</p><p>
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.
</p><p>
First "mutable". If you tend to do things like this:
</p><pre class="programlisting cpp">
class <code class="classname">myobj</code> {
public:
<code class="methodname">doit</code>() const;
<span class="type">int</span> <code class="varname">myint</code>;
};
<code class="classname">myobj</code>::<code class="methodname">doit</code>() {
((<span class="type"><code class="classname">myobj</code> *</span>)<code class="varname">this</code>)-&gt;<code class="varname">myint</code> = 3;
}
</pre><p>
This is known as casting away <code class="code">const</code>. Why would you do it? Because the
<code class="methodname">doit()</code> method is declared <code class="code">const</code>, 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
<code class="varname">myint</code>. Well, if you do this:
</p><pre class="programlisting cpp">
class <code class="classname">myobj</code> {
public:
<code class="methodname">doit</code>() const;
mutable <span class="type">int</span> <code class="varname">myint</code>;
};
</pre><p>
Then you can safely change the <code class="varname">myint</code> variable without having to cast away
<code class="code">const</code> and without a compiler error. This seems to be safer than the cast
away <code class="code">const</code> trick, which is compiler implementation dependent and breaks
the <code class="code">const</code> contract completely.
</p><p>
The other thing I learned was the use of the "explicit" constructor
</p><pre class="programlisting cpp">
class <code class="classname">myobj</code> {
public:
explicit <code class="methodname">myobj</code>(const <code class="classname">myobj</code> &amp;);
};
</pre><p>
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:
</p><pre class="programlisting cpp">
class <code class="classname">string</code> {
public:
<code class="methodname">string</code>(<span class="type">int</span> <code class="parameter">nElements</code>);
<code class="methodname">string</code>(<span class="type">char *</span><code class="parameter">initial</code>);
};
<span class="type">string</span> <code class="varname">aString</code> = 'a';
</pre><p>
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 <span class="type">int</span>, and the constructor that takes an <span class="type">int</span>
was implicitly used.
</p><p>
Using the <code class="code">explicit</code> keyword on the constructor will prevent this implied
usage and force you to implement what you mean instead.
</p><pre class="programlisting cpp">
class <span class="type">string</span> {
public:
explicit <code class="methodname">string</code>(<span class="type">int</span> <code class="parameter">nElements</code>);
<code class="methodname">string</code>(<span class="type">char</span> <code class="parameter">initialChar</code>);
<code class="methodname">string</code>(<span class="type">char *</span><code class="parameter">initialString</code>);
};
</pre><p>
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.
</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="Gassee2-38"></a>More (Or Less) on Modularity</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>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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?
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</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="BeDevTalk2-38"></a>BeDevTalk Summary</h2></div></div></div><p>
BeDevTalk is an unmonitored discussion group in which technical
information is shared by Be developers and interested parties. In this
column, we summarize some of the active threads, listed by their subject
lines as they appear, verbatim, in the mail.
</p><p>
To subscribe to BeDevTalk, visit the mailing list page on our web site:
http://www.be.com/aboutbe/mailinglists.html.
</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="id588550"></a>NEW</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588556"></a>Subject: Alpha port</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">
AKA: BeOS for Alpha ?<br />
AKA: C++ and the FBC issue
</h5></div></div></div><p>
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:
</p><p>
“<span class="quote">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...</span>”
</p><p>
So should the BeOS avoid "non-consumer"? No, says Stuart Mackinnon...
</p><p>
“<span class="quote">...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.</span>”
</p><p>
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...
</p><p>
“<span class="quote">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.</span>”
</p><p>
Christopher Tate was unbowed:
</p><p>
“<span class="quote">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.</span>”
</p><p>
Other first-hand testimonials vouch for Alpha's white-hot speed.
</p><p>
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.
</p><p>
So, is an Alpha port a good idea or not? Dave Haynie had this to say:
</p><p>
“<span class="quote">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.</span>”
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588674"></a>Subject: Determining screen resolution</h4></div></div></div><p>
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.
</p><p>
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).
</p><p>
Moreover, some of the Be classes don't implement copy constructors
properly. Jon Watte:
</p><p>
“<span class="quote">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.</span>”
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588713"></a>Subject: Interface considerations</h4></div></div></div><p>
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...
</p><p>
“<span class="quote">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.</span>”
</p><p>
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.
</p><p>
The "correct" response to drag &amp; 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:
</p><p>
“<span class="quote">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.</span>”
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588772"></a>Subject: GUI suggestions</h4></div></div></div><p>
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:
</p><p>
“<span class="quote">...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.</span>”
</p><p>
Mr. Ollman suggests the following mouse-&gt;action correspondence:
</p><p>
“<span class="quote">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.</span>”
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588811"></a>Subject: Musings (ramblings?) of a tired NA</h4></div></div></div><p>
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:
</p><p>
“<span class="quote">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.</span>”
</p><p>
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:
</p><p>
“<span class="quote">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.</span>”
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588856"></a>Subject: Networking Latency</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: Network flakiness...</h5></div></div></div><p>
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.
</p><p>
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.
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id588884"></a>Subject: Intel development system question</h4></div></div></div><p>
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.
</p><p>
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...
</p><p>
“<span class="quote">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...</span>”
</p><p>
...and rolled along thusly until the fires died down and we all went to
back to our tents.
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue2-37.html">Issue 2-37, September 17, 1997</a>  Up: <a href="volume2.html">Volume 2: 1997</a>  Next: <a href="Issue2-39.html">Issue 3-39, October 1, 1997</a> </div><div id="footerB"><div id="footerBL"><a href="Issue2-37.html" title="Issue 2-37, September 17, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue2-39.html" title="Issue 3-39, October 1, 1997"><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>
Reference in New Issue View Git Blame Copy Permalink