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.
When the MimeUpdateThread is done, it marks itself as finished and
notifies the thread manager to clean up finished threads. Since multiple
such threads might finish at the same time and trigger the cleanup
notification, other threads that already marked themselves finished but
haven't actually exited yet might already be deleted and removed. This
would then lead to a use-after-free when they subsequently tried to send
their own cleanup message.
To solve the race condition, the thread manager will now wait for the
thread to actually exit before cleaning it up.
The introduction of the launch_daemon has made this race condition more
likely due to more applications starting in parallel, each triggering a
CreateAppMetaMimeThread which is a subclass of MimeUpdateThread. This
commit might therefore fix#12237.
* Tint the button text 1.777f which yields #303030 for the text color
which produces a nice dark grey but-not-quite-black color. In testing
black text is too dark and B_DARKEN_4_TINT (1.555f) yields #606060
which is too light. #303030 is a compromise between the two.
* The button text gets darkened to black on mouse down and the button
background gets darkened to B_DARKEN_1_TINT on hover as before, but
the frame color is no longer affected --- the button frame tinted by
B_DARKEN_1_TINT always (yielding standard Haiku button frame color).
2 concrete classes which are currently implemented:
* BSpinner (works on int32s)
* BDecimalSpinner (works on doubles)
In addition BAbstractSpinner now inherits from BControl instead of
BView/BInvoker. This allowed for code simplification at the cost of needing to
cast for the decimal version because SetValue(int32 value) comes from BControl.
Also, add a spinner_button_style enum with 3 options:
* SPINNER_BUTTON_HORIZONTAL_ARROWS
* SPINNER_BUTTON_VERTICAL_ARROWS
* SPINNER_BUTTON_PLUS_MINUS
which sets the spinner arrows to either use horizontal arrows (left/right)
vertical arrows, (up/down), or +/- symbols (the default).
If the spinner button is using horizontal arrows you can decrement and increment
the spinner value by pushing control+left/right, otherwise you can increment and
decrement by pushing up or down. The reason for needing control is so that you
can move the cursor in the textbox otherwise.
Switch the 3 apps that are currently using BSpinners to use the integer variety
in Deskbar preferences, WebPostive preferences, and Screen preferences.
This arranges the buttons to the right of the text box horizontally and also
updates the background color and arrow cool to give feed back when moused over
the button, disabled, and pressed. Used be_control_look arrows to match arrows
used elsewhere (such as scrollbars).
The background darkens on mouse over if enabled, the arrow is drawn darker when
the mouse is down, and lighter if disabled.
The environment variables were always added to the static environment
list instead of the one supplied as argument. This worked for targets,
as there the scripts are evaluated before the static environment is
used. For services and jobs this isn't the case, causing sourced
environment variables to be missing.
- Add dedicated ReportDebugger application class for the case where we're
asked to do nothing more than save a report. Also add a corresponding
UserInterface subclass whose sole purpose is to take those necessary
actions and then exit.
- When the debugger is invoked via the --save-report option, we now start
via the aforementioned report/interface rather than piggybacking on the
CLI.
- Clean up CommandLineUserInterface/CliContext to remove handling for the
report saving option.
Should hopefully resolve#12155.
