FunctionInstance:
- Add new state FUNCTION_SOURCE_SUPPRESSED. This signals that the user
explicitly forced disassembly to be loaded despite source code being
available.
LoadSourceCodeJob:
- When forced to disassembly, use the above suppressed state accordingly.
SourceView/TeamWindow/TeamDebugger:
- Adjust to take new state into account as needed.
TeamDebugInfo::GetActiveSourceCode:
- When looking at a function to decide whether to return line information
based on source or disassembly, first examine the source code state. If
the source has never been loaded for that function, but we have it available,
set it on the function at that point. This lazily addresses the fact that
LoadSourceCodeJob is called on behalf of a specific function, and
consequently only sets the source code onto that function, and not all others
present in the same file. This allows us to differentiate between the case
where a function doesn't have source code available at all, versus a function
that has simply been forced to disassembly view at this point in time.
The primary symptom of the above issue was that attempting to set a breakpoint
outside of the currently active function, but within the same file would result
in the breakpoints view indicating that the breakpoint was at line 0 rather
than the appropriate line, and breakpoints would also not be drawn in the
source view for such locations.
Thanks to Humdinger for the heads up!
* The BeBook states that any media_kit app should have BApplication
behind. Beware the app don't need to be running, but the object
should be present. This is because we use BApplication as a safe
exit point to free the memory allocated.
* While I was a bit reclutant in doing that, after a developer
discussion we agreed this would be the cleaner way to solve this
problem without eluding it.
Chunks may be physically contiguous, but virtually disjoint. Adding
physical addresses may cause ranges to be merged incorrectly.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* The BMediaClient is an higher level API to the media_kit. It
corresponds to what the layout API was for the interface_kit.
The main idea is to allow the developer concentrate only on
higher level details and avoiding handle with the tricky parts
of the media_kit. At the same time the general purpose node that
is implemented inside would allow implementing the best techniques
around thus at the same time reducing code duplication and increasing
efficiency.
* BMediaClient is WIP, this is the initial merge of the branch.
The initial development stone was set long time ago and walked
through various design/implementation phases.
* Get rid of the "Actve Sound Font:" BStringView below the BListView.
Now the selected SoundFont is the active SF.
* If there's only one SF available, select it automatically.
* Added a BStringView below the list and only give feedback when needed:
- if no SF is installed
- if the user has to select a SF
* Double-clicking an entry opens its location in Tracker.
* Added node-monitoring to live-update the list of available SFs.
Note: Un/installing a package doesn't trigger a notification (related
to #9970 ?).
Added Haiku's new forums.
Added BeBytes.
Removed GuestOne repo (can be re-added if they return).
Added empty "Bookmarks bar" folder.
Added overlay icons for the folders in "Bookmarks".
Suggested by Adrien, to make the MIDI settings more future proof when
more settings will be added, and to make manual editing less error prone.
Moved the settings from B_USER_SETTINGS_DIRECTORY/midi to
B_USER_SETTINGS_DIRECTORY/Media/midi_settings.
- Resolve symlinks to bookmarks so we display the icons for those
- Adjust the minimal height of the bar to make space for icons (if you
use a tiny font size)
- Do not allow the bookmark bar to show when it is empty
The fSource can point to a source with code inside a media plug-in (in
particular, the HTTP source from the http_streamer plugin). However,
deleting the extractor can cause the plugin to become "unreferenced" and
unloaded. If we try to call code to delete the source later, we find
that the code is already unloaded, and the app crashes.
This happens in Web+ when navigating away from Youtube or otherwise
interrupting a video while it is being played.
Fixes the crashing part of #13058.
Parsing an URL can never fail. The regexp is designed to match any
input. In the worst case, everything will end up in the "path"
component. WebPositive relies on this to generate file URLs from a plain
path.
URLs without a protocol are also possible, and can be used with an
implicit protocol. A typical example is network shares sometimes noted in
"//host.domain/path/file" form.
Add tests for these two cases and fix the parser to behave as expected.
