* This is done by watching to registrar notifications
and providing a minimal service to contact the
media roster in private API. The roster use this
service to automatically reconnect to the media_server.
* Improve consistency by adding a BMediaRosterEx destructor
and using it for the specular functionality of ctor instead
to use the father's class destructor.
* Avoid double initialization of MediaInitializer that
becomes MediaRosterUndertaker.
* Remove superfluos call to BMediaRoster::Quit()
in media_addon_server.
* Since the app_server is a BApplication, too, now, Workspaces would
trigger this problem.
* Now it checks whether the shared memory is actually set, and only
uses it in this case. This will also fix using ui_color() in any
BServer without UI connection.
* This closes #12114 again; while not POSIX, it's just a line away.
* Removed exect() from the header -- not sure where this came from.
but I can't find anything about it on the net.
* Consolidated use of asterisk style in exec.cpp.
For defining the text that appears alongside the icon.
This function really has too many parameters; we probably should break
it out into a BAction class...
* A job must not be launched when its target hasn't been launched
yet. This fixes Tracker launching when the mount_server scanned
the initial disk, even though the FirstBootPrompt was showing.
* Jobs are no longer initialized when their target has not been launched
yet. This also means that you cannot talk to a service beforehand in
this case.
* Slight refactoring and clarifying, even added some documentation :-)
* _TriggerJob() is now called _LaunchJob(), and does all the checks for
jobs that _LaunchJobs() does now for targets.
* Now inherits from BServer, and gets its message port from the
launch_daemon.
* It registers an event "initial_volumes_mounted" that allows other
services to be started afterwards.
* This is now used in the boot launch files, and makes the scripting
based previous solution superfluous which has been removed with this
commit, too.
* This implements the last needed feature in order to reproduce the
complete former boot process using the launch_daemon.
* When the thread is started during the construction of the base
class, the virtual method table may still point to the methods
of the base class when the thread actually starts to run.
* This caused the main worker to have a timeout, which could
eventually be reached which in turn caused all job processing
to stop.
* That's what you get when you do Java all day; whoever designed
C++ should be slapped (I'm talking to you, Bjarne).
* Scripts from targets are evaluated once on first target launch,
scripts from jobs are evaluated on each start.
* The "desktop" target now sources SetupEnvironment as usual.
