The past two weeks can be characterized by having been 'releaseful'. OpenTracker 5.2.0 (and consequently 5.2.1), the Audio Mixer Alpha 1, and also the Translation kit Beta 2 all came out. All releases represent a lot of work, and I'm glad all the people involved were able to finally see their work, well, working. Anyway, enjoy this issue!

Applications

Andrew Bachman was fairly productive the past two weeks and did some improvements in the StyledEdit and the Terminal apps - two applications I use almost daily. On the tenth of August:

	Modified Files:
		StyledEditApp.cpp 
	Log Message:
		wrapping cascading! okay, i am really wasting my time now... I will

		go back to terminal I promise.

He also made some modifications for his interpretation of libtextencoding.so, a part of the BeOS programming API that handles the conversion of one text encoding to another. On the thirteenth of August, he changed:

	Modified Files:
		Jamfile character_sets.cpp utf8_conversions.cpp 
	Log Message:
		refine the error handling behavior.  note: we depart from the bebook

		specification for returning B_ERROR when no characters are converted.

		we do this in exactly one situation: when there are no bytes in the

		input.  this behavior is the behavior given by the R5 libs themselves.

		not having this behavior caused an error in our stylededit as well.

		stylededit has been fixed to not exercise this functionality.

		also added in the two most popular chinese encodings for my own evil

		purposes.  GB18030 support is required to legally sell an operating

		system in mainland china as well.  GB18030 support encompasses GBK

		and GB2312, additionally.

Jonas Sundstrom also committed, via Andrew, a Zip-O-Matic application:

	Added Files:
		GenericThread.cpp GenericThread.h Jamfile ZipOMatic.cpp 
		ZipOMatic.h ZipOMatic.icons.rdef ZipOMatic.rdef 
		ZipOMatic.version.rdef ZipOMaticActivity.cpp 
		ZipOMaticActivity.h ZipOMaticMisc.cpp ZipOMaticMisc.h 
		ZipOMaticSettings.cpp ZipOMaticSettings.h ZipOMaticView.cpp 
		ZipOMaticView.h ZipOMaticWindow.cpp ZipOMaticWindow.h 
		ZipOMaticZipper.cpp ZipOMaticZipper.h 
	Log Message:
		version 1.0 of Jonas Sundstrom's ZipOMatic app/add-on

He also worked on the filetypes application (the application that manages all the file types and the bindings to the actual apps installed), which he committed on the seventeenth of August:

	Modified Files:
		FileTypeView.cpp FileTypeView.h FileTypeWindow.cpp 
	Added Files:
		FileTypes.icons.rdef FileTypes.rdef FileTypes.version.rdef 
		FileTypesApp.cpp FileTypesApp.h FileTypesConstants.h 
		FileTypesView.cpp FileTypesView.h FileTypesWindow.cpp 
		FileTypesWindow.h Jamfile main.cpp 
	Log Message:
		first cut

Kernel Improvements

Axel Dörfler worked on the keyboard driver, and made it more modular on the eighteenth of August.

	Modified Files:
		keyboard.c 
	Log Message:
		Moved the driver initialization from init_hardware() to the more common
		init_driver() - also added a matching uninit_driver() (just in case :)).

		Replaced in8()/out8() with calls to the ISA bus manager (NewOS change

		1804). Removed unused includes.

He also worked on the vm part that managed the create_area(...) calls, and made the names BeOS compatible. He also updated the rest of the kernel code to use the new names (and implementations):

	Modified Files:
		vm.c 
	Log Message:
		Made the delete_area() function BeOS compatible; it now allows any

		area to delete. Added a comment how the security should be improved

		by adding another restriction. Also mentioned that it's probably a

		bad idea that vm_delete_region() will not wait until the region has

		been freed, but just "mark" it as to be freed.

