* The mail_daemon could have been launched too early, which caused it
not to be able to add its Deskbar icon. We don't really want a
dependency to the Deskbar, though, which is why we only run the
mail_daemon on the same event (which makes the Deskbar available
at that point).
* Ideally, the mail_daemon should be smart enough to install its Deskbar
icon once the Deskbar is available, though.
* Similar issue for the first login scripts. Here, we have a real
dependency to the Deskbar which makes the script launch once the
Deskbar is available.
* This finally fixes#12454.
* The same mechanism (and the same PostInstallScript) is used for this.
* If a file first_login exists in ~/config/settings/boot, the first-login
scripts are launched, and the file removed.
* This fixes adding the deskbar tray icons even when there is no Deskbar
running yet (for example on first boot when the FirstBootPrompt
starts), or, IOW bug #12275.
* Seems to work fine, although it should probably also be triggered when
there are still jobs in the queue -- someone more knowledgeable might
want to chime in here, please :-)
* If this turns out to be problematic, we can just drop the "on_demand"
job config again.
- Rather than depending just on mount_server's launch, instead use
a condition that waits for the volumes mounted event. Had missed
the existence of this one previously.
- Adjust launch configuration such that media_server requires mount_server.
Otherwise, if the user has specified sound files for any events that are
on non-boot disks, these won't be found/loaded properly during the boot
process.
* 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.
* 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.
* Allows to conditionally (or unconditionally) launch targets.
* Including tests for the settings parser.
* FirstBootPrompt is now launched when deemed necessary (as in
the Bootscript).
* You can now put jobs/services into a target.
* Instead of having Login started as part of the normal boot process,
it's now in the "login" target.
* The app_server now launches the login target when a login becomes
available (ie. during startup, but that could be improved later on).
* Instead of launching Tracker/Deskbar directly, we now launch the
Login application.
* This will now start a new session for the selected user (the password
is currently ignored).
* When a user session is started, the launch_daemon forks, and the
child then restarts the LaunchDaemon application in user mode.
* It then registers itself with its parent, in order to resolve user
dependent services.
* Added a user launch file that will cause Tracker, and Deskbar to
start in the new session.
* get_roster_port_name() is no longer needed.
* This also removes the app_server restart code from the debug
server -- this will be done by the launch_daemon in the future.
* Dropped "create_port" -- this is now the default for services.
* Additionally (or alternatively, if you use the "legacy" mode), you can
now create named ports, and specify their capacity.
* Added convenience methods to BLaunchRoster that automatically use the
signature of the current be_app.
* This is actually working already, although we cannot reproduce all
the features of the former Bootscript yet. This is without any
dependency support in launch_daemon.
* All shell activity like cleaning out /tmp, setting up the environment,
setting the time, etc. is not yet working.
* This will be heavily inspired by Apple's launchd, as well as
systemd -- for now it really doesn't do a whole lot, though.
* What works so far: the configuration files are read, parsed, and
the jobs created.
* The jobs are even initialized, and their message ports created.
* BApplication now retrieves a previously created port from the
launch_daemon for use with BServer.
* Only the registrar actually uses this for now.
