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