Marcus Overhagen took a plunge in Kernel Development on the twentieth of August. He started with finishing little bits and pieces, starting with the atomic_* set of functions. These functions do certain operations on variables that are thread safe, i.e. no two threads can do an operation on that same value.

	Modified Files:
		SupportDefs.h 
	Log Message:
		added missing 32 bit atomic functions,
		and added all their 64bit counterparts.

After a short message showing his intentions, Axel Dörfler committed changes to the kernel syscall naming scheme:

	Modified Files:
		syscalls.c 
	Log Message:
		Added/changed VM syscalls to the BeOS compatible ones. Reordered the

		syscalls a bit (in functional groups), not completely, though.

Bits'n'Pieces

After a discussion on the posix-compliant headers in the repository, some people were already beginning to confirm to the specifications that the OpenGroup has set. Philippe Houdoin, on the twelfth of August, went on cleaning up the network stack headers.

	Removed Files:
		domain.h protosw.h socketvar.h sockio.h 
	Log Message:
		Remove non-posix headers files, moved back to headers/private/net

		where they belong for the moment.

Marcus Overhagen put the last hand to his mixer (which he released shortly thereafter). I must say, it works great now! On the sixteenth of August:

	Modified Files:
		AudioMixer.cpp AudioMixer.h MixerInput.cpp MixerInput.h 
		MixerUtils.h 
	Log Message:
		implemeted non linear gain controls (similar to BeOS R5)
		allow to select gain control slider modus in setup
		(either controls physical input, or virtual output channels)

Waldemar Kornewald, on the twentieth of August, continued work on his PPP implementation for OpenBeOS:

	Modified Files:
		KPPPStateMachine.h 
	Log Message:
		Some comments were not understandable.
		Added a new case when to destroy interface (when Up() failes and

		DialOnDemand is disabled). Forgot some to remove fUpThread in Up().

		Changed UpFailedEvent() so that it pretends a connection-lost event

		(so we can try to redial). Added ResetOptionHandlers() and

		DownProtocols/Encapsulators()

Stefano Ceccherini, on the twentysecond of August, committed a change to the interface kit:

	Modified Files:
		clipping.h 
	Log Message:
		added offsect_rect, fixed a spelling error

And the last commit, this time is from Axel Dörfler, who added a parse_date(...) implementation to the libroot:

	Added Files:
		parsedate.cpp 
	Log Message:
		Added an initial implementation of parsedate(), parsedate_etc(),

		get_dateformats(), and set_dateformats(). It's not complete yet,

		but already quite useful. Added a "d.m.y" to the R5 set of formats.

Good Day! Here it is, fresh and new, a true CVS digest for us all. Last issue was written, however, due to unforeseen circumstances, it never went to press. Fortunately, this issue has (else you wouldn't have read this bit of information which would mean that I'd written it for nothing), and it is filled with what I consider a good view of progress in the OpenBeOS CVS repository. Enjoy yourself!

Kitwork

Erik Jaesler, on the 25th of August, committed a change to the Application Kit:

	Modified Files:
		Handler.cpp InitTerminateLibBe.cpp Message.cpp app.src 


	Log Message:
		Minor tweak to BHandler::UnlockLooper()
		Added calls to _init_message_(), _delete_message_(), and
		_msg_cache_cleanup() to InitTerminateLibBe.cpp
		Finished first implementation of BMessage::SendReply(),

		BMessage::_send_(), and BMessage::_send_message() Add BMessage

		to app.src, removed BBlockCache from support.src. New BMessage::Private

		class has functions for twiddling BMessage internals

On the 29th of August, Marcus Overhagen did some work in the support kit:

	Modified Files:
		BlockCache.cpp 


	Log Message:
		Replaced the broken BBufferCache implementation.
		According to the BeBook, it is NOT allowed to allocate one large

		pool, instead the memory blocks must be allocated individually. To

		achieve O(1) for both Save() and Get() function, only one list of free

		blocks is maintained.

