Welcome to the second edition of the OpenBeOS CVS digest. This edition is probably a bit thicker than the previous one, as it covers a longer time span. I'll start right away with what I haven't included. The media kit got a lot of attention (as you can see in the statistics below) by Marcus Overhagen. He continued with the major overhaul the mixer needed. After a short enquiry with Marcus himself, I can report that the mixer is progressing, even today (the 29th of June) he had fixed some bugs that stopped progress two weeks ago (no more plops!).

In other news, I generated a list of statistics with the help of cvstat. This utility generates the list based on the output of cvs log. These statistics are from the 15th of June up to today (the 29th of June). Please note that these statistics don't say anything about the contents or importance of the changes. It's just a little bit of fun. [Editor's note: We're looking at getting cheerleaders for the next edition.]

In this issue almost every part of the system is represented, from wealthy additions to the kernel, to the improvements in the network area, to the progress on the interface kit. I'd like to thank Marc Flerackers and Marcus Overhagen for responding to my enquiries on their status. And a special thanks to Kevin Field for proofreading this issue! Enjoy your digest!

Interface Kit Improvements

Marc Flerackers committed a whole series of improvements in the interface kit area on the sixteenth of June, especially the visible parts of the interface, which sounds quite logical and most probably is. I asked him what the current state of the interface components of the kits was, and he said:

• BControl, BButton, BCheckBox, and BRadioButton are finished, except that maybe the drawing could be written better.
• BBox still has some not-pixel-perfect issues.
• BSlider, BStatusBar, and BColorControl still miss some things.
• All BMenu classes are finished except for the tracking function.
• BListView and BOutlineListView have some small bugs.
• BPicture is finished for the client side, now doing the server side.
• BScrollBar works, but is client-side.
• BShape should be ok.
• BTabView is almost done.
• BTextControl still needs some work.
• BTextView is much better, with working styles and tabs.
• Some classes with new implementations are BInvoker, BStringView, and others.

Note that not everything is checked in yet though, only what I checked in yesterday is synchronized, the rest is still more ahead on my HD then on cvs :).

Here's a selection of his commits:

Added Files:

BMCPrivate.cpp MenuField.cpp BMCPrivate.h

Log Message:

BMenuField

Modified Files:

Shape.cpp Box.cpp TabView.cpp TextControl.cpp TextInput.cpp

Log Message:

Fixes

Modified Files:

ListItem.cpp ListView.cpp

Added Files:

OutlineListView.cpp

Log Message:

Compilation fixes and BOutlineListView

Modified Files:

Slider.cpp

Log Message:

Lots of changes

Modified Files:

RadioButton.cpp

Log Message:

Assynchronous mouse hooks and correct handling of BRadioButtons in BBox-en :)

A long and impressive list if you ask me. On the twenty-sixth of June, Stefano Ceccherini committed another important part:

Added Files:

Region.cpp clipping.h

Log Message:

Added a partial implementation of BRegion

Networking Kit Enhanched

After an inquiry on the mailing list about how to start testing the current Network Kit, Phillipe Houdoin wrote a set of instructions, which were HTML-ized by me on the sixteenth of June:

Modified Files:

build.html

Log Message:

Updated build instructions. This may attract more testers of the network kit.

In order to make the installation of the networking kit easier, Ingo Weinhold wrote a series of rules for Jam. By invoking 'jam install-networking' you can install the networking kit without any manual fiddling. On the seventeenth of June (one of the commits):

Modified Files:

Jamfile

Log Message:

Added support for installing the networking stuff. Use: jam [un]install-networking.

As many people were having a problem with the linking of the OBOS libnet.so on R5 installations because of a duplicate _res symbol, I decided to rename the _res symbol to something different. However, this fixed the symptoms, but not the problem. After a short investigation, we found out that the link problem was caused by a _res symbol in libnet.so from BeOS R5. But this still didn't explain why the problem was there in the first place, as we didn't link to this libnet.so. However, Ingo Weinhold found out that it was caused by the gcc linking to it by default. The temporary fix was reverted, and the Jamfile was adapted to build properly.

