In hrev49481, the call to AddCommonFilter was accidentally
removed, preventing SetShortcut() from working. The filter
has also been updated to enumerate all buttons, rather than
a maximum of the first three.
Replace avcodec_encode_audio with avcodec_encode_audio2. The latter
provides us with more information on the encoded data, so we can avoid
guessing things on our own. It also handles memory allocations on its
own, which fix some cases where we would provide a too small buffer.
The POSIX standard requires us to allow assert.h to be included multiple
times with differnt values of NDEBUG. So we can't have a global header
guard on the files. However, we must also make sure that we don't
declare functions multiple times in that case. Re-introduce an header
guard on the part of the file where we declare functions, only.
Fixes lots of warnings when building Netsurf.
It waits for the message port of each application to become available
using waitfor and then waits for the application to actually reply
using hey. This establishes the criterion of the boot process being
complete as "all servers (and Tracker & Deskbar) are started and
respond to messages".
This can be used by scripts to do verious performance measurements.
Specifically it can be used to measure the boot time since it represents
the uptime.
Since hrev49481, BAlert sets its default button in Go(), and not in the
constructor. So DefaultButton() will return NULL if Go() hasn't been called
yet.
Moreover, BAlert now centers itself on screen in Go() and not in the costructor,
so move it away from screen after the Go() call.
Fixes#12271, although there should be a nicer way to implement this.
A KMessage request always needs to be honoured, regardless of the data
size.
KMessage does not currently protect against messages that are too large,
but this needs to be solved in KMessage when it becomes a problem.
Long application signatures and paths could previously take up too much
space, causing the buttons to be cut off or become completely invisible.
Actually fixes#11367.
The application is now launched suspended and the ports are created
and transferred to the launched team before its main thread is
resumed.
The ports are therefore owned by the launched team instead of the
launch_daemon. This is important when sending messages by area, as
the port owner is used to determine where the data area needs to be
transferred to. This commit therefore fixes#12285.
Note that it is still possible to get at the ports with find_port()
while they are still owned by the launch_daemon. This should not be a
problem however, as these ports are not supposed to be found this way
but only through BLaunchRoster::GetData(), which is synchronized with
the above process.
Creating the ports in the launch_daemon still has the benefit of
returning valid communication ports earlier, i.e. without having to
wait for the launched application to actually become ready.
It allows to launch the app, but keep its main thread suspended instead
of automatically resuming it.
Also add appThread argument which allows to retrieve the main thread of
the launched team.
* TRANSITION_... was incorrectly changed from the original patch.
* Divided it into two constants, and also prefixed the new constants with
the register fields they are valid for.
* Fixed incorrect usage of |= and removed the corresponding TODO comments.
* Moved some reoccurring code into their own methods.
* Added check for the ST bit in the command register for the interrupt
hard reset, too.
* This closes ticket #12295, thanks Anarchos!
Previously the LaunchDaemon would send out its own team id when a given
job was not yet launched, leading to invalid BMessengers once the port
owner changed to the actually launched team.
The launch of the target team and the launch data replies were also not
synchronized, which could lead to the launched team getting a reply
pointing to the launch_daemon when requesting data for itself. This is
the case for the BRoster init of the registrar. The fix in hrev49561
therefore didn't always work, because the registrar would sometimes get
the launch_daemon team id instead of the id of itself. It would later
try talking to the launch_daemon, which obviously never replied, leading
to #12237.
The LaunchDaemon now delegates the launch data reply to the Job instead.
The Job either replies directly, in case it has already been launched,
or queues the reply for when the launch completes. This causes launch
data requesters to block until the launch attempt is completed, but
won't block the LaunchDaemon message loop.
This commit introduces the seperate fLaunchStatus to properly handle the
ambiguity of fTeam being < 0, which is the case for both, when no launch
was attempted and when the launch failed. This new field now determines
what IsLaunched() returns and how launch data replies are handled.
The new launch status is additionally protected by the launch status
lock, which will later probably be made broader in scope to protect
against race conditions once service monitoring is implemented.
Renamed box label from "SoundFont" to "Available SoundFonts", hopefully
improves the user experience by making it clearer that this is a list
of the available soundfonts.
When no midi settings file was available, BSoftSynth should use the well known
TimGM6mb.sf2 soundfont. This wasn't working, since the code looked in the wrong
path (we have to append "synth" to the path returned by find_directory).
In case this SF is not present, now we try harder not to fail, and look for any
soundfont available in the system and user directories.
Fixes ticket #12325 although the selected soundfont is not written to the
user settings file.
The extra quotes aren't needed and cause problems when not parsed
through a shell. For example LD_PRELOAD which is handled by the
runtime_loader directly failed to work as there was no way to remove
the extra single quotes.
Note that quotes and single quotes can still be added to the variables
through respective quoting in the driver settings syntax.
Previously the thread member was overwritten with the freeing thread
when a page was freed, leading to confusion when hitting unallocated
pages due to the debugger message still stating "allocated by thread".
Track the freeing thread separately as it might be interesting to know
both, which thread initially allocated and which thread eventually freed
an allocation.
