diff --git a/docs/develop/file_systems/node_monitoring.rst b/docs/develop/file_systems/node_monitoring.rst index e7fe91bf21..72bc9a032a 100644 --- a/docs/develop/file_systems/node_monitoring.rst +++ b/docs/develop/file_systems/node_monitoring.rst @@ -8,7 +8,7 @@ Author(s): Axel Dörfler This document describes the feature of the BeOS kernel to monitor nodes. First, there is an explanation of what kind of functionality we have to reproduce (along with the higher level API), then we will present the -implementation in OpenBeOS. +implementation in Haiku. Requirements - Exported Functionality in BeOS --------------------------------------------- @@ -95,7 +95,7 @@ use any application kit services. | -Meeting the Requirements in an Optimal Way - Implementation in OpenBeOS +Meeting the Requirements in an Optimal Way - Implementation in Haiku ----------------------------------------------------------------------- If you assume that every file operation could trigger a notification @@ -189,17 +189,17 @@ implementation, there are some notable differences between the two. BeOS reserves a certain number of slots for calls to ``watch_node()`` - each call to that function will use one slot, even if you call it twice -for the same node. OpenBeOS, however, will always use one slot per node +for the same node. Haiku, however, will always use one slot per node - you could call ``watch_node()`` several times, but you would waste only one slot. While this is an implementational detail, it also causes a change in behaviour for applications; in BeOS, applications will get one message -for every ``watch_node()`` call, in OpenBeOS, you'll get only one +for every ``watch_node()`` call, in Haiku, you'll get only one message per node. If an application relies on this strange behaviour of the BeOS kernel, it will no longer work correctly. -The other difference is that OpenBeOS exports its node monitoring +The other difference is that Haiku exports its node monitoring functionality to kernel modules as well, and provides an extra plain C API for them to use. @@ -250,4 +250,4 @@ is much larger then - but for applications like Tracker, the complexity would be removed from the application without extra cost. However, none of the discussed feature extensions have been implemented -for the currently developed version R1 of OpenBeOS. +for the currently developed version R1 of Haiku. diff --git a/docs/develop/kits/app/usecases/BMessageQueueUseCases.html b/docs/develop/kits/app/usecases/BMessageQueueUseCases.html index 262edcec13..94a8d9fd10 100644 --- a/docs/develop/kits/app/usecases/BMessageQueueUseCases.html +++ b/docs/develop/kits/app/usecases/BMessageQueueUseCases.html @@ -139,7 +139,7 @@ elements in the list will be high.

Because the BMessageQueue uses the link pointer which is a private part of the BMessage class, the BMessageQueue must be a friend class of BMessage. Checking the headers, this is in fact the case in Be's implementation. Although friendship in classes can cause some pretty serious long -term headaches if abused (and I am not convinced that this is an abuse), the OpenBeOS +term headaches if abused (and I am not convinced that this is an abuse), the Haiku implementation will follow the same implementation for now.

diff --git a/docs/develop/kits/app/usecases/BPropertyInfoUseCases.html b/docs/develop/kits/app/usecases/BPropertyInfoUseCases.html index 0c4941388f..52b7044bd0 100644 --- a/docs/develop/kits/app/usecases/BPropertyInfoUseCases.html +++ b/docs/develop/kits/app/usecases/BPropertyInfoUseCases.html @@ -131,7 +131,7 @@ properties.

BPropertyInfo Implementation:

-

There is a key difference between the OpenBeOS BPropertyInfo class and the Be implementation +

There is a key difference between the Haiku BPropertyInfo class and the Be implementation is support for BeOS R3 compiled executables. The elements in the property_info structure changed in R4 versus the one which was used in R3. Be did the following to handle this:

@@ -146,7 +146,7 @@ constructor would be called because the old one was made private. R3 based BPropertyInfo instances. I have not done serious checking on this however. -

For the OpenBeOS implementation, we have decided not to implement this R3 compatibility at +

