Displaying Newsletter
Issue 46, 17 Jul 2003


  In This Issue:
 
Why Tablet PCs are a good idea after all, why no one notices, and what OpenBeOS has got to do with that by Jürgen Starek  

The discussion about the best "personal computer" concept has never stopped since the first PC emerged from the - well, the garage, and is not likely to come to an end in the foreseeable future. Recently, a big and well-known company has begun to try to tell us that they found the ultimate solution for the problem, not long after Be, Inc. shifted its' focus towards webpads and the like...

A discussion at BeGeistert 10 (caused by Chris Simmons showing some video footage of a CeBIT presentation) made it clear to me that I was not the only person unwilling to believe in the possible success of tablet PCs. Meanwhile, however, having read about people who love their Apple Newton, having talked to a friend who's waiting to get his own tablet PC and having thought about my own working habits, I've changed my mind a bit.

Let's tell it like it is...

I'd like to start with a look at the current situation, with a focus on the educational sector, as I am a university student myself. People who need to have a lot of information handy will usually store it on whatever media seems fit - lecture notes and reference material on paper; up-to-date information and self-written stuff on computers; addresses and phone numbers in the cell phone's database; and then there are all those good books in the library you only need once a month and hence don't buy yourself. So, if you want to look something up, you generally have to look for it in quite a few places. And, according to Murphy, you may just have forgotten an important folder in the car or at home.

You might think, "so what? I store most of the important stuff on the PC anyway!" - *The* PC? The age of single "personal computers" seems to be over. Most people have access to a lot of computers all the time - this article is written on my laptop, while it will be FTPd from my big desktop machine. On a small desktop running Linux I store some programming exercises from university lectures that are synchronized occasionally with my account on the university's UNIX cluster. Oh, and then there's this BeOS-only multimedia box currently serving as a jukebox... you get the idea. Even if you know where to find the information you need, it isn't available "everywhere at any time" without actively synchronizing different machines (and media). And even if you have only one PC at home, synchronization with the machines at work or at the university (and also between different operating systems, if you multiboot) is necessary.

...and how it could be...

So synchronization seems to be becoming a more and more important issue. There are some concepts that rely on putting everything on the web - addresses, mail, appointments and texts are available from every location that has an Internet connection. Quite a nice idea, but whom can you trust? The Internet economy has always been subject to constant changes. The company that hosts half of your private life today might be bought by an address dealer tomorrow or go bankrupt. And besides, you've always got to look for a PC you can access first, boot it up, start a browser, login to your private pages, ... - a friend of mine has what he jokingly calls a "PAD" (Personal Analogue Database, aka paper notepad) and is five times faster with that.

So that is where I can imagine a tablet PC-like device jumping in. If you look at what Newton and Palm users use their handhelds for, then storage of personal information and texts comes foremost. Quick boot times and rather good displays (although mostly b/w) allow users of handhelds to look things up quickly. "Prosumers" are usually not a target group of these devices.

But tablet PCs could take it a step further. With their powerful CPUs and larger screens, I can imagine carrying an "intelligent screen" with me that holds all the information I need, passing it on to other devices (via Bluetooth or WLAN) as necessary. Such a device could replace folders full of lecture notes, and one could still make annotations or sketches directly in the lecture room. Synchronization with other devices would only occur if you need to edit content - I would not want to write longer texts without a decent keyboard. The important stuff would be stored in the device you're always carrying around. Specialized, but immobile devices would be given data to manipulate and store it back to this device.

However, the vision that's been criticized at BeGeistert - using such a device to do your home banking while playing with your kids - is obviously wishful thinking of some marketing guys. It's still humans who use computers. People can't concentrate on an arbitrary number of things, and (for everyone, I hope) family life takes precedence over getting one's work done. It's no good idea to push an ordinary computer with an unusual case shape deeply into one's private life. But as long as this is the main marketing strategy for tablet PCs in the consumer market, a lot of people will keep criticizing the concept and the products will fail.

...how it was...

This criticism will often be combined with reflections on the good old times when we used paper for everything. The image of a businessman carrying a briefcase comes to mind. And there it is again - the idea of having a central storage medium that can be carried around easily. Files left their owner only to be edited. And this was not only due to tradition (although "a million dead people can't be wrong", as Terry Pratchett put it) but because it had proved to be a good and useful way of doing things.

