i2p/haiku-beta6
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into sam460ex

Browse Source
This commit is contained in:
François Revol
2013-02-03 00:39:40 +01:00
parent 287040333d 401bf7a0b5
commit 34a12c7678
356 changed files with 4767 additions and 25517 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/develop/opengl/openGLkit_Jan-2013.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

docs/develop/opengl/readme
+120
View File
@@ -0,0 +1,120 @@
Haiku OpenGL kit developers introduction
The Haiku OpenGL kit is made up of the folwing pieces:
* The "OpenGL Kit" aka libGL.so and supporting libraries.
This is what the user applications interact with.
* The "OpenGL Add-ons" (which do the real work)
These are chosen by the OpenGL kit and utilized
In the traditional BeOS sense, the OpenGL Add-ons are the
vendor provided OpenGL drivers. This actually doesn't
mesh well with the current open source OpenGL stack.
Our "OpenGL Add-ons" are really wrappers around Mesa
and Gallium code. We gain greater OS control of OpenGL
rendering with the drawback of increased work overall.
The OpenGL Add-ons call private Mesa functions, thus
we get no compatibility saftey net between Mesa versions.
Our Gallium connecting Add-ons could actually fit into
the upstream Mesa / Gallium project, however this would
cause complications in the build process (linking in
OpenGL and all of it's libraries into a small number of
shared libraries is not really what the Mesa project
designs it's stack for. Several symbol collisions exist
when trying to link libmesa and libgallium together for
example)
Mesa drivers are the classical Mesa software rasterizers
Gallium drivers are the new-school software drivers.
**********
Mesa versions
The Haiku project uses two different versions of Mesa.
* Mesa 7.8.2 for gcc2 OpenGL Add-ons
* Mesa 9.0.1+ for gcc4 OpenGL Add-ons.
The reasoning behind this is that any version of Mesa
above 7.8.2 will require a *massive* porting effort to
make it compile under gcc2. Given this fact, it makes
sense to bump the gcc2 version of Mesa as far as it will
go and set it there statically. Think of Mesa 7.8.2
as the "stable" version Haiku R1 will use :)
Hardware 3D rendering and llvm-based software rendering
will never work for legacy gcc2 applications. Period.
However! If you're running a gcc2 hybrid version of
Haiku, llvm or hardware based rendering should be possible
on gcc4 applications.
It is *essential* to upgrade our build Mesa packages
with the latest release Mesa versions. If we fall too
far behind the update gets extremely tricky as functions
inside Mesa and Gallium change at a fast pace.
**********
gcc2 OpenGL kit
The following process occurs in order to generate the
gcc2 (Mesa 7.8.2) OpenGL kit:
* Some kind soul compiles a Mesa optional package on a
gcc2 Haiku system with the bep on haikuports. This
gets uploaded to Haiku-files and the package name
/ version gets updated as in the BuildFeatures jam
build script.
- The bep generally applies a few minimal patches to
Mesa 7.8.2 and compiles it. Then it rounds up all of
the headers and static libraries and throws them into
a .zip for the build
* Someone starts a gcc2 Haiku build. The build process pulls
down the Mesa optional package above and links the needed
parts into libGL and the swrast_legacy OpenGL add-on
**********
gcc4 OpenGL kit
The following process occurs in order to generate the
gcc4 (Mesa 9.0.1+) OpenGL kit:
* Some kind soul compiles a Mesa optional package on a
gcc4 Haiku system with the bep on haikuports. This
gets uploaded to Haiku-files and the package name
/ version gets updated as in the BuildFeatures jam
build script.
- The kind soul also needs to install the LLVM Optional
build package on his build machine *before* compiling
the Mesa bep. (unless he or she doesn't want llvmpipe
rendering)
- The bep for Mesa 9.0.1+ doesn't apply too many patches as
Haiku build fixes are accepted upstream.
- The bep rounds up all of the headers and static
libraries and throws them into a .zip for the build
* Someone starts a gcc4 Haiku build. The build process pulls
down the Mesa optional package above and links the needed
parts into libGL and OpenGL add-ons.
- If the user didn't link in LLVM, he can disable the LLVM
dependencies in the OpenGL kit Jamfile. swpipe will
automagically fall back to softpipe rendering
- The build system will download the LLVM optional package
and link it into any OpenGL add-ons that need it.
!! The LLVM optional package needs to match the LLVM
binaries on the machine which compiled Mesa
!!
docs/user/app/Application.dox
+5 -4
View File
@@ -387,10 +387,10 @@ main()
/*!
\fn BWindow* BApplication::WindowAt(int32 index) const
\brief Returns the BWindow object at the specified index in the
\brief Returns the BWindow object at the specified \a index in the
application's window list.
If index is out of range, this function returns \c NULL.
If \a index is out of range, this function returns \c NULL.
\warning Locking the BApplication object doesn't lock the window list.
@@ -520,7 +520,8 @@ main()
If the \a rate is set to 0 then the \c B_PULSE messages are not sent.
The pulse rate can be no faster than once per 100,000 microseconds or so.
\param rate The rate \a B_PULSE messages are sent to the application.
\param rate The rate at which \c B_PULSE messages are sent to the
application.
*/
docs/user/app/Handler.dox
+100 -98
View File
@@ -26,7 +26,7 @@
/*!
\def B_OBSERVE_ORIGINAL_WHAT
\brief Constant for a message data field in observer messages.
If you have called one of the flavors of BHandler::StartWachting(), and
you receive a notification, sometimes there can be send a BMessage to go
with that notification. The message you receive is a copy of that message,
@@ -52,17 +52,17 @@
\class BHandler
\ingroup app
\brief Handles messages that are passed on by a BLooper.
The BHandler class implements two important pieces of functionality. It
provides the foundations for <b>handling messages</b>, and it serves as a
<b>state machine</b> that sends out notifications of the state changes.
The most common use of this class is to <b>handle messages</b>. Handlers
can be tied to loopers, which are the objects that send and receive
messages. As soon as a message is received, the looper passes through its
list of associated handlers and tries them in a certain order until the
message is handled, or the options are exhausted.
You should know that a looper is a subclass of a handler, and as such,
loopers can be self-contained and do not need additional handlers. In many
cases, this construction will suffice. You will simply subclass the looper,
@@ -74,18 +74,18 @@
messages such as clicks are received, the window loops the handlers until
there is a handler that is at the screen position the click was in. It is
not unlikely that you will some day want to use this functionality of the
API.
API.
If your handler is limited to a certain type of messages, you can set a
filter that the looper will apply to your message before passing it on to
your overridden MessageReceived() method. The BMessageFilter class provides
the framework for the flexible filtering options, and using AddFilter() you
can apply filters to this handler. Note that a filter object should only be
applied to one handler. They cannot be shared.
For more information on the handling chain, have a look at the
documentation of the BLooper class.
Using BHandler as a <b>state machine</b> is a second area of functionality.
Since handlers process messages, and perform actions associated with those,
they are the center of keeping track on the current state of things within
@@ -93,7 +93,7 @@
parts of your application, you could perform this manually by sending
messages to the interested components, or you can use the more flexible
approach with observers.
Observers watch a certain state. A handler can track one or more different
states. Each state is represented by a four byte constant - just like the
\c what property of a message. Using the StartWatching() methods, you can
@@ -105,7 +105,7 @@
that you want to be send to the observers. This data is in the form of the
very flexible BMessage, as such you are almost free to pass anything you
want.
Whenever SendNotices() is called, all interested observers will receive a
message of the \a B_OBSERVER_NOTICE_CHANGE type. Please note that the
constant that is associated with the state itself is not transmitted. If
@@ -119,9 +119,9 @@
/*!
\fn BHandler::BHandler(const char* name = NULL)
\fn BHandler::BHandler(const char *name)
\brief Construct a new handler with a \a name.
The newly constructed handler is not associated with a looper until you
explicitly request this to happen. To associate this handler with a looper,
use BLooper::AddHandler().
@@ -131,11 +131,11 @@
/*!
\fn BHandler::~BHandler()
\brief Free the filters of this handler, as well as the list of observers.
This method does not remove the handler from the looper to which this
handler is associated. You should do this yourself, using
BLooper::RemoveHandler().
\warning This constructor does no type check whatsoever. Since you can pass
any BMessage, you should - if you are not sure about the exact type -
use the Instantiate() method, which does check the type.
@@ -145,7 +145,7 @@
/*!
\fn BArchivable *BHandler::Instantiate(BMessage *data)
\brief Static method to instantiate a handler from an archived message.
\return A pointer to the instantiated handler, or \c NULL if the \a data
is not a valid archived BHandler object.
\see BHandler(BMessage* data)
@@ -156,18 +156,19 @@
/*!
\name Archiving
BHandler inherits the BArchivable class, and as such implements support for
archiving and unarchiving handlers.
*/
//! @{
/*!
\fn BHandler::BHandler(BMessage* data)
\brief Construct a handler from an archived message.
This \a data has to be created using the BHandler::Archive() method.
Note that only the name is stored. The filters, the associated looper and
the observers are not stored, and should be manually added when you are
@@ -178,10 +179,10 @@
/*!
\fn status_t BHandler::Archive(BMessage *data, bool deep) const
\brief Archive a handler to a message
Currently, only the name is archived. The filters, the associated looper
and the observers are not stored.
\param data The message to archive the object in.
\param deep This parameter is ignored, as BHandler does not have children.
\retval B_OK Archiving succeeded.
@@ -206,13 +207,13 @@
/*!
\fn void BHandler::MessageReceived(BMessage *message)
\brief Handle a message that has been received by the associated looper.
\brief Handle \a message that has been received by the associated looper.
This method is reimplemented by subclasses. If the messages that have
been received by a looper pass through the filters, then they end up in
the MessageReceived() methods.
The example below shows a very common way to handle message. Usually,
The example below shows a very common way to handle \a message. Usually,
this involves parsing the BMessage::what constant and then perform an
action based on that.
@@ -239,13 +240,13 @@ ShowImageApp::MessageReceived(BMessage *message)
}
\endcode
If your handler cannot process this message, you should pass it on
If your handler cannot process this \a message, you should pass it on
to the base class. Eventually, it will reach the base implementation,
which will reply with \c B_MESSAGE_NOT_UNDERSTOOD.
\attention If you want to keep or manipulate the \a message, have a
look at BLooper::DetachCurrentMessage() to receive ownership of
the message.
the \a message.
\param message The message that needs to be handled.
*/
@@ -279,19 +280,19 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn void BHandler::SetNextHandler(BHandler *handler)
\brief Set the next handler in the chain that the message is passed on to
if this handler cannot process it.
if this \a handler cannot process it.
This method has three requirements:
-# This handler should belong to a looper.
-# This \a handler should belong to a looper.
-# The looper needs to be locked. See LockLooper().
-# The \a handler that you pass must be associated with the same looper.
Failure to meet any of these requirements will result in your application
crashing.
By default, the handlers are chained in order that they were associated to
a looper with BLooper::AddHander().
\see NextHandler()
*/
@@ -316,36 +317,36 @@ ShowImageApp::MessageReceived(BMessage *message)
//! @{
/*!
\fn void BHandler::AddFilter(BMessageFilter *filter)
\brief Add a filter as a prerequisite to this handler.
\brief Add \a filter as a prerequisite to this handler.
If the handler is associated with a looper, this looper needs to be locked
in order for this operation to succeed.
Note that the filter is not copied, rather a pointer to the filter is
stored. As such, you need to make sure that the filter object exists as
Note that the filter is not copied, rather a pointer to the \a filter is
stored. As such, you need to make sure that the \a filter object exists as
long as it is added to this handler.
\see RemoveFilter(), SetFilterList()
*/
/*!
\fn bool BHandler::RemoveFilter(BMessageFilter *filter)
\brief Remove a filter from the filter list.
\brief Remove \a filter from the filter list.
If the handler is associated with a looper, this looper needs to be locked
in order for this operation to succeed.
Note that the filter is not deleted, merely removed from the list. You need
to take care of the memory yourself.
\retval true The filter was in the filter list and is removed.
\retval false The filter was not found in the filter list.
Note that the \a filter is not deleted, merely removed from the list. You
need to take care of the memory yourself.
\retval true The \a filter was in the filter list and is removed.
\retval false The \a filter was not found in the filter list.
\see AddFilter(), FilterList()
*/
@@ -356,7 +357,7 @@ ShowImageApp::MessageReceived(BMessage *message)
If the handler is associated with a looper, this looper needs to be locked
in order for this operation to succeed.
The internal list will be replaced with the new list of \a filters. All the
existing filters will be \b deleted.
@@ -367,11 +368,11 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn BList *BHandler::FilterList()
\brief Return a pointer to the list of filters.
\return A pointer to the list of filters. Do not manipulate the list of
filters directly, but use the methods provided by this class, in order
to maintain internal consistency.
\see AddFilter(), RemoveFilter(), SetFilterList().
*/
@@ -384,22 +385,22 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\name Locking
This class provides some utility functions to look the looper associated
with this handler.
*/
//! @{
/*!
\fn bool BHandler::LockLooper()
\brief Lock the looper associated with this handler.
\retval true The looper is locked.
\retval false There was an error acquiring the lock.
\see LockLooperWithTimeout(), UnlockLooper()
*/
@@ -407,16 +408,16 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn status_t BHandler::LockLooperWithTimeout(bigtime_t timeout)
\brief Lock the looper associated with this handler, with a time out value.
\param timeout The time to wait for acquiring the lock in microseconds. You
may also use B_INFINITE_TIMEOUT, in which this method will wait as long
as it takes to acquire the lock.
\retval B_OK Locking succeeded.
\retval B_BAD_VALUE This handler is not associated with a looper (anymore).
\retval B_TIMED_OUT The time specified in \a timeout has passed without
locking the looper.
\see LockLooper(), UnlockLooper()
*/
@@ -463,16 +464,16 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\name Observing
Handlers can function as state machines, which emit messages to observers
when the state changes. Use the following methods to subscribe to these
notifications.
Note that there is a semantic difference between the two StartWatching()
methods. The overloaded method that accepts a BHandler, expects as
argument an \a observer that watches <em>this handler</em>. The method that
argument an \a observer that watches this handler. The method that
accepts a BMessenger, expects a \a target that emits the state changes
<em>to this handler</em>.
to this handler.
*/
@@ -483,25 +484,26 @@ ShowImageApp::MessageReceived(BMessage *message)
\fn status_t BHandler::StartWatching(BMessenger target, uint32 what)
\brief Subscribe this handler to watch a specific state change of a
\a target.
Use this method to subscribe messengers to watch state changes in <em>this
handler</em>. This means that also observers from other teams can be
Use this method to subscribe messengers to watch state changes in this
handler, this also means that observers from other teams can be
subscribed.
\code
// Handler B watches Handler A
BHandler A, B;
BMessenger messengerA(&A)
B.StartWatching(messengerA, kNetworkConnection);
// Handler B watches Handler A
BHandler A, B;
BMessenger messengerA(&A)
B.StartWatching(messengerA, kNetworkConnection);
\endcode
\param target The messenger from which the notifications would be
received.
\param what The state that needs to be watched.
\return During the call of this method, a notification will be transmitted
using the \a target. If this works, then this method will return
\c B_OK.
\see StartWatchingAll(BMessenger), StopWatching(BMessenger, uint32)
*/
@@ -509,10 +511,10 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn status_t BHandler::StartWatchingAll(BMessenger target)
\brief Subscribe this handler to watch a \a target for all events.
This method performs the same task as StartWatching(BMessenger, uint32),
but it will subscribe to all the state changes the \a target knows.
\see StartWatching(BMessenger, uint32), StopWatchingAll(BMessenger)
*/
@@ -520,10 +522,10 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn status_t BHandler::StopWatching(BMessenger target, uint32 what)
\brief Unsubscribe this handler from watching a specific state.
This method will unsubscribe this handler from watching a specific event
in a \a target.
\see StartWatching(BMessenger, uint32)
*/
@@ -531,9 +533,9 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn status_t BHandler::StopWatchingAll(BMessenger target)
\brief Unsubscribe this handler from watching all states.
This method will unsubscribe the \a target from watching all state changes.
\see StartWatchingAll(BMessenger)
*/
@@ -541,39 +543,39 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn status_t BHandler::StartWatching(BHandler* observer, uint32 what)
\brief Subscribe an \a observer for a specific state change of this handler.
Use this method to subscribe observers to watch this handler. State changes
of this handler that match the \a what argment, will be sent.
of this handler that match the \a what argument, will be sent.
\code
// Handler B wants to observe Handler A
BHandler A, B;
A.StartWatching(&B, kNetworkConnection);
// Handler B wants to observe Handler A
BHandler A, B;
A.StartWatching(&B, kNetworkConnection);
\endcode
Since pointers to handlers can only
exist in the local namespace, have a look at
StartWatching(BMessenger, uint32) for inter-team watching.
\param observer The observer for this handler.
\param what The state that needs to be watched.
\return During the call of this method, a notification will be transmitted
using the \a observer. If this works, then this method will return
\c B_OK.
\see StartWatchingAll(BHandler*), StopWatching(BHandler*, uint32)
*/
/*!
\fn status_t BHandler::StartWatchingAll(BHandler* observer)
\brief Subscribe an \a observer for a all state changes.
\brief Subscribe an \a observer for a all state changes.
This method performs the same task as StartWatching(BHandler, uint32),
but it will subscribe the \a observer to all the state changes this handler
tracks.
\see StartWatching(BHandler*, uint32), StopWatchingAll(BHandler*)
*/
@@ -591,9 +593,9 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\fn status_t BHandler::StopWatchingAll(BHandler* handler)
\brief Unsubscribe an observer from watching all states.
This method will unsubscribe the \a handler from watching all state changes.
\see StartWatchingAll(BHandler*)
*/
@@ -606,6 +608,7 @@ ShowImageApp::MessageReceived(BMessage *message)
/*!
\name Emitting State Changes
If your handler functions as a state machine, and it has observers (which
subscribed using the StartWatching() method), you can emit these state
changes.
@@ -613,12 +616,12 @@ ShowImageApp::MessageReceived(BMessage *message)
//! @{
/*!
\fn void BHandler::SendNotices(uint32 what, const BMessage *msg)
\brief Emit a state change to the observers.
The actual state (specified by \a what) will not be transmitted. This is
merely for internal bookkeeping. It is not entirely unimaginable that you
still want to inform the observers of what actually took place. You can
@@ -626,13 +629,13 @@ ShowImageApp::MessageReceived(BMessage *message)
message will be copied and slightly altered: the \c what member of the
message will be \c B_OBSERVER_NOTICE_CHANGE, and the \c what constant you
specified will be stored in the #B_OBSERVE_ORIGINAL_WHAT label.
\param what The identifier of the state.
\param msg Any data associated with the state change. You retain ownership
of this data, so make sure you dispose it when you are done.
*/
/*!
\fn bool BHandler::IsWatched() const
\brief Check if there are any observers watching this handler.
@@ -640,4 +643,3 @@ ShowImageApp::MessageReceived(BMessage *message)
//! @}
docs/user/book.css
+9 -4
View File
@@ -259,6 +259,10 @@ div.contents em, div.contents code {
font-style: normal;
}
div.contents em {
color: #dc3c01; /* grenadier */
}
div.contents code {
color: blue;
}
@@ -309,10 +313,6 @@ div.contents li {
margin-left: 20px;
}
div.contents dd {
font-size: 12px;
}
div.contents dt {
margin-top: 16px;
margin-bottom: 8px;
@@ -328,6 +328,10 @@ dl.note, dl.remark, dl.warning, dl.attention {
min-height: 48px;
}
dl.note dd, dl.remark dd, dl.warning dd, dl.attention dd {
font-size: 12px;
}
dl.note {
/* rice flower */
background:#e4ffde url('http://haiku-os.org/sites/haiku-os.org/themes/shijin/haiku-icons/alert_info_32.png') 15px 15px no-repeat;
@@ -764,6 +768,7 @@ div.memdoc dl dd table.params td.paramname {
vertical-align: top;
font-weight: normal;
font-style: normal;
color: #dc3c01; /* grenadier */
width: 157px;
}
docs/user/keyboard/US_PC_keyboard_keycodes.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 35 KiB

After

Width:  |  Height:  |  Size: 102 KiB

docs/user/locale/DurationFormat.dox
+1 -2
View File
@@ -50,8 +50,7 @@
/*!
\fn BDurationFormat&
BDurationFormat::operator=(const BDurationFormat& other)
\fn BDurationFormat& BDurationFormat::operator=(const BDurationFormat& other)
\brief Assignment overload.
\param other The BDurationFormat object to copy from.
docs/user/storage/FilePanel.dox
+1 -1
View File
@@ -62,7 +62,7 @@
/*!
\fn virtual bool Filter(const entry_ref* ref, BNode* node,
\fn virtual bool BRefFilter::Filter(const entry_ref* ref, BNode* node,
struct stat_beos* stat, const char* mimeType)
\brief Hook method that's called on each file in the target directory
displayed by a file panel.
docs/user/storage/Mime.dox
+187
View File
@@ -0,0 +1,187 @@
/*
* Copyright 2013 Haiku Inc.
* Distributed under the terms of the MIT License.
*
* Documentation by:
* Ingo Weinhold, [email protected]
* John Scipione, [email protected]
*
* Corresponds to:
* /trunk/headers/os/storage/Mime.h hrev45224
* /trunk/src/kits/storage/Mime.cpp hrev45224
*/
/*!
\file Mime.h
\ingroup storage
\brief Provides C and Haiku-only C++ MIME-type handling functions.
*/
/*!
\enum icon_size
\brief Legacy BeOS icon size constants.
*/
/*!
\var icon_size B_LARGE_ICON
32x32 "Large" icon.
*/
/*!
\var icon_size B_MINI_ICON
16x16 "Mini" icon.
*/
/*!
\var B_UPDATE_MIME_INFO_NO_FORCE
Files that already have a \c BEOS:TYPE attribute won't be updated.
*/
/*!
\var B_UPDATE_MIME_INFO_FORCE_KEEP_TYPE
Files that already have a \c BEOS:TYPE attribute will be updated too, but
\c BEOS:TYPE itself will remain untouched.
*/
/*!
\var B_UPDATE_MIME_INFO_FORCE_UPDATE_ALL
Similar to \c B_UPDATE_MIME_INFO_FORCE_KEEP_TYPE, but the \c BEOS:TYPE
attribute will be updated too.
*/
/*!
\fn status_t do_mime_update(int32 what, const char *path, int recursive,
int synchronous, int force)
\brief Helper function that contacts the registrar for mime update calls.
\param what The message identifier.
\param path The path to a file or directory, or \c NULL.
\param recursive Triggers recursive behavior if not \c NULL.
\param synchronous If not \c NULL update_mime_info() waits until the
operation is finished, otherwise it returns immediately and the
update is done asynchronously.
\param force Specifies how to handle files that already have MIME
information.
\returns A status code.
\see update_mime_info
*/
/*!
\fn int update_mime_info(const char *path, int recursive, int synchronous,
int force)
\brief Updates the MIME information (i.e MIME type) for one or more files.
If \a path points to a file, the MIME information for this file are
updated only. If it points to a directory and \a recursive is non-null,
the information for all the files in the given directory tree are updated.
If path is \c NULL all files are considered; \a recursive is ignored in
this case.
\param path The path to a file or directory, or \c NULL.
\param recursive Triggers recursive behavior if not \c NULL.
\param synchronous If not \c NULL update_mime_info() waits until the
operation is finished, otherwise it returns immediately and the
update is done asynchronously.
\param force Specifies how to handle files that already have MIME
information. See enum definitions for more information.
- \c B_UPDATE_MIME_INFO_NO_FORCE
- \c B_UPDATE_MIME_INFO_FORCE_KEEP_TYPE
- \c B_UPDATE_MIME_INFO_FORCE_UPDATE_ALL
\returns A status code. \c B_OK if everything went fine, an error code
otherwise.
*/
/*!
\fn status_t create_app_meta_mime(const char *path, int recursive,
int synchronous, int force)
\brief Creates a MIME database entry for one or more applications.
If \a path points to an application file, a MIME DB entry is create for
the application. If it points to a directory and \a recursive is not
\c NULL then entries are created for all application files in the given
directory tree. If path is \c NULL then all files are considered and
\a recursive is ignored.
\param path The path to an application file, a directory, or \c NULL.
\param recursive Trigger recursive behavior if not \c NULL.
\param synchronous Waits until the operation is finished if not \c NULL,
otherwise it returns immediately and the operation is done
asynchronously.
\param force Entries are created even if they do already exist if not
\c NULL.
\returns A status code. \c B_OK if everything went fine, an error code
otherwise.
*/
/*!
\fn status_t get_device_icon(const char *device, void *icon, int32 size)
\brief Retrieves an icon associated with a given device.
\param device The path to the device.
\param icon A pointer to a buffer the icon data shall be written to.
\param size The size of the icon to retrieve. Currently 16
(\c B_MINI_ICON) and 32 (\c B_LARGE_ICON) are supported.
\returns A status code.
\retval B_OK Everything went fine.
\retval B_BAD_VALUE \a device or \a icon was \c NULL.
\retval B_NO_MEMORY Ran out of memory allocating bitmap.
*/
/*!
\fn status_t get_device_icon(const char *device, BBitmap *icon,
icon_size which)
\brief Retrieves an icon associated with a given device into a BBitmap.
\param device The path to the device.
\param icon A pointer to a pre-allocated BBitmap of the correct dimension
to store the requested icon (16x16 for the mini and 32x32 for the
large icon).
\param which The size of the icon to retrieve. Currently 16
(\c B_MINI_ICON) and 32 (\c B_LARGE_ICON) are supported.
\returns A status code. \c B_OK if everything went fine, an error code
otherwise.
*/
/*!
\fn status_t get_device_icon(const char* device, uint8** _data,
size_t* _size, type_code* _type);
\brief Undocumented.
*/
/*!
\fn status_t get_named_icon(const char* name, BBitmap* icon,
icon_size which);
\brief Undocumented.
*/
/*!
\fn status_t get_named_icon(const char* name, uint8** _data,
size_t* _size, type_code* _type);
\brief Undocumented.
*/