Modified Files:

Jamfile

Log Message:

Fix the undefined _res symbol linker error: we don't link anymore our own libnet.so against default libs (which include BeOS's libnet.so)!

Also the Realtek driver started to improve. On the eighteenth of June, I committed the following:

Modified Files:

TODO driver.c

Log Message:

In theory the driver should now work. Though I'm not really buying it yet, I think that it shouldn't drop any packets anymore, only delay them.

• I implemented a packet wrap, so after 64k the driver will start over again.
• I fixed a bug where packets with the largest ethernet frame size (1514) weren't accepted.

Translation Efforts

Michael Wilber, the team leader of the Translation Kit, continued his ongoing work on the TIFF filter. On the fifteenth of June he committed:

Modified Files:

BitReader.h TIFFTranslator.h TIFFTranslator.cpp

Log Message:

• added support for Fax Group 3 TIFF images that use the EOL ends on a byte boundary option
• changed identify string from "TIFF Image*" to "TIFF image*" (more like Be's)

He also added the PPM translator, that Be had released under the sample code license . On the seventeenth of June:

Added Files:

Jamfile LICENSE PPMMain.cpp PPMTranslator.cpp colorspace.cpp colorspace.h

Log Message:

initial check in for PPMTranslator from BeOS R5 sample-code folder

He also committed Inspector, on the twentieth of June. This tool sounds like it will play an important role in the future of the translation kit, and most probably, the future of the rest of the OpenBeOS itself. He wrote:

Added Files:

Jamfile Inspector.rsrc Constants.h ImageView.h ImageWindow.h InspectorApp.h StatusCheck.h ImageView.cpp ImageWindow.cpp InspectorApp.cpp StatusCheck.cpp

Log Message:

initial check in for Inspector - image viewer (and later on, hopefully documents in general viewer) for developers of Translators and users of the Translation Kit in general

On the twenty-third of June, Michael Wilber added a new feature:

Modified Files:

Jamfile Constants.h ImageWindow.h InspectorApp.h ImageWindow.cpp InspectorApp.cpp

Added Files:

InfoWindow.h InfoWindow.cpp

Log Message:

added beginnings of InfoWindow -- window that displays as much info as possible for currently open document

Disk Device Manager (cont.)

Ingo Weinhold started the implementation of the Kernel Disk Device Manager, the interface that enables the programmer to see what devices are present on a system using the Be API. The past two weeks he was quite active (98 changes). He implemented a neat feature that enables us to treat files as volumes. This not only has its practical purposes (storing bootable floppies on your hard drive and still be able to see the contents), it also has its technical merits (being able to test the device manager without the risk of screwing up hardware). On the twenty-third of June he committed:

Modified Files:

KDiskDeviceManager.h KDiskDeviceManager.cpp

Log Message:

• Support for creating and deleting (the latter not yet implemented) file disk devices.
• Added file system addition.

That same day he also implemented the scanning system:

Modified Files:

KFileSystem.cpp KFileSystem.h

Log Message:

Implemented the scanning functionality.

He ported the BFS to the new device API:

Modified Files:

Jamfile bfs.c

Log Message:

Ported the BFS module over to the new disk device manager API. It still lives here so as to not interfere with Axel's FS add-on. Should be merged some day.

On the twenty-fifth of June he finalized the greatest part of the code:

Modified Files:

KDiskDevice.h KDiskDeviceManager.h KFileDiskDevice.h KPartition.h KDiskDevice.cpp KDiskDeviceManager.cpp KFileDiskDevice.cpp KPartition.cpp

Log Message:

• Implemented what was left to do for KDiskDevice and KPartition management regarding removal and deletion of objects.
• Fixed the file disk system related stuff. KFileDiskSystem now uses the virtualdrive driver. The former method was seemed simple and brilliant, but the B_SET_PARTITION ioctl wouldn't work.

Kernel extensions

Tyler Dauwalder, on the twenty-third of June, started a library with utilities for the kernel. Programming inside kernel space usually means reinventing the wheel or copying code from earlier implementations.

Added Files:

SinglyLinkedList.h

Log Message:

Beginnings of the kernel utils library. Templated singly-linked list class (not quite complete).

Added Files:

MallocFreeAllocator.h

Log Message:

Allocator that uses malloc()/free()

Added Files:

Constructor.h

Log Message:

General object constructor class

Axel Dörfler has implemented the POSIX pipe command, which will use the pipefs he committed later. On the twenty-sixth of June:

Modified Files:

Jamfile

Added Files:

pipe.c

Log Message:

Implemented the pipe() command - ready for the upcoming pipefs implementation.

He also worked on the locks:

Modified Files:

lock.c

Log Message:

• Fixed the return code of recursive_lock_init() (formerly known as recursive_lock_create())--this reveals bugs in other parts of the system (VM), but those won't be fixed for now (because of VM2).
• Added the possibility of giving a recursive lock a name.
• Moved the functions for benaphores and rw-locks to this file (they were part of the lock.h header as defines).
• Removed unused headers.
• Small cleanup.

On the twenty-eighth of June, Ingo Weinhold added an additional utility to the kernel utility library, which unfortunately won't work:

Added Files:

AVLTreeMap.h

Log Message:

The beginning of an AVL-tree-based map implementation. Well, the tree part is complete, but the interface needs work. Unfortunately our ancient compiler chokes on this (`Internal Compiler Error'). I got around the problem by restructuring parts of the code once, but now I'm stuck--no idea what I could change. So, there won't be AVLTree{Map,Set} until we have a working compiler. :-(

Bits'n'Pieces

Gabe Yoder, second-in-command for the app_server, committed the beginnings of code for the drawing of the actual windows and their contents, next to a whole load of GCC 3 fixes. On the twenty-third of June, he committed:

Modified Files:

ServerWindow.cpp

Log Message:

Added partial handling of graphics messages

Darkwyrm committed two things on the twenty-fourth of June. First he worked on code that made the app_server display actual BWindows! His second commit was a monster patch:

Modified Files:

AppServer.cpp Decorator.cpp Decorator.h DefaultDecorator.cpp DefaultDecorator.h DisplayDriver.cpp DisplayDriver.h Layer.cpp Layer.h RootLayer.cpp ServerWindow.cpp Utils.cpp Utils.h ViewDriver.cpp ViewDriver.h WinBorder.cpp WinBorder.h

Log Message:

• Added a serious speedup to window-move code
• Added a couple more empty message handlers to ServerWindow
• Improved DefaultDecorator--works better now
• DisplayDriver::CopyRegion added and implemented it for ViewDriver

Jérôme Duval, on the twenty-fifth of June, modernized the Media preference applet:

Modified Files:

Media.h MediaListItem.cpp MediaListItem.h MediaViews.cpp MediaWindow.cpp Jamfile Media.cpp MediaViews.h

Added Files:

iconfile.h MediaAlert.h MediaAlert.cpp MediaWindow.h Removed Files:tv.h mixer.h MediaPrefsSlider.cpp MediaPrefsView.h MediaWindows.h MediaPrefsApp.cpp MediaPrefsView.cpp MediaPrefsApp.h MediaPrefsWindow.cpp MediaPrefsSlider.h MediaConstants.h MediaPrefsWindow.h devices.h

(view the current directory contents)

Log Message:

Here is an alpha version. Restart media services still crashes the app.

On the twenty-seventh of June, Michael Pfeiffer improved the PDF printing OpenBeOS will have:

Modified Files:

Bookmark.cpp Bookmark.h Link.cpp Link.h XReferences.cpp XReferences.h PDFText.cpp PDFWriter.cpp PDFWriter.h

Log Message:

• Added option to show bookmarks expanded or collapsed.
• Link destination includes rectangle on page.
• Added ImageCache.

On the twenty-ninth of June, the same Michael Pfeiffer committed the serial-port transport add-on:

Added Files:

Jamfile print_transport.cpp

Log Message:

Added untested Serial Port transport add-on.

That same day Andreas Bentzler, by means of Michael Pfeiffer, added a USB add-on for the print_server:

Added Files:

print_transport.cpp

Log Message:

USB Port transport add-on contributed by Andreas Benzler

This was the digestible status report for these two weeks. As always, comments, omissions, questions, and liquor are welcome at n.reedijk@planet.nl .

Who is George Doughty? No one most of us know, but someone we can sympathize with. He is a bar owner who lives in Lafayette, Colorado. He was arrested on charges of felony menacing, reckless endangerment, and the prohibited use of weapons. Why? He shot his computer. As the story goes, he emerged from his on-site office and announced that he was going to shoot his computer. Half an hour later, he returned with a Dell laptop, set it on the floor, asked two customers to cover their ears, and said notebook took four bullets.

Microsoft has developed an unsavory reputation with a lot of different kinds of people for a lot of reasons. One of them is what I call "badgering the user." I have met many, many users who think computers don't "like" them, they are simply not good with them, or don't understand how to use them. Simply put, computers make them feel stupid. For example, a college student may say to campus support staff, "I need to print out this paper for my Medieval Plumbing class, but every time I print it, it keeps coming out the wrong way, and class starts in 15 minutes!" In my support days when I was also much more cynical and much less patient, my first thought would have been "Man, this guy needs five bucks to *buy* a clue!" followed by quickly showing him how to reorient page layout from Landscape to Portrait and sending him on his merry way. Nowadays, I still do support for my school, but when asked something about why MS Office isn't doing what it's supposed to, I remind myself of how much I can't stand Microsoft and its shoddy software. The student was frustrated because everything he thought he was doing right wasn't yielding the results he expected, and Microsoft is one place where what you expect and what you get are often two very different things.

Shortly after I graduated from college, I married a wonderful woman on the same level of computer literacy as the hypothetical student mentioned above. It has been quite the learning experience for the both of us. When it comes to the computer, we look at the beige box in the living room, but we see different things. I see a machine which I work with for both work and play and that I love to learn new things about. She sees a beige box which allows her to print parent newsletters and grade averages for school. She sees the computer as the means to an end. I see it both as such and also as an end unto itself. For both of us, in any event, it is a tool.

Hummer is a renowned brand of vehicle used by the US Military, famous for being rugged and reliable. It is used as a tool by which personnel are carried, for example, and it does what is expected of it, but this is not by accident. Innumerable hours were put into its design. Developers, as a group, are responsible for building the tools by which others perform tasks. Why should it be any different?

The USS Yorktown is a ship in the US Navy which was given quite a surprise by a Microsoft product. In the Navy's Smart Ship program, off-the-shelf PCs running Windows NT Server 4.0 were used to handle tasks normally performed by sailors. A divide-by-zero error rendered the vessel quite literally dead in the water for more than two hours.

On December 20, 1995 at about 6:30 EST, American Airlines Flight 965 left Miami for Cali airport. It never made it. About three hours later, it contacted Rozo airport for clearance to land and received it. The crew attempted to select the Rozo flight beacon in the flight computer. They found out that something was wrong when it passed the strip and turned left. 1.5 minutes after it turned, the plane crashed into the side of a mountain. Of the 163 people on board, only four survived.

Why did this have to happen? It didn't. The NTSB attributed the crash to human error. It was, but the human error came about from another flaw. Their Jeppesen approach plates told them that 'R' was the code for Rozo, but in the flight computer it was Romeo, a navigational aid 150 nautical miles from Rozo, but with the same frequency. The pilots didn't realize their mistake until after they were supposed to be landing. A design flaw killed 159 people. Product makers sometimes forget that people, though not normally, can live or die by the design of their product or products. Power tools used in building houses are carefully designed for safety, reliability, cost, marketability, and ease-of-use. Why not software?

Some software is, but it seems like for every well-designed software package, there are two or three which are not. Computers and software are tools, and software must not only pose no barriers to the user, it must be an aid to the user in whatever task is to be performed. Great software doesn't just happen--it requires careful thought, testing, and effort. Our focus of attention needs to change. How? Wait until next time and see.

Since the beginning of civilization, technology that improves transportation has been prized above almost all other. If you think about the first technologies discovered by man, the wheel ranks as probably the most important, followed closely by fire.

Imagine a world with teleportation. Not just an occasional thing (like a plane is today), but cheap, everyday teleportation. Think Star Trek, but consumerized. What would that mean for you and me?

First of all, no roads. Sure, that seems obvious, but think about it. Stand on a major highway and imagine all of that returned to grass/trees/whatever. Imagine hearing not the buzzing of cars, but the sound of silence. Imagine never scraping your car on an icy morning, never stretching your legs after a 10 hour drive, and never hitting a pot-hole again.

The nature of work would change. Instead of choosing from jobs near you, you could choose from jobs anywhere on earth! The flip side, of course, is that employers could pay only what the global market will bear. The economic impact on the earth would be huge. You could live anywhere you chose to. Whether that is a small cabin in Montana, or in the heart of downtown Madrid, completely up to you. Your commute would be a lot shorter, too. All of that drive time that is now wasted would be yours to use as you please. Obviously there would be a significant impact in the airline, automobile, and hospitality industries. Business travel becomes far cheaper and easier. Distance is no longer the issue--wise use of the employees' time is. Doctors who make house calls would come back into fashion.

Free time would change, too. I think that the concept of a vacation, as such, would probably end. People take time off in large blocks so that they can go somewhere else and visit new places or old friends. If I could teleport there for (nearly) free, I wouldn't need to take a week off to see (say) the Grand Canyon or the Scottish Highlands. I could go there after work and watch the sunset. Disney on the weekends, and evenings in an Irish pub. Families would be closer than ever, as distance would never be an issue for them.

Other technologies would change, as well. I think that telephones would disappear. What is the point of using a device to (only) talk to someone when you could simply 'port to their house? Cutting your lawn could be as easy as waving a wide wand which teleports the grass that the wand touches up three inches. Mail carriers, UPS, and FedEx would all go out of business. Most stores would become online-only. So what if the shirt doesn't look right on you? 'Port it back! Is the couch that looked so nice on the web site far uglier in your living room? 'Port it back!

Supermarkets, as we know them today, would go away. Let's say you want to make dinner. Well, there are 100,000 restaurants that are all competing on a cost basis for your money. But, no, you decide that you want to cook. Using the web, you go to an online meat market and indicate that you need a pound of hamburger. Put in your credit card number and the coordinates for your countertop and *poof* there it is. Freshly killed, never frozen, ready for your use. No need to even take the plastic off. Fresh fruits and vegetables, straight out of the ground (surely they are in season *somewhere*) all "delivered" to your countertop. Your refrigerator could be only big enough to hold leftovers. Freezer? Only for ice cream.

I don't want to paint this completely as a Utopia, though. People are still people. It is *far* easier to kill someone with a teleporter than with a car. They can't do a thing about it--you transport them out of their beds at night and over an active volcano. Furthermore, no nation could ever be safe. If we think that flying a plane into a building is bad, imagine teleporting 1000 lbs of explosives over a crowd of people. No one could ever be safe from homicidal maniacs. If bombs aren't your thing, you could teleport troops directly into your enemy's capital. The down sides don't even have to be malicious. People transporting into walls, for example. Consider, too, the energy cost. If teleportation is very energy hungry, it could cause ecological issues. Not that cars, semis, and planes don't, of course, but people will always choose what they prefer--and most of the time, for most people, that is not the ecological choice. People these days already have a tendency for instant gratification--far worse, it seems, than hundreds of years ago. Teleportation would remove one more thing that people have to wait for, increasing the "payoff" of being impatient.

Still, overall, I think that the benefits of teleportation would make a huge difference in the lives of all of the people on earth. I think that it would remove a lot of the issues with environment that help to perpetuate poverty. Natural resources would probably be used more wisely. People would be more productive.