On the 29th of August, Stefano Ceccherini was working on the text view.

	Modified Files:
		TextGapBuffer.cpp TextGapBuffer.h TextView.cpp 




	Log Message:
		Fixed SetRunArray(). It was callign StyleBuffer::SetStyleRange()

		with a BFont** pointer instead of a BFont* one (that fix is by

		Marc Flerackers, as the whole class, BTW :)). Refactored

		CharClassification(), also added some more separator characters.

		Also foreign characters should be added here (Andrew?). Fixed

		[Allow][Disallow]Chars(). Fixed a linking issue when we don't

		link to libbe.

Adrian Oanca, on the 31st of August, went on implementing an important part in the communication chain between the app_server and the applications:

	Added Files:
		Session.cpp 


	Log Message:
		New communication class that will be used by app_server

		- BWindow/BView ... later, maybe by every class!

On the fourth of September, Marc Flerackers continued with the improving of the Text View:

	Modified Files:
		TextView.cpp 


	Added Files:
		UndoBuffer.cpp UndoBuffer.h 


	Log Message:
		Some more work on TextView by Jack Burton and me, Undo

		partially works now

On the fifth of September, Stefano Ceccherini worked on BRegion (his pet project):

	Modified Files:
		clipping.h 


	Log Message:
		Fixed a bug in BRegion copy constructor. If one constructed a BRegion

		with BRegion region(region), the region would have been put into an

		uninitialised state. Took the chance to cleanup a bit the code, using some

		methods of clipping.h. Changed the way offset_rect works, and changed

		its name too. Added a note to Region.cpp

Bits'n'Pieces

MrSiggler, by means of Phil Greenway, committed a new application to CVS, the scrollbar preflet. He did this on the 25th of August:

	Added Files:
		fakescrollbar.cpp fakescrollbar.h knobsizeadjuster.cpp 
		knobsizeadjuster.h messages.h scrollbar.cpp scrollbar.h 
		scrollbar.rsrc scrollbar_window.cpp scrollbar_window.h 


	Log Message:
		Initial Check-in of app by MrSiggler

Axel Dörfler, on the 26th of August, finalised his date-parser:

	Modified Files:
		parsedate.cpp 


	Log Message:
		Big (and final for now) update to the code, it's now complete and

		working better and faster than the R5 code as far as I have checked

		it. Refactored the source a bit, it's now much clearer: divided the

		heavily overloaded type field into type/unit/flags. Introduced some

		new methods to track everything we have to to provide a useful date

		in hopefully all cases. Now supports using a dash to mark negative

		values as well.

François Revol worked on the eject command line application. He committed his implementation on the 29th of August:

	Modified Files:
		Jamfile 




	Added Files:
		eject.c 


	Log Message:
		Added /bin/eject; has improvements over the R5 one.

Waldemar Kornewald felt productive on the 29th of August, and did a monster-commit on the PPP stack:

	Modified Files:
		KPPPConfigurePacket.h KPPPDefs.h KPPPDevice.h 
		KPPPEncapsulator.h KPPPInterface.h KPPPLCP.h KPPPManager.h 
		KPPPOptionHandler.h KPPPProtocol.h KPPPReportDefs.h 




	Log Message:
		Finished:
		 - PPPDevice
		 - PPPEncapsulator
		 - PPPOptionHandler
		 - PPPProtocol



		Added SendCodeReject implementation (though, I am not sure if

		it really works because I am not familiar with mbufs).



		Fixed some bugs.



		Changed the manager interface (there are no pointers to classes

		anymore). Some minor changes.



		TODO for libkernelppp.a:
		  - finish PPPLCP
		  - finish PPPConfigurePacket

On the 31st of August, Marcus Overhagen, whom we all love, added support for the ICH5 chipset in his driver:

	Modified Files:
		ac97.c config.c ich.h util.c 


	Log Message:
		added ICH5 support and fixed a few warnings

