663 lines
46 KiB
HTML
663 lines
46 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-9.html" title="Issue 3-9, March 4, 1998" /><link rel="next" href="Issue3-11.html" title="Issue 3-11, March 18, 1998" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue3-9.html" title="Issue 3-9, March 4, 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-11.html" title="Issue 3-11, March 18, 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-9.html">Issue 3-9, March 4, 1998</a> Up: <a href="volume3.html">Volume 3: 1998</a> Next: <a href="Issue3-11.html">Issue 3-11, March 18, 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-10"></a>Issue 3-10, March 11, 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-10"></a>Be Engineering Insights: File Types, the Tracker, and You (Plus Some
|
||
Unrelated Tracker Rants)</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>
|
||
BeOS Release 3 uses file types much more extensively than Preview Release
|
||
2. Since file types have been a mild source of confusion to developers in
|
||
the past, and could be more so in the future, this article is an attempt
|
||
at reducing the mystery factor.
|
||
</p><p>
|
||
Application developers need to make sure that file types are set up
|
||
correctly. As you know, file types are represented by
|
||
<acronym class="acronym" title="Multi-purpose Internet Mail Extensions">MIME</acronym> strings, and
|
||
applications have a list of all the types they support in their
|
||
application info structure.
|
||
</p><p>
|
||
Dragging and dropping documents onto application icons now works only if
|
||
the corresponding application supports the given type or the group
|
||
(super-type) the type belongs to. If you drag a document onto an app that
|
||
doesn't support it, the icon doesn't highlight. If you drop it, it's the
|
||
same as moving or copying it.
|
||
</p><p>
|
||
The Tracker's new "Open With" feature relies entirely on file types and
|
||
the information in the <acronym class="acronym">MIME</acronym> database to do
|
||
its job. "Open With" lets you
|
||
choose from all the applications that support a given document,
|
||
displaying them in a hierarchically ordered menu or <span class="application">Tracker</span> window.
|
||
</p><p>
|
||
Say you have an application that can edit text files. Let's take my
|
||
favorite, <span class="application">StyledEdit</span>, as an example. The native document format of
|
||
<span class="application">StyledEdit</span> is 'text/plain', which is listed as a supported type in
|
||
<span class="application">StyledEdit</span>'s application info.
|
||
</p><p>
|
||
However, <span class="application">StyledEdit</span> can open just about any text file, including source
|
||
code, HTML, etc., some of which have a different type than 'text/plain'.
|
||
Instead of trying to enumerate all the different types of text files in
|
||
the list of supported types, <span class="application">StyledEdit</span> lists 'text'—in other words it
|
||
lists the entire <acronym class="acronym">MIME</acronym> group as its supported type.
|
||
</p><p>
|
||
Note, though, that listing 'text/*' does not do the job, since '*' is, in
|
||
fact, a valid string representing a sub-type, and it is definitely not
|
||
interpreted as a wild card. Several applications out there list similarly
|
||
confused file types. You know who you are, and now is your chance to fix
|
||
it.
|
||
</p><p>
|
||
Using the super-type as a supported type this way is convenient for
|
||
applications that, for example, use an add-on architecture to open video
|
||
files and you can't tell ahead of time which add-ons your application
|
||
will end up with.
|
||
</p><p>
|
||
Back to our <span class="application">StyledEdit</span> example. Even though 'text/plain' is a subset of
|
||
'text', you still want to include 'text/plain' in the supported types
|
||
list. The new "Open With" feature sorts applications so that those
|
||
listing specifically 'text/plain' appear before those that only list
|
||
'text'. Also, you may want distinct icons for different file types. In
|
||
other words, by listing a specific file type you are claiming to be able
|
||
to handle that particular file type.
|
||
</p><p>
|
||
As a rule of thumb, you should include all the types that your
|
||
application can generate and all the types your application can treat in
|
||
a special way, even though it already lists the corresponding super-type.
|
||
</p><p>
|
||
To add a super-type as a supported type in an application, use the good
|
||
old FileTypes application. Open your application or the
|
||
<code class="filename">.rsrc</code> file you
|
||
use to build it, press the Add button and select the super-type that you
|
||
want to add (e.g., 'text'). You can also drag the super-type from the
|
||
System File Types window and drop it into the list of supported types.
|
||
</p><p>
|
||
If you have an application that can open any type of document, such as a
|
||
<span class="application">ResEdit</span>-style app or a file hex editor, you could enumerate all the
|
||
existing file type groups (MIME super-types). Instead though, you should
|
||
include 'application/octet-stream' (Generic file) as a supported type.
|
||
Applications that list this type are super-handlers that the <span class="application">Tracker</span> lets
|
||
you drop any type of document onto.
|
||
</p><p>
|
||
<span class="application">FileTypes</span> and the new <span class="application">DiskProbe</span> are both examples of super-handler
|
||
applications. You'll notice that both show up at the bottom of the list
|
||
of suggestions every time you ask to open a document using the "Open
|
||
With" feature.
|
||
</p><p>
|
||
Your application should not include the wild card
|
||
'application/octet-stream' unless it can handle any file, and it also
|
||
makes sense for it to handle any type. Say you wrote a paint program that
|
||
listed 'application/octet-stream', but when you actually dropped a file
|
||
of any type other than an image, you got a dialog that "Document 'bla' is
|
||
not an image but it has 14359 bytes ..."
|
||
</p><p>
|
||
Not only would you sooner or later get arrested by the MIME Police for
|
||
misusing the super-handler privilege, but users would also despise you
|
||
for polluting their "Open With" menu/window with a false claim that your
|
||
application can handle the type 'audio/tube-sound' when in fact it
|
||
doesn't (don't you just hate all those gizmos that claim to sound like
|
||
tubes but don't even come close?). In other words, think twice before you
|
||
decide that your application is a super-handler and before you include
|
||
'application/octet-stream' as its supported type.
|
||
</p><p>
|
||
It goes without saying that if you specify a super-type (such as "audio")
|
||
as a supported type, you need to make sure your application does in fact
|
||
handle any type of that super-type gracefully, and that it won't crash
|
||
if, for instance, your application gets to open an audio file for which
|
||
there is no add-on. In fact, you should make sure every application can
|
||
handle every document gracefully and not rely on the file type mechanism
|
||
for factoring out the documents that could make your application crash or
|
||
otherwise misbehave. Here are two of the many reasons why:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
File types are not considered when opening an application from a
|
||
shell window, for example, when you type in a <span class="application">Terminal</span> window:
|
||
StyledEdit /boot/var/swap
|
||
</p></li><li><p>
|
||
Even though we strongly believe that using file types to control
|
||
document opening/drag-and-drop/application launching is a great way to
|
||
enhance the user experience in BeOS—and we will be enforcing it more
|
||
and more in future releases—we don't want the user to be unable to
|
||
open a document just because a file type is wrong or their favorite
|
||
application has confused application info. In that case, you can hold
|
||
down the Control key while dragging a document onto an application's
|
||
icon and the document will be passed to the app for opening, regardless
|
||
of the type.
|
||
</p></li></ul><p>
|
||
Therefore, make sure your app can deal with file types, that it can, for
|
||
example, bring up a clear explanation when it is asked to open a document
|
||
it doesn't understand instead of crashing.
|
||
</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="id670787"></a>More About File Types</h3></div></div></div><p>
|
||
We've tightened the screws on some of the file type API calls. The MIME
|
||
strings used for file types and application signatures can only contain
|
||
lower ASCII printable characters. /\<>@,;:"()[]?= are illegal characters.
|
||
The API does not let you set the application signature to anything that
|
||
does not start with 'application/' and you won't be able to set it to any
|
||
of the common file types of an application or executable (seems obvious
|
||
but there were apps out there that had it all confused).
|
||
</p><p>
|
||
All the file type handling code in Release 3 is case insensitive in
|
||
conformance with the MIME standard.
|
||
</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="id670812"></a>Text Clippings</h3></div></div></div><p>
|
||
Enough about file types. Here's a new Tracker feature that you can
|
||
support in your application:
|
||
</p><p>
|
||
The Tracker now handles drag-and-drop text and creates text clipping
|
||
files. Try dragging some text from <span class="application">StyledEdit</span> and dropping it onto the
|
||
desktop. Note that the name of the resulting clipping file has the name
|
||
of the originating document in it. This is done by adding a hint to the
|
||
drag message that <span class="application">Tracker</span> interprets as the suggested clipping file name.
|
||
When building the drag message, you can add the hint as follows:
|
||
</p><pre class="programlisting cpp">
|
||
<code class="classname">BMessage</code> <code class="varname">dragMessage</code>(<code class="constant">B_MIME_DATA</code>);
|
||
|
||
<span class="comment">// add the actual text to the drag message</span>
|
||
<code class="varname">dragMessage</code>.<code class="methodname">AddData</code>("text/plain", <code class="constant">B_MIME_TYPE</code>,
|
||
<code class="varname">someText</code>, <code class="varname">someLength</code>);
|
||
|
||
<span class="comment">// add the suggested clipping file name</span>
|
||
<code class="function">draggy</code>("be:clip_name", "my favorite text clipping");
|
||
</pre><p>
|
||
<span class="application">StyledEdit</span> uses <code class="classname">BTextView</code>,
|
||
which has a convenient new call
|
||
<code class="methodname">GetDragParameters()</code> that lets you do just that. So if you are already using
|
||
<code class="classname">BTextView</code>, you just add the suggested name in the overridden
|
||
<code class="methodname">GetDragParameters()</code>.
|
||
</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="id670920"></a>Why Is My Tracker Add-on Crashing?</h3></div></div></div><p>
|
||
Finally, here's a little update to Victor's cool article, "Fiddling With
|
||
Tracker Add-ons," from the February 4 Newsletter:
|
||
http://www.be.com/aboutbe/benewsletter/volume_II/Issue5.html#Workshop
|
||
</p><p>
|
||
Some developers have run into this problem. Say you have a <span class="application">Tracker</span> add-on
|
||
with a user interface that consists of classes that you wrote/overrode,
|
||
for example, you added some special features to <code class="classname">BWindow</code> in a
|
||
<code class="classname">MySuperTrackerAddonWindow</code> class. If you use the window in
|
||
a <span class="application">Tracker</span>
|
||
add-on like this, your add-on will most likely crash mysteriously, each
|
||
time probably in a different place:
|
||
</p><pre class="programlisting cpp">
|
||
<span class="type">void</span> <code class="function">process_refs</code>(<span class="type">entry_ref</span> <code class="parameter">someRef</code>, <span class="type"><code class="classname">BMessage</code> *</span><code class="parameter">someMessage</code>,
|
||
<span class="type">void *</span><code class="parameter">unused</code>)
|
||
{
|
||
...
|
||
<span class="type"><code class="classname">BWindow</code> *</span><span class="type">window</span> = new <code class="classname">MySuperTrackerAddonWindow</code>(...);
|
||
<code class="varname">window</code>-><code class="methodname">Show</code>();
|
||
}
|
||
</pre><p>
|
||
What happens is not quite as mysterious as it may seem. You created your
|
||
own window and launched it with the <code class="methodname">Show()</code> function. The window goes about
|
||
its business in its own thread while your <code class="function">process_refs</code> returns. The
|
||
<span class="application">Tracker</span> assumes the add-on is finished and unloads its code while
|
||
<code class="classname">MySuperTrackerAddonWindow</code> is still running: The rug got pulled right from
|
||
under its feet, er, I mean the program counter.
|
||
</p><p>
|
||
Obviously, the <span class="application">Tracker</span> could keep the add-on in memory, making it launch
|
||
a bit faster the next time. However the benefit of being able to
|
||
add/remove/change add-ons on the fly is great, and after all it's the
|
||
behavior you expect from the BeOS, right?
|
||
</p><p>
|
||
The correct way of dealing with this is to wait for any and all of the
|
||
threads that your add-on spawned to terminate, in our example:
|
||
</p><pre class="programlisting cpp">
|
||
<span class="type">void</span> <code class="function">process_refs</code>(<span class="type">entry_ref</span> <code class="parameter">someRef</code>, <span class="type"><code class="classname">BMessage</code> *</span><code class="parameter">someMessage</code>,
|
||
<span class="type">void *</span><code class="parameter">unused</code>)
|
||
{
|
||
...
|
||
<span class="type"><code class="classname">BWindow</code> *</span><code class="varname">window</code> = new <code class="classname">MySuperTrackerAddonWindow</code>(...);
|
||
<code class="varname">window</code>-><code class="methodname">Show</code>();
|
||
<span class="type">long</span> <code class="varname">dummy</code>;
|
||
<code class="function">wait_for_thread</code>(<code class="varname">window</code>-><code class="methodname">Thread</code>(), &<code class="varname">dummy</code>);
|
||
}
|
||
</pre><p>
|
||
It's a little trickier with multiple threads (for instance more dialogs
|
||
open, one for each <span class="type">entry_ref</span>) but I'm sure you get the picture and will
|
||
be able to deal with the more advanced cases.
|
||
</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="id671148"></a>Slap Up my beOs</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Baron</span> <span class="surname">Arnold</span></span></div></div></div><p>
|
||
you know why i like using bEos at home?<br />
|
||
i don't have to press F1.
|
||
</p><p>
|
||
there's a bug in PR2.<br />
|
||
but we fixed it for Release 3.
|
||
</p><p>
|
||
it's not rocket science,<br />
|
||
but it is work.<br />
|
||
it's about drivers before applications.<br />
|
||
it's about strength before style.<br />
|
||
you can front,<br />
|
||
but you will be confronted.
|
||
</p><p>
|
||
when a director feels that the very last take<br />
|
||
is the last grand stab at genius the camera will record,<br />
|
||
he says,<br />
|
||
"It's a wrap."
|
||
</p><p>
|
||
Release 3 is a wrap.<br />
|
||
it's done.<br />
|
||
it's shipping.
|
||
</p><p>
|
||
take your heart,<br />
|
||
restarted,<br />
|
||
into our labor of love.
|
||
</p><p>
|
||
re-shuffle,<br />
|
||
re-organize,<br />
|
||
assess your strengths and weaknesses.<br />
|
||
harness your revolutionary sprit and plow forward into the soil.<br />
|
||
bEos is strong.
|
||
</p><p>
|
||
because money rains onto the valley,<br />
|
||
and a river of vision has overrun its banks,<br />
|
||
again.
|
||
</p><p>
|
||
we have coated a little plastic disc with sixes and nines.
|
||
</p><p>
|
||
install it.<br />
|
||
run it.<br />
|
||
forget the pronunciations.<br />
|
||
don't worry about the title.<br />
|
||
because you've been on this planet forever.<br />
|
||
because you believe in fate.
|
||
</p><p>
|
||
i live in a rock and roll hovel.<br />
|
||
reckless but free.
|
||
</p><p>
|
||
i pin, as many of you do, my tail on a rolling chair,<br />
|
||
in front of a monitor i wish was bigger,
|
||
</p><p>
|
||
on a dream i wish was more useful,
|
||
</p><p>
|
||
in a wrestling match with focus.
|
||
</p><p>
|
||
because because because because because,<br />
|
||
because of the wonderful things it does.
|
||
</p><p>
|
||
developers rool.<br />
|
||
and baron drools.
|
||
</p><p>
|
||
see you at the conference.<br />
|
||
i love you all.
|
||
</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="DevWorkshop3-10"></a>Developers' Workshop: Welcome to x86</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Doug</span> <span class="surname">Wright</span></span></div></div></div><p>
|
||
"Greetings, people of earth! You will all worship my band and buy my
|
||
records!" Wouldn't it be great if you could tell everyone what to do?
|
||
Well, with the BeOS' scripting architecture you can! In preparation for
|
||
my upcoming BeDC presentation I needed to brush up on my scripting, so
|
||
here's some beginning material to get you started while it's fresh in my
|
||
mind.
|
||
</p><p>
|
||
Scripting on the BeOS uses <code class="classname">BMessage</code>s. This should be no surprise, since
|
||
<code class="classname">BMessage</code>s are great containers for commands and data, and can be easily
|
||
sent from one application to another. The receivers of <code class="classname">BMessage</code>s are
|
||
<code class="classname">BHandler</code>s. They respond appropriately to the message, either by handling
|
||
it or passing it on to another <code class="classname">BHandler</code>.
|
||
</p><p>
|
||
Be uses three main terms in its scripting metaphor: Properties,
|
||
Specifiers, and Suites.
|
||
</p><p>
|
||
Properties are the things in an app that you'd like to control from a
|
||
script. Four messages control properties:
|
||
</p><pre class="screen">
|
||
<code class="constant">B_CREATE_PROPERTY</code>
|
||
<code class="constant">B_DELETE_PROPERTY</code>
|
||
<code class="constant">B_GET_PROPERTY</code>
|
||
<code class="constant">B_SET_PROPERTY</code>
|
||
</pre><p>
|
||
Any part of an object can be considered a property. Code handles
|
||
scripting messages that SPECIFY that property.
|
||
</p><p>
|
||
You use specifiers to describe the property you are scripting. A
|
||
specifier must name a property as well as an instance of that property
|
||
when there is more than one. You can encapsulate specifier data inside
|
||
another BMessage. There are seven defined specifier message types:
|
||
</p><pre class="screen">
|
||
<code class="constant">B_INDEX_SPECIFIER</code>
|
||
<code class="constant">B_REVERSE_INDEX_SPECIFIER</code>
|
||
<code class="constant">B_RANGE_SPECIFIER</code>
|
||
<code class="constant">B_REVERSE_RANGE_SPECIFIER</code>
|
||
<code class="constant">B_NAME_SPECIFIER</code>
|
||
<code class="constant">B_ID_SPECIFIER</code>
|
||
<code class="constant">B_DIRECT_SPECIFIER</code>
|
||
</pre><p>
|
||
The simplest specifier is <code class="constant">B_DIRECT_SPECIFIER</code>. "Direct" means that the
|
||
property name is all that's needed to determine what to return.
|
||
</p><p>
|
||
Here's a direct specifier message in the making:
|
||
</p><pre class="programlisting cpp">
|
||
<code class="classname">BMessage</code> <code class="varname">name_msg</code>(<code class="constant">B_GET_PROPERTY</code>);
|
||
<code class="varname">name_msg</code>.<code class="methodname">AddSpecifier</code>("Name");
|
||
</pre><p>
|
||
There are special functions for adding specifiers to a message. If you
|
||
try to use <code class="classname">BMessage</code>::<code class="methodname">AddMessage</code>, the specifier will not be understood for
|
||
who it is, and we all know what that's like. ;-)
|
||
</p><p>
|
||
So how do we figure out what properties an object has and what messages
|
||
it understands? This is where suites come in. A suite is the description
|
||
of the properties an object understands. There are several suites defined
|
||
by Be and built into the Be kits. The suites are named in
|
||
<acronym class="acronym">MIME</acronym> style, for
|
||
example:
|
||
</p><pre class="screen">
|
||
suite/vnd.Be-handler
|
||
suite/vnd.Be-application
|
||
suite/vnd.Be-control
|
||
</pre><p>
|
||
The suite 'suite/vnd.Be-handler' is the most basic. All BeHandler-derived
|
||
objects inherit this basic understanding of scripting messages.
|
||
</p><p>
|
||
To demonstrate some basic scripting messages, I cooked up a little app
|
||
that gets a list of supported suites for all running applications. All
|
||
the work happens in the <code class="methodname">FillList()</code> function.
|
||
</p><pre class="programlisting cpp">
|
||
<span class="type">void</span>
|
||
<code class="classname">SuiteListView</code>::<code class="methodname">FillList</code>()
|
||
{
|
||
<span class="type">char *</span><code class="varname">name</code>;
|
||
<span class="type">char</span> <code class="varname">count_str</code>[25];
|
||
<span class="type">int32</span> <code class="varname">count</code>;
|
||
<code class="classname">BMessage</code> <code class="varname">reply</code>;
|
||
<code class="classname">BMessage</code> <code class="varname">name_msg</code>(<code class="constant">B_GET_PROPERTY</code>);
|
||
<code class="methodname">name_msg</code>.<code class="varname">AddSpecifier</code>("Name");
|
||
<code class="classname">BMessage</code> <code class="varname">suite_msg</code>(<code class="constant">B_GET_PROPERTY</code>);
|
||
<code class="varname">suite_msg</code>.<code class="methodname">AddSpecifier</code>("Suites");
|
||
<code class="classname">BMessage</code> <code class="varname">count_msg</code>(<code class="constant">B_COUNT_PROPERTIES</code>);
|
||
<code class="varname">count_msg</code>.<code class="methodname">AddSpecifier</code>("Window");
|
||
|
||
<code class="classname">BList</code> <code class="varname">teams</code>;
|
||
<code class="varname">be_roster</code>-><code class="methodname">GetAppList</code>(&<code class="varname">teams</code>);
|
||
<span class="type">int</span> <code class="varname">n</code> = <code class="varname">teams</code>.<code class="methodname">CountItems</code>();
|
||
<code class="function">printf</code>("%d apps running\n", <code class="varname">n</code>);
|
||
|
||
for(<span class="type">int</span> <code class="varname">i</code>=0; <code class="varname">i</code><<code class="varname">n</code>; <code class="varname">i</code>++){
|
||
<span class="type">team_id</span> <code class="varname">id</code> = (<span class="type">team_id</span>)<code class="varname">teams</code>.<code class="methodname">ItemAt</code>(<code class="varname">i</code>);
|
||
<code class="classname">BMessenger</code> <code class="varname">msgr</code>(<code class="constant">NULL</code>, <code class="varname">id</code>);
|
||
|
||
/* ask for Name and Suites */
|
||
if(<code class="varname">msgr</code>.<code class="methodname">SendMessage</code>(&<code class="varname">name_msg</code>, &<code class="varname">reply</code>, 10000, 10000)
|
||
== <code class="constant">B_OK</code>){
|
||
<code class="function">printf</code>("waiting for reply\n");
|
||
<code class="varname">reply</code>.<code class="methodname">PrintToStream</code>();
|
||
if(<code class="varname">reply</code>.<code class="methodname">FindString</code>("result", 0, &<code class="varname">name</code>) == <code class="constant">B_OK</code>){
|
||
<code class="function">printf</code>("%s\n", <code class="varname">name</code>);
|
||
<span class="type"><code class="classname">BStringItem</code> *</span><code class="varname">app</code> = new <code class="classname">BStringItem</code>(<code class="varname">name</code>);
|
||
<code class="methodname">AddItem</code>(<code class="varname">app</code>);
|
||
|
||
/* ask for supported Suites */
|
||
if(<code class="varname">msgr</code>.<code class="methodname">SendMessage</code>(&<code class="varname">suite_msg</code>, &<code class="varname">reply</code>, 10000, 10000)
|
||
== <code class="constant">B_OK</code>){
|
||
<span class="type"><code class="classname">BStringItem</code> *</span><code class="varname">label</code> =
|
||
new <code class="classname">BStringItem</code>("Supported Suites");
|
||
<code class="methodname">AddUnder</code>(<code class="varname">label</code>, <code class="varname">app</code>);
|
||
|
||
<span class="type">int</span> <code class="varname">x</code> = 0;
|
||
while(<code class="varname">reply</code>.<code class="methodname">FindString</code>("suites",<code class="varname">x</code>,&<code class="varname">name</code>) == <code class="constant">B_OK</code>){
|
||
<code class="function">printf</code>("%s\n", <code class="varname">name</code>);
|
||
<span class="type"><code class="classname">BStringItem</code> *</span><code class="varname">suite</code> = new <code class="classname">BStringItem</code>(<code class="varname">name</code>);
|
||
<code class="methodname">AddUnder</code>(<code class="varname">suite</code>, <code class="varname">label</code>);
|
||
<code class="varname">x</code>++;
|
||
}
|
||
}
|
||
|
||
/* ask for Window count */
|
||
if(<code class="varname">msgr</code>.<code class="methodname">SendMessage</code>(&<code class="varname">count_msg</code>, &<code class="varname">reply</code>,10000,10000)
|
||
== <code class="constant">B_OK</code>){
|
||
<code class="function">printf</code>("waiting for reply\n");
|
||
<code class="varname">reply</code>.<code class="methodname">PrintToStream</code>();
|
||
if(<code class="varname">reply</code>.<code class="methodname">FindInt32</code>("result", 0, &<code class="varname">count</code>) == <code class="constant">B_OK</code>){
|
||
<code class="function">sprintf</code>(<code class="varname">count_str</code>,"WindowCount = %d", <code class="varname">count</code>);
|
||
<span class="type"><code class="classname">BStringItem</code> *</span><code class="varname">wincount</code> =
|
||
new <code class="classname">BStringItem</code>(<code class="varname">count_str</code>);
|
||
<code class="methodname">AddUnder</code>(<code class="varname">wincount</code>, <code class="varname">app</code>);
|
||
}
|
||
}
|
||
}
|
||
}
|
||
}
|
||
<code class="function">printf</code>("finished with apps\n");
|
||
return;
|
||
}
|
||
</pre><p>
|
||
I use the global <code class="varname">be_roster</code> to get messengers for the running
|
||
applications. Then I send each app three messages: one to get the name of
|
||
the app, another to get the supported suites, and a third to get a count
|
||
of the windows.
|
||
</p><p>
|
||
In a future article I'll turn this into a useful app that lets you create
|
||
and send messages to a particular app handler.
|
||
</p><p>
|
||
In the meantime, check out the Be Book chapter on scripting:
|
||
http://www.be.com/documentation/be_book/app/scripting.html
|
||
</p><p>
|
||
Stay tuned, and remember, worship my band and buy my records!
|
||
</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-10"></a>Murphy Works at Be</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>
|
||
Or so it seems. A few days ago, we thought we had Release 3 (the
|
||
shorthand designation for our upcoming Intel release) nailed. Instead, we
|
||
got nailed, and how!
|
||
</p><p>
|
||
It started with a member of our board of directors. Two weeks ago, after
|
||
our first post-financing Board of Directors meeting, we gave Garrett
|
||
Gruener a handmade Release 3 CD. He went home happily and proceeded to
|
||
install the BeOS on one of his systems. It didn't work. We don't support
|
||
the graphics card on his system, yet.
|
||
</p><p>
|
||
So, the trial changed venues—to a machine graciously proffered by
|
||
Garrett's spouse. It turned out that we support her configuration but,
|
||
alas, not her data. Somehow, the partitioning tool we used (silently) set
|
||
the Windows partition to the new and improved FAT 32 file system, thereby
|
||
rendering the partition unreadable by Windows 95 OSR1, which only
|
||
understands the august DOS FAT 16 file system.
|
||
</p><p>
|
||
We know this now, and also how to set a partition back to FAT 16, but
|
||
when trouble struck, we thought we had destroyed the data on our
|
||
director's wife's hard drive. How to make a good impression and succeed
|
||
in the software business. Dominic Giampaolo, a Be engineer who bravely
|
||
ventured his technical support services, ended up working through most of
|
||
the night and finally succeeded in recovering the data, understanding the
|
||
cause of the problem, and feeding the appropriate information to the
|
||
people in charge of the partitioning software we bundle on the BeOS CD.
|
||
</p><p>
|
||
Our "luck" was in testing the installation process thoroughly. I was an
|
||
installation guinea pig myself, to make sure the process was
|
||
"executive-proof," but even this extreme form of QA wasn't pragmatic
|
||
enough. We made an invisible assumption, we used OSR2, the latest Win 95
|
||
OEM Service Release, and we got caught. Realizing this, we called the 200
|
||
or so recipients of similar CDs. Please, please, if you have OSR1,
|
||
proceed with extreme caution. We appreciate the positive feedback we got
|
||
by e-mail, phone, and newsgroup posts—many of you obviously "felt our
|
||
pain."
|
||
</p><p>
|
||
But we weren't done yet. I got a brand new "Ming Special," proceeded to
|
||
carve out a BeOS partition and install the newly improved Release 3. The
|
||
installation stalled. Engineers were called, looked at the system, looked
|
||
again, hooked it to a life support system to watch serial port output
|
||
during the boot process, fiddled with the BIOS. Nothing.
|
||
</p><p>
|
||
Then Windows wouldn't even boot. We suspected a hardware problem. As it
|
||
turns out, one of our engineers has an identical system and does not
|
||
experience the same symptoms. Eventually we discovered that my system
|
||
issues a non-maskable interrupt when first reading the real-time clock at
|
||
boot time and the kernel doesn't expect it and things gets stuck. Why on
|
||
my system? We should count ourselves lucky we caught that situation
|
||
inside, and now.
|
||
</p><p>
|
||
These are all useful reminders of the complexities and the humbling
|
||
experiences ahead of us.
|
||
</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="BeDevTalk3-10"></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="id672178"></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="id672185"></a>Subject: declspec...???????</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: BeOS carries on M$ legacy...</h5></div></div></div><p>
|
||
The Release 3 BeOS strongly recommends the use of the PC
|
||
industry-standard <code class="code">__declspec()</code> directive to import/export symbols. Is
|
||
this a sell out (to Microsoft rule)? Fighting words, and shoving ensued.
|
||
In a flame abatement effort, young Ficus Kirkpatrick had this to add...
|
||
</p><p>
|
||
“<span class="quote">Why are things being done the Microsoft way? Metrowerks is Be's compiler
|
||
vendor, and that's what they had available... [furthermore] by using a
|
||
format that is supported by tons of compilers already (Borland, Symantec,
|
||
Microsoft, the list goes on), it makes the porting effort easier, should
|
||
some tools vendor want to start supporting BeOS.</span>”
|
||
</p><p>
|
||
Cutting through the thicket, Sean Gies asked a practical question:
|
||
</p><p>
|
||
“<span class="quote">Will either of these methods [declspec or pragma] compile and link on
|
||
both PPC and x86 versions? I would like to be able to write the source
|
||
code _once_ and only change compile and link options for the different
|
||
platforms.</span>”
|
||
</p><p>
|
||
And Jon Watte answered:
|
||
</p><p>
|
||
“Both <code class="code">#pragma</code> and <code class="code">__declspec()</code> works on both PPC and Intel. And, while
|
||
__declspec(import) is not strictly necessary for code on Intel, it IS for
|
||
data (globals and class statics).
|
||
</p><p>
|
||
If you want to go with text files, you can create a .exp file for PPC,
|
||
and a COM file for Intel. Yes, you need to create two different files,
|
||
but then you touch no source.”
|
||
</p><p>
|
||
In performance land, Marco Nelissen observed that...
|
||
</p><p>
|
||
“<span class="quote">...the BeOS [uses] a compiler that I have not once seen listed among the
|
||
best, and for good reason. Performance of the BeOS on a P100 is pitiful,
|
||
it feels *much* slower than Windows 95 on the same machine.</span>”
|
||
</p><p>
|
||
To which Dominic Giampaolo replied:
|
||
</p><p>
|
||
“<span class="quote">We are aware that performance isn't what it could be. That is partly due
|
||
to the compiler and partly due to the fact that we haven't started
|
||
tweaking out things on Intel yet. If we made you guys wait until we
|
||
squeezed every last ounce of performance out of the software then you
|
||
wouldn't be receiving CD's any time in the next 6 months.</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="id672293"></a>Subject: B_MOUSE_MOVED, bug or feature ?</h4></div></div></div><p>
|
||
Does the system really generate only one <code class="constant">B_MOUSE_MOVED</code> event for each
|
||
four (or so) pixels of movement, as Joerg Stegemann claims? Yes, and for
|
||
the reason pointed out by many of our listeners: To avoid overflowing the
|
||
message queue.
|
||
</p><p>
|
||
Listeners wrote in to suggest other <code class="methodname">MouseMoved()</code> implementations and
|
||
work-arounds.
|
||
</p><p>
|
||
THE BE LINE: As mentioned in the Be Book: "<code class="methodname">MouseMoved()</code> should not be
|
||
used to track the cursor inside a view. Use the <code class="methodname">GetMouse()</code> function
|
||
instead."
|
||
</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="id672334"></a>Subject: Standardized resource formats</h4></div></div></div><p>
|
||
“<span class="quote">I'm curious to know how other developers are handling the lack of
|
||
resource format standards, especially as they relate to the development
|
||
of an application's GUI.</span>”
|
||
</p><p>
|
||
Also sprach Chris Russo. Und...
|
||
</p><p>
|
||
“<span class="quote">I've found Be's lack of something similar [to the Mac's ResEdit] to be a
|
||
bit disconcerting.</span>”
|
||
</p><p>
|
||
But shouldn't GUI elements be created by typing code, the way the
|
||
ancients did it? Nope—archives are the way to go, according to Tyler
|
||
Riti:
|
||
</p><p>
|
||
“<span class="quote">The advantage of using resources to build your GUI is that the compiled
|
||
code will be much smaller because you're not having to build the entire
|
||
interface in C++. Twenty or so function calls suddenly becomes just one
|
||
function call to completely build an entire window, interface and all.</span>”
|
||
</p><p>
|
||
“<span class="quote">But that's not the only way it can be done,</span>” said Dr. Peter Kittel,
|
||
emerging from the shadows with a fresh drink and a helpful smile, “<span class="quote">A
|
||
shareable library with the GUI configuration routines can take this load
|
||
from the programmer, so that he also has to issue just one call to get a
|
||
whole GUI. If done right, he even doesn't need external resources,
|
||
perhaps only for localization of his text strings.</span>”
|
||
</p><p>
|
||
“<span class="quote">Also,</span>” said Marco Nelissen, agreeably, “<span class="quote">although the *compiled code* may
|
||
be smaller when using a resource, the actual size of the executable file
|
||
shouldn't differ that much.</span>”
|
||
</p><p>
|
||
“<span class="quote">Another plus of coding it all is that your linker automatically tracks
|
||
the relation between the code and the classes it uses,</span>” said Mark-Jan,
|
||
joining his compatriots in the atrium. “<span class="quote">It throws out the ones you didn't
|
||
use. An 'object-factory' links itself to all classes it can generate,
|
||
bloating the code.</span>”
|
||
</p><p>
|
||
They adjourned to cigars and brandy in the study, where they found Kevin
|
||
Hendrickson slowly rotating the large globe in the corner. “<span class="quote">But one huge
|
||
advantage of resources is the ease of customization and localization. If
|
||
I want my app to have a bigger default window or a purple background, I
|
||
(or anyone else) can just edit the resource. If I want my dialog box to
|
||
say 'Don't do that!' in Japanese instead of (or in addition to) English,
|
||
I just edit a resource. I shouldn't have to recompile for such a simple
|
||
thing. This becomes increasingly important as apps get bigger and more
|
||
complex with users spread around the world.</span>”
|
||
</p><p>
|
||
The contestants agreed, or nearly so, that localization strings could be
|
||
stored in external files, which, of course, is not without its problems
|
||
(multiple files—precisely the bugaboo that resources attempts to
|
||
avoid).
|
||
</p><p>
|
||
A number of respondents wrote in to offer their own resource/localization
|
||
tools.
|
||
</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="id672460"></a>Subject: Release 3 and SCSI on Intel</h4></div></div></div><p>
|
||
Does Release 3 support SCSI?
|
||
</p><p>
|
||
THE BE LINE: Sorry, but no. This will be fixed in R4 (for Adaptec cards,
|
||
at least).
|
||
</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="id672477"></a>Subject: Raw CD read/write</h4></div></div></div><p>
|
||
A question from Jonathon Turner:
|
||
</p><p>
|
||
“<span class="quote">How would one do raw read and write from a CD, like for instance if it
|
||
is a video CD (or a PlayStation CD or a Saturn CD).</span>”
|
||
</p><p>
|
||
Dominic Giampaolo's reply: “<span class="quote">Just <code class="function">open()</code>
|
||
or <code class="methodname">BFile::SetTo()</code> the path name
|
||
of the CD. You can poke around in
|
||
<code class="filename">/dev/disk</code> to find what devices are
|
||
available.</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="id672521"></a>Subject: rgb_color</h4></div></div></div><p>
|
||
Naveen Michaud-Agrawal thinks that rgb_color should have a constructor.
|
||
Not everyone agrees. Brian Stern suggests that initializing the struct is
|
||
good enough; for example...
|
||
</p><pre class="programlisting c">
|
||
<span class="type">rgb_color</span> <code class="varname">color</code> = { 255, 255, 255, 255 };
|
||
</pre><p>
|
||
But, Mr. Stern continues, the struct COULD benefit from equivalence
|
||
operators.
|
||
</p><p>
|
||
Jason Gosnell rebuts the initialization method...
|
||
</p><p>
|
||
“<span class="quote">You can't declare [an initialization] on the fly as a temporary:</span>”
|
||
</p><p>
|
||
<code class="varname">foo</code>( <span class="type">rgb_color</span>(255, 255, 255, 255) ); <span class="comment">// can't do this</span>
|
||
<code class="varname">bar</code>( <code class="classname">BRect</code>(10.0, 10.0, 60.0, 60.0) ); <span class="comment">// but w/ BRect, we can.</span>
|
||
</p><p>
|
||
Also, says Mr. Michaud-Agrawal, you can't re-initialize; if you want to
|
||
reuse an <span class="type">rgb_color</span> struct, you have to reset each component separately.
|
||
(Mr. Michaud-Agrawal then conceded that what he really wants is a <code class="methodname">SetTo()</code>
|
||
method).
|
||
</p><p>
|
||
Unconvinced, Mr. Stern replied...
|
||
</p><p>
|
||
“<span class="quote"><span class="type">rgb_color</span>s are 4 bytes each. It makes more sense (to me) to allocate as
|
||
many on the stack as you need rather than setting the value of a single
|
||
variable back and forth to several different colors.</span>”
|
||
</p><p>
|
||
Jon Watte suggested that an in-line pseudo-constructor would be even
|
||
better than a real constructor:
|
||
</p><pre class="programlisting cpp">
|
||
inline <span class="type">rgb_color</span> <code class="function">rgb</code>(<span class="type">uint8</span> <code class="parameter">r</code>, <span class="type">uint8</span> <code class="parameter">g</code>, <span class="type">uint8</span> <code class="parameter">b</code>, <span class="type">uint8</span> <code class="parameter">a</code> = 255) {
|
||
<span class="type">rgb_color</span> <code class="varname">ret</code>;
|
||
<code class="varname">ret</code>.<code class="varname">red</code> = <code class="parameter">r</code>;
|
||
<code class="varname">ret</code>.<code class="varname">green</code> = <code class="parameter">g</code>;
|
||
<code class="varname">ret</code>.<code class="varname">blue</code> = <code class="parameter">b</code>;
|
||
<code class="varname">ret</code>.<code class="varname">alpha</code> = <code class="parameter">a</code>;
|
||
return <code class="varname">ret</code>;
|
||
}
|
||
</pre></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="id672734"></a>Subject: Query-Bug</h4></div></div></div><p>
|
||
Dirk Olbertz indexed an attribute, and then wrote, to a node, a longish
|
||
string as the attribute's value. A subsequent query seemed to ignore the
|
||
file. Why? Dominic Giampaolo:
|
||
</p><p>
|
||
“<span class="quote">Indexed attributes have to be less than 256 bytes in length. It may be
|
||
that this is not properly documented but this is definitely true.</span>”
|
||
</p><p>
|
||
Is this limit too low (ask our listeners)? If an attribute value exceeds
|
||
the limit, should the first 255 bytes (at least) be indexed? (Currently,
|
||
the entire attribute is tossed out of the indexed). How about storing
|
||
multiple values per attribute?
|
||
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue3-9.html">Issue 3-9, March 4, 1998</a> Up: <a href="volume3.html">Volume 3: 1998</a> Next: <a href="Issue3-11.html">Issue 3-11, March 18, 1998</a> </div><div id="footerB"><div id="footerBL"><a href="Issue3-9.html" title="Issue 3-9, March 4, 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-11.html" title="Issue 3-11, March 18, 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>
|