Of course, the well-known downsides of only using paper apply - everyone keeps telling me that there's no implementation of quicksort for folders full of lecture notes... So using a tablet-PC-like device might be a step towards the often-cited goal of combining the advantages of computers with a classical working environment.

...and, of course, how it should be

If an electronic device is to be used primarily as a content reader / viewer, its' display needs to come close to the characteristics of paper. Letters need to be anti-aliased on computer screens, so very small pixels are necessary in order to make small print look smooth and readable. And traditionally, we tend to write our documents in portrait format, so the OS would have to allow for rotation of the entire screen content, including GUI elements. This also means that the display needs to provide a good picture quality from different angles.

All sorts of portable PCs still have a long way to go before they can meet the flexibility and ergonomy of paper. They'll never replace paper for essays, lecture notes and books as long as TFTs have such low resolutions. If you read a cheaply printed scientific paper (e.g. the LaTeX-based Springer series), you'll generally have around 300 dpi in front of you. That's enough to make looking at small fonts quite pleasant - you can read these books from quite a short distance, perhaps 15 or 20 centimetres away, without straining your eyes. If you view the same .dvi file on a computer screen the same size as the book (try resizing your xdvi window to A5), the text looks blurry and small letters, like super- or subscripts, are rendered as indefinable black dots...

But now, after all this hardware stuff, let's talk about where OpenBeOS comes in and what it would need to occupy this niche. Oh, I can already hear the howling and growling of the developers in their cellars saying "he's just another guy trying to tell us what to do". I won't. I'd just like to point out two things about how OpenBeOS might fit into the greater picture.

The BeOS seems to be an excellent operating system for students. Not necessarily computer science students - they tend to either be tech-savvy enough to use Linux (and pretend to need all its special features for coolness' sake) or don't take an interest in actual computers at all (ever seen an x86-based Turing machine?). But think of all the students of humanities or natural sciences. All they usually need in a PC is a stable and simple OS, a word processor (AbiWord has MS-Word compatibility, and if it had an option to wrap a line after a given number of characters, the law students would have found the one and only word processor for them), a browser that supports all those buzzword-technologies that non-CS-faculties are so fond of, the usual web tools and some multimedia tools for watching DVDs and listening to music. BeOS already has most of that, and those non-geeks will love the "user experience" just like geeks do.

So, if OpenBeOS can get into this niche, it will find a number of tablet PCs there. While it is certainly too early to think about supporting touchscreens and so on, it is important not to make design decisions now that will block up this way later. For example, programs' UIs shouldn't rely on a 4:3 ratio screen size. File managers and network related programs ought to be prepared to handle different synchronization methods.

And then, BeOS programs always tended to start and respond quickly. This is an extremely important feature when computers are used in meetings, seminars or lectures. This also is a great advantage over MS Windows Tablet PC Edition, which currently is the standard OS of tablet PCs. Everyone who has ever used a slow PDA will agree with that.

I'm really looking forward to the first "paper- less" lecture I will hear - using the BeOS' successor on a portable machine simulating paper...

 
CVS Digest of the 13th of July by Niels Sascha Reedijk 

Welcome to the third installment of the CVS digest. I'd like to say that it is becoming increasingly difficult selecting the changes, because almost all changes in the repository are worth mentioning.

If you are interested in the progress of certain sub-modules, I suggest you check out the webcvs . Luckily, the Sourceforge crew is trying to make it more up to date than it was the previous weeks. There are again various things I haven't included. First of all, Philippe Houdoin committed some major changes to his work on the new network stack. Also, Tyler Dauwalder worked on the udf file_system add-on. Gabe Yoder did a whole set of gcc-3 fixes. Ingo Weinhold continued on his disk device API, and has started implementing the userspace part. Waldemar Kornewald started on the PPP implementation for the network kit. Darkwyrm added a MacDecorator to the repository.

Finally, Ingo Weinhold wanted to make a statement (revision 1.1). Perhaps someone can massage his feet to ease the burden.

CVS statistics
Committer # of Changes Lines Changed Lines per Change % of Changed Lines
Axel Dörfler 19 1194 63 6%
Marcus Overhagen 123 3167 26 16%
Ingo Weinhold 136 4627 34 23%
Darkwyrm 107 3701 35 19%
Bill Hayden 3 15 5 0%
Stefano Ceccherini 7 594 85 3%
Jérôme Duval 19 623 33 3%
Michael Pfeiffer 37 640 17 3%
Marc Flerackers 1 178 178 1%
Michael Phipps 8 2 0 0%
Michael Wilber 29 451 16 2%
Niels Reedijk 1 119 119 1%
Philippe Houdoin 36 980 27 5%
Gabe Yoder 35 1134 32 6%
Andrew Bachmann 27 923 34 5%
Tyler Dauwalder 29 860 30 4%
Waldemar Kornewald 32 584 18 3%
Total committers: 17
Most frequently modified file: /cvsroot/open-beos/current/src/add-ons/media/media-add-ons/mixer/AudioMixer.cpp,v (23)
Most frequent committer: Ingo Weinhold(136)
CVS statistics generated by cvstat
Created by Juli Mallett

Interface and Application Kit Improvements

Stefano Ceccherini comitted a fix to the interface kit on the thirtieth of June:

  Modified Files:
Region.cpp interface.src
Log Message:
Fixed an allocation bug in BRegion::set_size, started to comment BRegion with Doxygen (just the public methods and some friend functions for now). Added BRegion to the build.

Later, on the second of July, he gave it another go:

  Modified Files:
Region.cpp
Log Message:
Implemented sub_region_complex and or_region_complex. They divide the plane into horizontal bands, then pass the area to r_sub or r_or, which do the real work. Tested xxx_region_complex with R5's r_or and r_sub: they work fine. Just those last functions are missing now. Documented a bit more the private C functions.

Marc Flerackers committed a new BInvoker implementation on the seventh of July:

  Modified Files:
Invoker.cpp
Log Message:
A new BInvoker implementation. The InvokeNotify is now implemented as it should.

Darkwyrm committed a change to the app_server on the fifth of July:

  Modified Files:
AppServer.cpp ColorSet.cpp ColorSet.h RGBColor.cpp RGBColor.h
ServerConfig.h
Log Message:
Server now loads (and uses) the GUI system colors and can save 'em, too.

On the eighth of July, he continued work on the window decorators:

  Modified Files:
WinDecorator.cpp WinDecorator.h
Log Message:
Graphical retooling of the Windows decorator. Much better. :)

