1/*! 2 \mainpage Welcome to the Haiku Book 3 4 Below you will find documentation on the Application Programming 5 Interface (API) of the Haiku operating system. This API describes 6 the internals of the operating system allowing developers to write 7 native C++ applications and device drivers. See the 8 <a href="https://api.haiku-os.org">online version</a> for the most 9 updated version of this document. If you would like to help contribute 10 contact the <a href="https://www.freelists.org/list/haiku-doc">documentation 11 mailing list</a>. For guidelines on how to help document the API see 12 the \link apidoc Documenting the API\endlink page. A list of 13 contributors can be found \ref credits page. Documenting the API is 14 an ongoing process so contributions are greatly appreciated. 15 16 The Haiku API is based on the BeOS R5 API but changes and additions have 17 been included where appropriate. Important compatibility differences are 18 detailed on the \ref compatibility page. New classes and methods 19 and incompatible API changes to the BeOS R5 API are noted in the 20 appropriate sections. 21 22 A complete reference to the BeOS R5 API is available on the web in 23 <a href="https://haiku-os.org/legacy-docs/bebook/">The Be Book</a>. 24 The Be Book is used with permission from 25 <a href="https://www.access-company.com/">Access Co.</a>, the current 26 owners of Be's intellectual property. 27 28 \section book_kits Kits and Servers 29 30 The API is split into several kits and servers each detailing a different 31 aspect of the operating system. 32 - The \ref app is the starting point for developing applications 33 and includes classes for messaging and for interacting with 34 the rest of the system. 35 - The \ref game provides classes for producing game sounds and 36 working with full screen apps. 37 - The \ref interface is used to create responsive and attractive 38 graphical user interfaces building on the messaging facilities 39 provided by the Application Kit. 40 - The \link layout_intro Layout API \endlink is a new addition 41 to the Interface Kit in Haiku which provides resources to 42 layout your application flexibly and easily. 43 - The \ref locale includes classes to localize your application to 44 different languages, timezones, number formatting conventions and 45 much more. 46 - The \ref media provides a unified and consistent interface for media 47 streams and applications to intercommunicate. 48 - The \ref midi2 describes an interface to generating, processing, 49 and playing music in MIDI format. For reference documentation on the 50 \ref midi1 is also included. 51 - The \ref network handles everything network related, from interface 52 IP address settings to HTTP connections. 53 - The \ref storage is a collection of classes that deal with storing and 54 retrieving information from disk. 55 - The \ref support contains support classes to use in your application 56 including resources for thread safety, IO, and serialization. 57 - The \ref translation provides a framework for converting data streams 58 between media formats. 59 60 \section book_special_topics Special Topics 61 62 - \ref drivers 63 - \ref keyboard 64 - \ref json 65*/ 66 67///// Define main kits ///// 68 69/*! 70 \defgroup app Application Kit 71 \brief The Application Kit is the starting point for writing native Haiku 72 GUI applications. 73 74 The application kit is exactly what its name suggests — it is the 75 basis of Haiku applications. You should first read through this document 76 and the references here before moving on to the other parts of the API. 77 78 The Application Kit classes can be divided into two groups: the messaging 79 classes and the system interaction classes. The larger of the two groups is 80 the messaging classes. Since the Haiku API relies on pervasive 81 multithreading messaging is an essential topic for any application. Have a 82 look at the \link app_messaging Introduction to Messaging \endlink for more 83 information. 84 85 The following messaging classes which allow you to easily and securely 86 communicate between threads. 87 - BHandler 88 - BInvoker 89 - BLooper 90 - BMessage 91 - BMessageFilter 92 - BMessageQueue 93 - BMessageRunner 94 - BMessenger 95 96 The second group is the system interaction classes. These classes 97 provide hooks for your application to interact with the rest of the system. 98 The most important class in this group is BApplication. Below is a list of 99 all system interaction classes: 100 - BApplication 101 - BClipboard 102 - BCursor 103 - BPropertyInfo 104 - BRoster 105 106 107 \defgroup game Game Kit 108 \brief The Game Kit provides classes for producing game sounds and 109 working with full screen apps. 110 111 112 \defgroup interface Interface Kit 113 \brief API for displaying a graphical user interface. 114 115 The Interface Kit holds all the classes you'll need to develop a GUI. 116 Building on the messaging facilities provided by the Application Kit, 117 the Interface Kit can be used to create a responsive and attractive 118 graphical user interface. 119 120 The most important class in the Interface Kit is the BView class, which 121 handles drawing and user interaction. Pointer and keyboard events are 122 processed in this class. 123 124 Another important class is the BWindow class, which holds BViews and makes 125 them visible to the user. The BWindow class also handles BView focusing 126 and BMessage dispatching, among other things. 127 128 A new addition Haiku has added over the BeOS API is the Layout API, which 129 is based around the BLayoutItem and BLayout classes. These classes will 130 take care of making sure all your GUI widgets end up where you want them, 131 with enough space to be useful. You can start learning the Layout API 132 by reading the \link layout_intro introduction \endlink. 133 134 135 \defgroup locale Locale Kit 136 \brief Collection of classes for localizing applications. 137 138 \defgroup media Media Kit 139 \brief Collection of classes that deal with audio and video. 140 141 \defgroup midi1 The old MIDI Kit (libmidi.so) 142 \brief The old MIDI kit. 143 144 145 \defgroup midi2 MIDI 2 Kit 146 \brief The Midi Kit is the API that implements support for generating, 147 processing, and playing music in MIDI format. 148 149 <A HREF="https://www.midi.org/">MIDI</A>, which stands for 'Musical 150 Instrument Digital Interface', is a well-established standard for 151 representing and communicating musical data. This document serves as 152 an overview. If you would like to see all the components, please look 153 at \link midi2 the list with classes \endlink. 154 155 \section book_midi2twokits A Tale of Two MIDI Kits 156 157 BeOS comes with two different, but compatible Midi Kits. This 158 documentation focuses on the "new" Midi Kit, or midi2 as we like to 159 call it, that was introduced with BeOS R5. The old kit, which we'll 160 refer to as midi1, is more complete than the new kit, but less powerful. 161 162 Both kits let you create so-called MIDI endpoints, but the endpoints 163 from midi1 cannot be shared between different applications. The midi2 164 kit solves that problem, but unlike midi1 it does not include a General 165 MIDI softsynth, nor does it have a facility for reading and playing 166 Standard MIDI Files. Don't worry: both kits are compatible and you can 167 mix-and-match them in your applications. 168 169 The main differences between the two kits: 170 - Instead of one BMidi object that both produces and consumes events, 171 we have BMidiProducer and BMidiConsumer. 172 - Applications are capable of sharing MIDI producers and consumers 173 with other applications via the centralized Midi Roster. 174 - Physical MIDI ports are now sharable without apps "stealing" events 175 from each other. 176 - Applications can now send/receive raw MIDI byte streams (useful if 177 an application has its own MIDI parser/engine). 178 - Channels are numbered 0–15, not 1–16 179 - Timing is now specified in microseconds rather than milliseconds. 180 181 \section book_midi2concepts Midi Kit Concepts 182 183 A brief overview of the elements that comprise the Midi Kit: 184 - \b Endpoints. This is what the Midi Kit is all about: sending MIDI 185 messages between endpoints. An endpoint is like a MIDI In or MIDI 186 Out socket on your equipment; it either receives information or it 187 sends information. Endpoints that send MIDI events are called 188 \b producers; the endpoints that receive those events are called 189 \b consumers. An endpoint that is created by your own application 190 is called \b local; endpoints from other applications are 191 \b remote. You can access remote endpoints using \b proxies. 192 - \b Filters. A filter is an object that has a consumer and a producer 193 endpoint. It reads incoming events from its consumer, performs some 194 operation, and tells its producer to send out the results. In its 195 current form, the Midi Kit doesn't provide any special facilities 196 for writing filters. 197 - \b Midi \b Roster. The roster is the list of all published producers 198 and consumers. By publishing an endpoint, you allow other 199 applications to talk to it. You are not required to publish your 200 endpoints, in which case only your own application can use them. 201 - \b Midi \b Server. The Midi Server does the behind-the-scenes work. 202 It manages the roster, it connects endpoints, it makes sure that 203 endpoints can communicate, and so on. The Midi Server is started 204 automatically when BeOS boots, and you never have to deal with it 205 directly. Just remember that it runs the show. 206 - \b libmidi. The BMidi* classes live inside two shared libraries: 207 libmidi.so and libmidi2.so. If you write an application that uses 208 old Midi Kit, you must link it to libmidi.so. Applications that use 209 the new Midi Kit must link to libmidi2.so. If you want to 210 mix-and-match both kits, you should also link to both libraries. 211 212 Here is a pretty picture: 213 214 \image html midi2concepts.png 215 216 \section book_midi2mediakit Midi Kit != Media Kit 217 218 Be chose not to integrate the Midi Kit into the Media Kit as another media 219 type, mainly because MIDI doesn't require any of the format negotiation that 220 other media types need. Although the two kits look similar -- both have a 221 "roster" for finding or registering "consumers" and "producers" -- there are 222 some very important differences. 223 224 The first and most important point to note is that BMidiConsumer and 225 BMidiProducer in the Midi Kit are \b NOT directly analogous to 226 BBufferConsumer and BBufferProducer in the Media Kit! In the Media Kit, 227 consumers and producers are the data consuming and producing properties 228 of a media node. A filter in the Media Kit, therefore, inherits from both 229 BBufferConsumer and BBufferProducer, and implements their virtual member 230 functions to do its work. 231 232 In the Midi Kit, consumers and producers act as endpoints of MIDI data 233 connections, much as media_source and media_destination do in the Media Kit. 234 Thus, a MIDI filter does not derive from BMidiConsumer and BMidiProducer; 235 instead, it contains BMidiConsumer and BMidiProducer objects for each of its 236 distinct endpoints that connect to other MIDI objects. The Midi Kit does not 237 allow the use of multiple virtual inheritance, so you can't create an object 238 that's both a BMidiConsumer and a BMidiProducer. 239 240 This also contrasts with the old Midi Kit's conception of a BMidi object, 241 which stood for an object that both received and sent MIDI data. In the new 242 Midi Kit, the endpoints of MIDI connections are all that matters. What lies 243 between the endpoints, i.e. how a MIDI filter is actually structured, is 244 entirely at your discretion. 245 246 Also, rather than use token structs like media_node to make connections 247 via the MediaRoster, the new kit makes the connections directly via the 248 BMidiProducer object. 249 250 \section book_midi2remotelocal Remote vs. Local Objects 251 252 The Midi Kit makes a distinction between remote and local MIDI objects. 253 You can only create local MIDI endpoints, which derive from either 254 BMidiLocalConsumer or BMidiLocalProducer. Remote endpoints are endpoints 255 that live in other applications, and you access them through BMidiRoster. 256 257 BMidiRoster only gives you access to BMidiEndpoints, BMidiConsumers, and 258 BMidiProducers. When you want to talk to remote MIDI objects, you do so 259 through the proxy objects that BMidiRoster provides. Unlike 260 BMidiLocalConsumer and BMidiLocalProducer, these classes do not provide a 261 lot of functions. That is intentional. In order to hide the details of 262 communication with MIDI endpoints in other applications, the Midi Kit must 263 hide the details of how a particular endpoint is implemented. 264 265 So what can you do with remote objects? Only what BMidiConsumer, 266 BMidiProducer, and BMidiEndpoint will let you do. You can connect 267 objects, get the properties of these objects -- and that's about it. 268 269 \section book_midi2lifespan Creating and Destroying Objects 270 271 The constructors and destructors of most midi2 classes are private, 272 which means that you cannot directly create them using the C++ 273 <CODE>new</CODE> operator, on the stack, or as globals. Nor can you 274 <CODE>delete</CODE> them. Instead, these objects are obtained through 275 BMidiRoster. The only two exceptions to this rule are BMidiLocalConsumer 276 and BMidiLocalProducer. These two objects may be directly created and 277 subclassed by developers. 278 279 \section book_midi2refcount Reference Counting 280 281 Each MIDI endpoint has a reference count associated with it, so that 282 the Midi Roster can do proper bookkeeping. When you construct a 283 BMidiLocalProducer or BMidiLocalConsumer endpoint, it starts with a 284 reference count of 1. In addition, BMidiRoster increments the reference 285 count of any object it hands to you as a result of 286 \link BMidiRoster::NextEndpoint() NextEndpoint() \endlink or 287 \link BMidiRoster::FindEndpoint() FindEndpoint() \endlink. 288 Once the count hits 0, the endpoint will be deleted. 289 290 This means that, to delete an endpoint, you don't call the 291 <CODE>delete</CODE> operator directly; instead, you call 292 \link BMidiEndpoint::Release() Release() \endlink. 293 To balance this call, there's also an 294 \link BMidiEndpoint::Acquire() Acquire() \endlink, in case you have two 295 disparate parts of your application working with the endpoint, and you 296 don't want to have to keep track of who needs to Release() the endpoint. 297 298 When you're done with any endpoint object, you must Release() it. 299 This is true for both local and remote objects. Repeat after me: 300 Release() when you're done. 301 302 \section book_midi2events MIDI Events 303 304 To make some actual music, you need to 305 \link BMidiProducer::Connect() Connect() \endlink your consumers to 306 your producers. Then you tell the producer to "spray" MIDI events to all 307 the connected consumers. The consumers are notified of these incoming 308 events through a set of hook functions. 309 310 The Midi Kit already provides a set of commonly used spray functions, 311 such as \link BMidiLocalProducer::SprayNoteOn() SprayNoteOn() \endlink, 312 \link BMidiLocalProducer::SprayControlChange() SprayControlChange() 313 \endlink, and so on. These correspond one-to-one with the message types 314 from the MIDI spec. You don't need to be a MIDI expert to use the kit, but 315 of course some knowledge of the protocol helps. If you are really hardcore, 316 you can also use the 317 \link BMidiLocalProducer::SprayData() SprayData() \endlink to send raw MIDI 318 events to the consumers. 319 320 At the consumer side, a dedicated thread invokes a hook function for every 321 incoming MIDI event. For every spray function, there is a corresponding hook 322 function, e.g. \link BMidiLocalConsumer::NoteOn() NoteOn() \endlink and 323 \link BMidiLocalConsumer::ControlChange() ControlChange() \endlink. 324 The hardcore MIDI fanatics among you will be pleased to know that you can 325 also tap into the \link BMidiLocalConsumer::Data() Data() \endlink hook and 326 get your hands dirty with the raw MIDI data. 327 328 \section book_midi2time Time 329 330 The spray and hook functions accept a bigtime_t parameter named "time". This 331 indicates when the MIDI event should be performed. The time is given in 332 microseconds since the computer booted. To get the current tick measurement, 333 you call the system_time() function from the Kernel Kit. 334 335 If you override a hook function in one of your consumer objects, it should 336 look at the time argument, wait until the designated time, and then perform 337 its action. The preferred method is to use the Kernel Kit's 338 <CODE>snooze_until()</CODE> function, which sends the consumer thread to 339 sleep until the requested time has come. (Or, if the time has already 340 passed, returns immediately.) 341 342 Like this: 343 344 \code 345void MyConsumer::NoteOn( 346 uchar channel, uchar note, uchar velocity, bigtime_t time) 347{ 348 snooze_until(time, B_SYSTEM_TIMEBASE); 349 ...do your thing... 350} 351 \endcode 352 353 If you want your producers to run in real time, i.e. they produce MIDI data 354 that needs to be performed immediately, you should pass time 0 to the spray 355 functions (which also happens to be the default value). Since time 0 has 356 already passed, <CODE>snooze_until()</CODE> returns immediately, and the 357 consumer will process the events as soon as they are received. 358 359 To schedule MIDI events for a performance time that lies somewhere in the 360 future, the producer must take into account the consumer's latency. 361 Producers should attempt to get notes to the consumer by or before 362 <I>(scheduled_performance_time - latency)</I>. The time argument is still 363 the scheduled performance time, so if your consumer has latency, it should 364 snooze like this before it starts to perform the events: 365 366 \code 367snooze_until(time - Latency(), B_SYSTEM_TIMEBASE); 368 \endcode 369 370 Note that a typical producer sends out its events as soon as it can; 371 unlike a consumer, it does not have to snooze. 372 373 \section book_midi2ports Other Timing Issues 374 375 Each consumer object uses a Kernel Kit port to receive MIDI events from 376 connected producers. The queue for this port is only 1 message deep. 377 This means that if the consumer thread is asleep in a 378 <CODE>snooze_until()</CODE>, it will not read its port. Consequently, 379 any producer that tries to write a new event to this port will block until 380 the consumer thread is ready to receive a new message. This is intentional, 381 because it prevents producers from generating and queueing up thousands of 382 events. 383 384 This mechanism, while simple, puts on the producer the responsibility 385 for sorting the events in time. Suppose your producer sends three Note 386 On events, the first on t + 0, the second on t + 4, and the third on t + 2. 387 This last event won't be received until after t + 4, so it will be two ticks 388 too late. If this sort of thing can happen with your producer, you should 389 somehow sort the events before you spray them. Of course, if you have two or 390 more producers connected to the same consumer, it is nearly impossible to 391 sort this all out (pardon the pun). So it is not wise to send the same kinds 392 of events from more than one producer to one consumer at the same time. 393 394 The article Introduction to MIDI, Part 2 in <A 395 HREF="https://open-beos.sourceforge.net/nsl.php?mode=display&id=36">OpenBeOS 396 Newsletter 36</A> describes this problem in more detail, and provides a 397 solution. Go read it now! 398 399 \section book_midi2filters Writing a Filter 400 401 A typical filter contains a consumer and a producer endpoint. It receives 402 events from the consumer, processes them, and sends them out again using the 403 producer. The consumer endpoint is a subclass of BMidiLocalConsumer, whereas 404 the producer is simply a BMidiLocalProducer, not a subclass. This is a 405 common configuration, because consumers work by overriding the event hooks 406 to do work when MIDI data arrives. Producers work by sending an event when 407 you call their member functions. You should hardly ever need to derive from 408 BMidiLocalProducer (unless you need to know when the producer gets connected 409 or disconnected, perhaps), but you'll always have to override one or more of 410 BMidiLocalConsumer's member functions to do something useful with incoming 411 data. 412 413 Filters should ignore the time argument from the spray and hook functions, 414 and simply pass it on unchanged. Objects that only filter data should 415 process the event as quickly as possible and be done with it. Do not 416 <CODE>snooze_until()</CODE> in the consumer endpoint of a filter! 417 418 \section book_midi2apidiffs API Differences 419 420 As far as the end user is concerned, the Haiku Midi Kit is mostly the same 421 as the BeOS R5 kits, although there are a few small differences in the API 422 (mostly bug fixes): 423 - BMidiEndpoint::IsPersistent() always returns false. 424 - The B_MIDI_CHANGE_LATENCY notification is now properly sent. The Be 425 kit incorrectly set be:op to B_MIDI_CHANGED_NAME, even though the 426 rest of the message was properly structured. 427 - If creating a local endpoint fails, you can still Release() the object 428 without crashing into the debugger. 429 430 \section book_midi2seealso See also 431 432 More about the Midi Kit: 433 - \ref Midi2Defs.h 434 - Be Newsletter Volume 3, Issue 47 - Motor Mix sample code 435 - Be Newsletter Volume 4, Issue 3 - Overview of the new kit 436 - <A HREF="https://haiku-os.org/documents/dev/introduction_to_midi_part_1">Newsletter 437 33</A>, Introduction to MIDI, Part 1 438 - <A HREF="https://haiku-os.org/documents/dev/introduction_to_midi_part_2">Newsletter 439 36</A>, Introduction to MIDI, Part 2 440 - Sample code and other goodies at the 441 <A HREF="https://haiku-os.org/about/teams/midi_kit">Haiku Midi Kit team page</A> 442 443 Information about MIDI in general: 444 - <A HREF="https://www.midi.org">MIDI Manufacturers Association</A> 445 - <A HREF="https://www.borg.com/~jglatt/tutr/miditutr.htm">MIDI Tutorials</A> 446 - <A HREF="https://www.borg.com/~jglatt/tech/midispec.htm">MIDI Specification</A> 447 - <A HREF="https://www.borg.com/~jglatt/tech/midifile.htm">Standard MIDI File Format</A> 448 - <A HREF="https://www.io.com/~jimm/midi_ref.html">Jim Menard's MIDI Reference</A> 449 450 451 \defgroup network Network Kit 452 \brief Classes that deal with all network connections and communications. 453 454 The Haiku Network Kit consists of: 455 - A modular, add-ons based network stack 456 - Two shared libraries, libnet.so and libnetapi.so 457 - A stack driver, acting as interface between the network stack and 458 libnet.so 459 - Basic network apps 460 - A modular GUI preflet 461 462 The libnet.so shared library is the way that BeOS R5 provided POSIX/BSD 463 API sockets to apps. Being binary compatible with BeOS R5 has made this 464 library implementation tedious. To counter this, the libnetapi.so shared 465 library was developed. It contains thin C++ classes wrapping the C 466 sockets POSIX/BSD API into these BNet* classes we're used under BeOS. 467 468 The stack driver is the interface between libnet.so and the real stack 469 behind it, hosted by the network stack kernel modules. Its purposes 470 include: 471 -# Providing sockets to file descriptors translation support 472 -# Providing support for select() on sockets 473 -# Loading the network stack on first access, and then keeping it for 474 further accesses 475 476 The following diagram illustrates the network stack design on Haiku: 477 478 \image html obos_net_stack_design_1.gif 479 480 The Network Kit includes a handful of useful networking related apps 481 including ping, ifconfig, route, traceroute, and arp. 482 483 See the User Guide for more information about the 484 <a href="https://haiku-os.org/docs/userguide/en/preferences/network.html">Network preferences app</a> 485 included as part of the Network Kit. 486 487 488 \defgroup storage Storage Kit 489 \brief Collection of classes that deal with storing and retrieving 490 information from disk. 491 492 493 \defgroup support Support Kit 494 \brief Collection of utility classes that are used throughout the API. 495 496 The Support Kit provides a handy set of classes that you can use in your 497 applications. These classes provide: 498 - \b Thread \b Safety. Haiku can execute multiple threads of an 499 application in parallel, letting certain parts of an application 500 continue when one part is stalled, as well as letting an application 501 process multiple pieces of data at the same time on multicore or 502 multiprocessor systems. However, there are times when multiple 503 threads desire to work on the same piece of data at the same time, 504 potentially causing a conflict where variables or pointers are 505 changed by one thread causing another to execute incorrectly. To 506 prevent this, Haiku implements a \"locking\" mechanism, allowing one 507 thread to \"lock out\" other threads from executing code that might 508 modify the same data. 509 - \b Archiving \b and \b IO. These classes allow a programmer to 510 convert objects into a form that can more easily be transferred to 511 other applications or stored to disk, as well as performing basic 512 input and output operations. 513 - \b Memory \b Allocation. This class allows a programmer to hand off 514 some of the duties of memory accounting and management. 515 - \b Common \b Datatypes. To avoid unnecessary duplication of code 516 and to make life easier for programmers, Haiku includes classes that 517 handle management of ordered lists and strings. 518 519 There are also a number of utility functions to time actions, play system 520 alert sounds, compare strings, and atomically manipulate integers. Have a 521 look at the overview, or go straight to the complete 522 \link support list of components \endlink of this kit. 523 524 \section book_overview Overview 525 - Thread Safety: 526 - BLocker provides a semaphore-like locking mechanism allowing for 527 recursive locks. 528 - BAutolock provides a simple method of automatically removing a 529 lock when a function ends. 530 - \ref TLS.h "Thread Local Storage" allows a global variable\'s 531 content to be sensitive to thread context. 532 - Archiving and IO: 533 - BArchivable provides an interface for \"archiving\" objects so 534 that they may be sent to other applications where an identical 535 copy will be recreated. 536 - BArchiver simplifies archiving of BArchivable hierarchies. 537 - BUnarchiver simplifies unarchiving hierarchies that have been 538 archived using BArchiver. 539 - BFlattenable provides an interface for \"flattening\" objects so 540 that they may be easily stored to disk. 541 - BDataIO provides an interface for generalized read/write streams. 542 - BPositionIO extends BDataIO to allow seeking within the data. 543 - BBufferIO creates a buffer and attaches it to a BPositionIO 544 stream, allowing for reduced load on the underlying stream. 545 - BMemoryIO allows operation on an already-existing buffer. 546 - BMallocIO creates and allows operation on a buffer. 547 - Memory Allocation: 548 - BBlockCache allows an application to allocate a \"pool\" of 549 memory blocks that the application can fetch and dispose of as 550 it pleases, letting the application make only a few large memory 551 allocations, instead of many small expensive allocations. 552 - Common Datatypes: 553 - BList allows simple ordered lists and provides common access, 554 modification, and comparison functions. 555 - BString allows strings and provides common access, modification, 556 and comparison functions. 557 - BStopWatch allows an application to measure the time an action takes. 558 - \ref support_globals "Global functions" 559 - \ref TypeConstants.h "Common types and constants" 560 - Error codes for all kits 561 562 563 \defgroup translation Translation Kit 564 \brief Provides a framework for converting data streams between media 565 formats. 566 567 568 \defgroup libtranslation (libtranslation.so) 569 570 \defgroup libbe (libbe.so) 571 572 573 \defgroup libroot (libroot.so) 574*/ 575 576///// Subgroups ///// 577 578/*! 579 \defgroup support_globals Global functions 580 \ingroup support 581 582 \defgroup layout Layout API 583 \brief Provides classes for automatically laying out UIs. 584 \ingroup interface 585*/ 586 587 588///// Special Topics ///// 589 590/*! 591 \defgroup drivers Device Drivers 592 593 \defgroup json Json Handling 594 \brief Provides for parsing and writing of data in Json encoding. 595*/ 596