For the Haiku implementation, we have decided not to implement this R3 compatibility at this time but we are not going to rule it out. The header file for BPropertyInfo will be changed to "remove" the R3 compatibility interfaces using an "ifdef R3_compatible". The interfaces will still appear to the human reader but not be there as far as the compiler is concerned. If we @@ -154,15 +154,15 @@ revise out decision in the future, it will be a simple matter of removing the if these R3 compatibility interfaces. For now, we have decided not to do this because:

diff --git a/docs/develop/kits/interface/BPicture_specifications.html b/docs/develop/kits/interface/BPicture_specifications.html index a2b93b34b6..f314031a70 100644 --- a/docs/develop/kits/interface/BPicture_specifications.html +++ b/docs/develop/kits/interface/BPicture_specifications.html @@ -6,7 +6,7 @@ content="text/html; charset=ISO-8859-1"> + content="BPicture specifications for Haiku"> Author: diff --git a/docs/develop/media/codec_mapping b/docs/develop/media/codec_mapping index ad5b285063..ce2462722d 100644 --- a/docs/develop/media/codec_mapping +++ b/docs/develop/media/codec_mapping @@ -1,5 +1,5 @@ # This file belongs into /boot/home/config/settings/Media and is called codec_mapping -# It contains codec assignments for the new OpenBeOS media kit +# It contains codec assignments for the new Haiku media kit # # WARNIG! This format is experimental and will possibly be changed! # diff --git a/docs/develop/midi/design.rst b/docs/develop/midi/design.rst index 87696f922c..68fae57eac 100644 --- a/docs/develop/midi/design.rst +++ b/docs/develop/midi/design.rst @@ -5,7 +5,7 @@ The Midi Kit consists of the midi_server and two shared libraries, libmidi2.so and libmidi.so. The latter is the "old" pre-R5 Midi Kit and has been re-implemented using the facilities from libmidi2, which makes it fully compatible with the new kit. This document describes the design -and implementation of the OpenBeOS midi_server and libmidi2.so. +and implementation of the Haiku midi_server and libmidi2.so. The midi_server has two jobs: it keeps track of the endpoints that the client apps have created, and it publishes endpoints for the devices diff --git a/docs/develop/midi/midi1.rst b/docs/develop/midi/midi1.rst index d2b7643b10..e12f859e70 100644 --- a/docs/develop/midi/midi1.rst +++ b/docs/develop/midi/midi1.rst @@ -36,7 +36,7 @@ do, while it is likely that no applications use them anyway. However, problems. ``BSamples`` doesn't do anything; its functions are mostly empty. In -other words, with the OpenBeOS Midi Kit you cannot push waveform data +other words, with the Haiku Midi Kit you cannot push waveform data into the output of the softsynth. For simplicity's sake, ``BMidiSynthFile`` is implemented using diff --git a/docs/develop/midi/oldprotocol.rst b/docs/develop/midi/oldprotocol.rst index 700e982933..9121b37980 100644 --- a/docs/develop/midi/oldprotocol.rst +++ b/docs/develop/midi/oldprotocol.rst @@ -1,7 +1,7 @@ The BeOS R5 Midi Kit protocol ============================= -In the course of writing the OpenBeOS Midi Kit, I spent some time +In the course of writing the Haiku Midi Kit, I spent some time looking at how BeOS R5's libmidi2.so and midi_server communicate. Not out of a compulsion to clone this protocol, but to learn from it. After all, the Be engineers spent a lot of time thinking about this already, @@ -358,7 +358,7 @@ has a zero refcount, libmidi still sends out the 'Mdel' message. It also drops you into the debugger. (I think it should return an error code instead, it already has a status_t.) However, if you Release() proxies a few times too many, your app does not jump into the debugger. (Again, I -think the return result should be an error code here -- for OpenBeOS R1 +think the return result should be an error code here -- for Haiku R1 I think we should jump into the debugger just like with local objects). Hmm, actually, whether you end up in the debugger depends on the contents of memory after the object is deleted, because you perform the diff --git a/docs/develop/midi/testing.rst b/docs/develop/midi/testing.rst index bfa2f49312..29dfe5f2bc 100644 --- a/docs/develop/midi/testing.rst +++ b/docs/develop/midi/testing.rst @@ -1,7 +1,7 @@ Testing the Midi Kit ==================== -Most of the OpenBeOS source code has unit tests in the current/src/tests +Most of the Haiku source code has unit tests in the current/src/tests directory. I looked into building CppUnit tests for the midi2 kit, but decided that it doesn't really make much sense. Unit tests work best if you can test something in isolation, but in the case of the midi2 kit diff --git a/docs/develop/servers/app_server/AppServer.rst b/docs/develop/servers/app_server/AppServer.rst index d6c755c2c2..8a31e4ed86 100644 --- a/docs/develop/servers/app_server/AppServer.rst +++ b/docs/develop/servers/app_server/AppServer.rst @@ -135,7 +135,7 @@ Attached Data: GET_SCREEN_MODE --------------- -Received from the OpenBeOS Input Server when requesting the current +Received from the Haiku Input Server when requesting the current screen settings via synchronous PortLink messaging. This is a temporary solution which will be deprecated as soon as the BScreen class is complete. diff --git a/docs/develop/servers/app_server/Decorator.rst b/docs/develop/servers/app_server/Decorator.rst index ef663b93b2..b575942aaa 100644 --- a/docs/develop/servers/app_server/Decorator.rst +++ b/docs/develop/servers/app_server/Decorator.rst @@ -212,7 +212,7 @@ void \_SetFocus(void) This hook function is primarily used to change colors used when a window changes focus states and is called immediately after the state -is changed. If, for example, a decorator does not use OpenBeOS' GUI +is changed. If, for example, a decorator does not use Haiku' GUI color set, it would change its drawing colors to reflect the change in focus. diff --git a/docs/user/book.dox b/docs/user/book.dox index d8898bf409..df3654fd41 100644 --- a/docs/user/book.dox +++ b/docs/user/book.dox @@ -388,7 +388,7 @@ snooze_until(time - Latency(), B_SYSTEM_TIMEBASE); of events from more than one producer to one consumer at the same time. The article Introduction to MIDI, Part 2 in OpenBeOS + HREF="https://www.haiku-os.org/legacy-docs/openbeosnewsletter/nsl36.html">OpenBeOS Newsletter 36 describes this problem in more detail, and provides a solution. Go read it now! diff --git a/docs/user/midi2/MidiEndpoint.dox b/docs/user/midi2/MidiEndpoint.dox index 4dc9fb8d74..1331772506 100644 --- a/docs/user/midi2/MidiEndpoint.dox +++ b/docs/user/midi2/MidiEndpoint.dox @@ -292,8 +292,8 @@ if (endpoint->GetProperties(&props) == B_OK) field type'MICN' - The MidiUtil package (downloadable from the OpenBeOS website) contains a - number of convenient functions to associate icons with endpoints, so you + The MidiUtil package (downloadable from https://www.haiku-os.org/files/MidiUtil-1_0.zip) + contains a number of convenient functions to associate icons with endpoints, so you don't have to write that code all over again. \sa GetProperties() diff --git a/docs/user/midi2/midi2intro.dox b/docs/user/midi2/midi2intro.dox index 53dbdb7e12..752e55cb33 100644 --- a/docs/user/midi2/midi2intro.dox +++ b/docs/user/midi2/midi2intro.dox @@ -244,7 +244,7 @@ connected to the same consumer, it is nearly impossible to sort this all out than one producer to one consumer at the same time. The article Introduction to MIDI, Part 2 in OpenBeOS +HREF="https://www.haiku-os.org/legacy-docs/openbeosnewsletter/nsl36.html">OpenBeOS Newsletter 36 describes this problem in more detail, and provides a solution. Go read it now!