Gabe Yoder also committed some changes on the app_server on the ninth of July:

  Modified Files:
Layer.h ServerWindow.cpp
Log Message:
Begin adding clipping to graphics message processing.
Add sibling access functions to layers.

Continued Work on the Mixer

Marcus Overhagen, someone who likes to commit often, made us happy with a whole set of improvements on the mixer, a very central component of the media kit (which is an important kit, as BeOS is a media OS). On the twenty-ninth of June he started with:

  Modified Files:
AudioMixer.cpp MixerCore.cpp MixerInput.cpp MixerInput.h
MixerOutput.cpp MixerOutput.h
Log Message:
added output channel control functions,
made most often called functions inline

The next day, an important milestone was reached:

  Modified Files:
AudioMixer.cpp MixerCore.cpp MixerUtils.cpp MixerUtils.h
Log Message:
finally it does mixing, but we should get rid of the CPU eating List template at this place, as it internally calls malloc, free, new and delete quite often

That same day, he made another major improvement:

  Modified Files:
MixerCore.cpp
Log Message:
uses about 20% less CPU now

On the first of July, Marcus Overhagen implemented support for setting the volume (the gain):

  Modified Files:
AudioMixer.cpp AudioMixer.h MixerCore.cpp MixerInput.cpp
MixerInput.h MixerOutput.cpp MixerUtils.cpp MixerUtils.h
Log Message:
added mixer gain controls

Also on the media kit (but not in the mixer), was the work by Axel Dörfler regarding the ParameterWeb and the DefaultMediaTheme. The ParameterWeb contains a number of settings regarding a media node (such as a device) and how this node interacts with the world around it. The MediaTheme is a class that creates a user interface for the settings based on the contents of the ParameterWeb. There were a number of updates:

  Modified Files:
DefaultMediaTheme.cpp
On the first of July: 1.2-1.3:
Implemented a very simple default media theme. You can't do anything yet, but you should already see most of the options.
On the second of July: 1.3-1.4: Big visual update: it's now almost the same as the original MediaTheme. Some special parameter types are still missing, actually changing anything is missing, some needed work-arounds for broken Be code, etc.
1.4-1.5 : Added workaround for a misbehaving BOptionPopUp class (doesn't resize itself properly - it obviously needs the correct size at creation time...). 1.5-1.6: Added support for the B_HIDDEN_PARAMETER flag.
Added heuristics to only show those BNullParameters which the original media kit shows. Removed flickering in the SeparatorView drawing code.
1.6-1.7 : Now sets the height of the parameter web correctly (wasn't visible with the Media preferences application alone). Replaced the BBox with a simple BView for the container of a BParameterGroup.
1.7-1.8 : The creation of the parameter views now happens before the sub-groups are added to the group. That way, a title view can be identified and always placed at the top of the view. Fixed minor related bugs. On the sixth of July: 1.8-1.9 : The groups are now put into special GroupViews which not only set the target of its members correctly, but will also add scroll bars as needed. Implemented basic message filters for discrete/continuous parameter views. The views are now set to the correct parameter value and vice versa.
BContinuousParameter::{Get|Set}Response() is not yet supported, though.

In other media kit news: Jérôme Duvall committed the beta version of the Media Kit preference panel. On the tenth of July, he committed:

  Modified Files:
iconfile.h MediaAlert.h MediaWindow.h MediaAlert.cpp
MediaListItem.h MediaWindow.cpp Media.cpp MediaViews.cpp
Media.h MediaViews.h MediaListItem.cpp
Log Message:
Beta version

Bits'n'Pieces

On the twenty-ninth of June, Ingo Weinhold continued to extend the kernel toolkit with a vector implementation:

  Added Files:
Vector.h
Log Message: Added a generic Vector implementation.

The day after that, he added another useful container:

  Added Files:
VectorSet.h
Log Message:
Added a Vector based set implementation.

Just a short recap for those of you who, like me, forgot the use of these generic containers: A vector is a programming device that holds a few objects of a certain type, and it can shrink and grow. One use in the kernel is, for example, to store a list of threads, devices, or ethernet packets. A vector can shrink and grow. A set container is like a vector; however, every object in it needs to be unique. By using a common implementation, you prevent reimplementing the wheel every time you need these types of objects, which means that you spend less time on one thing, and that there will be less bugs.

Michael Wilber, improved his Inspector application with options to choose which translators will be active during opening and saving. On the first of June:

  Modified Files:
Jamfile Constants.h InspectorApp.h ImageView.cpp
ImageWindow.cpp InspectorApp.cpp
Added Files:
ActiveTranslatorsWindow.h ActiveTranslatorsWindow.cpp
Log Message:
Added beginnings of Active Translators window -- allows the user to select which translators will be active when an image is opened or saved

Jacques Lema committed a command line mail application on the fourth of July:

  Modified Files:
Jamfile
Added Files:
mail.cpp
Log Message:
/bin/mail by Jacques Lema

On the fifth of July, Andrew Bachman gave StyledEdit a new feature, one that the BeOS one didn't have. The ability to load and save different encodings is here:

  Modified Files:
CharacterSet.cpp CharacterSet.h Constants.h Jamfile
StyledEditWindow.cpp
Log Message:
first start encodings menu up for save as

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

 
What do you want to do with your life? by Michael Phipps 

It seems to be a universal question that parents ask their children at some point. Around age 14 or so, we start hinting that the young adult needs to start thinking about what sorts of career paths they are interested in. There is a myriad of ways that these adolescents can explore potential career choices. Sometimes they follow a person in their career for a day or two (job shadowing). There are tons of written descriptions, salary expectations, forecasts of job openings for 10 and 20 years in the future, etc. in the Guidance Counselor's office. Sometimes a person who is gainfully employed in their particular profession will come to the youth's school or youth group to talk about their job. Relatives, too, can often provide a contact in the field of endeavor.

For me, it was different. I wasn't like the other kids. My dad bought a computer when I was all of 8 years old. It was a TRS-80 Model I that he bought to track inventory for his business. It was silver and black--shiny enigma. Kids of my generation are fascinated by anything that emits photons from a screen. Early TV training, I suppose, is to blame. The concept that this thing was like a TV, except that you could control what it said and did, was too much for me to pass up. The person who sold us the computer made a disk of games for me, but that wasn't my key interest. I was fascinated with this "BASIC" language. I could give the computer things to do and it would do them! How much power could an 8-year-old want? I was in complete control of a multi-thousand-dollar machine. It was like I had a giant earth mover or something. To say that I was fascinated would be a dramatic understatement. I spent hours every night on that computer, learning the ins and outs of BASIC. I knew no one who could help me--it was all out of the BASIC book (which was very good, as I remember it) and beating my head against the machine. I don't have any of those old programs, but they certainly did teach me a lot about problem solving and coding.

A few years later, I was in school, and my teacher sent me down to the library. They had just finished unpacking an Apple ][+ and didn't have the first clue what to do with it. I sat down in front of it like I owned the thing and wrote a few programs for them. They were shocked. Here was a 10-year-old writing computer programs. This was 1982--that was certainly far from the norm. I continued to code, moving to an Atari 8-bit (600 XL), Commodore 64, Commodore 128D then my Amiga 500. Ah, the Amiga. The first machine that I ever coded in C for. Then the Amiga 2000 and 1200 came along. By this point, I was in college and writing OSs and other school work on Unix boxes. I sold my Amiga and built a Windows box. That one was quickly relegated to the wife and kids and I installed Linux on a 486. When BeOS became available for X86--I was in Boston to see it!--I immediately installed it, and I have been using the same hard drive ever since.

I never once wavered from the concept that I would be a programmer. Once I realized that you could get paid to write programs, I thought that I would be involved in the greatest job ever: I get to write code and get paid for it. What a scam! How cool could it get?

My first inkling that there was anything wrong with my dream came in my first year of college. One of my classmates was a professional photographer taking some computer courses. He had seen, first hand, what the software industry does to a person, and he tried to warn me. "They will chew you up and spit you out!", he told me. They don't care about you or your interests or dreams. They don't care how many hours you have to work to meet their insane schedules. They don't care if the code is good or elegant. They just want it to work perfectly and to be done yesterday.

I was young, naïve, and foolish, and I didn't believe that it could still be like that. I mean, he was old, right? He was nearly 40. What did he know? Whatever they did in the COBOL mills back in his day, well, that was back then, right? Things were all different now. The people managing were programmers themselves and they knew better. They would keep management under control and we would be in coding utopia.

Right. Sure.

I had a couple of internships in college. Both had severe management issues--one was at the US Government, and the other was at a small company. Still, I decided that small companies were my thing, and I joined a small company out of college. I thought that I was in coding utopia. I was literally 30 projects behind schedule the day that I started there. I didn't know the system, the industry or the language. I worked night and day and was caught up in a matter of months. My boss was (and still is) a great guy who encouraged me to find things to learn. I taught myself a few languages, read OSS code to increase my understanding, and built a new product from scratch--my own version of the company's flagship application. It was mostly complete and it looked beautiful, if I do say so myself.

Then the hammer fell. I was being reassigned to fix bugs in a legacy system and my project was cancelled. Three weeks later, I was at a different company.

The new company started out really promisingly. I learned a TON my first year or so. I wrote a lot of code and made a lot of difference in the company. But now things are different. I am not learning anything. I am maintaining the same code that I started on 4 years ago. Management and I don't see eye-to-eye about anything. Work is misery and pain. I still do the best job I can--I am a professional, but it is a joyless task.

So, I find myself asking myself, "Self, what do you want to do with your life?" If this were a video game, I might well press the reset button. If it were EverQuest, I might start a different character. But it is real life, and you have to make changes the hard way--one step at a time. Just like the old coin-op days, you don't walk away when there's a quarter in the machine.

So I am thinking through the changes that I want to make. What is important to me? Where do I want to be in 10 years? 20 years? In my retirement years? What tradeoffs and sacrifices am I willing to make to get to where I want to be?

When I interviewed for my current job, I told my boss-to-be "I want to work on neat, new things." The truth of it is, that hasn't changed one bit. I still want to work on neat, new things. Submitting patches to Linux won't cut it for me. Writing new apps, stretching the boundaries of computing is where I want to be. OpenBeOS is my outlet for (at least) part of that urge right now. OBOS is a neat, (mostly) new thing. Especially in the directions that we (the admin team) and you (the community) want it to go. I honestly believe that BeOS R5 is, in many ways, still the best OS out there. I use Win2K, WinXP, and Solaris every day. I certainly am not blind to R5's faults--don't get me wrong--but I think that OBOS is the most exciting technology in development today.

The problem that I have is that I don't have enough free time to work on it. It is difficult to find time to manage the project, write code, have a paying job, have a family, and sometimes even do non-code-related things. The impact of OBOS on my family is hard to understate. At the same time, I think that I would lose my mind if I were not involved. It would kill the part of me that likes coding. I would resign myself to being a drudge. I can't bring myself to do that, either.

I am not sure that I have the answer, yet. Corporate America doesn't seem to be the way for me to write cool stuff. Open Source doesn't seem to offer me any way to pay the bills. If anyone does have an answer for me, you know how to find me.