Source Activity

Syndicate content
Haiku's main repository
Updated: 58 min 35 sec ago

Midi: Remove some duplicated code

Thu, 2015-08-27 09:48
Introduced new private read/write_midi_settings() and used them in MidiSettingsView and SoftSynth. Introduced new private read/write_midi_settings() and used them in MidiSettingsView and SoftSynth.
Categories: Development

Revert accidental addition to Jamfile.

Wed, 2015-08-26 19:54
Categories: Development

launch_daemon: Delegate launch data replies to Job.

Wed, 2015-08-26 19:39
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. 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.
Categories: Development

BRoster: Apply no-registrar mode in a few more cases.

Wed, 2015-08-26 19:33
Avoids some more attempts at communicating with the registrar if the no-registrar flag has been set. Avoids some more attempts at communicating with the registrar if the no-registrar flag has been set.
Categories: Development

Revert "MediaNode: Wait for 0 time if the absolute timeout is in the past"

Wed, 2015-08-26 18:53
This reverts commit ae9cbf9c4e167470b47964059e90c2b0881367eb. * Thanks to Pawel Dziepak for reporting! This reverts commit ae9cbf9c4e167470b47964059e90c2b0881367eb. * Thanks to Pawel Dziepak for reporting!
Categories: Development

Screen: Rework AlertView to just use BAlert.

Wed, 2015-08-26 18:36
Fixes #12330. Fixes #12330.
Categories: Development

docs/user: BAlert: Fix incorrect ::TextView() docs.

Tue, 2015-08-25 14:25
TextView() returns *the* BTextView the BAlert is using, not a new TextView with the contents of the BAlert (which is what this seemed to imply). TextView() returns *the* BTextView the BAlert is using, not a new TextView with the contents of the BAlert (which is what this seemed to imply).
Categories: Development

radeon_hd: Add missing id for Radeon HD 8490

Tue, 2015-08-25 10:38
Categories: Development

B_BIG_SYNTH_FILE and B_LITTLE_SYNTH_FILE are deprecated.

Mon, 2015-08-24 15:18
Small style change in midi headers. Small style change in midi headers.
Categories: Development

MidiSettingsView: renamed box label

Mon, 2015-08-24 08:23
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. 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.
Categories: Development

BBitmap: Archive the data also if "deep" is not set

Mon, 2015-08-24 08:21
Fixes #12326 Fixes #12326
Categories: Development

BSoftSynth: Fixed auto selection of soundfont.

Mon, 2015-08-24 08:04
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. 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.
Categories: Development

Improved comment. Added TODO

Mon, 2015-08-24 08:03
Categories: Development

Fix naming

Mon, 2015-08-24 07:33
Categories: Development