Axel Dörfler, on the 31st of August, added a new partition type to the kernel device manager: the Amiga type. I guess this means it is possible to put hard drives from your Amiga into your OBOS machine, and then read the data on it!

	Added Files:
		Jamfile amiga_rdb.cpp amiga_rdb.h 


	Log Message:
		Initial Amiga RDB read-only support. Code itself is tested,

		but not yet in this "shell" (the new DiskDeviceManager module

		API). Hope for the best :-) 

On the third of September, Axel committed another part of the kernel:

	Added Files:
		Jamfile main.cpp partitions.cpp stdio.cpp vfs.cpp 


	Log Message:
		Initial commit of the platform independent part of the

		new stage2 boot loader. Not yet complete, of course, but

		already scans Amiga partitions :-)

Axel Dörfler, on the fourth of September, committed a change to a very basic part of the BeOS experience:

	Modified Files:
		ps2mouse.c 


	Log Message:
		Applied NewOS change 1828 - moved the interrupt initialization

		to the correct point. Cleaned up the sources a bit.

[Obnoxious, snotty narrator begins]

"....When last we left our heroes at Munstris Diveloperz Inc., they were left wondering how applications can be made truly simple. Some software just worked well and other software just seemed bad, but they couldn't figure out why. It seemed like finding a good software tool was no simpler a task than navigating a vast digital jungle with little more than a pocket knife while wishing for a razor-sharp machete. As digital carpenters, the development team needed a good whack with a Clue-By-Four^TM or face being left pretty much to the same shoddy equipment as everyone else. The management just needed a good whack."

*Thump*

---------> We pardon the interruption. The people responsible for this irresponsible attempt at sophomoric humor have just been sacked. <-----------

-- Management

Seeing Clearly

What our poor developers in the above scenario were missing is focus. While we developers are used to getting into "the zone" and flinging code that (mostly) works way it should, this is not the kind of focus to which I am referring. When developing an application, the main thing that must not remain as the sole focus is the technology. Technology is the means to the goal. Should we focus on the cool stuff we can build into software, we lose sight of what it is ultimately supposed to do--just like running a marathon while staring at your feet, one tends to not see problems until one quite literally runs into them. What is the goal? The ultimate goal is to write good, fast, stable software which does exactly what it is supposed to do--and nothing else--while making it accessible to the intended type of person, and only one person of that type. Who is this person? It depends on the type of application, and an application's target audience will be discussed in detail! ! in the next article. In order to write a good application, some forethought is required before flinging code.

The Process

<*spit*> Just the name disgusts me, because the first thought it brings to mind is a bureaucratic fad which doesn't work and (hopefully) dies a relatively quick death in the department after a short time of decreasing productivity. The task at hand could better be termed "look before you leap," and it doesn't really take much time or effort.

First, describe the entire application's concept in a sentence. This could simply be something like, "The goal of this project is to create a front end to cdrecord which gives the user the ability to burn music and data CDs with a minimum of fuss." Second, come up with a list of tasks the user will commonly perform with the application, such as "Add an MP3 to an audio project." We can call these tasks "primary tasks" for the sake of reference. Next, brainstorm a list of tasks which the user may have a need for on an less frequent basis--secondary tasks. The number of secondary tasks should not greatly outnumber the number of primary tasks. The reason for this is to gear the application primarily toward the tasks which are most likely to be needed. Now that it is relatively clear what the application is supposed to do, it is time to consider the implementation.

When considering the implementation of the application, we don't need to genuinely consider the nasty details--just the generalities--and only doing this to get a rough idea of how the application will work. Continuing with our example, we just could say that when we add a track to a music CD project, we'll verify that the file is a sound file and add it to the track list. One thing to note is that not only has no code been written, no consideration has been given to what the front end will look like, either. This is next.

Designing the interface is perhaps the most difficult part of designing an application because a great number of considerations must be made. Even when one writes a command-line app some thought must be given to this, albeit less than for a GUI app. For the purposes of these articles, we will limit our focus to the GUI. An interface should be unnoticed if constructed well. A quote from Albert Einstein also applies here: "Things should be made as simple as possible, but no simpler." In the same manner, here is a list of good rules of thumb to design by:

