|Issue 53, 10 May 2004
What follows is the template for an email that will go out to all of the people who signed up for WalterCon. Some payment details and room assignments will be added.
We are into May already and it is just over a month before WalterCon!
This e-mail is to confirm your registration. I assumed that you would want a double occupancy
unless otherwise stated.
Room prices are slightly higher than originally thought due to taxes, but more people will be
able to double up than expected.
- $30 for attendence only
- $75 for double occupancy (i.e. we assign you a roommate)
- $120 for single occupancy (i.e. you are alone or with non-attending roommates)
Details on how to pay will be coming soon.
There are a few (two) rooms empty from our default fifteen. If you would prefer a single room for the
full $90, please let me know - I am sure that the hotel will be thrilled to sell us more
OK. Who will be there? The current list of OpenBeOS developers who will be there is:
- Michael Phipps
- Tyler Dauwalder
- Gabe Yoder
- Andrew Genduso
- Andrew Bachmann
- Kevin Field
Here is our planned agenda. This may change at any time.
- 9AM Intro and Welcome (Michael Phipps)
- 10AM State of the Project, New name and site unveiled (Michael Phipps)
- 11AM BeUnited presentation (Simon Gauvin or Deej)
- 12PM Lunch
- 1PM Interface Kit (DarkWyrm)
- 2PM ScreenSaver and Translation Kit (Michael Phipps)
- 3PM Storage Kit (Tyler Dauwalder)
- 4PM Input Kit and Device Kit (Michael Phipps)
- 5PM Media Kit (Andrew Bachmann)
- 6PM Dinner
- 7PM - 10PM - Free Time/Coding/Whatever
- 9AM Welcome Back (Michael Phipps)
- 10AM Applications brainstorming (Michael Phipps)
- 12PM Lunch
- 1PM R2 Brainstorming (Michael Phipps)
- 3PM Marketing/Business Brainstorming (Michael Phipps)
- 4PM Windup and closing (Michael Phipps)
Currently, we have more than thirty people attending! The conference room is "spec'ed" at twenty-five, so
unless we have cancellations, we really can't accept new registrations.
Because the number of people exceeded our expectations, we want to provide each attendee with a
t-shirt. Please get back to us with your t-shirt size as soon as possible.
Looking forward to seeing you there!
Yep. I remember when Be first announced Replicants. They were
going to be the next ActiveX. I wonder what ever happened to them.
The sad truth is that absolutely nothing happened to Replicants. Almost no one ever used them.
No great mountains of applications ever came out for them. I was chatting with some people the
other day on IRC and we wondered about this. Needing to write an article and not sure what to
write, that commiseration came back to mind.
I started looking around for "official" documentation on Replicants, not wanting to recreate the wheel. I found very little. There were a few newsletters that mentioned Replicants, and the documentation in the BeBook about BeDragger and BShelf, plus the sample code. I was very surprised not to see more. With some more digging, I managed to find the introduction that Peter Potrebic gave at BeDevCon ྜྷ. I believe that I was at that session. I recommend reading it at http://www.beatjapan.org/mirror/www.be.com/developers/aug_dev_conf/transcripts/extending_replicants/index.html.
The question that I set out to discover the answer to: What is a replicant, and how do I play
with one? A replicant, quite simply, is a
BView. The "trick" to a replicant is that the
Archive() function (something that any
BView can have but people rarely seem to bother)
and a link to a
BDragger--a handle to move the
BView around with. When you grab the handle, it
BView to archive itself. The app_server then treats that archive just like a drag and
drop (as if it were text or a bitmap). The other side of the coin is the
BShelf, which is a special
BView that knows how to receive
BView drag and drop messages. It loads the application or add-on
that created the
BView, searches for the archived class's
Instantiate() function and calls
it. Voila--the code from one application is now running in another.
How did I play with it? Some time ago, I had started something called kitView. It was to become
what BeHappy did become, down to using NetPositive as a replicant. I dug the code out, removed
the list views and rebuilt. Sure enough, the code still worked! OK, so that covers the
BShelf side of the replicant. Time to write a "sending" side of the
I had never done this before and there were many pitfalls on the way, including crashing the
app_server multiple times. You have been warned. :-D I created a simple application called
"grapher". Its whole purpose in life is to draw a simple bar graph with hard coded values. I
actually copied kitView and modified it.
Step 1: Adding the
BDragger is the little handle that you can move the
BView around with. The handle can be a child of the
BView, the parent of the
BView, or a sibling. You could put the handle on the other side of the window (sibling).
Step 2: Make the
BView archivable. If you hadn't subclassed your
BView already, well, now you
have to. Create an
Archive() method (look at
BHandler's BeBook section). Any member values of
BView that are necessary, you need to save into the
BMessage. The "Clock" sample code has
a good, easy example of this. You also need to call
AddString() to add the "add_on" field,
populating it with your app's signature. Make sure that you set the app's signature using
FileType or resources. Otherwise your replicant will not work and you will not know why.
Step 3: Create a constructor for instantiating your
BView from a
BMessage. This is the
constructor that takes only a
BMessage as a parameter--documentation is in the
of the BeBook. Any data that you saved into the
BMessage in Step 2 you need to read from the
BMessage here and populate the member variables. Note that static variables do not work across
application boundries. So if you intend to share data across different instances of views in
your application using statics, they will not work properly with Replicants.
Step 4: Create a static method called
Instantiate(). This static method should call
create a new instance of your
BView, passing it a
Finally, I wondered if you could print a replicant. I added a print button to kitView and added
some simple code to create a new print job containing the
BShelf. It works!
There are many areas of exploring that I did not do with this sample code. I did not install a
pop-up menu, for example. I did not test to see if I could do things like create windows as a
replicant. I did not attempt to make my replicant resizable--it would be a very
neat thing to resize your replicants inside the shelf.
After playing with Replicants, I believe that they are easier to use than I had ever thought.
Having written my first one, I would bet that I could write another in an hour or so (outside
BView functionality). There is a lot of power inside Replicants. Be's demos, I think, set
the wrong tone for Replicants--as toys that are not really useful. I would like to consider
another direction for them: as an OpenDoc or ActiveX replacement. You can create Replicants
with a message-based API--no fragile base class, no headers, no C++ dependence, etc.--something
very powerful to think about.
In many ways, the BeOS community is different from the community of other operating systems. If
you look at the Windows community, for example, you will see that, in general, it is a very
profit-minded community. There is a lot of shareware and for-profit software out there. The
freeware in the Windows community, in my experience, is mostly Linux ports or stuff that is
pretty low quality. In contrast, in the Linux/BSD communities is mostly free software with a few
exceptions. The free software ranges in quality but tends to be pretty good, if not great in
most cases. The BeOS community was, in its largest days, a mix of these. There were a number of
companies that put out software, but there was a lot of good freeware, as well.
It is my firm belief that the BeOS community failed Be, Inc. in a large number of ways. And Be,
Inc. failed the community in just as many ways. I say this not to indict anyone or make them
feel guilty, but to attempt to make this situation better for the future. Initially, Be was
pretty open--information flow between the company and the community was very good. The
community knew, for the most part, what was coming in new versions of the OS and the company
knew what developers needed and were working on. There was a healthy ebb and flow. BeDevTalk
was filled with Be engineers. As time went on, two things happened. The community grew and was
no longer quite so tightly knit. Be, Inc filed for an IPO. Those two things pushed the parties
apart in a way that was not good for either group. When you add into that the repeated focus
shifts and the developers (mostly the bigger companies) who didn't live up to expectations, it
was a recipe for disaster.
To some degree, the BeOS community is looking for a "new identity". It seems obvious that the parent-child relationship that was Be-->Developers/Users doesn't work. We aren't big enough (and don't want) the "messenger from on high" approach that huge companies use. At the same time, I don't think that the "everyone do what you want and let evolution clean out the crap" approach of other OSS groups will work, either - we aren't big enough for that.
It isn't yet clear, to me, how all of this should turn out. One of the advantages of a completely open source and non-profit organization is that there will never be
any question of the communication coming out of OpenBeOS. Exactly what is going on is perfectly
available to anyone. Our CVS is Web available. You can browse and see exactly where we are. The
real work (and the challange for me) is to convert a couple of million lines of code into a few
paragraphs that tell people what is going on. I know that people would like to see more stuff
on the main page. As we hit milestones, we are posting, but milestones only come every mile.
The other side of this coin is developers communicating with us. This was the point of the
Glass Elevator project: To give developers direct feedback into the direction that would be
chosen for R2. The problem that we have in GE is that it is a discussion forum. We have
(literally) years of archives of e-mails. Someone (or several someones) is/are needed to put
all of that into a reasonable format for the actual OS devs to peruse. Taking a thread of 50
e-mails and converting it into a reasonable sized proposal is very time consuming, and there are
thousands of emails to work on. If some very energetic person is interested, please let me
I was sitting at lunch the other day thinking about WalterCon, as I do a lot these days. As you
can see in the above agenda, I have a planning session for applications. There is a sort of a
chicken and the egg issue with applications and OS features. I have used the maxim "if five
different applications for typical users require some code, it should be part of the OS." I
don't quite know if this is true or not, but it sounds like a good place to start. Take, for
example, instant messaging (IM). Most people think of IM as something in its own application.
But here are a few more cases for IM as a general tool: collaborative writing, network games,
professional tech support, combined with e-mail ("User mphipps is on-line with AIM - would you
like this e-mail sent to him via instant message?"), workflow processing ("the timesheet for
mphipps has been submitted for your approval. Open it now?"). IM, IMHO, belongs in the OS. So
from features, you can easily start to see how to improve your applications (bottom up
development). On the other hand, as I started to consider the applications that I see as
necessary for OpenBeOS to be successful on the desktop, common features started popping out
like champagne bubbles.
I think that an iterative collaboration between applications and features will allow us to
design R2 in a fashion that brings us the most applications and power for our buck. I wish
everyone could be at WalterCon. I hope to webcast it and to take ideas in realtime via IRC or
BeShare. But understand, too, that every idea that we come up with at WalterCon is not a
promise of what will go into R2. Especially since many of the developers will not be there, it
is not at all fair to commit to something that they have no input into.
Having said all of this, I would like to put a radical idea out there. Many of the OS
developers, myself included, have put their application ideas aside to work on OpenBeOS.
Without the OS, there is no platform for our apps. On the other hand, without the apps, there
is no point in the platform. This is the infamous chicken and the egg dilema that Be faced. I
know that there are a lot of developers out in the community who are working on other things.
Some are really critical things, like the Mozilla port. Others are... less visible. What I
would like to ask every developer to do is this: put everything else aside for one month. Put
one month into OpenBeOS. We have lots of areas that can be finished in one month of
concentrated development. I would love to be able to demo a bootable, functional alpha of R1 at
WalterCon. What would that take? A lot of hands working on a lot of things. Parallelism is the
only way that modern software can be written. We have need in the Interface Kit, networking,
kernel, midi, etc. I am only looking for developers. If you are a fairly good (not a newbie)
developer who will commit for a month (or longer), we really need you. A concentrated push here
could bring about a lot of those milestones that we all love to see so much on the news page.