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

472 lines
34 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 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-1.html" title="Issue 3-1, January 7, 1998" /><link rel="next" href="Issue3-3.html" title="Issue 3-3, January 21, 1998" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue3-1.html" title="Issue 3-1, January 7, 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-3.html" title="Issue 3-3, January 21, 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-1.html">Issue 3-1, January 7, 1998</a>  Up: <a href="volume3.html">Volume 3: 1998</a>  Next: <a href="Issue3-3.html">Issue 3-3, January 21, 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-2"></a>Issue 3-2, January 14, 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-2"></a>Be Engineering Insights: Workspace Workout</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Robert</span> <span class="surname">Polic</span></span></div></div></div><p>
Workspaces are an illusion that allow users to organize their
applications and documents into different virtual screens. By default,
application windows open in the current workspace and live solely in a
single workspace (though the user, through the Workspaces preference
panel, can later position the window in any of the available workspaces).
</p><p>
If the default behavior satisfies the needs of your application, you
don't need to add any workspace- specific code. However, if your
application supports multiple windows, gratuitous animation, or other
processing tasks that can stop when its workspace is deactivated and
continue when it is reactivated, there area handful of <code class="classname">BWindow</code> and global
functions to assist you.
</p><p>
In most cases the user should determine which workspace a given window
exists in (use <code class="constant">B_CURRENT_WORKSPACE</code> in the
<code class="classname">BWindow</code> constructor), though
there may be cases were it makes sense for the application to set the
workspace for a window. To create a window in a specific workspace (or
workspaces) the <code class="classname">BWindow</code> constructor takes an
<span class="type">unsigned int32</span> bit field. A
"1" in any bit position indicates the window should exist in that
workspace (with bit 0 corresponding to the first workspace). Using
<code class="constant">B_ALL_WORKSPACES</code> forces the window to exist in all workspaces. Most
applications should not use <code class="constant">B_ALL_WORKSPACES</code> since this would rapidly
defeat the purpose of workspaces.
</p><p>
To change the current workspace (or workspaces) for a window after
construction, there is a <code class="classname">BWindow</code> method,
<code class="methodname">SetWorkspaces()</code>, that takes the
same bit field parameter. An example of an application that may need to
do this is a paint program with an editing window and separate tool
palette windows. When the user moves the editing window to another
workspace, the palette windows should follow. To do this, override the
edit window's <code class="methodname">WorkspaceChanged()</code> method and call the palette window's
<code class="methodname">SetWorkspaces()</code> function:
</p><pre class="programlisting cpp">
<span class="type">void</span> <code class="classname">TEditWindow</code>::<code class="methodname">WorkspacesChanges</code>(<span class="type">uint32</span> <code class="parameter">old_ws</code>,
<span class="type">uint32</span> <code class="parameter">new_ws</code>)
{
<code class="varname">fPaletteWindow</code>-&gt;<code class="methodname">SetWorkspaces</code>(<code class="parameter">new_ws</code>);
}
</pre><div class="admonition note"><div class="title">Note</div><div class="graphic"><img class="icon" alt="Note" width="32" src="./images/admonitions/Info_32.png" /><div class="text"><p>
Before creating or moving a window to a given workspace you should
first determine that the workspace is valid (the user can set between 1
and 32 workspaces). There is a global function, <code class="function">count_workspaces()</code>, that
can be used to determine the number of workspaces.
</p></div></div></div><p>
Some applications may wish to create follow-on windows in the same
workspace that the main window resides in. To determine which workspace
(or workspaces) the main window is in, use the window's <code class="methodname">Workspaces()</code>
method. An application example might be a compiler that creates a status
window:
</p><pre class="programlisting cpp">
<span class="type">void</span> <code class="classname">TCompilerWindow</code>::<code class="methodname">ShowStatus</code>(...)
{
<span class="type"><code class="classname">BWindow</code>*</span> <code class="varname">status</code> = new <code class="classname">BWindow</code>(<code class="parameter">rect</code>, <code class="parameter">title</code>, <code class="parameter">type</code>, <code class="parameter">flags</code>,
<code class="methodname">Workspaces</code>());
}
</pre><p>
An application that can curtail processing when its window's workspace
becomes inactive should do so. Obviously, a web browser should not stop a
download, but it could stop all animated GIFs. To do this, override the
<code class="classname">BWindow</code>'s <code class="methodname">WorkspaceActivated()</code>
method and stop or start processing tasks
according to the state variable:
</p><pre class="programlisting cpp">
<code class="classname">EyeCandy</code>::<code class="methodname">WorkspaceActivated</code>(<span class="type">int32</span> <code class="parameter">ws</code>, <span class="type">bool</span> <code class="parameter">active</code>)
{
(<code class="varname">active</code>) ?
<code class="function">release_sem</code>(<code class="varname">process_sem</code>) :
<code class="function">acquire_sem</code>(<code class="varname">process_sem</code>);
}
</pre><p>
Applications with windows that live in more than one workspace can do
this a bit more efficiently by ignoring the ws variable and instead using
the global function <code class="function">current_workspace()</code> to determine if the window lives
in the current workspace:
</p><pre class="programlisting cpp">
<code class="classname">EyeCandy</code>::<code class="methodname">WorkspaceActivated</code>(<span class="type">int32</span> <code class="parameter">ws</code>, <span class="type">bool</span> <code class="parameter">active</code>)
{
(<code class="methodname">Workspaces</code>() &amp; (1 &lt;&lt; <code class="function">current_workspace</code>())) ?
<code class="function">release_sem</code>(<code class="varname">process_sem</code>) :
<code class="function">acquire_sem</code>(<code class="varname">process_sem</code>);
}
</pre></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-2"></a>Developers' Workshop: Proper Attribution</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Stephen</span> <span class="surname">Beaulieu</span></span></div></div></div><p>
As you know, the Developer's Workshop is all about answering questions
and providing sample code to developers. We get a list of topics and
questions developers send in. We look them over and provide the sample
code that we think will solve the problem. Well, being the new kid on the
block, I brought a question with me. "When is it appropriate to use
attributes to store information for your program?"
</p><p>
Making the most of my direct access to the Be engineers, I wandered
around asking my question until I got some answers.
</p><p>
The quick and dirty answer is that attributes are appropriate for storing
extra information that is inappropriate or impossible to store in the
file itself. This information may change frequently, or can be done
without if it doesn't exist.
</p><p>
As always, the quick and dirty answer isn't the full story. But the full
story needs a little background information.
</p><p>
Attributes are arbitrary name/value pairs associated with a file, which
can be indexed by the file system for querying. Attribute names can be up
to 255 characters in length, and their values can be of any size.
Attribute names and values are stored together, and a file can only have
a single value for a given attribute name. Attributes are stored in the
order they are added to the file. Queries are limited to indexed
attributes whose values are strings, <span class="type">float</span>s, or one of the various
integer types.
</p><p>
Some implementation details suggest ways to optimize attribute storage.
These details are subject to change, but the suggestions I'll make
shouldn't negatively affect future performance. In any case, these
details will be completely invisible to users.
</p><p>
While attributes can store any amount of information, each file has a
small "fast attribute" area that is accessible at little cost whenever
the file is referenced. This "fast attribute" area is about 700 bytes in
size, and is the first place attribute information is stored. As soon as
it fills up, the file system creates additional areas to store
attributes. The additional areas impose some file system access costs,
making them considerably slower than the "fast" area.
</p><p>
So, what can a developer do to maximize the performance of retrieving
attribute information? Try and get as much information into the "fast"
attribute area as possible. Although there are no specific methods to
guarantee that an attribute exists inside of the fast attribute area, we
can suggest guidelines that should increase the likelihood of having your
attributes accessed in the fastest method possible:
</p><div class="orderedlist"><ol><li><p>
Keep attribute names short, but descriptive. Remember to avoid
namespace conflicts.
</p></li><li><p>
Create all of your smallest attributes first, leaving larger ones
for the end.
</p></li></ol></div><p>
With these optimization guidelines in mind, let's look to the BeOS for
some appropriate uses for attributes. Perhaps the best overall example is
using attributes to store information about e-mail files. The mail_daemon
saves each message to a file and adds the following attribute information:
</p><pre class="screen">
Information Attribute Name
----------- --------------
Name MAIL:name
Subject MAIL:subject
To MAIL:to
From MAIL:from
ReplyTo MAIL:reply
Status MAIL:status
Priority MAIL:priority
When MAIL:when
Header Length MAIL:header_length
Content Length MAIL:content_length
</pre><p>
Most of these are self explanatory, and are simply the record of
information contained in the file in the attribute system for querying
purposes.
</p><p>
The header_length attribute, however, is worthy of special note, as it
shows an efficient use of attributes. Header information is not normally
needed when displaying a message to the user, but since it's at the
beginning of the file it's important to know its length to make it easier
to jump to the real contents of the file. Similarly, when the headers are
specifically requested, having the length available makes it easy to read
that amount of data from the file. This makes parsing the file to get to
the end of the headers every time the file is accessed unnecessary.
</p><p>
Other BeOS uses of attributes can be found in StyledEdit and the Tracker.
StyledEdit stores all of its style information in attributes. This allows
the actual data of the file to be stored as plain text, making it easy to
read the file in applications that don't care about the styled
information. The Tracker uses attributes to store icon and position
information for files and folders.
</p><p>
The People app also uses attributes for information storage. Person files
contain only attributes; there is no other data in the file itself. This
raises the question of whether it is appropriate to use attributes as a
kind of built-in database. The answer is that it really depends on the
type of information you want to store. The drawback of such a system is
that it is inefficient in terms of storage. Every record would exist as
an individual file, taking up a minimum of a block on the drive. Each
file must live in some directory somewhere.
</p><p>
While in theory this method should work for nearly any amount of
information, as a practical matter a "database" with hundreds of
thousands of records would be inefficient both in terms of storage space
and speed of accessing information. On the other hand, it can be useful
for storing contact information in a place where it's easily accessed by
any application.
</p><p>
There are many uses for attributes in addition to those we've touched on
in this article. Attributes could be used to store the URL of a
downloaded document; the last backup date for a file; the keywords of a
document; or gamma correction, color depth and dimensions of an image.
We'd like to hear about the uses that developers are putting attributes
to. If you have an interesting use, drop us a line at the online support
form in the Registered Developers Area. We're curious.
</p><p>
Finally, there are a few things to be aware of when dealing with
attributes. Currently, only direct Tracker copying to another Be File
System disk or archiving your files with zip preserves attribute
information. Most of the other common storage and transfer formats do not
save that information (including tar, cp, ftp and mail attachments.) This
means that you need to take extra care when transferring files that
contain attributes. Also, applications should be aware that a file might
not contain the attributes they expect, and be prepared to rebuild them,
if possible.
</p><p>
Well, I've gone over many things to consider when using attributes, but
I've not touched on how to actually use them. I'll cover that in four
weeks, along with some sample code that shows how to read and write files
in the BeOS.
</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-2"></a>CES Snapshot</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>
Last week, Steve Sakoman and I took time off MacWorld to go to Las Vegas.
This wasn't a desperation financing trip, but an attempt to survey the
scene at the Consumer Electronics Show. It didn't start well. Steve tried
to register electronically and the server promptly got stuck leaving him
in registration limbo for a while.
</p><p>
We went in looking for signs of the convergence between consumer
electronics and computing. We saw black boxes and silver boxes and
titanium colored boxes, but not much convergence. Still, WebTV Plus, the
latest version, is really good, TV and the Web coexist nicely, even if
they don't merge yet and this product will make Microsoft look very smart.
</p><p>
Smart is an adjective that becomes harder to place when contemplating the
latest TCI machinations. John Malone gives a layer of the mille-feuilles
to Scott McNealy's Personal Java and another one to Windows CE. But the
hardware layer is still to be defined, the microprocessor is to be
anointed in the Spring, all the while NextLevel nee and born again
General Instruments (the NextLevel name didn't work) claims billions in
orders for their next generation set-top boxes.
</p><p>
I guess John Malone is the smartest right now for wringing money out of
Sun and Microsoft. Sun is rumored to provide about $10 per box to
"compensate" for the hardware penalty required to run Personal Java and
Microsoft is rumored to have made similar concessions in excess of the
WinCE royalty, while pointing out Java, unlike Win CE, won't run on all
boxes, only higher-end ones. The "happy" processor manufacturer knows
what to expect.
</p><p>
Will this yield a nice product? The developments will be interesting to
watch with each player bringing up hardware or debugging code while
watching the other guys trying to create some kind of toll gate in order
to recoup their "advance payment" and, at the same time, rereading the
legal paperwork looking for loopholes in the contracts.
</p><p>
With this in mind, the un-second-guessed approach pursued by WebTV looks
even more attractive, in a different domain for the time being.
</p><p>
We watched with great interest the PalmPC demos (I'm a Palm Pilot user
and a director of 3Com, the owner of Palm Computing—so you know the
possible biases in my opinions). Same physical size as the Pilot, and
running a version of Windows CE, with Microsoft's might, it could become
tough competition.
</p><p>
The PalmPC demo involved a man and a woman. The woman played the role of
the "conventional" user of paper organizers, big purse, you see the
picture, and the man inside the little demo booth was the more
enlightened user of a PDA.
</p><p>
On top of the booth, a big screen reproduced the small PalmPC screen for
a large audience—I thought, until Steve Sakoman's sharper eyes and
elbow brought me back to reality. "They're running a tape," said Steve.
Indeed, this was a karaoke demo, the two actors were saying their lines
as the video tape of the demo ran. I went around the booth, the male
"demonstrator" followed the tape on a small screen and kept flipping his
neat little cue cards with yellow highlights as he went along.
</p><p>
Just to acquire more data about WinCE, I bought a Sharp 2.0 device,
grayscale display, 12MB of RAM, integrated (soft) modem, and took it on
an overseas trip along with my Hitachi portable, my Pilot, my Swiss-Army
knife, my screw-pull (don't want to face a bottle of fine Bordeaux
without it) and other unmentionables. Without getting into a detailed
review of the Sharp hardware nor of Windows CE 2.0, the whole system
looks to me as too big, too slow, too unreliable and too battery-hungry
(one set of two AAs per day) to compete in the smaller, lighter, more
nimble Pilot category.
</p><p>
HDTV was everywhere and looked pretty real. Yes, the sets are horribly
expensive. But imagine the following situation: two sports bars in town,
one shows football and basketball on HDTV, one on a current set. The beer
costs 50 cents more, which bar will get more volume and better margins?
Joe, where did you get that set? Sports sells ads, somehow a way will be
found to prime this better pump for commercials.
</p><p>
For the rest, wireless devices continue to proliferate happily, GPS
devices can now be had for less than $100 and slightly more expensive
ones acquire better displays, store maps—they'll be and take us
everywhere.
</p><p>
The rest was either unmentionable or too hilarious for this family
newsletter, or too sad. In this latter case, I'm referring to the "very
high-end" audio with Russian mil-spec 12AX7 triodes, gold-plated
everything and oxygen-free copper crystal cables.
</p><p>
We grabbed a cab, ran through the airport, caught a just-boarding
Southwest flight to San Jose. The peanuts and the diet coke never tasted
better. Comdex looks even better now.
</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-2"></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="id655993"></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="id655999"></a>Subject: B_PAGE_SIZE</h4></div></div></div><p>
If you <code class="function">malloc()</code> a single page (4096 bytes), does the system actually
reserve another page for bookkeeping overhead? Should you be wary as
your <code class="function">malloc()</code> request approaches a page size boundary? Should you use
areas instead?
</p><p>
THE BE LINE: A <code class="function">malloc()</code> smaller than 2048 bytes rounds up to the next
power of two. Greater than 2048 rounds up to the next multiple of 4096.
The bookkeeping overhead needn't be a concern; for example, the
overhead won't push a malloc(4096) call into an 8k allocation. Note
that the 2048/4096 numbers are NOT related to the page size (which,
coincidentally, is also 4096 bytes); these numbers could change in a
later release.
</p><p>
As many readers pointed out, you shouldn't blithely swap <code class="function">create_area()</code>
for <code class="function">malloc()</code>. Areas are useful when you need to lock or share a chunk
of data; they aren't meant to be fast.
</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="id656049"></a>Subject: Mouse Position</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">
AKA: Mouse Position Again<br />
AKA: Pointers.
</h5></div></div></div><p>
Should Be allow programmatic mouse positioning? The "all things are
possible" camp thinks a modern OS should allow this sort of
manipulation.
</p><p>
From Marco Nelissen:
</p><p>
“<span class="quote">SetMousePosition is *good*. For one thing, it allows you to plug in
all kinds of funky hardware to control the mouse cursor with, and you
don't even have to write a fake mouse driver for it. It also allows for
stand-alone recorded demo's to play...</span>”
</p><p>
UI wonks fear that this ability will corrupt interface consistency and
confuse users. Many of our listeners adopted a laissez-faire, natural
selection position:
</p><p>
“<span class="quote">Is <code class="methodname">SetMousePosition()</code> so bad an idea that we can't let programmers do
what they will and let Darwin sort them out?</span>” (Trey Boudreau)
</p><p>
“<span class="quote">Sure, it could be abused, but software that abuses this feature will
annoy users, and thereby die a quiet death.</span>” (Marco Nelissen)
</p><p>
Wholesale mouse repositioning was a pretty hot issue, with little room
for compromise. But what about mouse constraint? Should a developer be
allowed to declare a rectangle that restricts the mouse's movement?
Ross A. Knepper thinks this is antisocial...
</p><p>
“<span class="quote">...remember that the user might have other things going on at the same
time. While you're constraining the mouse, the user might be
desperately trying to click cancel on the requester that says "melt
down the processor in 3 seconds"</span>”
</p><p>
And Trey Boudreau responded...
</p><p>
“<span class="quote">Constraining the mouse motion is likely to be done ... only while a
specific set of modifiers are being held down. Programs that do
otherwise will likely be un-installed pretty quickly.</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="id656148"></a>Subject: Shutdown message?</h4></div></div></div><p>
When the computer is shutdown, the BeOS doesn't send a "shutdown
pending" message, it simply sends a "quit requested" to all
applications. Would it be worthwhile to send a special "shutdown"
message? Most folks can't see the harm in it; the idea is fine-tuned
thus:
</p><ul class="itemizedlist"><li><p>
Broadcast a <code class="constant">B_SYSTEM_SHUTDOWN</code> to all applications and then launch
all apps [that are] in a special shutdown folder. (Dirk Steins)
</p></li><li><p>
Let individual apps (or the entire system) set an "interaction at
shutdown" level. An unattended server machine (for example) wouldn't
want any interaction.
</p></li></ul><p>
Scott Lindsey took this last point further, applying it interaction at
any time:
</p><p>
“<span class="quote">...there's nothing special about user interaction on quit. It's not
reasonable to define an alternative message for every message type that
might interact with the user. Seems to me there's two ways of handling
it. Either build an interaction level into the messaging system, or
attach an optional parameter to the message (where the absence of the
parameter is the same as full interaction).</span>”
</p><p>
Jon Watte modified the idea to fit the "save changes" situation:
</p><p>
“<span class="quote">I would prefer a boolean [message field] named 'saving' that tells you
whether to save changes or not... The cool thing is that a scripting
language might use the same [field] to quit just one application: tell
SomeApp quit saving:true</span>”
</p><p>
And Osma Ahvenlampi suggested a couple more fields:
</p><p>
“<span class="quote">Okay, I suggest two modifiers for all standard system
messages:</span>”
</p><pre class="screen">
'unattended':bool—don't pop up any dialogs,
take the default action.
'force':bool —message demands immediate action
</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="id656238"></a>Subject: Using RefsReceived</h4></div></div></div><p>
Some <code class="classname">BMessage</code> thoughts, concentrating on
<code class="varname">what</code> types. Is 32 bits
enough to encode a message's <code class="varname">what</code> constant? Marco Nelissen wishes
that the <code class="varname">what</code> field were 64 bits, thus making vendor/what encoding
simple. Should developers adopt a separate 'owner' field convention? As
suggested by Wendell Beckwith:
</p><p>
“<span class="quote">We simply need to define a convention that all foreign messages (i.e.
messages traveling outside of your app's address space) contain a <span class="type">int32</span>
named 'owner' and then add your own data to it. Be could fix the
<code class="classname">BMessage</code> constructor to automatically do this and define a default
'owner' field to be 0/-1 or whatever. This would indicate that the
message was generated by an unknown entity.</span>”
</p><p>
But what about forwarded messages? Is the original sender always the
owner, or should it be the app that last touched the message?
</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="id656296"></a>Subject: Control locking</h4></div></div></div><p>
This discussion about provable programs concentrated on what happens
when a (non-<code class="code">virtual</code>) function is invoked on an invalid object, where
"invalid" can mean deleted or reused.
</p><p>
The practical answer: <code class="classname">BLooper</code>'s <code class="methodname">Lock()</code>
function doesn't throw an
exception when invoked on a <code class="constant">NULL</code> pointer. The theoretical question
(does it make sense to strive for provability?) faded away without
resolution.
</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="id656331"></a>Subject: dynamic_cast</h4></div></div></div><p>
Is it possible to "cross cast" an object, changing its flavor from one
branch of a multiple inheritance to another branch? For example, should
this excerpt, submitted by Marco Nelissen, do anything other than what
it does do, which is crash:
</p><pre class="programlisting cpp">
class <code class="classname">MyButton</code>: public <code class="classname">BButton</code>, public <code class="classname">MyBase</code>;
<span class="type"><code class="classname">MyBase</code> *</span><code class="varname">thing</code>=new <code class="classname">MyButton</code>();
... dynamic_cast&lt;<span class="type"><code class="classname">MyBase</code>*</span>&gt;((<span class="type"><code class="classname">BButton</code>*</span>)<code class="varname">thing</code>);
</pre><p>
According to Jon Watte, it should, indeed, crash. This foils Mr.
Nelissen's attempt to create a varargs function that does its own
casting of its semi-anonymous arguments. The desired casting can't be
done because the function doesn't know the exact class of the argument.
</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="id656401"></a>Subject: text/weird, and other strange mime types</h4></div></div></div><p>
Olaf Seibert was seeing odd file types when he noticed that the problem
stemmed from a confusion between app signatures and an app's file
type/supported types. Mr. Seibert's testimony was seconded by other
listeners; it seems that many folks regularly (or, worse, irregularly)
experience messed-up file types. The answer? Check with us next week.
</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="id656418"></a>Subject: BeOS "face"</h4></div></div></div><p>
Customizable user interface talk. Nothing much new, here, except for
this observation by Jeff A. Campbell:
</p><p>
“<span class="quote">As a support tech, I KNOW how hard it can be to talk a user over the
phone through a process and not know where everything is. I personally
want as customizable an interface as humanly possible, but I also want
this: The ability to switch back to a non-editable 'interface' with
VERY little effort, and no restart.</span>”
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue3-1.html">Issue 3-1, January 7, 1998</a>  Up: <a href="volume3.html">Volume 3: 1998</a>  Next: <a href="Issue3-3.html">Issue 3-3, January 21, 1998</a> </div><div id="footerB"><div id="footerBL"><a href="Issue3-1.html" title="Issue 3-1, January 7, 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-3.html" title="Issue 3-3, January 21, 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>
Reference in New Issue View Git Blame Copy Permalink