1. Whenever possible, make commands undoable.
2. The interface should not reflect the implementation in its design.
3. In terms of features, be concerned with what the user is likely to need.
4. Use everyday language--avoid computer terms whenever possible.
5. Use controls for the tasks and in the manner for which they were designed.
6. Control layout should have a logical or natural order.
7. Make errors nearly impossible, if not impossible.

From a perspective which focuses on technology, humans are imprecise, illogical, disorganized, and they frequently make mistakes. God also created them to be good at matching patterns and at creating habits. Being able to undo a command suddenly makes the software forgiving, and the user is allowed to explore without worry of causing irreparable harm. Windows is infamous for asking the user "Are you sure?" when sending an item to the Recycle Bin. The Recycle Bin itself is good because it is possible to restore a "deleted" file. The confirmation dialog is useless because the user will habitually click 'Yes.'

The interface should not reflect the way an app is implemented because doing so often overcomplicates the interface. There are quite a few BeOS apps which are little more than front ends to mp3 encoding programs like lame and bladeenc, for example. The reason for their existence is because the encoders are command-line applications with many, many options, which reflects, in a sense, the way that they were written. These front ends should--and often do--reduce the great complexity of these encoders to the options which most users need to encode MP3 files.

Software which includes every feature save the kitchen sink is an excellent example of hubris and the wrong perspective. For example, I have a 6-in-1 tool I was given for Christmas. In combining so many tools, such as a hammer, wrench, pliers, etc., it unfortunately doesn't do any of them very well. Given a personal choice among Word, WordPerfect, Works, and Productive for Windows, I choose Productive because it offers the word-processing features I need without requiring me to hunt for them among features that I either don't understand or will never use. The common practice is to think "well, the user might need to do this." It is most often better to have smaller, specialized tools than one tool which does it all.

One of the qualifications for a field to be considered a profession is that the field has its own body of knowledge with its own technical terms. The computer field is no different. Using these terms in an application is appropriate only if the software is intended only for developers. Most often it is not. Helios, for example, is a good BeOS cdrecord front end, and does a good job of simplifying the task for which it is designed. However, a perusal of the preferences window yields some panels with checkboxes and radio buttons whose function remains a mystery to me.

Graphical controls are largely used the way they should be, but not always. This UI Hall of Shame shows some good examples of what *not* to do. Edit boxes should not be used in place of labels. Buttons should not be used as toggles--that's what checkboxes are for. Tabs should not imply a mode based on which one is active. A group of checkboxes should not be used for a group of radio buttons, which are designed to choose one from a number of choices.

Likewise, controls should be presented in a natural order. The edit boxes in the People application are ordered in the same manner as an address would be listed. Random or illogical control layout presents a hurdle to the user by forcing the user to think in a flow different from the natural order or exert unnecessary effort to move between the controls to maintain the natural order of thought. Interfaces need to let us work smarter, not harder.

Error messages are all too common, especially those in dialog boxes. If a developer can foresee an error condition, it needs to be compensated for. Does a directory not exist when it should? Create it. Can't find a file where it should be? Query for it. Only when software runs out of options in compensating for error conditions should it tell the user, and even then, the error message should be as non-technical as possible and also helpful, informing the user what course of action should be taken to remedy the problem. Crashes should not happen. Period. The error compensation in software sometimes requires considerable work, but it is worth it.

Human-computer interaction is a complicated subject and there are Masters degrees in the field, but designing good software does not have to be quite so difficult. It merely requires us developers to change the way we think. The more I work with software, the more frustrated I get because the software is bad and doesn't have to be this way. When I run, I prefer to keep my eyes on the goal. How about you?

On Monday, I downloaded WonderBrush.Go grab it and check it out, if you haven't already. I will wait.

Back? Great! I have to say that this is one of the best looking and smoothest BeOS apps that I have ever used. It seems solid and stable. It's translation mechanism is even very nice. I wrote to the author to tell him so.

