BodyHaiku R1 (x86) was designed and is being implemented to be binary and source compatible with applications written for BeOS R5 (x86) to a large extent, but not the other way around. In some cases we deliberately broke source compatibility while at the same time maintaining binary compatibility. Here are some specific examples:
The "be" header path is gone - it's called "os" in Haiku; since it is always part of the default header search path anyway, you can always just remove it to let your software compile on both platforms, ie.
To support Haiku and do something useful for it, I am pleased to show you how to communicate with the input server in BeOS.
In BeOS, almost everything uses the UTF-8 character encoding for the processing of characters. Thus, if you want to write or display the characters of other languages than English, all you need to do is to find a font able to display the characters properly and an input method add-on to help you at outputting characters to the running application. The input method handling of BeOS was originally found in the Japanese support. It works this way: The input server loads the add-ons located at B_SYSTEM_ADDONS_DIRECTORY /input_server/methods or B_USER_ADDONS_DIRECTORY/input_server/methods, then filter all events generated by the keyboard or mouse with the Filter() method of BInputServerFilter to change them. There are only a few input methods written since the time BeOS R4 was released. Maybe it's because only ERGOSOFT Crop. and just a few developers know how to have method working. In my memory, existing methods are BeCJK, HanBe, Canna, ChineseTool and more recently "Anthy for Zeta".
This is the Haiku boot screen. Pressing the spacebar while Haiku boots displays a screen with various boot options.
Small demo app to showcase the 2D drawing functions of Haiku.
Body: The way scrollbars work is pretty inefficient - especially for novice computer users. They offer three (!) methods for scrolling relative to the current position and none of them offers comfortable scrolling speed for all document sizes.
The arrows in the corners are very small compared to the scrollbar's overall size and they are too slow in most cases. Still, a lot of people use the arrows to scroll rather large distances in a document.
How is it that the Haiku vector icons are so small? You might expect great hackery, but actually HVIF is pretty simple. When I tell you all the "secrets", you might just go "doh!". The most important thing is that the format is optimized for icons. Once you take this simple assumption and think it through, you find all sorts of ways to reduce the storage space.
Here is an index of the existing documentation for end users.
Body: The means of having the operating system automatically sort, file and perform actions on filesystem objects based on user-configurable criteria should be provided through the use of a "drop target" replicant known as the "Sorting Chute".
Details The sorting chute would be comprised of three main components:
Replicant Preference Applet Drop Folder Replicant The replicant would act as a space on the desktop, designated by an appropriate visual representation, whereby filesystem objects can be dropped to have actions invoked upon them based on a set of user-defined rules.
Body: Haiku could include a dedicated API and an additional server who's task would be to manage and optimise simultaneous downloads on a global level.
Details In order to optimise downloads from a Haiku system it is proposed that all mass downloads be conducted using a dedicated download kit. Any software which wanted to download large files should use the download kit API to queue the download, query it's progress and other management tasks.