His response brought up a very important, fundamental question that this community needs to consider. Which came first, the OS or the app? If you have 5 hours per week to "hobby code", should you contribute to OBOS or work on an app?

The first and most obvious answer is to do what you feel right about. If you have to grit your teeth and force yourself to work on OBOS, don't. You won't be happy and you will burn out. and you won't do your best work. It isn't worth it. OTOH, if you don't really know what you want to do, or know that you won't ever finish whatever app you start, consider working on OBOS. There are lots of little things that need to be done--tons of preferences and command line apps that aren't all there yet. Code reviews could be done. Writing test apps. If you can write code and have a few hours, any of those things would be great!

But if you are going to write an app, I would like you to thoughtfully consider a few things. You should consider some of the troubles that have struck other people.

First is to start with a whimper and end with a bang. It probably seems hypocritical, since OBOS didn't start that way, but I will stand by the statement. Posting on a mailing list that you are setting out to write "the coolest IRC client ever, so who is with me?" is not going to cut it. First, download every app in the category that you are considering. Write down every single cool (and not cool) thing that you notice from using them. Then sketch out your own quasi-design. Not class layout, so much, but things like your key ideas for the UI. How you want the user to work with the app. That sort of thing. Write a little code to implement that. Do a quick prototype. So what if it doesn't load preferences. It is a proof of concept. When you have put some work into it and you like the way that it is shaping up, show it to a few good devs and ask for criticism. Take it like a man (or woman)--don't whine, complain or defend; ask questions to draw them out. Slowly, the project will grow. People will want to help out. People are attracted to momentum.

Secondly, please, don't reinvent the wheel for the twenty-third time. BeOS does not need another IRC client. We probably don't need any more mail clients (there are a whole bunch under development right now). Pick something that we don't have any of or enough of. Better yet, volunteer to help with something that already exists. There are a number of them at BeUnited or on SourceForge.

Make a general-audience app. There are more than enough geek tools (heresy, I know). We need tools that our moms can use, that the secretary from work can use. Not tools with more command line options than there are keys on the keyboard, but tools with a nice looking, easy to use GUI.

Consider open source. I can name a hundred reasons that OSS is good for BeOS. One is that newbies can get a ton of software just for installing BeOS. Another is that if you get sick of working on your project, you can hand it off to the team of developers that have been attracted by your momentum.

Fail fast and hard, if ever. Pick the hardest part of your application and do it first. If it is too slow, too memory intensive or you just can't figure it out, you have saved yourself all of the time that you would have spent on coding that fancy about box.

Build your infrastructure organically as you need it. This applies to both code and non-code. Don't build yourself a 20 page web site with 4 gig of fancy graphics before you write the first line of code. In the same way, don't design the Be All End All of class libraries. Often times, you will be surprised at how different your actual needs are from your perceived needs at the beginning.

If you have some knowledge about a non-computer topic, you might be able to work that in. Finance knowledge? How about a Quicken type thing? If you know sports, maybe a simulation or a tool for running a fantasy league. [Editor's note: If you can convince JellyVision to work with you on porting You Don't Know Jack: Sports, that's good too.] Do you know science? How about a simulation or a data acquisition tool? There are tons of possibilities for applications that will be useful to the general public.

Finally, polish your app. Test it to death. Give it to your mom to use. Oh, she crashed it? Couldn't figure it out? Good indications that something is wrong. Beta test it with a few people. That will often bring out all sorts of stuff that you never planned on. Go the extra mile to make it look and feel really nice.

Be had a great OS and not enough apps. If every developer out there turns their eyes to OBOS and works on nothing else, we will be back where Be was. I consider most of the progress that BeOS made into the hearts and minds of users came from the third party apps. OBOS doesn't want to "be in the app business". That isn't our mission in life. That doesn't mean, though, that we don't want/need/love third party developers. We need a perfectly symbiotic relationship to survive and grow.